Inferenz-Cluster: vLLM Tensor Parallel, Pipeline Parallel – und was Sie das jeweils wirklich kostet

Ein Modell der 70B-Klasse passt bei keiner Quantisierung auf eine einzelne GPU, die noch nutzbaren KV-Cache übrig lässt. Ein 405B-Modell passt auf keinen einzelnen Node. Sobald das gilt, lautet die Frage nicht mehr „welche GPU“, sondern „wie zerlege ich das Modell auf die GPUs, die ich habe – und was kostet mich jeder Schnitt?“

Dieser Artikel behandelt die vier Wege, auf denen vLLM ein Modell zerlegt – Tensor-Parallelität, Pipeline-Parallelität, Expert-Parallelität, Daten-Parallelität –, was jeder davon mit Ihrem Bandbreitenbudget anstellt und wie Sie im Kentino-Portfolio zwischen ihnen wählen (PCIe-angebundene 5090, RTX Pro 6000 Blackwell, L40, L4 – keine SXM-Teile mit NVLink-Fabric). Die Leserschaft hat I01gelesen, weiß, was vLLM ist, und muss jetzt Konfigurationsentscheidungen treffen.

Die vier Dimensionen, ein Modell zu zerlegen

Jedes Framework für verteilte Inferenz – vLLM, SGLang, TensorRT-LLM, Triton – bietet irgendeine Kombination derselben vier Achsen. Sie sind keine Alternativen, sie lassen sich kombinieren.

Die dritte Spalte entscheidet alles. TP brüllt bei jeder Schicht über den Bus. PP flüstert zwischen zwei Stufen. Allein diese Tatsache bestimmt, ob Sie TP innerhalb eines Gehäuses halten, PP über Nodes hinweg schieben – und wo die Grenze verläuft.

Tensor-Parallelität – wie sie tatsächlich funktioniert

Bei TP wird jede Gewichtsmatrix im Transformer (Attention-QKV, Attention-Output, FFN-Up, FFN-Down) über tensor_parallel_size GPUs aufgeteilt. Jede GPU speichert einen Shard jeder Schicht und berechnet einen Shard jeder Aktivierung. Da Attention und FFN Matmuls enthalten, die vor der nächsten Operation (Softmax, SwiGLU) die vollständige wieder zusammengesetzte Aktivierung benötigen, müssen Teilergebnisse zusammengeführt werden. vLLM erledigt das mit einem All-Reduce am Ende der Attention und einem weiteren am Ende des FFN – zwei pro Transformer-Block.

Llama 3.3 70B hat 80 Schichten bei einer Hidden Size von 8192. Bei Batch 32 im Decode bewegt jedes All-Reduce rund 512 KB, ×160 pro erzeugtem Token → rund 80 MB pro Token über den Bus. Im Prefill ist es dramatisch schlimmer: Ein 4-K-Prefill bei Batch 32 schiebt in einem einzigen Forward Pass in der Größenordnung von 300 GB durch den All-Reduce-Ring.

Diese Zahl ist der Grund, warum TP NVLink liebt. SXM-H100/B200-NVLink liefert 900 GB/s. PCIe Gen 5 x16 schafft 64 GB/s unidirektional, bestenfalls 128 GB/s bidirektional – auf einem 4-GPU-Board selten der Fall, da sich die Lanes meist teilen (siehe W02). Die Lücke von 14× bis 28× zeigt sich in Benchmarks: Die Skalierungseffizienz liegt bei NVLink bei rund0.92×/Karte, bei PCIe bei rund0.70–0.78×/Karte bei Modellen der 70B-Klasse.

Praktische Konsequenz: TP skaliert in einem PCIe-Gen-5-Node bis 4 GPUs gut. Darüber hinaus kostet das All-Reduce mehr, als die Parallelität einspart – dann sollten Sie stattdessen zur Pipeline-Parallelität greifen.

vLLM-Konfiguration: tensor_parallel_size

--tensor-parallel-size N weist die Engine an, jeden Gewichtstensor über N GPUs im lokalen Node zu sharden. Einschränkungen:

• N muss die Anzahl der Attention-Heads des Modells teilen (Llama 70B hat 64 Heads → N ∈ {1, 2, 4, 8, 16, 32, 64}).
• vLLM platziert TP-Ranks auf demselben Node und setzt einen schnellen Intra-Node-Bus voraus.
• Der KV-Cache wird entlang der Head-Dimension gesharded – jede GPU speichert total_heads / N Heads. Ein höherer TP-Wert schafft mehr KV-Reserve pro Anfrage.

Auf Kentino-Hardware: TP=4 auf einer Box mit 4× RTX 5090 oder 4× RTX Pro 6000 Blackwell ist der Sweet Spot. TP=8 funktioniert, aber der PCIe-Bus ächzt – in einer 8-GPU-Box fahren Sie meist mit TP=4 × PP=2 besser.

Pipeline-Parallelität – die Option über die Raumgrenze hinweg

PP zerlegt das Modell nach Tiefe. Mit pipeline_parallel_size=2hält GPU 0 die Schichten 0–39 eines 70B-Llama, GPU 1 die Schichten 40–79. Eine Anfrage läuft durch GPU 0, der Aktivierungstensor geht an GPU 1, und GPU 1 schließt den Forward Pass ab.

Die Kommunikation besteht aus einem Tensor der Form (batch, seq_len, hidden_size) je Stufengrenze. Bei Batch 32, Seq 4096, Hidden 8192 in FP16 sind das rund 1 GB pro Prefill und rund 0.5 MB pro Decode-Token bei Batch 32 – zwei Größenordnungen weniger als das All-Reduce bei TP. PP läuft problemlos über einfaches 25 GbE oder sogar 10 GbE.

Der Preis dafür ist Latenz. Mit PP=2 springt jedes Token zwischen den Stufen – naiv gerechnet die doppelte Wall-Time pro Token. vLLM entschärft das mit Micro-Batching: Stufe 0 beginnt den nächsten Micro-Batch, während Stufe 1 den aktuellen abschließt. Bei ausreichend Nebenläufigkeit schließt sich die Blase; bei einer einzelnen Anfrage ohne Batching ist PP eine Latenzsteuer ohne Gegenwert.

vLLM-Konfiguration: pipeline_parallel_size

--pipeline-parallel-size M teilt das Modell schichtweise auf M Gruppen auf. GPUs insgesamt = tensor_parallel_size × pipeline_parallel_size. Empfehlung der Dokumentation:

• Ein Node, ≤ 8 GPUs, Modell passt: reines TP, pipeline_parallel_size=1.
• Mehrere Nodes: TP innerhalb des Nodes, PP über Nodes hinweg. Ein Cluster aus zwei Nodes mit 8 GPUs fährt TP=4, PP=2.
• Die GPU-Anzahl teilt die Head-Anzahl nicht sauber: Setzen Sie TP=1, PP=GPUs. PP kümmert sich nicht um die Head-Anzahl. (Eine 5-GPU-Box – ein Steckplatz geht an eine NIC – kann Llama nur über PP=5 fahren.)

Expert-Parallelität – nur für MoE

MoE-Modelle (DeepSeek-V3, Mixtral, Qwen-MoE-Varianten) aktivieren nicht bei jedem Token jeden Parameter. Sie besitzen geroutete FFN-Schichten, in denen pro Token nur eine kleine Teilmenge der „Experten“ feuert; die dichten Attention-Schichten bleiben dicht.

Expert-Parallelität (EP) verteilt Experten über GPUs , während dichte Schichten unter TP oder DP bleiben. Mit --enable-expert-parallelwechseln die Expertenschichten von repliziert zu partitioniert, mit einem oder wenigen Experten je GPU. Das Kommunikationsmuster ist ein All-to-All pro MoE-Schicht: Tokens werden zu derjenigen GPU geroutet, die den Zielexperten hält, dort berechnet und zurückgeschickt.

EP ist bandbreitenmäßig stoßweise. Erst dadurch werden große MoE-Modelle auf PCIe-Clustern überhaupt handhabbar – volles TP auf einem Modell mit 671B aktiven Parametern ist aussichtslos. Für Kentino-Deployments ist EP nur bei Modellen der DeepSeek-V3-Klasse relevant; ein dichtes Llama 70B profitiert nicht davon. Der eingebaute EP-Support von vLLM in Verbindung mit einem aktuellen Build ist der Standardeinstieg.

Daten-Parallelität – die langweilige, geniale Achse

DP ist die einfachste Skalierungsachse – und die, die in den meisten Installationen zu wenig genutzt wird. Sie starten N identische Kopien des Modells, jede auf ihrem eigenen GPU-Satz (der seinerseits TP und/oder PP nutzen kann). Ein Load Balancer verteilt die Anfragen auf das Replikat, das gerade Kapazität hat.

Was DP bringt:

• Lineare Durchsatzskalierung (N× Anfragen/Sekunde).
• Keinerlei Kommunikation zwischen den Replikaten während der Inferenz.
• Unabhängige KV-Caches je Replikat (der Prefix-Cache gilt pro Replikat).
• Triviale Fehlerisolierung.

Was DP kostet:

• N× den GPU-Speicher – jedes Replikat hält das vollständige Modell.
• Keine Latenzreduktion. Eine einzelne Anfrage dauert so lange, wie sie auf einem Replikat eben dauert.

Wenn Sie eine Box mit 4× RTX Pro 6000 haben und Llama 70B bei TP=4 hineinpasst, ergibt eine zweite 4er-Box DP=2 × TP=4 – doppelter Durchsatz bei gleicher Latenz pro Anfrage. Für Chat-, Agenten- und RAG-Workloads ist das der richtige Kompromiss. Der Schalter --data-parallel-size von vLLM (und der neuere Modus data_parallel_deployment ) startet und verwaltet die Replikate. DP ist der sauberste Weg, über eine einzelne Box hinaus zu skalieren.

Die Achsen kombinieren – die Faustregel

Achsenwahl: Beginnen Sie mit der kleinsten Parallelität, die passt, und fügen Sie DP vor PP hinzu.

Ein durchgerechnetes Beispiel: Llama 3.3 70B (FP8 ≈ 75 GB Gewichte plus KV) bei hoher Nebenläufigkeit ausliefern:

• Eine Box mit 4× RTX Pro 6000 Blackwell (4 × 96 GB = 384 GB) fährt das Modell bequem unter TP=4, mit rund 250 GB Reserve für KV, Prefix-Cache und CUDA-Graphen.
• Stellen Sie eine zweite 4er-Pro-6000-Box dazu: DP=2 × TP=4. Zwei Replikate hinter einem Router. Doppelter Durchsatz, gleiche Latenz.
• Llama 3.1 405B in FP8 (rund 400 GB Gewichte)? Eine 4er-Pro-6000-Box reicht nicht. Zwei Boxen mit PP=2 × TP=4 schon – und über die Node-Grenze wandern Aktivierungen, kein All-Reduce. 25 GbE genügt, 100 GbE ist komfortabel.

KV-Cache: der Teil, den alle unterschätzen

Der KV-Cache umfasst die kumulierten Key-/Value-Tensoren der Attention für jedes Prompt-Token, jedes erzeugte Token, jede gleichzeitige Anfrage und jede Schicht. Er wächst linear mit Kontextlänge und Nebenläufigkeit. Llama 70B bei 8 K Kontext braucht in FP16 grob 2.5 GB KV-Cache pro Anfrage . Bei 32 gleichzeitigen Anfragen sind das 80 GB – mehr als der gesamte VRAM einer 5090.

Wie die Parallelität mit dem KV-Cache zusammenspielt:

• Unter TPwird KV nach Attention-Head über die TP-Gruppe verteilt. KV pro GPU = gesamt / tensor_parallel_size. Höheres TP → mehr Reserve für gleichzeitige Anfragen.
• Unter PPbleibt KV auf der GPU, die die erzeugende Schicht hält. Jede Stufe besitzt ihren eigenen KV-Cache.
• Unter DPist KV je Replikat vollständig unabhängig.
• Unter Kontext-Parallelität (ein neuerer vLLM-Modus) wird KV entlang der Sequenz -Dimension gesharded – nützlich für sehr lange Kontexte einzelner Anfragen.

Prüfen Sie bei der Dimensionierung einer Box nicht nur, ob die Gewichte hineinpassen. Rechnen Sie den KV-Bedarf bei Ihrer Zielnebenläufigkeit und Ihrem Zielkontextfenster durch. Der häufigste stille Ausfall in produktivem vLLM ist eine Engine, die unter KV-Druck Anfragen verdrängt.

Request-Routing – was vor dem Cluster sitzt

Eine einzelne vLLM-Instanz erledigt ihr internes Batching selbst (Continuous Batching, Prefix-Caching, Scheduling). Sie routet jedoch nicht über Replikate hinweg. Das ist Aufgabe des Routers.

NGINX ist die richtige Standardwahl für eine Installation mit zwei Replikaten – Round Robin, Health-Checks auf /health, fertig. Der vLLM Router (Rust, Ende 2025 veröffentlicht) ist die richtige Wahl, sobald die Trefferquote des Prefix-Cache Ihre Tail-Latenz dominiert: Er routet über konsistentes Hashing des Prompt-Präfixes, sodass Replikate mit warmem Cache immer wieder dieselben Konversationen bekommen. Bei Agenten-Workloads mit langen, gemeinsam genutzten System-Prompts kann das den effektiven Durchsatz gegenüber Round Robin verdoppeln.

Die Bandbreitenrechnung

Querverweise: N02, N06.

Die ehrliche Lesart: TP und EP wollen in einer Box bleiben. PP und DP ist es egal. Mit einer Verbindung von 10–25 GbE zwischen den Nodes sind PP und DP völlig ausreichend. Sobald Sie TP über Node-Grenzen hinweg wollen, zahlen Sie für InfiniBand HDR oder 200 GbE RoCE – und sollten zuerst prüfen, ob DP über TP-Gruppen innerhalb einzelner Nodes nicht dasselbe Ergebnis für ein Zehntel des Budgets liefert. Bei den meisten Deployments in Kentino-Größe tut es das.

Zwei konkrete Konfigurationsrezepte

Rezept A – Ein Node, 4× RTX 5090, Llama 70B Q4 / FP8

Hardware: Kentino AI 256 Turin Dual oder eine beliebige 4-GPU-5090-Box. PCIe Gen 5, kein NVLink, AMD-EPYC-Host.

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 1 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --dtype auto \
  --port 8000

Zu erwarten: grob 30–40 Token/s pro Anfrage bei geringer Nebenläufigkeit, aggregiert rund 400–600 Token/s bei 32 gleichzeitigen Anfragen (abhängig von Prompt-Mix, Prefix-Cache-Trefferquote und exakter Quantisierung – verstehen Sie das als Startkorridor). Das All-Reduce über PCIe Gen 5 ist im Decode der Flaschenhals; das Prefill skaliert nahezu linear.

Rezept B – Zwei Nodes, insgesamt 8× RTX Pro 6000 Blackwell, Llama 405B FP8

Zwei Kentino-AI-Boxen mit je 4× Pro 6000 (96 GB). 100 GbE RoCE zwischen beiden, oder 25 GbE, wenn das Budget knapp ist (funktioniert, das Prefill wird etwas langsamer).

# Node 0 (Head):
vllm serve meta-llama/Llama-3.1-405B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 32

# Node 1 (Worker, via Ray verbunden):
ray start --address=<head-ip>:6379

TP=4 innerhalb jedes Nodes nutzt PCIe Gen 5 für die All-Reduces. PP=2 über die Nodes hinweg schickt Aktivierungen über 25/100 GbE. Mit Ray als verteiltem Backend (dem vLLM-Standard für Multi-Node-Betrieb) koordiniert der Head das Scheduling und den KV-Zustand.

Ehrliche Leistungseinschätzung: 405B in FP8 über 8× Pro 6000 via PCIe und Ethernet landet bei rund 6–12 Token/s pro Anfrage – deutlich unter einem 8× SXM-B200-Chassis, dafür zu einem Bruchteil der Investitionskosten und ohne das SXM-Lieferproblem. Wenn Ihr SLA lautet „Antwort in 30 s für eine 500-Token-Completion“, funktioniert das. Lautet es „Antwort in 2 s“, nehmen Sie kein 405B – nehmen Sie ein 70B.

Was wir nicht betreiben

NVLink, NVSwitch, SXM B200, komplette HGX-Boards: nicht im Kentino-Portfolio. Sie sind die richtige Antwort, wenn Budget und Workload dafür sprechen. Für die meisten unserer Kunden sind sie es nicht – sie dimensionieren für 1–4 gleichzeitige Agenten-Workflows oder eine einzelne Roboterplattform, nicht für SaaS-Inferenz mit 1 000 Nutzern. Der PCIe-Weg ist ehrlich in dem, was er kann und was nicht. TP über 16 GPUs mit unter 10 ms pro Token ist ein anderes Thema – und nicht der Cluster, um den es in diesem Artikel geht.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen gern an info@kentino.com.