Tensor-Parallelismus im Vergleich zu Pipeline-Parallelismus bei der lokalen Inferenz von großen Sprachmodellen

Falls Ihr Modell nicht auf einer einzigen GPU Platz findet – oder falls Sie eine höhere Durchsatzrate benötigen als 1 GPUs bereitstellen können – müssen Sie die Arbeitslast auf mehrere GPUs verteilen. Es gibt 2 Hauptstrategien: Tensor-Parallelismus (TP) und Pipeline-Parallelismus (PP). Beide lösen unterschiedliche Probleme; die falsche Wahl führt zu einer ineffizienten Nutzung der Hardware.

Kurzfassung

Anwendungsszenario	Empfohlene Strategie	Begründung
Einzelner Knoten mit mehr als 2 GPUs (z. B. ein DGX Spark-Setup oder 2 RTX 4090-GPUs)	TP	Geringere Latenz sowie effizientere Nutzung der Bandbreite zwischen den GPUs
Mehrere Knoten (2 oder mehr Geräte im Netzwerk)	PP	Ermöglicht die Verarbeitung bei Netzwerkverzögerungen; jeder Knoten speichert ein Modellfragment
Große Modelle bei hoher Anzahl gleichzeitiger Anfragen	Hybride TP + PP-Architektur	Tensor-Parallelismus innerhalb eines Knotens, Pipeline-Parallelismus zwischen mehreren Knoten
Skalierbarkeit der Durchsatzrate – geeignet für viele Nutzer, sofern das Modell auf 1 GPUs passt	Datenparallelismus (DP)	Das Modell wird mehrfach kopiert; die Anfragen werden auf diese Instanzen verteilt

Verwenden Sie Tensor-Parallelismus bei mehreren GPUs auf einem einzelnen Knoten. Nutzen Sie Pipeline-Parallelismus für mehrere Knoten. Diese Regel gilt für die meisten Konfigurationen.

Erläuterung zum Tensor-Parallelismus

Beim Tensor-Parallelismus werden die Gewichtsmatrizen jeder Schicht auf mehrere GPUs aufgeteilt. Während einer Vorwärtspropagation berechnet jede GPU einen Teil der Matrixmultiplikation gleichzeitig; anschließend erfolgt die Synchronisation über ein Hochgeschwindigkeits-Interconnect wie NVLink, PCIe oder InfiniBand.

Layer N:
  GPU 0: weights[0:50%] × input  ──┐
                                    ├── all-reduce ──→ output
  GPU 1: weights[50:100%] × input ─┘

Wesentliche Eigenschaften:

Jede GPU verwaltet jeweils einen Teil jedes Layers.
Alle GPUs arbeiten bei jedem Token aktiv mit.
Voraussetzung ist ein Hochgeschwindigkeits-Interconnect, etwa NVLink statt PCIe.
Zwar entsteht dadurch pro Layer zusätzlicher Synchronisationsaufwand, doch bleibt die Latenz pro Token gering.
vLLM bezeichnet dies als --tensor-parallel-size

Besonders geeignet für: 2× DGX Spark, verbunden über einen 200-Gb/s QSFP-Interconnect, ferner 2× RTX 4090-Karten via PCIe oder jede Einzelknoten-Konfiguration, bei der mehrere GPUs einen schnellen Bus nutzen.

Erläuterung zur Pipeline-Parallelisierung

Bei der Pipeline-Parallelisierung werden verschiedene Layers auf unterschiedliche GPUs verteilt. GPU 0 verwaltet die Layers 0 bis 15; GPU 1 übernimmt die Layers 16 bis 31. Der Vorwärts-Durchlauf verläuft wie auf einer Fließbandlinie: GPU 0 verarbeitet die Eingabedaten und leitet die Aktivierungen an GPU 1 weiter, welche die Verarbeitung fortsetzt.

GPU 0: [Layer 0–15]  ──activations──→  GPU 1: [Layer 16–31]  ──→ output

Wesentliche Eigenschaften:

Jede GPU verwaltet ein zusammenhängendes Bündel an Layers.
Zu jedem Zeitpunkt ist lediglich 1 GPU pro Token aktiv; die übrigen verbleiben inaktiv oder bearbeiten andere Tokens.
Auch langsamere Interconnects stellen kein Problem dar, da die Aktivierungen kleiner sind als vollständige Gewichtsmatrizen.
Es werden Pausen im Verarbeitungsablauf eingefügt, wodurch die Auslastung verringert wird.
vLLM bezeichnet dies als --pipeline-parallel-size

Besonders geeignet: für Mehrknoten-Cluster, bei denen die Knoten über ein 10GbE–100GbE-Netzwerk verbunden sind, oder wenn das Modell allein mittels Tensor-Parallelismus nicht unterzubringen ist.

Entscheidungsmatrix

Beantworten Sie folgende Fragen, um die passende Strategie zu wählen:

Passt das Modell auf eine einzige 1-GPU?
- Ja → es ist keine Parallelisierung erforderlich. Falls mehr Durchsatz benötigt wird, empfiehlt sich die Nutzung von Daten-Parallelismus.
- Nein → fahren Sie fort.
Befinden sich alle GPUs auf demselben Rechner?
- Ja → Tensor-Parallelismus (geringere Latenz sowie höherer Decodier-Durchsatz).
- Nein → fahren Sie fort.
Sind die GPUs auf mehr als 2 Rechnern verteilt?
- Ja → Pipeline-Parallelismus über mehrere Knoten hinweg. Falls jeder Knoten über 2+ GPUs verfügt, sollte TP innerhalb jedes Knotens sowie PP zwischen den Knoten eingesetzt werden.
Handelt es sich um ein sehr großes Modell (405B+)?
- Ja → hybride Methode aus TP und PP. Beispiel: TP=2 auf jedem DGX Spark, PP=2 über insgesamt 2 Sparks.

Empfehlungen je nach Hardware

Hardware	GPUs	Vernetzung	Empfohlene Vorgehensweise
2× DGX Spark (GB10)	2 ist einheitlich	200 Gb/s QSFP	TP=2
2× RTX 4090	2 dedizierte GPU	PCIe 4.0	TP=2
2× RTX 3090	2 dedizierte GPU	PCIe 4.0	TP=2 (Achten Sie auf Out-of-Memory-Fehler – vLLM reserviert mehr Speicher als Ollama)
2-Node DGX Spark-Cluster	2 Knoten	200 GB/s QSFP	PP=2 (Alternativ TP=2 sowie PP=2 für 405B)
3+ Node-Cluster	3+ Knoten	10–100 Gigabit-Ethernet	PP steht für die Anzahl der Knoten, TP für die Anzahl der GPUs pro Knoten

Dataparallelismus sowie Expertenparallelismus

Zwei weitere Strategien sind in bestimmten Szenarien von Bedeutung: Datenparallelität (DP) – Hierbei wird das gesamte Modell auf jeder GPU repliziert und eingehende Anfragen auf diese verteilt. Diese Methode eignet sich, wenn das Modell bereits auf 1 GPUs Platz findet und Sie mehr gleichzeitige Nutzer bedienen möchten. vLLM unterstützt dies von Haus aus; starten Sie einfach mehrere Instanzen hinter einem Lastverteiler. Expertenparallelismus (EP) – speziell für MoE-Modelle gedacht. Verschiedene GPUs verwalten jeweils unterschiedliche Expertengruppen. Sobald ein Token an einen bestimmten Experten weitergeleitet wird, gelangt die Aktivierung zur zuständigen GPU. Diese Strategie ist sinnvoll bei sehr großen MoE-Modellen, bei denen der reine TP-Ansatz Speicherplatz verschwendet, da inaktive Experten ebenfalls gespeichert werden müssen.

Strategie	Am besten geeignet für	Latenz	Durchsatz	Hardware-Anforderungen
Tensor-Parallelismus (TP)	Das Modell ist für eine einzelne GPU unter der Upstream-Modell-ID 1 zu groß.	Gering	Hoch	Schnelle Interconnect-Technologien (NVLink, PCIe)
Pipeline-Parallelismus (PP)	Einsatz mehrerer Knoten für äußerst große Modelle	Noch höher (Blasenbildung)	Mittel	Netzwerkverbindung (10 GbE+)
Dataparallelismus (DP)	Das Modell passt, doch es werden mehr Nutzer benötigt	Verhält sich genauso wie bei einer einzelnen GPU	Die Skalierung erfolgt linear	Alles ist möglich – lediglich mehr GPUs sind erforderlich
Expert Parallelism (EP)	Große MoE-Modelle	Mittel	Hoch	Schnelle Interkonnektivität

Beispiele für Konfigurationen

vLLM in Kombination mit Tensor Parallelism

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90

Für 2× DGX Spark, verbunden über einen 200-Gigabit/s QSFP-Anschluss:

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 2 \
  --distributed-executor-backend ray

vLLM mit Pipeline-Parallelismus

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --pipeline-parallel-size 2 \
  --tensor-parallel-size 1

Hybride Tensor-Parallelität sowie Pipeline-Parallelismus (für große Modelle auf mehreren Knoten)

Für ein 405B-Modell auf 2 DGX Spark-Systemen (Tensor-Parallelität innerhalb jedes Knotens, Pipeline-Parallelismus zwischen den Knoten):

vllm serve meta-llama/Llama-3.1-405B-Instruct \
  --tensor-parallel-size 2 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray

SGLang mit Tensor-Parallelismus

SGLang erzielt bei bestimmten Arbeitslasten auf Systemen mit zwei GPUs vergleichbare Ergebnisse wie vLLM:

python -m sglang.launch_server \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --tp 2 \
  --port 30000

NCCL-Umgebungsvariablen

Zur Kommunikation zwischen mehreren GPUs müssen diese Variablen vor dem Start gesetzt werden:

export NCCL_DEBUG=INFO
export NCCL_IB_DISABLE=0          # Enable InfiniBand if available
export NCCL_SOCKET_IFNAME=eth0    # Pin the network interface
export NCCL_NET_GDR_LEVEL=2       # Enable GPUDirect RDMA

Auf DGX Spark-Clustern, die über 200 Gigabit/s schnelle QSFP-Verbindungen vernetzt sind, wählt NCCL automatisch den optimalen Übertragungsweg. In der Regel ist es nicht nötig, NCCL_IB_DISABLE oder NCCL_SOCKET_IFNAME manuell zu ändern – außer bei der Fehlerbehebung bezüglich der Netzverbindung.

Leistungsvergleich

Basierend auf Community-Benchmarks für dense Modelle der 70B-Klasse:

Konfiguration	Decodierungsgeschwindigkeit in Tokens pro Sekunde (einzelner Nutzer)	Anzahl gleichzeitiger Nutzer (jeweils 5 Tokens pro Sekunde)	Hinweise
1× DGX Spark (ohne Parallelität)	~10	2–3	Referenzwert
2× DGX Spark, TP=2 (200 GB/s QSFP)	~18	5–8	Nahezu lineare Skalierung beim Dekodieren
2× RTX 4090, TP=2 (PCIe)	~20	5–7	Die PCIe-Bandbreite begrenzt das Prefill-Verfahren
2× DGX Spark, PP=2 (Netzwerk)	~12	4–6	Pipeline-Engpässe mindern die Auslastung

Auf derselben Hardware liefert vLLM 5.9× mehr Tokens pro Sekunde als Ollama bei 50 gleichzeitigen Nutzern. Bei der Bereitstellung von Modellen für ein Team spielt der Inferenz-Engine eine ebenso große Rolle wie die Parallelitätsstrategie.

Wann man auf Parallelität verzichten sollte

Nicht jede Konfiguration profitiert von der Aufteilung auf mehrere GPUs:

Das Modell passt problemlos auf 1 GPU – Parallelisierung erzeugt jedoch zusätzlichen Overhead. Nutzen Sie stattdessen 1 GPU und wenden Sie Datenparallelität an, um die Durchsatzrate zu erhöhen.
Kleine Modelle (7B–13B) auf Consumer-GPUs – Der Synchronisationsaufwand bei Tensor Parallelism kann dazu führen, dass 2× GPU langsamer arbeitet als 1× GPU bei kleinen Modellen. SGLang weist in solchen Fällen deutliche Leistungseinbußen auf.
Inferenz für einen einzelnen Nutzer – Sofern das Modell überhaupt auf einer GPU Platz findet, ist die Nutzung von 1 GPU meist einfacher und schneller.
Netzwerkgeschwindigkeit unterhalb von 10 GbE zwischen Knoten – Bei langsamen Verbindungen kommt es zu Engpässen bei der Pipeline-Parallelisierung. In solchen Fällen sollte zuerst das Netzwerk verbessert werden.

Behebung häufig auftretender Probleme

Speicherüberlauf bei mehrfacher GPU-Nutzung mit vLLM

vLLM reserviert reichlich Speicher für CUDA-Graphen sowie KV-Cache. Auf 2× RTX 3090 (Gesamtspeicher 48 GB) kann ein 32B-Modell zu einem Speicherüberlauf führen, obwohl Ollama damit problemlos umgeht. Reduzieren Sie --gpu-memory-utilization vom Standardwert 0.90:

vllm serve your-model \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.80

Fehler bei NCCL-Verbindungen

Falls GPUs nicht miteinander kommunizieren können, prüfen Sie Folgendes:

nvidia-smi topo -m – Überprüfen Sie die NVLink- bzw. PCIe-Topologie
NCCL_DEBUG=INFO – Stellen Sie fest, welchen Übertragungsweg NCCL wählt
Firewall-Regeln für Port 29500 (der Standard-Port für NCCL-Rendezvous)

Gemischte GPU-Typen

vLLM unterstützt heterogene GPU-Konfigurationen; doch die Leistung wird durch die langsamste GPU begrenzt. Zur Erzielung optimaler Ergebnisse empfiehlt es sich, identische GPUs zu verwenden. Bei gemischten Konfigurationen sollten mehr Schichten der schnelleren GPU zugewiesen werden, indem man die Pipeline-Parallelität mit ungleicher Verteilung der Phasen nutzt.

Multi-GPU-Deployments über Tokios bereitstellen

Unabhängig davon, ob Sie TP, PP oder beides nutzen, stellt Ihr vLLM- oder SGLang-Server ein OpenAI-kompatibles /v1 API auf dem lokalen Rechner bereit. Starten Sie den Tokios-Connector auf derselben Maschine, wird Ihre Deployment-Instanz von jedem Gerät, Agenten oder Teammitglied erreichbar – ohne dass eingehende Ports geöffnet werden müssen.

# Start vLLM with tensor parallelism
vllm serve your-model --tensor-parallel-size 2

# Pair the Tokios connector
curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX

Die vollständige Anleitung finden Sie im Leitfaden für den Fernzugriff auf vLLM.

Weitere Schritte

Modell-Bereitstellung und Skalierung

Verstehen Sie, wie Inferenz-Engines Speicher, Batching sowie KV-Caches verwalten.

Anwendungsfall für DGX Spark

Richten Sie Tokios auf einem DGX Spark- oder einem 2-Spark-Cluster ein.

Fernzugriff auf vLLM

Stellen Sie Ihren vLLM-Server von überall aus sicher zur Verfügung.

Leitfaden zur Quantisierung

Verkleinern Sie Modelle, damit sie auf weniger GPUs passen, bevor Sie auf Parallelverarbeitung zurückgreifen.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Tensor-Parallelismus im Vergleich zu Pipeline-Parallelismus bei der lokalen Inferenz von großen Sprachmodellen

Kurzfassung

Erläuterung zum Tensor-Parallelismus

Erläuterung zur Pipeline-Parallelisierung

Entscheidungsmatrix

Empfehlungen je nach Hardware

Dataparallelismus sowie Expertenparallelismus

Beispiele für Konfigurationen

vLLM in Kombination mit Tensor Parallelism

vLLM mit Pipeline-Parallelismus

Hybride Tensor-Parallelität sowie Pipeline-Parallelismus (für große Modelle auf mehreren Knoten)

SGLang mit Tensor-Parallelismus

NCCL-Umgebungsvariablen

Leistungsvergleich

Wann man auf Parallelität verzichten sollte

Behebung häufig auftretender Probleme

Speicherüberlauf bei mehrfacher GPU-Nutzung mit vLLM

Fehler bei NCCL-Verbindungen

Gemischte GPU-Typen

Multi-GPU-Deployments über Tokios bereitstellen

Weitere Schritte

Modell-Bereitstellung und Skalierung

Anwendungsfall für DGX Spark

Fernzugriff auf vLLM

Leitfaden zur Quantisierung

​Kurzfassung

​Erläuterung zum Tensor-Parallelismus

​Erläuterung zur Pipeline-Parallelisierung

​Entscheidungsmatrix

​Empfehlungen je nach Hardware

​Dataparallelismus sowie Expertenparallelismus

​Beispiele für Konfigurationen

​vLLM in Kombination mit Tensor Parallelism

​vLLM mit Pipeline-Parallelismus

​Hybride Tensor-Parallelität sowie Pipeline-Parallelismus (für große Modelle auf mehreren Knoten)

​SGLang mit Tensor-Parallelismus

​NCCL-Umgebungsvariablen

​Leistungsvergleich

​Wann man auf Parallelität verzichten sollte

​Behebung häufig auftretender Probleme

​Speicherüberlauf bei mehrfacher GPU-Nutzung mit vLLM

​Fehler bei NCCL-Verbindungen

​Gemischte GPU-Typen

​Multi-GPU-Deployments über Tokios bereitstellen

​Weitere Schritte

Modell-Bereitstellung und Skalierung

Anwendungsfall für DGX Spark

Fernzugriff auf vLLM

Leitfaden zur Quantisierung

Kurzfassung

Erläuterung zum Tensor-Parallelismus

Erläuterung zur Pipeline-Parallelisierung

Entscheidungsmatrix

Empfehlungen je nach Hardware

Dataparallelismus sowie Expertenparallelismus

Beispiele für Konfigurationen

vLLM in Kombination mit Tensor Parallelism

vLLM mit Pipeline-Parallelismus

Hybride Tensor-Parallelität sowie Pipeline-Parallelismus (für große Modelle auf mehreren Knoten)

SGLang mit Tensor-Parallelismus

NCCL-Umgebungsvariablen

Leistungsvergleich

Wann man auf Parallelität verzichten sollte

Behebung häufig auftretender Probleme

Speicherüberlauf bei mehrfacher GPU-Nutzung mit vLLM

Fehler bei NCCL-Verbindungen

Gemischte GPU-Typen

Multi-GPU-Deployments über Tokios bereitstellen

Weitere Schritte