Zum Hauptinhalt springen
Ein Modell vom Typ 70B in FP16-Genauigkeit benötigt etwa 140 GB an VRAM. Keine herkömmliche Consumer-GPU verfügt über so viel Speicher. Mittels Sharding teilen Inferenz-Engines ein Modell auf mehrere GPUs – oder mehrere Rechner – auf, sodass Modelle genutzt werden können, die physisch nicht auf ein einzelnes 1-Gerät passen, oder mehr Nutzer als ein einzelnes 1-Gerät bewältigen kann. Auf dieser Seite werden die verschiedenen 4-Sharding-Strategien erläutert, wie jede davon die Arbeitslast verteilt und welche zu Ihrer Hardware passt. Für eine schnelle Entscheidung zwischen Tensor- und Pipeline-Parallelismus siehe Tensor- vs. Pipeline-Parallelismus.

​
Warum Sharding nutzen?

You reach for sharding when 1 of 4 things is true:
  1. Das Modell ist für die 1-GPU zu groß. Ein 70B dichtes Modell im FP16-Format benötigt etwa 140 GB Speicherplatz. Selbst bei einer Q4-Quantisierung (~35 GB) wird der Speicherplatz einer einzelnen RTX 4090 (24 GB) vollständig ausgeschöpft. Um alle Gewichte unterzubringen, benötigen Sie mindestens 2 GPUs.
  2. Man benötigt eine geringere Latenz pro Token. Wenn jede GPU gleichzeitig zu jedem Token beiträgt, verringert sich die Gesamtzeit pro Token.
  3. Man benötigt eine höhere Durchsatzrate. Mehr GPUs ermöglichen es, mehr Nutzer parallel zu bedienen.
  4. Man benötigt Redundanz. Durch den Betrieb von 2 Replikaten hinter einem Lastverteiler kann ein Ausfall von 1 GPUs ohne Betriebsunterbrechung kompensiert werden.
Falls das Modell bereits auf 1 GPUs Platz findet und Sie keinerlei Probleme mit der Durchsatzrate haben, bleiben Sie bei der Verwendung von 1 GPUs. Die Aufteilung des Modells erhöht die Komplexität sowie den Kommunikationsaufwand.

​
Wohin fließt der Speicherplatz Ihrer GPU eigentlich?

Bevor Sie sich für eine Sharding-Strategie entscheiden, sollten Sie wissen, welche Komponenten um den VRAM konkurrieren. Es sind nicht nur die Modellgewichte: A 24 GB RTX 4090 running a 70B Q4 model has ~35 GB of weights — it does not fit on 1 GPU at all. With TP=2, each GPU holds ~17.5 GB of weights and has ~6.5 GB left for KV cache and overhead. That is enough for short contexts and a few concurrent users, but not much more.
Der nutzbare Speicher ist geringer als die GesamtvRAM-Kapazität. Auf einem DGX Spark (128 GB gemeinsamer Speicher) stehen nach Belegung durch Betriebssystem und Laufzeitumgebung rund 110 GB für Modell und KV-Cache zur Verfügung. Bei dedizierten GPUs regelt der Parameter --gpu-memory-utilization von vLLM (Standardwert 0.90) diesen Wert. Setzen Sie ihn niedriger, falls es zu Speicherüberläufen kommt.
Bei MoE-Modellen gestaltet sich die Aufteilung anders – die Speicherplätze der Experten dominieren hier. Aus diesem Grund existiert die Experten-Parallelität: Anstatt alle 231 GB an Modulen auf jede GPU zu laden, enthält jede GPU lediglich die ihr zugewiesenen Module. Weitere Informationen finden Sie unter Experten-Parallelität.

​
2 Entscheidungen: Zuerst die Passung sicherstellen, anschließend die Geschwindigkeit optimieren

Die Aufteilung beantwortet 2 Fragen in folgender Reihenfolge: Passung sicherstellen – die Gewichte (sowie ausreichend Speicherplatz für den KV-Cache) müssen in das verfügbare GPU-Speichervolumen passen:
  • Zuerst quantisieren. Der Wechsel von FP16 zu Q4 reduziert den Speicherbedarf der Gewichte um etwa 4-fach. Dies ist der kostengünstigste Optimierungsschritt. Weitere Details finden Sie in der Quantisierungsanleitung.
  • Auf mehrere GPUs verteilen. Falls die Quantisierung allein nicht ausreicht, sollte das Modell mittels TP, PP oder EP aufgeteilt werden.
  • Pruning von Experten (nur bei MoE). Bei MoE-Modellen mit insgesamt 256 Experten, wobei pro Token lediglich 6 aktiv werden, reduziert das REAP-Pruning die Gewichte der gerouteten Experten nahezu um die Hälfte, ohne die aktuelle Rechenleistung zu beeinflussen.
Geschwindigkeit erhöhen – sobald das Modell passt, sollten die Bytes pro Token sowie die Dekodierungsschritte minimiert werden.
  • Die passende Parallelisierung wählen. TP sorgt für die geringste Latenz pro Token. PP kompensiert langsame Netzwerkkonnektivitäten. DP erhöht die Gesamtdurchsatzrate.
  • Nutzen Sie den dokumentierten spekulativen Pfad des Modells. Bei DeepSeek-V4-Flash-0731 muss das mitgelieferte DSpark-Modul mittels der offiziellen vLLM- oder SGLang-Parameter aktiviert werden. Ein separater Entwurfs-Checkpoint ist nicht erforderlich. Weitere Infos finden Sie unter Model-Serving und Skalierung.
  • KV-Cache und Batch-Größe anpassen. Ein größerer KV-Cache ermöglicht mehr gleichzeitige Nutzer. Details dazu liefert Speichereinstellungen für DGX Spark.

​
Ein kurzer Überblick über die verschiedenen 4 Sharding-Strategien

DeepSeek-V4-Flash-0731 is a practical sharding case: 13B active parameters lower per-token compute, but all 284B parameters still need resident weight memory. See DeepSeek V4 Flash local hardware for the memory floor and the maturity of each 2-device route.

​
Tensor-Parallelismus: Aufteilung von Schichten auf mehrere GPUs

Beim Tensor-Parallelismus werden die Gewichtsmatrizen jeder Schicht auf mehrere GPUs verteilt. Jede GPU speichert einen Teil jeder Schicht und alle GPUs verarbeiten dasselbe Token gleichzeitig.
Nach jeder Schicht führen die GPUs eine AllReduce-Operation durch, wobei sie ihre Teilresultate zu einem vollständigen Ausgabewert kombinieren. Dadurch bleibt die Latenz pro Token gering, doch erfordert dies eine hohe Bandbreite zwischen den GPUs. Speicherbedarf: Jede GPU speichert 1/N Anteil der Modellgewichte; dabei entspricht N dem Grad des Tensor-Parallelismus. Ein Modell mit 70B Parametern bei Q4 (~35 GB) und TP=2 benötigt pro GPU etwa 17.5 GB Speicherplatz. Latenz: Die geringste Latenz pro Token. Da alle GPUs jedes Token verarbeiten, ergibt sich die Gesamtzeit aus der eigentlichen Rechenzeit sowie der Synchronisation mittels AllReduce. Ideal geeignet für: 2 bis 4 GPUs, die über NVLink oder einen schnellen PCIe-Bus miteinander verbunden sind. Besonders geeignet ist die 200 Gb/s QSFP-Verbindung zwischen den 2 DGX Sparks-Systemen. vLLM-Parameter: --tensor-parallel-size 2
Im Vergleich zu NVLink bietet PCIe bei AllReduce-Operationen nur 3 bis 5-fach weniger Bandbreite. Tensor-Parallelismus über PCIe funktioniert dennoch; eine typische Konfiguration ist 2-fach RTX 4090 bei TP=2. Dennoch ist die Decodierleistung um 20 bis 30% geringer als bei GPUs mit NVLink-Verbindung.

​
Beispiel: 70B auf 2-fach RTX 4090

Jede GPU speichert etwa 17.5 GB an Q4-Gewichten. Die verbleibenden etwa 6.5 GB pro GPU dienen dem KV-Cache sowie CUDA-Graphen.

​
Pipeline-Parallelismus: sequenzielle Aufteilung der Schichten

Beim Pipeline-Parallelismus werden zusammenhängende Schichtgruppen verschiedenen GPUs zugewiesen. GPU 0 verwaltet die Schichten 0 bis 19, GPU 1 die Schichten 20 bis 39. Token durchlaufen die Pipeline ähnlich wie auf einer Fließbandlinie.
Jede GPU verarbeitet ihre zugewiesenen Schichten und leitet die Aktivierungen an die nächste Stufe weiter. Die zwischen den GPUs ausgetauschten Daten sind Aktivierungstensoren an einer einzelnen Schichtgrenze – deutlich kleiner als die vollständigen Gewichtsmatrizen, die beim Tensor-Parallelismus übertragen werden. Speicher: Jede GPU beherbergt ihren Anteil an Schichten. Bei PP=2 verwaltet GPU 0 die erste Hälfte des Modells, GPU 1 die zweite Hälfte. Latenz: additiv. Ein Token muss nacheinander alle Stufen durchlaufen. Bei PP=2 entspricht die Latenz ungefähr der Summe beider Stufen. Kommunikation: punktuelle Übertragungen zwischen benachbarten Stufen. Nur benachbarte GPUs kommunizieren, weshalb der Bandbreitenbedarf gering bleibt. Dies macht den Pipeline-Parallelismus ideal für langsamere Verbindungen wie PCIe, Ethernet oder Netzwerkverbindungen zwischen Rechnern. Das Blasen-Problem: Bei kleinen Batch-Größen bleiben spätere GPUs untätig, während frühere GPUs ihre Schichten verarbeiten. Bei PP=2 und einer Batch-Größe von 1 wartet GPU 1 stets darauf, dass GPU 0 jede einzelne Schicht abgeschlossen hat. Größere Batches mindern diesen Effekt; vLLMs kontinuierliches Batching hilft dabei, die Pipeline zu füllen. vLLM-Flag: --pipeline-parallel-size 2

​
Wann der Pipeline-Parallelismus dem Tensor-Parallelismus vorzuziehen ist

Man sollte Pipeline-Parallelismus statt Tensor-Parallelismus nutzen, wenn:
  • Die GPUs sich auf verschiedenen Rechnern befinden, die über ein Netzwerk verbunden sind (10GbE bis 100GbE).
  • GPUs werden über PCIe miteinander verbunden; das Modell ist zudem klein genug, sodass die durch PP entstehenden Speicherverschwendungen geringer ausfallen als die Bandbreitenkosten bei TP-AllReduce.
  • Man kombiniert mehrere 3+ Knoten, wobei eine TP-Deployment über alle Knoten hinweg die verfügbare Interconnect-Bandbreite vollständig auslastet.

​
Dataparallelismus: Ausführung desselben Modells auf mehreren GPUs

Beim Dataparallelismus (DP) wird eine vollständige Kopie des Modells auf jeder GPU gespeichert; eingehende Anfragen werden dabei auf alle GPUs verteilt. Während der Inferenz findet keine Kommunikation zwischen den GPUs statt – jede GPU verarbeitet ihre eigenen Anfragen eigenständig.
Speicherbedarf: Es werden N Kopien des gesamten Modells benötigt. Ein Modell vom Typ 7B mit Q4 (etwa 4 GB Umfang) erfordert bei DP=4 insgesamt 16 GB Speicherplatz auf 4 GPUs. Dieser Aspekt ist besonders kostspielig – man tauscht Speicherkapazität gegen höhere Durchsatzraten ein. Latenz: Sie entspricht der Latenz bei der Nutzung einer einzigen GPU; jede GPU verarbeitet Tokens unabhängig voneinander. Durchsatz: Er erhöht sich linear. 4 Instanzen des Modells können etwa 4-mal so viele Nutzer gleichzeitig bedienen. Geeignet für: Modellen, die auf einer 1 GPU Platz finden (7B, 14B – gelegentlich auch 32B bei starker Quantisierung), wenn gleichzeitig viele Nutzer bedient werden müssen. vLLM-Einrichtung: Starten Sie mehrere vLLM-Instanzen und platzieren Sie anschließend einen Load Balancer davor.
Anschließend nutzen Sie nginx, HAProxy oder einen beliebigen Round-Robin-Balancer, um /v1/chat/completions Anfragen auf beide Ports zu verteilen.

​
Expertenparallelismus: Einsatz bei Modellen mit gemischten Experten

Expert parallelism (EP) applies only to mixture-of-experts (MoE) models. In an MoE model, each token activates only a small subset of the model’s “experts” — for example, Qwen3-235B has 256 routed experts but only 6 fire per token (~22B active parameters out of 235B total). EP puts different experts on different GPUs so you do not waste memory storing inactive experts everywhere.
Speicher: Jede GPU speichert lediglich die ihr zugewiesenen Experten. Der dichte Modell-Teil (Aufmerksamkeitsmechanismen, Embeddings sowie gemeinsam genutzte Schichten – etwa 14 GB bei 4 Bit für Qwen3-235B) wird auf allen GPUs repliziert. Die Experten-Teile (etwa 231 GB bei 2 Bit) werden hingegen fragmentiert verteilt. Dies spart deutlich mehr Speicherplatz als die Tensor-Parallelisierung, bei der alle 256 Experten auf jeder GPU vorhanden wären, obwohl die meisten pro Token ungenutzt bleiben. Kommunikation: Es findet ein All-zu-All-Austausch zwischen den GPUs statt. Sobald der Router für ein Token einen Experten auf einer anderen GPU auswählt, muss die Aktivierung dorthin übertragen werden. Dadurch entstehen unterschiedliche Datenverkehrsmuster: Einige Tokens bleiben lokal, andere erfordern den Austausch zwischen mehreren GPUs. vLLM-Parameter: --enable-expert-parallel in Kombination mit --tensor-parallel-size
Das verfügbare Speichervolumen von 128 GB auf DGX Spark eignet sich hervorragend für die Experten-Parallelisierung. Ein einzelner Spark-Cluster mit etwa 110 GB nutzbarem Speicher kann den dichten Modell-Teil sowie einen großen Teil der Experten lokal speichern, wodurch der durch die Experten-Parallelisierung verursachte Datenverkehr zwischen GPUs reduziert wird. Bei Modellen wie Qwen3-235B, bei denen selbst die Experten-Parallelisierung auf 1 Knoten nicht ausreicht, empfiehlt sich die Kombination aus Experten-Pruning und einer 2-Bit-Quantisierung, um den Speicherbedarf pro Knoten zu begrenzen. Weitere Informationen zu den Hardware-Eigenschaften finden Sie im Anwendungsbeispiel für DGX Spark.

​
Kombination verschiedener Strategien: Tensor-Parallelisierung, Pipeline-Parallelisierung sowie Deployment-Parallelisierung

Bei Verwendung vieler GPUs werden diese Strategien hierarchisch kombiniert:
  • Tensor-Parallelisierung innerhalb eines Knotens, wo die Verbindung zwischen GPUs besonders schnell ist.
  • Pipeline-Parallelisierung über mehrere Knoten, bei der die Verbindung langsamer ausfällt.
  • Deployment-Parallelisierung zur Steigerung der Durchsatzrate: Hierbei werden mehrere Instanzen der kombinierten Tensor- und Pipeline-Parallelisierung gleichzeitig betrieben.

​
4 GPUs: Tensor-Parallelisierung=2 sowie Pipeline-Parallelisierung=2

Dadurch entstehen 2 Pipeline-Stufen, wobei jede Stufe die 2-fache Tensor-Parallelisierung nutzt. Die GPUs 0 und 1 verarbeiten die erste Hälfte der Schichten mittels Tensor-Parallelisierung, während GPUs 2 und 3 die zweite Hälfte übernehmen.

​
8 GPUs: Tensor-Parallelisierung=4 sowie Deployment-Parallelisierung=2

Starten Sie 2 Replikate einer Tensor-Parallel-Setup-Konfiguration mit 4 Wegen. Jedes Replikat nutzt 4 GPUs für die Tensor-Parallelität; ein Lastverteiler leitet Anfragen an die 2 Replikate weiter. Dadurch erhalten Sie die geringe Latenz von TP=4 bei einer um 2-fach höheren Durchsatzrate.

​
Eine Faustregel

  1. Zuerst TP – über den schnellsten verfügbaren Interconnect (NVLink, QSFP, PCIe).
  2. Anschließend PP – über langsamere Verbindungen (Ethernet, Netzwerke zwischen Rechnern).
  3. Zuletzt DP – falls Sie mehr Durchsatz benötigen und zusätzliche GPUs für weitere Replikate zur Verfügung stehen.
Für vLLM ist TP × PP = total GPUs used for one replica erforderlich. Bei Angabe von --tensor-parallel-size 4 --pipeline-parallel-size 2 nutzt vLLM 8 GPUs für das Erstellen von 1 Replikaten.

​
Entscheidungsmatrix für die Aufteilung der Last

70B, 2× RTX 4090 (PCIe)

PP. Die Bandbreite von PCIe reicht nicht aus, um AllReduce effizient durchzuführen. Pipeline-Parallelität verhindert dieses Engpass-Problem.

70B, 2× A100 (NVLink)

TP. NVLink bietet ausreichend Bandbreite für AllReduce; die Latenz pro Token verringert sich dadurch.

235B MoE, DGX Spark

EP. Native MoE-Verarbeitung – jede GPU speichert lediglich ihre eigenen Experten, nicht das gesamte 235B.

7B, hohes Datenaufkommen

DP. Das Modell passt auf eine einzige 1-GPU. Mehrere Instanzen erhöhen die Durchsatzrate.

70B, 4× A100 (NVLink)

TP=4 (oder TP=2 + DP=2, falls die Durchsatzrate wichtiger ist als die Latenz).

70B, 2 Rechner

PP=2. Das Netzwerk zwischen den Rechnern ist für TP zu langsam; die Pipeline-Architektur umgeht dieses Bandbreitenproblem.

​
Praktische Befehle

​
Überprüfen, ob die Aufteilung korrekt funktioniert

Führen Sie nvidia-smi auf jeder GPU aus. Alle beteiligten GPUs sollten den für das Modell reservierten Speicher anzeigen:
Bei TP=2 sollte der Speicherverbrauch auf beiden GPUs etwa gleich sein. Bei PP=2 kann die Verteilung ungleichmäßig ausfallen, falls die ersten Modellschichten anders groß sind als die späteren.

​
Häufige Fehler

Einsatz von Tensor-Parallelismus bei langsamen PCIe-Verbindungen. Bei AllReduce werden Aktivierungsdaten nach jeder Schicht übertragen. Auf PCIe 3.0 führt dies zu erheblichen Einbußen bei der Decodierungsgeschwindigkeit. Falls Ihre GPUs keinen NVLink unterstützen, sollten Sie Pipeline-Parallelismus testen und beide Methoden vergleichen. Anwendung von Pipeline-Parallelismus mit einem Batch-Volumen von 1. Der sogenannte Pipeline-Blaseffekt verursacht den größten Rechenaufwand, wenn lediglich 1 Token gleichzeitig verarbeitet werden. Die kontinuierliche Batch-Verarbeitung in vLLM mindert dieses Problem – achten Sie darauf, genügend gleichzeitige Anfragen zu senden, um die Pipeline vollständig auszulasten. Forgetting that DP requires N× model memory. 4 replicas of a 70B Q4 model (~35 GB each) need 140 GB total. Plan memory before adding replicas. Vernachlässigung des KV-Cache-Bedarfs. Die Modellgewichte machen nur einen Teil des GPU-Speichers aus; der KV-Cache für aktive Sequenzen beansprucht den Rest. Bei Aufteilung der Gewichte auf 2 GPUs wird auch der KV-Cache verteilt – dadurch erhöht sich die Anzahl gleichzeitig verarbeitbarer Nutzer. Wer jedoch nur den Speicherbedarf für die Gewichte einplant, läuft schnell in einen Speicherüberlauf. Berücksichtigen Sie daher Gewichte, KV-Cache sowie ca. 3 GB Overhead bei der Auswahl der Aufteilungsstrategie. Falsche Reihenfolge bei Kombination von Tensor- und Pipeline-Parallelismus. vLLM wendet Tensor-Parallelismus innerhalb jedes Pipeline-Stadiums an. Setzen Sie --tensor-parallel-size auf die Anzahl der GPUs pro Knoten und --pipeline-parallel-size auf die Gesamtanzahl der Knoten. Umgekehrte Einstellungen führen dazu, dass Pipeline-Parallelismus innerhalb eines Knotens genutzt wird – wodurch die schnellen Interconnects verschwendet werden – und Tensor-Parallelismus über Knotengrenzen hinweg, was die Netzwerklast durch AllReduce erhöht.

​
Nächste Schritte

Tensor-Parallelismus im Vergleich zu Pipeline-Parallelismus

Detaillierter Vergleich von Tensor- und Pipeline-Parallelismus inklusive Leistungsmessungen.

Einsatz von einem oder zwei DGX Spark-Systemen

Wann ein zweites Spark-System sinnvoll ist sowie Konfiguration der 200 GB/s-Verbindung.

Speichereinstellungen für DGX Spark

Berechnung des KV-Cache-Bedarfs sowie Speicherparameter bei verteilten Deployment-Szenarien.

Bereitstellung und Skalierung von Modellen

Wie Inferenz-Engines das Batching, die Genauigkeit sowie den Parallelismus verwalten.