Konzeptkarte

Tensor-Parallelismus vs. Pipeline-Parallelismus — Multi-GPU-Inferenz

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Tensor-Parallelismus vs. Pipeline-Parallelismus — Multi-GPU-Inferenz?

Tensor-Parallelismus benötigt NVLink und skaliert bis zu 8 GPUs in einem Knoten; Pipeline-Parallelismus toleriert langsamere knotenübergreifende Verbindungen, verschwendet aber Rechenleistung durch die Pipeline-Bubble — produktive Stacks kombinieren beides.

Tensor-Parallelismus und Pipeline-Parallelismus sind die beiden grundlegenden Strategien, um ein großes Sprachmodell zu servieren, dessen Gewichte zu groß sind, um auf eine einzelne GPU zu passen. Ein Modell mit siebzig Milliarden Parametern benötigt in Standard-Halbpräzision rund einhundertvierzig Gigabyte Speicher, noch bevor irgendein Spielraum für den Key-Value-Cache hinzukommt — weit mehr als die achtzig Gigabyte einer einzelnen High-End-Rechenzentrums-GPU. Das Modell auf mehrere Geräte aufzuteilen ist nicht optional, und wie diese Aufteilung gestaltet wird, bestimmt unmittelbar Latenz, Durchsatz und Interconnect-Kosten des gesamten Deployments.

Wie jede Strategie das Modell aufteilt

Tensor-Parallelismus teilt jede Gewichtsmatrix horizontal über eine Gruppe von GPUs auf: Jede Schicht des Modells läuft gleichzeitig auf jeder GPU, wobei jedes Gerät seinen eigenen Anteil der Matrixmultiplikation berechnet, und die Teilergebnisse werden über die Geräte hinweg aufsummiert, bevor die nächste Schicht beginnt. Da jede Schicht weiterhin im Gleichschritt über alle GPUs hinweg ausgeführt wird, hält Tensor-Parallelismus die End-to-End-Latenz niedrig — es gibt kein Warten darauf, dass frühere Stufen sich leeren. Die Kosten zeigen sich am Interconnect: Jede Schicht löst einen vollständigen Synchronisationsschritt über die Geräte hinweg aus, sodass eine sehr schnelle GPU-zu-GPU-Verbindung faktisch zwingend erforderlich ist. Bei langsameren Interconnects dominiert der Synchronisations-Overhead, und der Durchsatz bricht ein. Tensor-Parallelismus skaliert innerhalb eines einzelnen Knotens mit hoher Bandbreite sauber, verschlechtert sich aber rasch, sobald es einen zweiten Knoten überschreiten muss, wo sich die zusätzliche Netzwerklatenz über Dutzende von Transformer-Schichten hinweg summiert.

Warum es zählt

TP löst bei jeder Schicht ein AllReduce aus, sodass Knoten nur mit PCIe unter der Bandbreitenlast zusammenbrechen — NVLink (900GB/s bei H100 SXM) ist zwingend erforderlich, und knotenübergreifendes TP fügt Latenz hinzu, die sich über 80+ Transformer-Schichten summiert.
Der Anteil der PP-Pipeline-Bubble beträgt (P-1)/(M+P-1) — bei 8 Micro-Batches und Pipeline-Tiefe 4 sind das 27 % Leerlaufzeit, akzeptabel für Batch-Serving, aber inakzeptabel für interaktive Single-Stream-Workloads.
Ein 70B-Modell in FP16 benötigt ~140GB, weit mehr als die 80GB einer einzelnen H100, sodass jeder Serving-Stack in dieser Größenordnung eine Aufteilungsstrategie wählen muss — daran führt kein Weg vorbei.

Kernpunkte

TP teilt Gewichtsmatrizen horizontal auf — jede GPU führt jede Schicht parallel aus, AllReduce summiert Teilergebnisse; NVLink zwingend erforderlich, skaliert innerhalb eines Knotens am besten bis TP=8.
PP teilt das Modell vertikal nach Schichtbereichen auf — Aktivierungen fließen einmal pro Forward Pass von GPU zu GPU; funktioniert über InfiniBand/Ethernet knotenübergreifend.
TP minimiert die Latenz einer einzelnen Anfrage auf Kosten der Interconnect-Bandbreite; PP minimiert den Interconnect-Traffic auf Kosten der Pipeline-Bubble-Leerlaufzeit.
Produktionsregel: TP innerhalb des Knotens (NVLink-gebunden), PP über Knoten hinweg (netzwerkgebunden); Llama-3.1-405B typischerweise TP=8 × PP=2 auf 16 H100.
Frameworks: vLLM ≥0.5, TensorRT-LLM, SGLang, DeepSpeed-Inference stellen beide Stellschrauben bereit; Standardwerte sind selten optimal für den eigenen Workload-Mix.
Anti-Pattern: TP über PCIe (ohne NVLink) — AllReduce sättigt den Bus, und der Durchsatz bricht um 30-50 % bei der Time-to-First-Token und um 60-80 % beim anhaltenden Durchsatz ein.
Bubble-Anteil-Formel: (P-1)/(M+P-1), wobei P = Pipeline-Tiefe, M = Anzahl der Micro-Batches; Zielwert <20 % für interaktive Workloads.
Der KV-Cache-Speicher skaliert als batch_size × context_length × num_layers × hidden_dim × 2 (K+V) × bytes_per_element — dies vor der Wahl des TP-Grads dimensionieren.
SAP-BTP-AI-Inference-Hosts sind 2026 NVLink-SXM-Pods; die NVLink-Topologie vor der Angabe von TP>4 prüfen, sonst ist die Garantie hinfällig.
Sequence Parallelism (SP) erweitert TP auf die Sequenzdimension der Attention — wird in vLLM verwendet, wenn die Kontextlänge 8K überschreitet, um OOM beim KV-Cache-Shard zu vermeiden.

Begriffe auf dieser Seite

AllReduce: Kollektive Kommunikationsprimitive, die Teiltensoren über alle beteiligten GPUs hinweg aufsummiert und das Ergebnis verteilt; die dominierende Kostenquelle bei tensor-parallelen Forward Passes — auf NVLink-H100 dauert es bei TP=8 ~5 µs pro Schicht.
Pipeline bubble: Leerlaufzeit der GPU beim Pipeline-Parallelismus, während spätere Stufen bei den ersten/letzten Micro-Batches eines Schritts auf frühere Stufen warten; Anteil = (P-1)/(M+P-1), wobei P die Pipeline-Tiefe und M die Anzahl der Micro-Batches ist.
NVLink: NVIDIAs hochbandbreitiger GPU-zu-GPU-Interconnect (900 GB/s bidirektional bei H100 SXM5 NVSwitch) — Voraussetzung für effizienten Tensor-Parallelismus; PCIe-Bandbreite (~64 GB/s) ist 14-mal langsamer und bricht unter AllReduce-Traffic zusammen.
KV-cache: Zwischengespeicherte Key/Value-Attention-Tensoren, die über Decodierungsschritte hinweg beibehalten werden; verbraucht GPU-Speicher proportional zu Kontextlänge × Batchgröße × num_layers × hidden_dim × 2; die primäre Speicherbudget-Einschränkung bei der Dimensionierung des TP-Grads.
Sequence Parallelism (SP): Erweiterung des Tensor-Parallelismus, die die Eingabesequenz während der Attention-Berechnung über GPUs verteilt und so den KV-Cache-Speicherbedarf pro GPU bei langen Kontextlängen reduziert; implementiert in vLLM und Megatron-LM.
TTFT: Time To First Token — die Latenz von der Einreichung der Anfrage bis zum ersten Ausgabe-Token; die dominierende UX-Metrik für interaktive Anwendungen; TP=8 innerhalb eines NVLink-Knotens minimiert die TTFT; PP fügt Bubble-Latenz hinzu, die die TTFT verschlechtert.
Micro-batch: Eine Untereinheit des globalen Batches beim Pipeline-Parallelismus; mehrere gleichzeitig durch die Pipeline fließende Micro-Batches unterdrücken die Pipeline-Bubble und verbessern die GPU-Auslastung.
Tensor shard: Der Anteil einer GPU an einer Gewichtsmatrix beim Tensor-Parallelismus; bei einer versteckten Dimension d=8192 mit TP=4 hält jede GPU einen Shard von 2048 Spalten jedes Gewichts und berechnet ihre Teilmatrixmultiplikation vor dem AllReduce.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →