vLLM Production Deployment: High-Throughput Inferenz-Serving-Architektur aufbauen

Aktualisiert am 11. Dezember 2025

Dezember 2025 Update: Stripe erzielt 73% Kostenreduktion bei der Inferenz durch vLLM-Migration (50M tägliche API-Aufrufe mit 1/3 der GPU-Flotte). PagedAttention eliminiert 60-80% Speicherverschwendung durch KV-Cache-Fragmentierung. vLLM liefert 2-24x Durchsatz vs. konventionelles Serving. Treibt Produktion bei Meta, Mistral AI, Cohere, IBM an. OpenAI-kompatible APIs vereinfachen die Einführung.

Stripes ML-Plattform-Team sah ihre Inferenz-Kosten um 73% sinken, nachdem sie von Hugging Face Transformers zu vLLM migrierten und dabei dieselben 50 Millionen täglichen API-Aufrufe mit einem Drittel der GPU-Flotte verarbeiteten.¹ Das Geheimnis hinter vLLMs Effizienz liegt in PagedAttention, einem Algorithmus, der GPU-Speicher wie virtuellen Speicher in Betriebssystemen behandelt und die Fragmentierung eliminiert, die 60-80% des Speichers in traditionellen Inferenz-Systemen verschwendet.² Organisationen, die produktionsreife LLM-Workloads betreiben, entdecken, dass vLLM 2-24x Durchsatzverbesserungen gegenüber konventionellen Serving-Frameworks liefert und die Wirtschaftlichkeit des Einsatzes großer Sprachmodelle in großem Maßstab transformiert.³

Die Inferenz-Serving-Landschaft fragmentiert sich in Dutzende von Optionen: TensorRT-LLM verspricht maximale NVIDIA-Optimierung, Hugging Face TGI bietet vertraute Integration, und Ollama vereinfacht lokale Bereitstellung. Dennoch hat sich vLLM als dominante Wahl für Produktions-Workloads etabliert und treibt Inferenz bei Meta, Mistral AI, Cohere und IBM an.⁴ Die Kombination des Frameworks aus PagedAttention, kontinuierlichem Batching und OpenAI-kompatiblen APIs schafft ein Deployment-Erlebnis, das rohe Performance mit operativer Einfachheit in Balance bringt. Das Verständnis von vLLMs Architektur und Deployment-Mustern unterscheidet Organisationen, die kosteneffektive Inferenz erzielen, von denen, die in GPU-Rechnungen ertrinken.

PagedAttention transformiert Speicherverwaltung

Traditionelle LLM-Inferenz allokiert einen zusammenhängenden Speicherblock für den Key-Value (KV) Cache jeder Sequenz und reserviert Platz für die maximal mögliche Sequenzlänge unabhängig von der tatsächlichen Nutzung. Ein System, das für 4.096 Token konfiguriert ist, allokiert diese volle Speichermenge selbst für 100-Token-Antworten und verschwendet dabei 97% der reservierten Kapazität. Multipliziert mit Hunderten gleichzeitiger Anfragen füllt sich GPU-Speicher mit leeren Reservierungen, während tatsächliche Sequenzen in der Warteschlange auf Ressourcen warten.

PagedAttention reimaginiert diese Architektur, indem GPU-Speicher in Seiten fester Größe aufgeteilt wird, typischerweise 16 Token pro Seite.⁵ Jede Sequenz verwaltet eine Liste von Seitenreferenzen statt einer zusammenhängenden Allokation, was mehrere bahnbrechende Fähigkeiten ermöglicht:

Nicht-zusammenhängende Speicherung erlaubt KV-Cache-Blöcken, sich über verfügbaren GPU-Speicher zu verteilen. Das System benötigt keine großen zusammenhängenden Regionen mehr und eliminiert die Fragmentierung, die traditionelle Allokatoren plagt. Eine 2.000-Token-Sequenz speichert ihren Cache über 125 Seiten verteilt, wo immer Platz verfügbar ist.

Dynamische Allokation stellt Speicher nur bereit, während Sequenzen wachsen. Der erste Token allokiert eine Seite. Der siebzehnte Token löst eine zweite Seitenallokation aus. Speicherverbrauch verfolgt tatsächliche Nutzung statt theoretischer Maxima und verbessert die effektive Kapazität dramatisch.

Speicher-Sharing ermöglicht identischen Prompt-Präfixen, KV-Cache-Seiten über Anfragen hinweg zu teilen. Zehn Benutzer, die Variationen desselben System-Prompts stellen, teilen sich eine einzige gecachte Kopie dieses Präfix und reduzieren den Speicherverbrauch um 90% für häufige Muster. Produktionssysteme mit standardisierten Prompts sehen Nutzungsverbesserungen von über 400%.⁶

Nahezu null Verschwendung eliminiert interne Fragmentierung, die bei statischer Allokation üblich ist. Traditionelle Systeme verschwenden durchschnittlich 4,1 Token pro Sequenz in teilweise gefüllten Blöcken. PagedAttentions Granularität auf Seitenebene reduziert Verschwendung auf Bruchteile einer Seite, typischerweise unter 8 Token pro Sequenz unabhängig von der Länge.

Der Algorithmus zieht direkte Inspiration aus Betriebssystem-Virtual-Memory und wendet Jahrzehnte der Speicherverwaltungsforschung auf GPU-Inferenz an. Genau wie moderne Betriebssysteme virtuelle Adressen auf physische Speicherseiten mappen, mappt PagedAttention logische KV-Cache-Positionen auf physische GPU-Speicherblöcke. Der Übersetzungsoverhead fügt Mikrosekunden zu jeder Attention-Berechnung hinzu, spart aber Gigabytes an Speicherkapazität.

Kontinuierliches Batching maximiert GPU-Auslastung

Statisches Batching wartet auf eine feste Anzahl von Anfragen, bevor es sie zusammen verarbeitet, was Latenzspitzen erzeugt, wenn Batches teilweise gefüllt sind, und Durchsatz fallen lässt, wenn Anfragen ungleichmäßig ankommen. Eine Batch-Größe von 32 bedeutet, dass die 31. Anfrage auf eine weitere Ankunft warten muss, bevor die Verarbeitung beginnt, was während verkehrsarmer Zeiten potenziell Sekunden an Latenz hinzufügt.

Kontinuierliches Batching in vLLM eliminiert Batch-Grenzen vollständig.⁷ Der Scheduler operiert auf Iterationsebene statt Anfrage-Ebene und trifft Entscheidungen bei jedem Forward-Pass statt bei jedem Batch. Wenn eine Sequenz die Generierung abschließt, akzeptiert ihr Slot sofort eine neue Anfrage, ohne zu warten, bis Geschwister-Sequenzen fertig sind. Die GPU verarbeitet whatever Arbeit zu jedem Moment existiert und füllt Lücken, die statisches Batching leer lässt.

Die Implementierung erfordert sorgfältige Koordination zwischen Speicherverwaltung und Scheduling:

Iterationsebenen-Scheduling evaluiert die Anfrage-Warteschlange bei jedem Decoder-Schritt. Abgeschlossene Sequenzen geben ihre Slots frei, wartende Anfragen beanspruchen verfügbare Kapazität, und die nächste Iteration läuft mit einem optimal gefüllten Batch weiter. Latenzvarianz zwischen Anfragen wird absorbiert statt verstärkt.

Preemption-Handling verwaltet Situationen, wo Speicherdruck Sequenz-Evictions erzwingt. Niedrigpriorisierte Anfragen checkpointen ihren KV-Cache-Zustand und geben GPU-Speicher an höher priorisierte Sequenzen ab. Wenn Kapazität zurückkehrt, setzen preemptierte Sequenzen von ihren Checkpoints fort, statt von vorn zu starten.

Prefix-Caching identifiziert Anfragen mit gemeinsamen Präfixen und leitet sie zu Instanzen weiter, die bereits relevante KV-Cache-Seiten halten. Ein Kundensupport-System, wo jede Anfrage mit demselben 500-Token-Kontext beginnt, serviert nachfolgende Token aus gecachtem Zustand und eliminiert redundante Präfix-Berechnung.

Benchmarks demonstrieren den Impact: vLLM erzielt einen Durchsatz von 793 Token pro Sekunde verglichen mit Ollamas 41 Token pro Sekunde bei äquivalenten Konfigurationen, mit P99-Latenz von 80ms versus 673ms.⁸ Die kontinuierliche Batching-Architektur behält diese Vorteile über Concurrency-Level von 1 bis 256 simultanen Benutzern bei.

Produktionsarchitektur skaliert über Cluster

Single-Node vLLM-Deployments handhaben beträchtlichen Traffic, aber Produktionssysteme erfordern cluster-weite Orchestrierung für Zuverlässigkeit, Skalierung und Effizienz. Der vLLM-Production-Stack transformiert die Inferenz-Engine in ein komplettes Serving-System mit vier kritischen Ergänzungen.⁹

Request-Routing leitet eingehende Queries zu geeigneten Backend-Instanzen basierend auf Routing-Keys, Session-IDs oder Prefix-Matching. Intelligentes Routing maximiert KV-Cache-Wiederverwendung, indem verwandte Anfragen zu Instanzen gesendet werden, die bereits relevanten Kontext halten. Eine Unterhaltung mit mehreren Turns routet konsistent zur selben Backend-Instanz und vermeidet redundante Präfix-Berechnung über Instanzen hinweg.

KV-Cache-Sharing erweitert PagedAttentions Speichereffizienz über mehrere vLLM-Instanzen durch das LMCache-Projekt. Backends teilen berechnete KV-Cache-Blöcke über Hochgeschwindigkeits-Interconnects und ermöglichen Cache-Hits selbst wenn Anfragen zu verschiedenen Instanzen routen. Systeme mit repetitiven Workloads sehen 3-10x Latenzreduktion und 2-5x Durchsatzverbesserung durch instanzübergreifendes Cache-Sharing.¹⁰

Observability-Integration exponiert Metriken durch Prometheus und Visualisierung durch Grafana-Dashboards. Per-Request-Metriken erfassen Time-to-First-Token (TTFT), Time-Between-Tokens (TBT) und End-to-End-Latenz. Per-Instanz-Metriken verfolgen GPU-Auslastung, Speicherdruck, Warteschlangentiefe und Cache-Hit-Raten. Operations-Teams gewinnen Sichtbarkeit in Performance-Bottlenecks und Capacity-Planning-Daten.

Horizontale Skalierung fügt vLLM-Instanzen basierend auf Demand-Signalen hinzu und entfernt sie. Kubernetes-Deployments nutzen Horizontal Pod