70B-Modelle self-hosted: vLLM auf mehrere GPUs verteilen

TL;DR

Ein Llama-3.3-70B-Modell braucht in FP16 rund 140 GB VRAM — mehr als jede einzelne GPU hat. Mit vLLM und --tensor-parallel-size verteilen Sie das Modell auf 2 bis 4 GPUs innerhalb eines Servers, über mehrere Server hinweg kombinieren Sie es mit Ray und --pipeline-parallel-size. Continuous Batching hält dabei den Durchsatz bei vielen Nutzern hoch.

Wer ein 70B-Modell im eigenen Rechenzentrum betreiben will, stößt sofort auf ein hartes Limit: Das Modell passt nicht auf eine GPU. Eine H100 hat 80 GB VRAM, Llama-3.3-70B in voller Präzision belegt aber rund das Doppelte. Die Frage ist also nicht "welche GPU kaufe ich", sondern "wie verteile ich das Modell sauber über mehrere GPUs, ohne dass der Durchsatz einbricht".

Genau dafür ist vLLM gebaut. Für den Single-Node-Einstieg mit kleineren Modellen haben wir die Ollama-Installation auf Ubuntu beschrieben — hier geht es eine Stufe höher: um Modelle, die keine einzelne Karte mehr fassen kann.

Warum eine GPU nicht reicht

Rechnen wir es durch. Die Faustformel für den reinen Gewichtsspeicher lautet: Parameterzahl × Bytes pro Parameter. Bei 70 Milliarden Parametern in FP16 (2 Byte) sind das grob 140 GB — nur für die Gewichte. Dazu kommt der KV-Cache, der mit jeder gleichzeitigen Anfrage und jedem Token Kontextlänge wächst. Realistisch sollten Sie bei FP16 also 150 GB oder mehr einplanen.

Keine aktuelle Einzel-GPU liefert das. Die Konsequenz: Sie brauchen entweder mehrere GPUs oder Quantisierung — meistens beides. vLLM löst den ersten Teil über Tensor-Parallelismus.

Die INT4-Zahl von rund 35 GB ist der Grund, warum viele Mittelständler mit quantisierten 70B-Modellen anfangen: Sie kommen mit deutlich weniger Hardware aus. Der Preis dafür ist ein leichter Qualitätsverlust, der bei AWQ in der Praxis oft im einstelligen Prozentbereich liegt. Unsere Empfehlung: FP16 nur, wenn Sie den maximalen Output brauchen und die GPUs ohnehin da sind. Für die meisten internen Assistenten und RAG-Systeme reicht AWQ INT4.

Tensor-Parallelismus: das Modell in Scheiben schneiden

Tensor-Parallelismus zerlegt jede einzelne Gewichtsmatrix in Stücke und verteilt sie auf die verfügbaren GPUs. Jede Karte berechnet ihren Teil, danach werden die Ergebnisse zusammengeführt. Der große Vorteil: Die Rechenlast einer einzelnen Anfrage wird auf mehrere GPUs verteilt, nicht nur der Speicher.

In vLLM steuern Sie das über einen einzigen Parameter. So starten Sie ein 70B-Modell auf zwei GPUs:

# vLLM-Server für Llama-3.3-70B auf 2 GPUs (FP16)
# tensor-parallel-size = Anzahl GPUs im Server
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --port 8000

Wichtig ist eine Regel, an der viele Setups scheitern: --tensor-parallel-size muss die Anzahl der Attention-Heads des Modells glatt teilen. Llama-3.3-70B hat 64 Heads. 2, 4, 8 gehen also — 3 oder 5 nicht. Verwenden Sie deshalb Werte, die eine Zweierpotenz sind und zur Head-Zahl passen. Setzen Sie den Wert höher als die tatsächlich vorhandenen GPUs, bricht der Start mit einem Fehler ab.

--gpu-memory-utilization legt fest, welchen Anteil des VRAM vLLM belegen darf. Der Default liegt bei 0.90. Lassen Sie ihn hoch, denn der freie Speicher geht direkt in den KV-Cache — und der KV-Cache bestimmt, wie viele Anfragen Sie parallel bedienen können.

Die quantisierte Variante

Wollen Sie mit weniger Hardware auskommen, laden Sie ein vorquantisiertes Modell. AWQ-Gewichte sind in vLLM besonders schnell, weil das Layout gut zu den INT4-Kernels passt:

# AWQ-quantisiertes 70B-Modell, passt auf 2× A100 40GB
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
  --quantization awq \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 16384 \
  --port 8000

Durch den geringeren Gewichtsspeicher bleibt bei INT4 mehr Platz für den KV-Cache — Sie können also --max-model-len höher setzen oder mehr parallele Nutzer bedienen.

Warum der KV-Cache über die Nutzerzahl entscheidet

Der KV-Cache ist der am meisten unterschätzte Faktor im Cluster-Betrieb. Vereinfacht gilt: Jede aktive Anfrage reserviert Speicher proportional zu ihrer Kontextlänge. Wer viele Nutzer mit langen Kontexten gleichzeitig bedienen will, braucht entsprechend viel freien VRAM neben den Modellgewichten.

Genau hier zahlt sich Tensor-Parallelismus doppelt aus: Verteilen Sie das 70B-Modell auf 4 statt 2 GPUs, sinkt der Gewichtsanteil pro Karte, und mehr VRAM steht für den KV-Cache bereit. Das erhöht die Zahl gleichzeitiger Anfragen, nicht nur die Rohgeschwindigkeit. Wenn Ihre Auslastung also nicht an der Latenz einer Einzelanfrage hängt, sondern an der Zahl paralleler Nutzer, ist eine breitere GPU-Verteilung oft der wirksamere Hebel als die schnellere Einzel-GPU.

Ein praktischer Nebeneffekt: vLLM aktiviert Prefix-Caching, mit dem sich gemeinsame Prompt-Anfänge — etwa ein fixer System-Prompt für alle Nutzer — nur einmal berechnen lassen. Bei Assistenten mit standardisiertem System-Prompt spart das spürbar Rechenzeit.

Über mehrere Server: Ray und Pipeline-Parallelismus

Was, wenn ein einzelner Server nicht genug GPUs hat? Dann kombinieren Sie Tensor-Parallelismus (innerhalb eines Servers) mit Pipeline-Parallelismus (über Server hinweg). vLLM nutzt dafür Ray als verteilte Laufzeit.

Die Aufteilung ist logisch: --tensor-parallel-size entspricht der GPU-Zahl pro Node, --pipeline-parallel-size der Zahl der Nodes. Zwei Server mit je 8 GPUs ergeben also --tensor-parallel-size 8 --pipeline-parallel-size 2.

Zuerst starten Sie den Ray-Cluster. Auf dem Head-Node:

# Head-Node startet den Ray-Cluster
ray start --head --port=6379

# Worker-Node tritt bei (IP des Head-Nodes einsetzen)
ray start --address='192.168.10.5:6379'

Danach genügt ein einziger vllm-Befehl auf dem Head-Node — Ray sieht alle GPUs im Cluster und verteilt die Last:

# 2 Nodes × 8 GPUs = 16 GPUs, Ray verteilt automatisch
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray \
  --port 8000

Ein Punkt, der in der Praxis am häufigsten Ärger macht: Die Umgebung muss auf allen Nodes identisch sein — gleicher Modellpfad, gleiche Python-Umgebung, gleiche vLLM-Version. Der saubere Weg dafür ist ein einheitliches Docker-Image auf allen Maschinen. Wir raten davon ab, Nodes manuell mit pip zu synchronisieren; die erste abweichende Bibliotheksversion kostet Sie einen halben Tag Fehlersuche.

Und noch eine ehrliche Einordnung: Multi-Node über Ethernet ist langsamer als Multi-GPU innerhalb eines Servers, weil die Zwischenergebnisse über das Netzwerk müssen. Solange ein einzelner Server Ihre GPUs fasst, bleiben Sie bei Single-Node mit Tensor-Parallelismus. Multi-Node ist die Lösung für Modelle jenseits von 70B oder für sehr hohe Lastanforderungen, nicht der Default.

Der eigentliche Grund für vLLM: Durchsatz unter Last

Bei einer einzelnen Anfrage liefern Ollama und vLLM fast identische Tokens pro Sekunde — beide landen am Ende bei denselben Matmul-Kernels. Der Unterschied entsteht, sobald mehrere Nutzer gleichzeitig anfragen.

vLLM verwendet Continuous Batching und PagedAttention. Continuous Batching heißt: Neue Anfragen werden laufend in den Batch aufgenommen, statt auf einen freien Slot zu warten. PagedAttention verwaltet den KV-Cache in kleinen Blöcken und weist Speicher dynamisch nach aktiver Anfragenzahl zu — nicht als fixen Block beim Modellstart.

Der Effekt in Zahlen: Bei acht gleichzeitigen Nutzern liefert vLLM in Red-Hat-Benchmarks aus 2026 rund die 2,3-fache Durchsatzrate von Ollama, bei stabiler Tail-Latenz. Auf einer H100 mit einem 8B-Modell hält vLLM über 180 gleichzeitige Anfragen, bevor der Speicher überläuft, während viele fixe Allokations-Engines schon bei etwa 40 an ihre Grenze kommen (Benchmark-Details).

Für einen internen Assistenten mit 5 Testnutzern merken Sie davon nichts. Für 200 Sachbearbeiter, die gleichzeitig Dokumente zusammenfassen, ist es der Unterschied zwischen "läuft" und "Time-out". Genau diese Abwägung haben wir im Vergleich Ollama vs vLLM vs LocalAI im Detail aufgeschlüsselt.

Kurzvergleich: wann welcher Ansatz

Der Client bleibt gleich: OpenAI-kompatibel

Ein oft unterschätzter Vorteil: vLLM stellt eine OpenAI-kompatible API bereit. Ihre bestehenden Anwendungen sprechen den Cluster an, als wäre es die OpenAI-API — nur dass die Daten Ihr Haus nicht verlassen.

# Client-Zugriff auf den vLLM-Cluster — Standard-OpenAI-SDK
from openai import OpenAI

client = OpenAI(
    base_url="http://192.168.10.5:8000/v1",
    api_key="egal-lokal-ungeprueft",  # vLLM prüft den Key standardmäßig nicht
)

antwort = client.chat.completions.create(
    model="meta-llama/Llama-3.3-70B-Instruct",
    messages=[{"role": "user", "content": "Fasse diesen Wartungsbericht zusammen."}],
)
print(antwort.choices[0].message.content)

Das macht den Umstieg von der Cloud-API auf den eigenen Cluster zu einer Config-Änderung, nicht zu einem Rewrite. Für die Hardware-Seite — welche GPUs, welcher Server, welches Budget — ist unser KI-Server-Hardware-Guide die passende Ergänzung.

Worauf Sie beim Cluster-Betrieb achten sollten

• Attention-Heads prüfen: --tensor-parallel-size muss die Head-Zahl teilen (Llama-70B: 64). Sonst startet vLLM nicht.
• --max-model-len bewusst wählen: Lange Kontexte fressen KV-Cache. Setzen Sie ihn nur so hoch, wie Sie ihn wirklich brauchen.
• GPU-Interconnect zählt: NVLink zwischen den Karten macht Tensor-Parallelismus deutlich schneller als reines PCIe.
• Quantisierung zuerst evaluieren: AWQ INT4 halbiert den Hardware-Bedarf bei oft akzeptablem Qualitätsverlust. Testen Sie es mit Ihren eigenen Prompts, bevor Sie FP16-Hardware kaufen.
• Einheitliche Images: Bei Multi-Node identische Docker-Images auf allen Nodes — sonst zahlen Sie mit Debugging-Zeit.

Wer erst grundsätzlich klären will, ob On-Premise oder Cloud der richtige Weg ist, findet die Rechnung in unserem Self-Hosted-LLM-Kosten-Guide.

Häufig gestellte Fragen

Wie viele GPUs brauche ich für ein 70B-Modell mit vLLM?

In FP16 belegt Llama-3.3-70B rund 140 GB nur für die Gewichte — praktisch also 2× H100 80GB oder 4× L40S 48GB. Quantisieren Sie auf AWQ INT4, sinkt der Bedarf auf etwa 35 GB, dann reicht eine einzelne A100 80GB oder zwei kleinere Karten mit Tensor-Parallelismus.

Was ist der Unterschied zwischen Tensor-Parallelismus und Pipeline-Parallelismus?

Tensor-Parallelismus teilt jede Gewichtsmatrix über GPUs innerhalb eines Servers auf — schnell, weil per NVLink oder PCIe verbunden. Pipeline-Parallelismus teilt das Modell in aufeinanderfolgende Schichten über mehrere Server. In vLLM setzt man --tensor-parallel-size auf die GPU-Zahl pro Node und --pipeline-parallel-size auf die Node-Zahl.

Ist vLLM schneller als Ollama?

Bei einer einzelnen Anfrage nein — beide liefern ähnliche Tokens pro Sekunde. Unter Last dreht sich das Bild: Bei acht gleichzeitigen Nutzern erreicht vLLM in 2026er-Benchmarks rund die 2,3-fache Durchsatzrate, dank Continuous Batching und PagedAttention. Für viele parallele Nutzer ist vLLM die richtige Wahl, für einen Einzelplatz ist Ollama einfacher.

Kann ich vLLM ohne Kubernetes im Cluster betreiben?

Ja. Für Multi-Node genügt ein Ray-Cluster: Head-Node mit ray start --head, Worker mit ray start --address. vLLM sieht dann alle GPUs im Cluster und verteilt die Last automatisch. Kubernetes ist optional und lohnt sich erst, wenn Sie mehrere Modelle und Autoscaling brauchen.

Was kostet ein 70B-Cluster gegenüber der Cloud-API?

Das hängt am Auslastungsgrad. Zwei gebrauchte A100 40GB plus Server liegen im niedrigen fünfstelligen Bereich als Einmalinvestition. Ob sich das gegenüber einer nutzungsbasierten Cloud-API rechnet, hängt an Ihrem Token-Volumen — bei durchgehend hoher Auslastung amortisiert sich eigene Hardware oft innerhalb von 12 bis 24 Monaten.

Fazit und nächster Schritt

Ein vLLM-Cluster ist der Standardweg, um 70B-Modelle self-hosted zu betreiben: Tensor-Parallelismus verteilt das Modell über GPUs, Ray skaliert über Server, und Continuous Batching hält den Durchsatz bei vielen Nutzern hoch. Der Einstieg ist ein einzelner Befehl mit --tensor-parallel-size — die Komplexität kommt erst mit Multi-Node.

Wenn Sie gerade evaluieren, ob ein eigener 70B-Cluster für Ihre Anwendung Sinn ergibt, starten Sie mit einer quantisierten Variante auf zwei GPUs und messen Sie den Durchsatz mit Ihren echten Prompts, bevor Sie in FP16-Hardware investieren.