GPUs für vLLM-Inferenz richtig dimensionieren und konfigurieren

Eine passende GPU-Dimensionierung und Konfiguration für vLLM-Inferenz beginnt mit einem klaren Verständnis der beiden zentralen Phasen bei der Verarbeitung großer Sprachmodelle: Prefill und Decode. Beide Phasen belasten die Hardware unterschiedlich und beeinflussen dadurch die Auswahl der GPU, die Speicherplanung und die gesamte Bereitstellungsstrategie.

Dieser Leitfaden erläutert, wie sich vLLM zur Laufzeit verhält, erklärt wichtige Konzepte wie Speicherbedarf, Quantisierung und Tensor Parallelism und zeigt praxisnahe Methoden, um GPU-Entscheidungen an reale Workloads anzupassen. Wer diese Zusammenhänge versteht, kann Leistungsengpässe besser einschätzen und große Sprachmodelle fundierter sowie kosteneffizienter auf GPU-basierter Infrastruktur betreiben.

Wichtige Erkenntnisse

• Prefill- und Decode-Phasen bestimmen die Hardware-Anforderungen: Die Prefill-Phase verarbeitet Eingabe-Prompts und wird meist durch die Speicherbandbreite begrenzt. Sie beeinflusst direkt die Time-To-First-Token. Die Decode-Phase erzeugt Ausgabetoken und ist in der Regel rechenlastig, wodurch sie die Geschwindigkeit der Token-Generierung bestimmt.
• Die VRAM-Kapazität setzt die absolute Grenze: Sowohl Modellgewichte als auch der KV-Cache müssen in den verfügbaren GPU-Speicher passen. Ein 70B-Modell in FP16 benötigt allein für die Gewichte etwa 140 GB, weshalb Quantisierung für viele Single-GPU-Bereitstellungen entscheidend ist.
• Der KV-Cache wächst während der Laufzeit: Im Gegensatz zu festen Modellgewichten erweitert sich der KV-Cache abhängig von Kontextlänge und Anzahl paralleler Nutzer. Ein 70B-Modell mit 32k Kontext und 10 gleichzeitigen Nutzern benötigt ungefähr 112 GB für einen FP16-Cache oder 56 GB für einen FP8-Cache.
• Quantisierung ist der wichtigste Optimierungshebel: Wird die Präzision von FP16 auf INT4 reduziert, sinkt der Speicherverbrauch um etwa 75 %. Dadurch können größere Modelle auf kleineren GPUs betrieben werden. FP8-Quantisierung bietet auf moderner Hardware häufig das beste Verhältnis aus Geschwindigkeit und Qualität.
• Tensor Parallelism ermöglicht größere Modelle: Wenn ein Modell zu groß für eine einzelne GPU ist, verteilt Tensor Parallelism die Gewichte auf mehrere GPUs und kombiniert deren VRAM. Dies verursacht jedoch zusätzlichen Kommunikationsaufwand. Passt ein Modell auf eine einzelne GPU, ist der Single-GPU-Betrieb meist schneller.

Das Laufzeitverhalten von vLLM: Prefill vs. Decode

Die Prefill-Phase: „Lesen“

Die Prefill-Phase ist der erste Schritt bei der Verarbeitung einer Anfrage. vLLM übernimmt den vollständigen Eingabe-Prompt, also Nutzeranfrage, System-Prompt und gegebenenfalls zusätzlichen RAG-Kontext, und verarbeitet diesen stark parallelisiert.

• Was passiert: Das Modell liest den bereitgestellten Kontext und befüllt den Key-Value-Cache mit der mathematischen Repräsentation dieses Kontexts.
• Der Engpass: Da in dieser Phase tausende Token gleichzeitig verarbeitet werden, wird sie meist durch die Speicherbandbreite limitiert. Entscheidend ist, wie schnell die GPU große Gewichtsmatrizen aus dem VRAM in die Recheneinheiten übertragen kann.
• Praktische Auswirkung: Diese Phase bestimmt die Time-To-First-Token. Wenn beispielsweise ein sehr großes Dokument mit 100k Token zusammengefasst werden soll, sorgt die Prefill-Phase dafür, dass der Nutzer vor dem ersten generierten Wort warten muss.

Die Decode-Phase: „Schreiben“

Nach Abschluss der Prefill-Phase wechselt vLLM in eine autoregressive Generierungsschleife, um die Antwort zu erstellen.

• Was passiert: Das Modell erzeugt ein Token, fügt es der Sequenz hinzu und führt das Modell anschließend erneut aus, um das nächste Token zu erzeugen. Für eine einzelne Anfrage ist dieser Ablauf grundsätzlich sequenziell.
• Die Herausforderung: Sehr große Modellgewichte aus dem VRAM zu laden, nur um ein einzelnes Token für einen einzelnen Nutzer zu berechnen, ist ineffizient. In diesem Fall kann die GPU mehr Zeit mit Datentransfer als mit eigentlicher Berechnung verbringen.
• Die Lösung: Continuous Batching: Moderne Inferenz-Engines wie vLLM verarbeiten Anfragen nicht strikt nacheinander. Stattdessen nutzen sie Continuous Batching, bei dem Anfragen dynamisch in einen Batch aufgenommen und wieder entfernt werden. vLLM kann dabei Prefill-Arbeiten neuer Anfragen mit Decode-Schritten laufender Anfragen innerhalb desselben GPU-Zyklus kombinieren.
• Der Engpass: Wenn Batching effektiv funktioniert, wird die Decode-Phase rechengebunden. Ziel ist es, möglichst viele parallele Token-Berechnungen durchzuführen und den Gesamtdurchsatz zu maximieren.

Laufzeitphasen mit Workloads und Hardware verknüpfen

Die passende Hardware-Auswahl hängt stark davon ab, welche Laufzeitphase im jeweiligen Workload dominiert.

Der KV-Cache zur Laufzeit

Während der Inferenz nutzt vLLM intensiv einen KV-Cache, um bereits erledigte Berechnungen nicht erneut durchführen zu müssen.

• Die Funktionsweise: In einem Transformer-Modell wird jedes Token innerhalb der Attention-Layer in Key- und Value-Vektoren umgewandelt. Ohne Cache müsste das Modell den gesamten bisherigen Verlauf von Token 0 bis Token t erneut verarbeiten, nur um Token t+1 zu erzeugen.
• Die Lösung: Der KV-Cache speichert Key- und Value-Vektoren einmalig und verwendet sie während der Generierung wieder.
• Prefill: vLLM berechnet die Key- und Value-Vektoren für alle Prompt-Token und speichert sie direkt.
• Decode: Für jedes neue Token ruft vLLM den bisherigen Verlauf aus dem Cache ab und berechnet nur die Key- und Value-Vektoren für das neu generierte Token.
• Der Vorteil: Dadurch wird Attention von einem Prozess, der den gesamten Kontext immer wieder betrachtet, zu einem lineareren Ablauf, der sich auf das nächste Token konzentriert.
• Der Kompromiss: Der Leistungsvorteil wird mit zusätzlichem Speicherbedarf erkauft. Jedes erzeugte Token fügt dem Cache weitere Einträge hinzu.

Zur Laufzeit wächst der Speicherbedarf des KV-Caches dynamisch anhand mehrerer Faktoren:

• Prompt-Länge und Ausgabelänge: Längere Gespräche benötigen mehr VRAM.
• Parallelität: Jede aktive Anfrage benötigt einen eigenen, isolierten Cache.
• Modellgröße: Tiefere Modelle mit mehr Layern und breitere Modelle mit mehr Attention-Heads benötigen pro Token größere Cache-Strukturen.

Dieses Skalierungsverhalten erklärt, warum zwei Workloads mit demselben Modell sehr unterschiedliche Hardware-Anforderungen haben können. Ein 70B-Modell kann anfangs auf eine GPU passen, aber wenn der KV-Cache während einer langen Unterhaltung zu stark wächst, kann dem System der VRAM ausgehen. Das Verständnis dieses Speicherverhaltens ist deshalb für produktive Bereitstellungen zentral.

Grundlagen der Dimensionierung: Wie Modelle, Präzision und Hardware zusammenspielen

Nachdem das Laufzeitverhalten von vLLM klar ist, besteht der nächste Schritt darin zu prüfen, ob ein bestimmtes Modell auf einer bestimmten GPU ausgeführt werden kann und welche Kontextlänge oder Parallelität realistisch unterstützt wird.

Dieser Abschnitt beschreibt die benötigten Formeln und Entscheidungslogiken, um statische Speicheranforderungen zu berechnen, das Wachstum des KV-Caches abzuschätzen und Fit-Probleme strukturiert zu analysieren.

GPU-Hardware: Eigenschaften und Grenzen

Vor der Berechnung der Modellgröße ist es wichtig, den Hardware-Rahmen zu verstehen, in den das Modell passen muss. Unterschiedliche GPUs setzen unterschiedliche Grenzen für Machbarkeit und Leistung.

Typische VRAM-Kapazitäten von Data-Center-GPUs

Die folgenden Werte zeigen die festen Speichergrenzen gängiger GPUs, die für Inferenz-Workloads eingesetzt werden.

GPU-Vergleich für vLLM-Inferenz und Training

Auch wenn ein Modell in den VRAM passt, hat die GPU-Architektur erheblichen Einfluss auf die vLLM-Leistung. Die wichtigsten Kennzahlen sind:

Speicherbedarf der Modellgewichte: Statischer Speicher

Bevor vLLM Anfragen verarbeiten kann, müssen die Modellgewichte zunächst in den GPU-VRAM geladen werden. Wie viel Speicherplatz sie dabei belegen, hängt von der Anzahl der Modellparameter sowie vom verwendeten Präzisionsformat ab.

Formel für statische Gewichte

Der ungefähre VRAM-Bedarf in GB für Modellgewichte lässt sich wie folgt berechnen:

VRAM (GB) ≈ Parameter (Milliarden) × Bytes pro Parameter

Die folgende Tabelle zeigt, wie diese Berechnung für ein Llama-3.1-70B-Modell bei verschiedenen Präzisionsstufen aussieht.

Die Wahl der Präzision ist der stärkste Hebel für die Machbarkeit. Wird ein 70B-Modell von FP16 auf INT4 quantisiert, sinkt sein statischer Speicherbedarf um 75 %. Dadurch kann eine Bereitstellung, die auf einem einzelnen Node unmöglich wäre, auf einer einzelnen GPU mit hoher Speicherkapazität realisierbar werden. Quantisierung ist damit ein entscheidender Faktor für kosteneffiziente Deployments auf cloudbasierten GPU-Instanzen.

KV-Cache-Anforderungen: Dynamischer Speicher

Modellgewichte bestimmen, ob ein Modell starten kann. Der KV-Cache bestimmt jedoch, ob eine Bereitstellung skalieren kann. Der Speicherbedarf des KV-Caches wird häufig unterschätzt, was unter Last zu Out-of-Memory-Fehlern führen kann.

Für eine realistische Dimensionierung muss abgeschätzt werden, wie viel Speicher der Cache abhängig von Kontextlänge und Parallelität benötigt.

Praxisregel für eine schnelle Abschätzung

Für die meisten praktischen Workload-Gespräche ist die exakte Formel zu detailliert, um sie spontan zu berechnen. Eine einfachere Methode ist ein Speicherfaktor pro Token. Diese Näherung ist für erste Dimensionierungsentscheidungen meist ausreichend genau.

Vereinfachte KV-Cache-Formel:

Gesamter KV-Cache (MB) = Gesamttoken × Multiplikator

(Dabei gilt: Gesamttoken = Kontextlänge × Parallelität.)

Standard-Multiplikatoren

Beispielrechnung

Eine Bereitstellung soll Llama 3 70B mit einem 32k-Kontext und 10 gleichzeitigen Nutzern ausführen.

• Gesamttoken berechnen: 32.000 × 10 = 320.000 Token.
• Standard-Multiplikator anwenden: 320.000 × 0,35 MB = 112.000 MB, also 112 GB.
• FP8-Option prüfen: Mit aktiviertem FP8-Cache sinkt der Cache-Bedarf ungefähr auf die Hälfte, also etwa 56 GB.

Bewertung

• FP16-Cache: 112 GB Cache + 140 GB Gewichte = 252 GB Gesamtbedarf. Dafür werden ungefähr 4 GPUs der H100-Klasse benötigt.
• FP8-Cache: 56 GB Cache + 140 GB Gewichte = 196 GB Gesamtbedarf. Das passt ungefähr auf 3 GPUs der H100-Klasse oder kann auf 2 GPUs knapp werden, wenn zusätzlich die Gewichte quantisiert sind.

Exakte Berechnung und Tools

Für detaillierte Validierungen oder Randfälle kann die formale Formel oder ein Online-Rechner genutzt werden.

Online-Tool: LMCache KV Calculator

Formale Formel:

Gesamter KV-Cache (GB) = (2 × n_layers × d_model × n_seq_len × n_batch × precision_bytes) / 1024³

Wann Tensor Parallelism erforderlich ist

Tensor Parallelism ist eine Methode, bei der einzelne Gewichtsmatrizen eines Modells auf mehrere GPUs verteilt werden. Praktisch ermöglicht dies vLLM, mehrere GPUs wie ein größeres Gerät mit gemeinsam nutzbarem VRAM zu behandeln.

Warum Tensor Parallelism einsetzen?

Tensor Parallelism ist vor allem ein Werkzeug zur Machbarkeit und nicht primär eine Leistungsoptimierung. Es wird typischerweise aktiviert, wenn:

• Die Gewichte nicht passen: Das Modell ist zu groß für eine einzelne GPU, beispielsweise ein Llama-3-70B-Modell auf einer 24-GB-Karte.
• Kein Platz für den KV-Cache bleibt: Die Modellgewichte passen zwar, lassen aber kaum Speicher für lange Kontexte oder hohe Parallelität übrig.

Der Leistungsaufschlag durch Parallelisierung

Tensor Parallelism stellt deutlich mehr kombinierten Speicher bereit, verursacht aber zusätzlichen Kommunikationsaufwand. Nach jeder Rechenschicht müssen die GPUs ihre Teilergebnisse synchronisieren.

• Wenn das Modell auf eine GPU passt: Der Betrieb auf einer einzelnen GPU ist fast immer schneller als auf zwei GPUs, da keine Synchronisation zwischen GPUs erforderlich ist.
• Abhängigkeit vom Interconnect: Tensor Parallelism ist stark von schneller GPU-zu-GPU-Bandbreite abhängig. Wenn GPUs nur über Standard-PCIe statt über einen schnellen Interconnect wie NVLink kommunizieren, kann die Inferenzgeschwindigkeit durch Synchronisationslatenz deutlich sinken. Für Multi-GPU-Bereitstellungen können Container-Orchestrierungsplattformen genutzt werden, um vLLM-Workloads zuverlässig zu verwalten.

Für weitere Details dazu, wie Tensor Parallelism Modelle aufteilt und die Latenz beeinflusst, kann Hugging Face: Tensor Parallelism Concepts herangezogen werden.

Die Zahlen in der Praxis: Dimensionierungsszenarien

Bevor erweiterte Konfigurationen betrachtet werden, ist es sinnvoll, die vorherigen Formeln auf realistische Szenarien anzuwenden. So lässt sich das Konzept des „Fits“ validieren, und praktische Einschränkungen werden sichtbar, die reine Mathematik oft übersieht.

Die versteckte VRAM-Abgabe

Ein häufiger Fehler besteht darin, Gewichte und Cache zu addieren und davon auszugehen, dass der gesamte VRAM nutzbar ist. In der Praxis ist eine Auslastung von 100 % nicht möglich.

• CUDA-Kontext und Laufzeit: GPU-Treiber, PyTorch und die vLLM-Laufzeit reservieren bereits beim Initialisieren Speicher, oft etwa 2 bis 4 GB.
• Activation Buffers: Für Zwischenergebnisse während des Forward Pass wird temporärer Speicher benötigt.
• Sichere Dimensionierungsregel: Etwa 4 bis 5 GB VRAM sollten immer als nicht nutzbarer Overhead eingeplant werden. Wenn die Berechnung nur 0,5 GB freien Speicher übrig lässt, ist ein Absturz des Servers wahrscheinlich.

Szenario A: Der einfache Fit für Standard-Chat

Hardware: 1 × NVIDIA L40S mit 48 GB VRAM

Modell: Llama 3 8B in FP16

Berechnung:

• Gewichte: 8B Parameter × 2 Bytes = 16 GB
• Overhead: -4 GB
• Verbleibender Cache-Speicher: 48 – 16 – 4 = 28 GB

Cache-Kapazität:

28.000 MB / 0,15 MB pro Token = 186.000 Token.

Bewertung: Sehr guter Fit.

Diese Konfiguration kann große Workloads bedienen, beispielsweise 60 gleichzeitige Nutzer mit jeweils 3k Kontext.

Ergebnis: Hoher Durchsatz bei niedrigen Kosten.

Szenario B: Der Gewichtsfehler bei einem großen Modell auf einer einzelnen GPU

Hardware: 1 × NVIDIA H100 mit 80 GB VRAM

Modell: Llama 3 70B in FP16

Berechnung:

• Gewichte: 70B Parameter × 2 Bytes = 140 GB

Bewertung: Nicht realisierbar.

Die Modellgewichte benötigen 140 GB und überschreiten damit physisch die GPU-Kapazität von 80 GB.

Lösung: Tensor Parallelism mit 2 GPUs einsetzen oder Quantisierung anwenden.

Szenario C: Die Cache-Falle, wenn das Modell passt, aber kaum lauffähig ist

Hardware: 1 × NVIDIA H100 mit 80 GB VRAM

Modell: Llama 3 70B, auf FP8 quantisiert

Berechnung:

• Gewichte: 70B Parameter × 1 Byte = 70 GB
• Overhead: -4 GB
• Verbleibender Cache-Speicher: 80 – 70 – 4 = 6 GB

Cache-Kapazität:

6.000 / 0,175 MB pro Token bei FP8 = insgesamt 34.000 Token.

Bewertung: Riskant und schlecht ausbalanciert.

Das Modell lädt, aber für die eigentliche Workload-Ausführung bleibt fast kein Speicher übrig.

Auswirkung: Bei 10 gleichzeitigen Nutzern erhält jeder Nutzer nur etwa 3,4k Kontext. Wenn ein Nutzer ein längeres Dokument mit 4k Token einfügt, kann dem System der Speicher ausgehen.

Lektion: Passende Gewichte bedeuten nicht automatisch, dass der Workload passt. Dieses Szenario erfordert meist eine zweite GPU oder ein kleineres Modell.

Szenario D: Die Lösung mit Tensor Parallelism

Dieses Szenario verbessert die Cache-Falle durch das Hinzufügen einer zweiten GPU und zeigt, wie Tensor Parallelism Speicherressourcen bündelt.

Hardware: 2 × NVIDIA H100 mit jeweils 80 GB, zusammen 160 GB VRAM

Modell: Llama 3 70B, auf FP8 quantisiert

Berechnung:

• Gesamter VRAM: 160 GB
• Gewichte: -70 GB, verteilt auf beide GPUs
• Overhead: -8 GB, angenommen etwa 4 GB pro GPU
• Verbleibender Cache-Speicher: 160 – 70 – 8 = 82 GB

Cache-Kapazität:

82.000 / 0,175 MB pro Token bei FP8 = insgesamt 468.000 Token.

Bewertung: Produktionsbereit.

Durch die zweite GPU wächst der verfügbare Cache-Speicher von riskanten 6 GB auf deutlich stärkere 82 GB.

Auswirkung: Bei 10 gleichzeitigen Nutzern kann jeder Nutzer etwa 46k Kontext verwenden. Das Out-of-Memory-Risiko ist beseitigt, und die Bereitstellung kann RAG- oder Langdokument-Workloads zuverlässig bedienen.

Quantisierung: Modelle effizient komprimieren

Wie die Dimensionierungsszenarien zeigen, ist VRAM häufig der zentrale Engpass bei LLM-Inferenz. Quantisierung reduziert die numerische Präzision, mit der Daten dargestellt werden, und tauscht einen kleinen Genauigkeitsverlust gegen deutliche Verbesserungen bei Speichereffizienz und Geschwindigkeit.

Dabei ist es wichtig, zwischen den zwei wichtigsten Arten der Quantisierung in vLLM zu unterscheiden, da sie unterschiedliche Probleme lösen.

Typ 1: Modellgewichts-Quantisierung als statische Lösung

Diese Methode komprimiert die großen, statischen Gewichtsmatrizen des vortrainierten Modells, bevor das Modell geladen wird.

• Ziel: Ein Modell soll auf eine GPU passen, obwohl seine vollpräzisen Gewichte den verfügbaren VRAM überschreiten würden.
• vLLM-Umsetzung: vLLM kann Gewichte zwar dynamisch beim Start quantisieren, effizienter ist jedoch oft ein bereits vorab quantisiertes Modell mit optimierten Formaten wie AWQ oder GPTQ. Diese Formate bewahren die Genauigkeit meist besser und liefern schnellere Decode-Leistung als eine generische Umwandlung zur Laufzeit.
• Auswirkung: Der statische VRAM-Bedarf kann mit FP8 oder INT8 um 50 % und mit INT4 oder AWQ um 75 % sinken. Dadurch bleibt deutlich mehr Speicher für den KV-Cache verfügbar.

Typ 2: KV-Cache-Quantisierung als dynamische Lösung

Diese Methode komprimiert die zwischengespeicherten Key- und Value-Zustände, die während der Sequenzgenerierung im Speicher gehalten werden.

• Ziel: Das Modell soll höhere Parallelität oder längere Kontextfenster unterstützen können.
• vLLM-Umsetzung: Die KV-Cache-Quantisierung wird über das Runtime-Flag --kv-cache-dtype gesteuert.
• Empfehlung: Auf modernen GPUs mit FP8-Tensor-Core-Unterstützung, beispielsweise NVIDIA H100, L40S oder AMD MI300X, ist ein FP8-KV-Cache dringend zu empfehlen. Er kann die verfügbare Kontextkapazität nahezu verdoppeln, ohne die Modellqualität spürbar zu beeinträchtigen.
• Auswirkung: Der Speicherbedarf pro Token halbiert sich im Vergleich zu den zuvor beschriebenen Werten. Bei einem 70B-Modell sinkt der Multiplikator beispielsweise von etwa 0,35 MB pro Token auf ungefähr 0,175 MB pro Token.

GPU-Präzisionsformate für vLLM

Quantisierungsformate unterscheiden sich deutlich. Die passende Wahl hängt von der Hardware-Architektur und dem gewünschten Verhältnis zwischen Modellgröße und Genauigkeit ab.

Strategische Anwendung und Kompromisse

Die Entscheidung für Quantisierung erfordert eine Abwägung zwischen praktischen Deployment-Grenzen und der Empfindlichkeit des Workloads. Quantisierung ist wirkungsvoll, bringt aber Kompromisse mit sich, die in der Planung berücksichtigt werden müssen.

Wichtige Faktoren: Genauigkeit und Hardware

Vor der Wahl einer Deployment-Strategie sollten zwei grundlegende Aspekte geprüft werden:

• Genauigkeit vs. Kompression: Aggressive Quantisierung wie INT4 kann die Qualität bei komplexem Reasoning oder Codegenerierung verringern. FP8 gilt für die meisten Chat- und RAG-Workloads in der Regel als sicher.
• Hardware-Kompatibilität: Das gewählte Präzisionsformat muss zu den Fähigkeiten der GPU passen. FP8-Quantisierung benötigt beispielsweise GPUs mit FP8-Tensor-Cores, etwa NVIDIA-Ada- oder Hopper-Architekturen beziehungsweise AMD-CDNA3-Architekturen, um echte Leistungsvorteile zu erzielen.

Wann Quantisierung empfohlen wird

Unter Berücksichtigung dieser Kompromisse ist Quantisierung in vielen realen Bereitstellungsszenarien sinnvoll und in Unternehmensumgebungen häufig die bevorzugte Standardwahl.

• Große Modelle, die nicht in FP16 passen: INT4 oder INT8 ist oft der einzige praktikable Weg, 70B-Modelle auf einer einzelnen 48-GB- oder 80-GB-GPU bereitzustellen.
• Workloads mit hoher Parallelität: Geringerer VRAM-Verbrauch schafft mehr Platz für den KV-Cache und ermöglicht mehr aktive Sequenzen sowie längere Prompts.
• RAG und Unternehmens-Chat: Diese Workloads tolerieren kleine Genauigkeitsabweichungen meist gut, ohne dass die Nutzererfahrung spürbar leidet.
• Kostenoptimierung: Quantisierung ermöglicht den Betrieb auf kleineren und günstigeren GPU-Optionen, während eine akzeptable Leistung erhalten bleibt. Das ist besonders hilfreich, wenn Leistung und Kosten auf GPU-basierter Cloud-Infrastruktur gegeneinander abgewogen werden.

Wann Quantisierung vermieden werden sollte

Quantisierung ist nicht für jeden Workload geeignet. Manche Aufgaben reagieren empfindlich auf Präzisionsverluste und sollten möglichst in FP16 oder BF16 ausgeführt werden.

• Codegenerierung und Debugging: Geringere Präzision kann strukturiertes Reasoning verschlechtern und zu feinen Syntax- oder Logikfehlern führen.
• Mathematik, Finanzen und wissenschaftliche Abfragen: Aufgaben mit exakten Berechnungen profitieren von höherer Präzision, um Rundungsfehler zu reduzieren.
• Evaluation, Benchmarking oder Regressionstests: Bereits kleine Genauigkeitsabweichungen können Vergleiche zwischen Modellversionen oder Konfigurationen verfälschen.
• Agentische Workflows mit mehrstufigem Reasoning: Kleine Fehler können sich über mehrere Schritte hinweg verstärken und die Zuverlässigkeit sowie Abschlussrate der Aufgabe reduzieren.

Alles zusammenführen: Von Anforderungen zum Deployment-Plan

Bis hierhin wurden das Laufzeitverhalten von vLLM, die Speichergrundlagen und die Quantisierungsstrategien betrachtet.

Dieser Abschnitt verbindet diese Konzepte zu einem wiederholbaren Entscheidungsrahmen. Er führt von der Theorie in die Praxis und bietet einen strukturierten Ablauf, um Machbarkeit zu bewerten, Hardware auszuwählen und einen Deployment-Plan zu erstellen.

Schritt 1: Eine Dimensionierungs-Checkliste nutzen

Um eine vLLM-Bereitstellung präzise zu dimensionieren, müssen konkrete technische Details aus der Workload-Beschreibung abgeleitet werden. Allgemeine Ziele wie „schnelle Inferenz“ reichen dafür nicht aus. Die folgenden fünf Fragen liefern die notwendigen Informationen:

• Welche maximale Kontextlänge muss unterstützt werden? Diese Angabe bestimmt die Größe des KV-Caches und das Risiko für Out-of-Memory-Fehler.
• Welche Ziel-Parallelität wird benötigt? Sie vervielfacht den KV-Cache-Bedarf.
• Welche Latenz ist für TTFT und Token pro Sekunde akzeptabel? Dies hilft zu entscheiden, ob hohe Bandbreite wie bei H100-Klasse-Hardware erforderlich ist oder ob solide allgemeine Kapazität wie bei L40S-Klasse-Hardware ausreicht.
• Ist Modellgenauigkeit für Mathematik oder Code kritisch, oder reicht gute Qualität für Chat-Anwendungen aus? Diese Antwort bestimmt, ob INT4 oder FP8 zur Kostensenkung genutzt werden kann.
• Gibt es ein festes Budgetlimit? Dies hilft bei der Entscheidung zwischen maximaler Leistung und Preis-Leistungs-Optimierung.

Schritt 2: Modellgröße und Präzision auswählen

Sobald die Anforderungen bekannt sind, sollte das kleinste Modell mit der höchstmöglichen Präzision gewählt werden, das die geforderte Qualität erreicht.

• Präzision ist der Hebel: Niedrigere Präzisionsformate wie INT4 oder FP8 machen größere Modelle auf günstigerer Hardware möglich.
• Die 70B-Regel: Ein 70B-Modell in FP16 benötigt Multi-GPU- oder sehr speicherstarke Hardware. Dasselbe Modell in INT4 kann auf eine einzelne GPU passen.

Empfehlung:

• Chat- oder Assistant-Workloads: INT4 oder FP8 verwenden.
• Code- oder Reasoning-Workloads: FP16 oder FP8 verwenden und INT4 vermeiden.

Schritt 3: Hardware-Machbarkeit prüfen

Die Bereitstellung sollte mit den zuvor beschriebenen Speicherberechnungen validiert werden.

• Statischer Fit für Gewichte: Passen Parameter × Präzision in den VRAM? Falls nicht, muss das Modell quantisiert oder mit Tensor Parallelism auf mehrere GPUs verteilt werden.
• Dynamischer Fit für den Cache: Reicht der Speicher für Kontext × Parallelität × Multiplikator? Falls nicht, sollten Parallelität reduziert, Kontextlänge gekürzt oder FP8-KV-Cache aktiviert werden.
• Workload-Fit hinsichtlich Bandbreite: Lange RAG- und Zusammenfassungs-Workloads benötigen hohe Bandbreite, während Standard-Chat vor allem starke Rechenleistung braucht.

Schritt 4: Die GPU-Strategie festlegen

Nach der Machbarkeitsprüfung kann die GPU-Konfiguration ausgewählt werden. Die folgende Übersicht fasst typische Szenarien zusammen.

Typische Konfigurationsergebnisse

Schritt 5: Mit Metriken validieren

Keine theoretische Dimensionierung ist perfekt. Die Validierung sollte immer anhand realer Kennzahlen erfolgen.

• TTFT prüfen: Ist sie hoch, wird die Prefill-Phase wahrscheinlich durch Speicherbandbreite begrenzt.
• Inter-Token-Latenz prüfen: Ist sie hoch, könnte die Batch-Größe zu aggressiv sein und die Rechenleistung sättigen.
• KV-Cache-Nutzung prüfen: Liegt sie dauerhaft über 90 %, besteht ein Risiko für Out-of-Memory-Fehler. Chunked Prefill sollte aktiviert oder die Parallelität reduziert werden.

Häufig gestellte Fragen

1. Wie viel GPU-Speicher wird für LLM-Inferenz benötigt?

Die Planung des GPU-Speichers hängt von vier Hauptfaktoren ab: der Anzahl der Modellparameter, dem verwendeten Präzisionsformat, der Kontextlänge und der Anzahl gleichzeitiger Nutzer. Allein für die Modellgewichte benötigt FP16 in der Regel etwa 2 GB pro Milliarde Parameter. Ein Modell mit 70 Milliarden Parametern belegt somit ungefähr 140 GB VRAM in FP16, während eine INT4-Quantisierung den Speicherbedarf der Gewichte auf rund 35 GB reduzieren kann.

Zusätzlich muss der KV-Cache berücksichtigt werden, dessen Speicherbedarf mit längeren Kontextfenstern und höherer Parallelität wächst. Ein 70B-Modell mit einem Kontext von 32.000 Tokens und 10 gleichzeitigen Nutzern kann beispielsweise etwa 112 GB für einen KV-Cache in FP16 benötigen. Bei Verwendung von FP8 reduziert sich dieser Bedarf auf ungefähr 56 GB.

2. Was ist der Unterschied zwischen Tensor Parallelism und Pipeline Parallelism in vLLM?

Tensor Parallelism verteilt Modellgewichtsmatrizen innerhalb jeder Schicht auf mehrere GPUs, sodass die GPUs gleichzeitig an derselben Berechnung arbeiten. Dadurch wird VRAM gebündelt, aber nach jeder Schicht ist Synchronisation erforderlich, was Kommunikationsaufwand verursacht. Pipeline Parallelism verteilt hingegen Modellschichten sequenziell auf GPUs, wobei verschiedene GPUs unterschiedliche Schichten verarbeiten. Tensor Parallelism wird normalerweise genutzt, wenn ein Modell zu groß für eine einzelne GPU ist. Pipeline Parallelism ist häufiger in Trainingsszenarien anzutreffen. Für Inferenz ist Tensor Parallelism der Standardansatz, wenn Modelle die Kapazität einer einzelnen GPU überschreiten.

3. Wann sollte Quantisierung für vLLM-Bereitstellungen genutzt werden?

Quantisierung wird empfohlen, wenn Modelle nicht in den verfügbaren VRAM passen, wenn höhere Parallelität oder längere Kontextfenster erforderlich sind oder wenn Kostenoptimierung eine wichtige Rolle spielt. FP8-Quantisierung eignet sich besonders für moderne Hardware wie H100, L40S oder MI300X und verursacht in der Regel nur minimale Genauigkeitsverluste. INT4-Quantisierung ist hilfreich, um große Modelle auf kleineren GPUs auszuführen, sollte jedoch bei Codegenerierung, Mathematik und wissenschaftlichen Workloads vermieden werden, wenn hohe Präzision wichtig ist. Für Chat- und RAG-Workloads ist Quantisierung häufig die bevorzugte Standardoption.

4. Wie lassen sich KV-Cache-Speicheranforderungen berechnen?

Für eine schnelle Abschätzung eignet sich die Multiplikator-Methode pro Token: Gesamttoken, berechnet aus Kontextlänge × Parallelität, werden mit dem modellspezifischen Multiplikator multipliziert. Für kleine Modelle im Bereich 7B bis 14B gelten 0,15 MB pro Token für FP16-Cache oder 0,075 MB für FP8-Cache. Für große Modelle im Bereich 70B bis 80B gelten 0,35 MB pro Token für FP16-Cache oder 0,175 MB für FP8-Cache. Für exakte Berechnungen kann die Formel Gesamter KV-Cache (GB) = (2 × n_layers × d_model × n_seq_len × n_batch × precision_bytes) / 1024³ verwendet werden, alternativ ein Tool wie der LMCache KV Calculator.

5. Kann vLLM auf Cloud-GPU-Instanzen betrieben werden?

Ja, vLLM kann auf Cloud-GPU-Instanzen bereitgestellt werden. Viele Anbieter stellen GPU-basierte virtuelle Maschinen mit NVIDIA- oder AMD-GPUs bereit, die die Anforderungen von vLLM erfüllen. Bei der Bereitstellung sollte sichergestellt werden, dass die ausgewählte GPU genügend VRAM für Modellgröße und erwarteten Workload besitzt. Für kosteneffiziente Deployments sind quantisierte Modelle wie INT4 oder FP8 sinnvoll, um größere Modelle auf kleineren GPU-Instanzen zu betreiben. Bei Multi-GPU-Bereitstellungen sind schnelle GPU-Interconnects wichtig, damit Tensor Parallelism effizient funktioniert.

Praktische Einsatzbereiche von vLLM-GPU-Inferenz

Auf Basis des Verständnisses dafür, wie Modellgröße, Präzision, GPU-Architektur, KV-Cache und Batching die Leistung beeinflussen, lassen sich diese Konzepte auf praktische vLLM-Workloads anwenden.

Für jeden Anwendungsfall helfen drei zentrale Fragen dabei, die optimale Konfiguration zu bestimmen:

• Workload-Definition: Welche Merkmale sind entscheidend, etwa Prompt-Länge, Ausgabelänge, Parallelität und Latenzempfindlichkeit?
• Dimensionierungsprioritäten: Welche Faktoren bilden den Engpass, beispielsweise Gewichte vs. KV-Cache oder Bandbreite vs. Rechenleistung?
• Konfigurationsmuster: Welche Flags und Hardware-Entscheidungen liefern zuverlässig gute Ergebnisse?

Anwendungsfall 1: Interaktive Chats und Assistenten

• Fokus: Niedrige Latenz und decode-gebundene Leistung.
• Ziel: Flüssiges Streaming und schnelle „Tippgeschwindigkeit“ für Nutzer.
• Zentrale Grenze: Rechenleistung in TFLOPS und Inter-Token-Latenz.

Anwendungsfall 2: Batch-Verarbeitung mit hohem Volumen

• Fokus: Maximaler Durchsatz und compute-gebundene Ausführung.
• Ziel: Millionen Token pro Stunde für Offline-Workloads wie Zusammenfassungen verarbeiten.
• Zentrale Grenze: Gesamtsystemdurchsatz, gemessen in Token pro Sekunde.

Anwendungsfall 3: RAG und Long-Context-Reasoning

• Fokus: Kontextkapazität und speichergebundene Leistung.
• Ziel: Sehr große Dokumente oder lange Verläufe in den Speicher bringen, ohne Ausfälle zu verursachen.
• Zentrale Grenze: VRAM-Kapazität und Speicherbandbreite für schnellen Prefill.

Fazit

Die richtige Dimensionierung und Konfiguration von GPUs für vLLM setzt voraus, dass die wichtigsten Kompromisse zwischen Modellgröße, Präzision, Kontextlänge und Parallelität verstanden werden. Prefill und Decode stellen unterschiedliche Anforderungen an die Hardware: Prefill hängt stark von der Speicherbandbreite ab, während Decode vor allem Rechendurchsatz benötigt. Quantisierung ist der wichtigste Hebel, um größere Modelle auf vorhandener Hardware zu betreiben, und Tensor Parallelism macht Skalierung über einzelne GPUs hinaus möglich.

Entscheidend für eine erfolgreiche Bereitstellung ist, die Eigenschaften des Workloads mit der passenden Hardware-Konfiguration abzugleichen. Interaktive Chat-Anwendungen priorisieren Rechenleistung für schnelle Token-Generierung, während RAG- und Long-Context-Workloads große VRAM-Kapazität und hohe Speicherbandbreite benötigen. Mit dem beschriebenen Dimensionierungsrahmen lässt sich die Machbarkeit systematisch prüfen, geeignete Hardware auswählen und eine vLLM-Bereitstellung für produktive Workloads optimieren.