Ein 600-GB-LLM auf zwei Servern mit je vier NVIDIA RTX PRO 6000 Blackwell Server Edition

Zwei Server mit vier Karten für ein Modell mit 600 GB

Ein Modell mit etwa 600 GB, etwa Kimi-K2.6 oder Kimi K2.7-Code in INT4, läuft verteilt auf zwei Server mit je vier NVIDIA RTX PRO 6000 Blackwell Server Edition. Nach unserer Regel für Nutzer je Karte halten die acht Karten 664,3 GiB für Gewichte und Cache bereit; die 554,3 GiB Gewichte lassen 13,8 GiB je Karte frei. vLLM teilt das Modell in zwei Pipeline-Stufen, eine je Server, mit Tensor-Parallelismus über die vier Karten in jedem, und über das Netzwerk gehen nur die Aktivierungen an der Grenze zwischen den Stufen.

Die Aufteilung funktioniert und kostet dreierlei: ein RDMA-Netzwerk zwischen den Servern, eine Cluster-Laufzeit, die beide Hälften zusammen startet, und eine Ausfalldomäne über beide Hosts. Es passt an einen Standort, an dem ein Gehäuse mit acht Karten nicht zur Stromversorgung des Racks oder zum Raum passt, oder wo zwei Server mit vier Karten schon stehen. Unser Vergleich ein 8-GPU-Server oder zwei 4-GPU-Server behandelt die allgemeine Wahl, unser Leitfaden zum GPU-Inferenz-Cluster ohne InfiniBand die Netzwerkmuster; diese Seite rechnet ein Modell dieser Größe auf diesem Paar durch.

Welche Modelle mit etwa 600 GB auf zwei Server mit vier Karten passen

Unsere Regel für Nutzer je Karte nimmt 90 Prozent der 95,6 GiB, die der Treiber meldet, und zieht 3 GiB je Karte ab, 83,0 GiB je Karte. Vier Karten ergeben 332,2 GiB, zwei Server 664,3 GiB.

Dateilisten auf Hugging Face (Kimi K2.7-Code, Muse Spark Open NVFP4 und GLM-5.3 NVFP4 am 24. Oktober 2026 aufsummiert; die übrigen aus unseren Modell-Leitfäden, gelesen vom 9. bis 24. Oktober 2026); Rest je Karte nach unserer Regel, unsere Rechnung.

Kimi-K2.6 und K2.7-Code haben dieselbe Architektur und dieselbe Checkpoint-Größe von 595,2 GB, die Werte unten gelten also für beide. GLM-5.3 in NVIDIAs NVFP4-Version hat mehr Platz je Karte, und unser Beitrag zu GLM-5.3 NVFP4 auf acht Server-Edition-Karten dimensioniert es; die Speicherwerte gelten auf zwei Servern genauso. Muse Spark Open in NVFP4 hält einen Grouped-Query-Cache, der sich anders als der Latent-Cache von Kimi in dieser Aufteilung auf alle acht Karten verteilt: nach unserer Schätzung etwa 71 Gespräche mit 32K bei 16-Bit-Cache, wie unser Leitfaden zu Muse Spark Open für einen Server mit acht Karten rechnet, und das vLLM-Rezept für das Modell nennt „TP + PP“ unter den Aufteilungen, die NVIDIA unterstützt.

vLLM-Aufteilung: TP=4 in jedem Server, zwei Pipeline-Stufen

vLLMs Dokumentation zu Parallelismus und Skalierung, aktualisiert am 15. Oktober 2026, gibt die Regel vor: „Set tensor_parallel_size to the number of GPUs per node and pipeline_parallel_size to the number of nodes.“ Für zwei Server mit vier Karten heißt das --tensor-parallel-size 4 --pipeline-parallel-size 2. Jeder Server hält die Hälfte der Schichten. Die vier Karten eines Servers teilen jede Schicht und tauschen Teilergebnisse über PCIe aus, wie in einem einzelnen Server mit vier Karten; unser Vergleich von TP=2, TP=4 und Replikaten ohne NVLink behandelt diesen Verkehr.

vLLM betreibt das entweder auf einem Ray-Cluster oder mit seinem eigenen Multiprocessing-Backend. Für das zweite startet die Dokumentation auf beiden Servern denselben Befehl vllm serve mit --nnodes 2, --node-rank 0 oder 1 und --master-addr auf den ersten Server und ergänzt auf dem zweiten --headless. Sie verlangt, dass „every node provides an identical execution environment, including the model path and Python packages“; beide Server tragen also dasselbe Image und eine lokale Kopie des Checkpoints mit 595 GB im selben Pfad.

Tensor-Parallelismus über alle acht Karten beider Server ist die andere Option der Dokumentation, die warnt: „Efficient tensor parallelism requires fast internode communication“. Er würde je Schicht zwei All-Reduces, bei Kimi K2 über 61 Schichten, für jedes Token über das Netzwerk schicken. NVIDIAs eigene Evaluation seines NVFP4-Checkpoints von GLM-5.3 nutzte „tensor parallelism 8 across two 4-GPU nodes“ auf B300-Hardware, und die Model Card beschreibt das Netzwerk nicht. Über Ethernet zwischen zwei Server-Edition-Servern planen wir mit Pipeline-Stufen.

Was über das Netzwerk geht, und wie viel

Bei einer Pipeline-Aufteilung gehen Hidden State und Residual jedes Tokens über die Stufengrenze. Unser Leitfaden zu Clustern ohne InfiniBand rechnet das für DeepSeek-V3.2 in vLLM vor, und Kimi K2 hat dieselbe Textarchitektur von DeepSeek-V3 mit einer Hidden Size von 7.168 in seiner config.json: zwei Tensoren mit 7.168 Werten in BF16, 28 KiB je Token.

Unsere Rechnung bei Leitungsrate, ohne Protokoll-Overhead und Switch-Latenz: 28.672 Byte je Token (2 × 7.168 × 2 Byte); 65.536 × 28.672 Byte = 1,88 GB; 32 × 28.672 Byte = 0,92 MB.

Die Datenmenge ist überschaubar. Eine Verbindung mit 200 Gb/s trägt 25 GB/s, gegenüber 64 GB/s je Richtung für einen Steckplatz mit PCIe 5.0 x16 im Server, und ein langer Agenten-Prompt kostet an der Grenze einige zehn Millisekunden. Was das Netzwerk hinzufügt, ist eine feste Verzögerung bei jedem Decode-Schritt, weil jedes Token beide Server nacheinander durchläuft. Eine Pipeline-Aufteilung macht eine einzelne Anfrage auch nicht schneller, als ein Server sie machen könnte: Nach unserem Verständnis bringt der zweite Server Speicher und lässt vLLM mehr Anfragen gleichzeitig bearbeiten, während jedes Token weiterhin alle Schichten nacheinander durchläuft.

NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems, zuletzt aktualisiert am 30. September 2026, setzt die Untergrenze für das Netzwerk: „Minimum 200 Gbps for multi-node inference“, wobei „multiple nodes are connected with high-speed networking (either InfiniBand or RoCE)“. Er verlangt außerdem: „NICs and NVMe drives should be placed within the same PCIe switch or root complex as the GPUs“. Für zwei Server mit vier Karten setzen wir je Server einen oder zwei Ports mit 200 oder 400 GbE für die Ost-West-Verbindung ein, neben den 25-GbE-Ports für Nutzer und das Laden von Modellen.

Wir bauen beide Server nach Auftrag mit den NICs für die Stufenverbindung und prüfen vor dem Angebot die Anordnung am PCIe-Bus; schicken Sie uns Modell, Kontext und die Stromanschlüsse Ihres Racks, und unser Team antwortet mit der Konfiguration für einen oder zwei Server.

Gespräche auf dem Paar, verglichen mit einem Server mit acht Karten

Pipeline-Stufen teilen auch den Cache. Jede Karte hält den Cache nur für die Schichten ihrer Stufe, ein Kimi-Gespräch mit 32K, in 16 Bit 2,14 GiB, kostet in zwei Stufen mit 31 und 30 Schichten also etwa 1,09 GiB je Karte, gegenüber 2,14 GiB auf jeder Karte bei Tensor-Parallelismus über acht. Unser Leitfaden zu den Hardware-Anforderungen von Kimi K2 leitet den Cache aus der config.json her.

Unsere Schätzungen per Rechnung, keine Messungen: Kimi-K2.6 oder K2.7-Code in INT4, 13,8 GiB Cache je Karte, Gespräche in voller Länge, ganze Zahlen abgerundet; FP8-Cache mit 576 statt 1.152 Byte je Schicht, einem Byte je Latent-Wert, so wie vLLM 0.32.0 einen dichten MLA-Cache bemisst und wie in unserem Leitfaden zu Kimi K2.7-Code. DCP: Decode Context Parallelism, das den Cache jedes Gesprächs nach Token auf die Karten verteilt.

Vom Speicher her entspricht das Paar einem Server mit acht Karten in derselben Aufteilung mit zwei Stufen. Der Unterschied ist Decode Context Parallelism. vLLMs Blog vom 7. August 2026 beschreibt es für Latent-Attention-Modelle wie Kimi K2.6, mit der Bedingung, dass die Tensor-Parallel-Größe mindestens die DCP-Größe erreicht; in einem Server mit acht Karten hebt TP=8 mit DCP 8 den Wert nach unserer Schätzung auf etwa 51 Gespräche mit 32K. Über zwei Server könnte DCP nur innerhalb jeder Stufe mit vier Karten laufen, und der Blog behandelt es nicht zusammen mit Pipeline-Parallelismus; für das Paar rechnen wir deshalb nicht damit. Behandeln Sie alle diese Werte als Obergrenzen: Auf acht H200 ließ vLLMs Kimi-Rezept etwa 7,4 GiB je Karte weniger Cache als unsere Regel.

Ausfalldomäne, Start und Sicherheit

Beide Server tragen ein Modell; fällt einer der beiden Hosts aus, steht es also, wie beim Ausfall eines einzelnen Servers mit acht Karten. Auch ein Firmware-Update, ein Treiberwechsel oder ein Kernel-Neustart auf einem Server hält den Dienst an, und auf beiden Servern muss dieselbe vLLM-Version laufen. Ein Dienst, der einen Host-Ausfall überstehen muss, braucht eine zweite Kopie des Modells auf anderen Servern; unser Leitfaden zur Hochverfügbarkeit für LLM-Inferenz auf zwei Knoten beschreibt Replikate hinter einem Load Balancer für Modelle, die in einen Server passen.

Die Stufenverbindung gehört in ein eigenes Netzwerk. vLLMs Dokumentation verlangt, VLLM_HOST_IP auf eine Adresse in einem privaten Netzwerk zu setzen, und hält fest, dass der Verkehr darin unverschlüsselt ist; halten Sie Unbefugte aus diesem Netzwerk heraus. Prüfen Sie vor dem ersten Lasttest, ob NCCL RDMA nutzt: Starten Sie vLLM mit NCCL_DEBUG=TRACE und suchen Sie im Log nach [send] via NET/IB/GDRDMA; [send] via NET/Socket bedeutet einfaches TCP, das die Dokumentation „not efficient for cross-node tensor parallelism“ nennt.

Jeder Server hält seine eigene Kopie des Checkpoints auf lokalem NVMe-Speicher, 595 GB, plus Platz für die nächste Version, weil vLLM auf jedem Knoten die Gewichte seiner Stufe lädt. Unser Leitfaden zum Abnahmetest von GPU-Servern beschreibt den Lasttest, der vor dem Produktivstart auf dem Paar läuft.

Strom und Rack: warum zwei Server statt einem

Die Stromversorgung des Racks ist der übliche Grund für diese Aufteilung. Nach unserer Schätzung zieht ein Server mit vier Karten etwa 3,4 kW an der Steckdose, wenn die Karten mit 600 W laufen, und etwa 2,7 kW mit einer Begrenzung auf 450 W, wie unser Leitfaden zum Server mit vier Server-Edition-Karten vorrechnet. Ein Server mit acht Karten kommt auf etwa 6,3 kW.

Unsere Schätzungen: Karten, zwei Prozessoren und 15 Prozent für den Rest wie in unseren verwandten Leitfäden; geplant mit 80 Prozent des Stromkreises, 2,94 kW bei 230 V 16 A und 5,89 kW bei 230 V 32 A. Eine Messung am gelieferten System bestätigt die Werte.

Zwei begrenzte Server mit vier Karten passen je Seite an einen einphasigen Anschluss mit 16 A und können in zwei Racks stehen, was auch die Wärme verteilt. Die Begrenzung kostet etwas Geschwindigkeit; unser Leitfaden zur Leistung der RTX PRO 6000 Server Edition bei 600, 450 und 300 W sammelt die veröffentlichten Messungen. NVIDIAs Konfigurations­leitfaden verlangt Arbeitsspeicher vom Doppelten des GPU-Speichers, 768 GB je Server mit vier Karten, insgesamt dieselben 1.536 GB wie bei einem Server mit acht Karten. Doppelt wird die Plattform: zwei Gehäuse, zwei Paare Prozessoren, zwei Management-Controller und doppelt so viele Netzwerkports.

Wann ein Server mit acht Karten die bessere Wahl ist

Wenn ein Rackplatz Drehstrom bietet und der Raum etwa 6,3 kW aufnimmt, ist ein Server mit acht Karten für eine einzelne Kopie eines Modells mit 600 GB einfacher. Er braucht kein RDMA-Netzwerk und keine Cluster-Laufzeit, die Stufengrenze bleibt auf PCIe im Host, und Decode Context Parallelism über acht Karten wird möglich, was den Kimi-Wert nach unserer Schätzung von etwa 12 auf etwa 51 Gespräche mit 32K hebt. Unser Überblick zu großen LLMs auf acht Server-Edition-Karten dimensioniert den Fall mit acht Karten. Sollen die beiden Server mit vier Karten später getrennte Modelle betreiben, behält das Paar diese Freiheit; für ein einzelnes großes Modell mit vielen Nutzern fassen acht H200 NVL in einem Server mehr Cache, wie unser Leitfaden zum Server mit acht H200 NVL zeigt.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Arbeitslast und Ihrem Budget und antwortet innerhalb eines Werktages. Wir bauen KI-Server nach Auftrag mit vier oder acht RTX PRO 6000 Server Edition, mit NICs für 25, 100, 200 oder 400G und Out-of-Band-Management, vor der Lieferung montiert und getestet, mit EU-Vertrag und EU-Rechnung sowie Herstellergarantie auf jede Komponente. Mengen und Lieferzeit werden schriftlich mit dem Angebot bestätigt. Unsere Seite zum Kauf eines Servers mit 4× RTX PRO 6000 Server Edition listet die Varianten mit vier Karten. Die Einrichtung von vLLM über beide Server, das Stufennetzwerk und das Modell übernimmt unser Service Private AI/ML, mit Engineering durch unseren Partner Vixen.UNO.

FAQ