Kimi-K2-Hardware-Anforderungen: K2.6, K2-Thinking und K2-Instruct auf H200 NVL und RTX PRO 6000

Kimi-K2-Hardware-Anforderungen im Oktober 2026

Die Hardware-Anforderungen der aktuellen Kimi-K2-Modelle beginnen bei einem Server mit acht H200 NVL. Kimi-K2.6 und Kimi-K2-Thinking erscheinen mit nativen INT4-Gewichten von etwa 595 GB. Das Kimi-K2-Thinking-Rezept von vLLM, ausgeführt auf acht H200 mit je 141 GB, meldet KV-Cache für etwa 21 Gespräche mit 32.768 Token bei Tensor-Parallelismus und für etwa 174 mit Decode Context Parallelism, sodass sowohl 20 als auch 100 gleichzeitige Nutzer Platz haben. Unsere eigene Regel ergibt für acht H200 NVL etwa 25 und 200; wir planen mit den niedrigeren Werten des Rezepts.

Acht RTX PRO 6000 fassen die INT4-Gewichte ebenfalls, doch kein Dokument von Moonshot AI oder vLLM, das wir gefunden haben, betreibt Kimi K2 auf dieser Karte. Das ältere Kimi-K2-Instruct-0905 hat in FP8 1.029 GB und lässt acht H200 NVL Platz für höchstens ein Gespräch. Vier DGX Spark (128 GB) sind zu klein für die Checkpoints, die Moonshot AI und NVIDIA veröffentlichen.

Das sind unsere Schätzungen für Hardware, die wir liefern: die DGX Spark Founders Edition (128 GB Unified Memory), die RTX PRO 6000 (96 GB, PCIe) und die H200 NVL (141 GB, NVLink-Brücken für zwei oder vier Karten). Unser Überblick über LLM-Hardware-Anforderungen je Modell wendet dieselbe Methode auf andere Modellfamilien an.

Kimi-K2-Modelle auf Hugging Face: K2.6, K2-Thinking und K2-Instruct

Stand 9. Oktober 2026 führt die Hugging-Face-Organisation moonshotai Kimi-K2-Instruct mit seinem Update 0905, Kimi-K2-Thinking, Kimi-K2.5, Kimi-K2.6 und Kimi-K2.7-Code. Alle haben 1T Parameter insgesamt und 32B aktivierte, 61 Layer und 384 Experten, von denen je Token 8 ausgewählt werden. Die Card von K2.6 gibt an, dass das Modell, in deutscher Übersetzung, „dieselbe Architektur wie Kimi-K2.5 hat“, ergänzt den Vision-Encoder MoonViT mit 400M Parametern und nennt eine Kontextlänge von 256K. Die Card von K2.7-Code beschreibt, ebenfalls übersetzt, „ein auf Programmierung ausgerichtetes agentisches Modell, das auf Kimi K2.6 aufbaut“, mit derselben Architektur; die Werte von K2.6 unten gelten nach unserer Lesart also auch dafür.

Model Cards, Dateilisten (Summe der safetensors-Shards) und config.json-Dateien auf Hugging Face, abgerufen am 9. Oktober 2026; 256K sind 262.144 Token in der config.json von K2.6. K2.5 und K2.7-Code teilen die Architektur von K2.6; ihre Dateien haben wir nicht summiert.

Die Card von K2-Thinking erklärt die INT4-Gewichte, in deutscher Übersetzung: „Wir setzen in der Post-Training-Phase Quantization-Aware Training (QAT) ein und wenden eine reine INT4-Gewichtsquantisierung auf die MoE-Komponenten an“. K2.6 „übernimmt dieselbe native int4-Quantisierungsmethode“, und seine config.json quantisiert die linearen Layer in Blöcken zu 32 auf 4-Bit-Ganzzahlen und hält Attention, den Shared Expert, den dichten ersten Layer und den Output-Head in 16 Bit. Die Card von 0905 gibt an, dass seine Checkpoints „im block-fp8-Format gespeichert sind“ und dass sein Kontextfenster „von 128k auf 256k Token erweitert wurde“.

NVIDIAs NVFP4-Version von K2.6 quantisiert, übersetzt, „nur die Gewichte und Aktivierungen der linearen Operatoren innerhalb der Transformer-Blöcke im MoE“. Ihre Card führt NVIDIA Blackwell, nennt die B200 als Testhardware und startet vLLM mit --tensor-parallel-size 4. Das neuere Kimi-K3 von Moonshot AI, mit 2,8T Parametern, davon 104B aktiv, MXFP4-Gewichten und 1M Kontext, ist eine andere Architektur unter einer eigenen Kimi K3 License und nicht Gegenstand dieses Artikels.

KV-Cache je Gespräch: Latent Attention in Kimi K2

Unsere Dimensionierungsregel, erklärt in unserem Leitfaden dazu, wie viel VRAM ein LLM braucht, gibt Gewichten und Cache 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB je Karte: 83,0 GiB je RTX PRO 6000 und 123,4 GiB je H200 NVL. Für einen DGX Spark (128 GB) setzen wir 102 GB je System an. Der Cache ist in 16 Bit gerechnet, wie in vLLM voreingestellt, weil die Befehle von vLLM für Kimi-K2-Thinking auf der H200 keinen Cache-Typ setzen.

Kimi K2 nutzt die Multi-Head Latent Attention (MLA) von DeepSeek-V3: Der Textabschnitt seiner config.json nennt die Architektur DeepseekV3ForCausalLM mit einem kv_lora_rank von 512 und einem qk_rope_head_dim von 64. Jeder der 61 Layer speichert je Token 576 Werte, das ergibt in 16 Bit 68,6 KiB je Token, 2,14 GiB je Gespräch mit 32K, 8,6 GiB bei 128K und 17,2 GiB bei den vollen 262.144 Token. Ein FP8-Cache, den das K2.6-Rezept von vLLM auf seinem B300-Pfad setzt, senkt diese Werte auf etwa die Hälfte.

Der vLLM-Blogbeitrag vom 7. August 2026 zu Decode Context Parallelism hält fest, in deutscher Übersetzung: „Bei normalem TP gibt es nichts, was sich nach Heads aufteilen ließe; der latente KV-Cache wird also vollständig auf jeden TP-Rank repliziert.“ Bei Tensor-Parallelismus vergleichen wir deshalb den Cache eines Gesprächs mit dem freien Speicher einer Karte. Drei Anordnungen teilen den Cache stattdessen auf. Pipeline-Parallelismus (PP) gibt jeder Karte nur den Cache ihrer eigenen Layer. Decode Context Parallelism (DCP), gesetzt mit --decode-context-parallel-size bis zur Größe des Tensor-Parallelismus, kann laut vLLM, übersetzt, „den KV-Cache nach der Sequenz- bzw. Kontextdimension auf die GPUs aufteilen“. Mit datenparalleler Attention (DP) hat laut der Dokumentation von vLLM „jede DP-Engine einen eigenen KV-Cache“ (übersetzt), aber jede Karte wiederholt die Attention und die übrigen Gewichte außerhalb der Experten; DP haben wir für Kimi K2 nicht dimensioniert. Unser Artikel zu Long-Context-LLM-Hardware vergleicht diese Anordnungen bei anderen Modellen.

Karten für 1, 20 und 100 gleichzeitige Nutzer

Unsere Schätzungen, keine Messungen, für 1, 20 und 100 Gespräche mit je 32.768 Token und 16-Bit-Cache, auf 1, 2, 4 oder 8 Karten oder bis zu vier DGX Spark (128 GB), nur ob der Speicher reicht; Tensor-Parallelismus über alle Karten oder Decode Context Parallelism (DCP), wo die Zelle es angibt. Kein Dokument von Moonshot AI oder vLLM betreibt Kimi K2 auf der RTX PRO 6000; FP8 auf acht H200 NVL ist knapp, siehe Text.

Die INT4-Gewichte belegen 554,3 GiB, auf acht Karten 69,3 GiB je Karte. Vier H200 NVL stellen nach unserer Regel 493 GiB bereit und vier RTX PRO 6000 332 GiB, deshalb brauchen beide Kartentypen acht. Acht RTX PRO 6000 lassen etwa 13,8 GiB je Karte, Platz für sechs Gespräche mit 32K bei Tensor-Parallelismus, 12 mit zwei Pipeline-Stufen und etwa 51 mit -dcp 8, sodass hundert Nutzer mindestens zwei solche Server mit DCP brauchen. Diese RTX-Werte sind Obergrenzen, denn auf acht H200 lässt das Rezept von vLLM je Karte etwa 7,4 GiB weniger Cache als unsere Regel, und derselbe Fehlbetrag würde den freien Speicher einer RTX PRO 6000 halbieren. Der DCP-Blog von vLLM nennt außerdem, übersetzt, „die Unterstützung auf eine größere Vielfalt von Backends auszuweiten“ als weitere Arbeit; testen Sie DCP also auf dieser Karte, bevor Sie danach dimensionieren. Acht H200 NVL lassen nach unserer Regel 54,1 GiB je Karte, etwa 25 Gespräche mit 32K bei Tensor-Parallelismus, 50 mit zwei Pipeline-Stufen und etwa 200 mit DCP.

Kimi-K2-Instruct-0905 belegt in FP8 958,5 GiB, auf acht H200 NVL 119,8 GiB je Karte. Das liegt etwa 20,6 GiB unter den 140,4 GiB, die der Treiber meldet, lässt aber innerhalb unserer Regel nur 3,6 GiB je Karte, ein Gespräch mit 32K oder etwa 13 mit DCP. Mit dem Fehlbetrag von 7,4 GiB aus dem K2-Thinking-Rezept bliebe bei der voreingestellten Speichereinstellung von vLLM kein Cache übrig. Der Deployment-Leitfaden von Moonshot AI hält fest, in deutscher Übersetzung: „Die kleinste Bereitstellungseinheit für die FP8-Gewichte von Kimi-K2 mit 128k seqlen auf einer gängigen H200- oder H20-Plattform ist ein Cluster mit 16 GPUs“. Für ein Team mit dem FP8-Modell sind zwei Server mit acht Karten das Minimum; K2.6 in INT4 bedient dieselben Zahlen auf einem.

Wir bauen Inferenz-Server mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Nennen Sie uns die Kimi-K2-Variante, die Sie betreiben wollen, mit Kontext und Nutzerzahl in der Spitze, und wir antworten mit Konfiguration und Angebot.

Kimi K2 auf acht H200 NVL: was die vLLM-Rezepte setzen

Das Kimi-K2-Thinking-Rezept von vLLM, aktualisiert am 17. April 2026, nennt als Hardware acht H200- oder acht H20-GPUs („8x H200 or 8x H20 GPUs“). Sein Befehl für niedrige Latenz nutzt --tensor-parallel-size 8, und sein Befehl für hohen Durchsatz ergänzt --decode-context-parallel-size 8. Das Rezept hält fest, übersetzt: „DCP multipliziert die Größe des GPU-KV-Cache mit dcp_world_size“, und meldet aus seinem Benchmark auf acht H200 einen Cache von 715.072 Token bei Tensor-Parallelismus und 5.721.088 Token mit DCP. Das sind etwa 21 und 174 Gespräche mit 32K, aus 46,8 GiB Cache je Karte, etwa 7,4 GiB weniger, als unsere Regel lässt. Nach unserer Lesart ist der Unterschied Laufzeitspeicher, den vLLM beim Start misst und den unsere pauschale Reserve von 3 GiB nicht abdeckt; deshalb planen wir mit den Werten des Rezepts, wo es welche nennt. Bei den vollen 262.144 Token bedeuten sie zwei Gespräche bei Tensor-Parallelismus und 21 mit DCP.

Das K2.6-Rezept, aktualisiert am 29. Juli 2026, nennt für den INT4-Checkpoint, übersetzt, „8× H200-GPUs (verifiziert) oder gleichwertigen aggregierten VRAM (~640 GB)“. Seine Option für CPU-Offload erweitert den Präfix-Cache mit SimpleCPUOffloadConnector in den Host-DRAM und „nutzt standardmäßig 220 GiB je Rank“. Nach unserer Lesart ist das ein Cache zur Wiederverwendung, der Prefill-Zeit spart, den längsten Kontext aber nicht erhöht, und acht Ranks würden mit der Voreinstellung nach unserer Rechnung 1.760 GiB Serverspeicher belegen.

Die Rezepte nennen den Formfaktor ihrer H200 nicht. Die H200 NVL hat dieselben 141 GB, und in einem Server mit acht Karten bilden ihre Brücken zwei NVLink-Domänen zu je vier Karten, die über PCIe verbunden sind, wie unser Leitfaden dazu, wie viele H200 NVL große Modelle brauchen erklärt. Tensor-Parallelismus über acht Karten läuft dann zwischen den Domänen über PCIe. Vierfacher Tensor-Parallelismus in jeder Domäne mit zwei Pipeline-Stufen hält den Verkehr je Layer auf NVLink und halbiert den Cache je Karte, was den Tensor-Parallel-Wert des Rezepts nach unserer Schätzung auf etwa 43 Gespräche mit 32K verdoppelt. Acht H200 NVL mit bis zu 600 W je Karte ziehen 4,8 kW, ohne Prozessoren, Arbeitsspeicher und Lüfter.

Wir bauen Server mit acht H200 NVL und ihren NVLink-Brücken und prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie Ihren Rack-Standort und seine Stromversorgung im Formular unten.

Kimi K2 auf RTX PRO 6000 und DGX Spark

Acht RTX PRO 6000 haben 768 GB, mehr als die „~640 GB“ aggregierten Speichers, die das K2.6-Rezept nennt. Der INT4-Checkpoint nutzt das Format „pack-quantized“ von compressed-tensors; testen Sie die Engine und ihre Kernel also auf der RTX PRO 6000, bevor Sie einen Server danach dimensionieren. Die RTX PRO 6000 rechnet FP4 auf ihren Blackwell-Tensor-Cores, was zu NVIDIAs NVFP4-Version passt, doch NVIDIA hat diese Version auf der B200 getestet, einer anderen Blackwell-GPU.

Die Karten sind nur über PCIe verbunden, deshalb schickt Tensor-Parallelismus über acht Karten den Austausch jedes Layers über PCIe. Unser Artikel zu Tensor-, Pipeline- und Experten-Parallelismus über PCIe und NVLink behandelt die Verbindung und die Peer-to-Peer-Einstellungen. Bei 262.144 Token braucht ein Gespräch bei Tensor-Parallelismus 17,2 GiB auf jeder Karte, mehr als die verbleibenden 13,8 GiB, deshalb braucht ein Gespräch mit voller Länge auf acht RTX PRO 6000 zwei Pipeline-Stufen oder DCP.

Der DGX Spark fasst die veröffentlichten Kimi-K2-Checkpoints nicht. Vier Spark-Systeme stellen nach unserer Regel 408 GB bereit, gegenüber etwa 595 GB INT4-Gewichten. Die Card von K2.6 führt außerdem die Engine KTransformers, und Quantisierungen aus der Community mit weniger Bits je Gewicht sind kleiner; beides haben wir nicht dimensioniert.

Modified MIT License und Umgang mit Daten

Moonshot AI veröffentlicht den Code und die Gewichte der Kimi-K2-Modelle in diesem Artikel unter einer Modified MIT License. Ihre einzige Änderung greift, wenn die Software oder ein abgeleitetes Werk in kommerziellen Produkten oder Diensten genutzt wird, die mehr als 100 Millionen monatlich aktive Nutzer haben oder eine in der Lizenz genannte monatliche Umsatzschwelle überschreiten. Solche Produkte müssen den Modellnamen, in der Lizenz von K2.6 „Kimi K2.6“, auf ihrer Benutzeroberfläche deutlich sichtbar anzeigen. Im Übrigen gelten die MIT-Bedingungen. NVIDIAs NVFP4-Version unterliegt der NVIDIA Open Model License, mit der Modified MIT License als zusätzlicher Information. Ein Modell, das aus heruntergeladenen Gewichten auf Ihren eigenen Servern läuft, sendet keine Prompts oder Ausgaben an Moonshot AI. Ob eine Klausel Ihr Unternehmen betrifft, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir liefern

Wir liefern die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken, die RTX PRO 6000 als Workstation, Max-Q und Server Edition sowie die DGX Spark Founders Edition. Sie kommen als Karten für einen Server, den Sie bereits betreiben, oder in nach Auftrag gebauten KI-Servern, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Konfiguration und Angebot erhalten Sie innerhalb eines Werktages, und unser Sortiment professioneller GPUs führt jede Karte. Kimi K2 mit vLLM auf diesen Servern bereitzustellen ist Teil unserer Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ