Kontinuierliches Batching ermöglicht es einem vLLM-Server, eine neue Anfrage aufzunehmen, während andere Anfragen noch Tokens generieren. Ein festes Batch wartet, bis alle Mitglieder abgeschlossen sind, bevor das nächste Batch gebildet werden kann; kontinuierliches Batching überprüft die aktive Menge bei jedem Scheduling-Schritt erneut. Dieser Unterschied ist wichtig, wenn Prompts und Ausgaben unterschiedliche Längen haben. Kurze Anfragen können an der GPU-Verarbeitung teilnehmen, ohne auf die längste Antwort einer vorherigen Gruppe warten zu müssen.
Für ein Inferenzteam lautet die entscheidende Frage nicht, ob kontinuierliches Batching in einer Funktionsliste aktiviert ist. Entscheidend ist, ob Ihr tatsächlicher Anfrage-Mix mehr abgeschlossene Antworten pro Sekunde erzielt, ohne die Zeit bis zum ersten Token, die Wartezeit in der Queue oder die Fehlerrate über Ihr Serviceziel hinaus zu erhöhen. Dieser Leitfaden erläutert den Mechanismus, die relevanten Grenzen und einen Benchmark, den Sie vor der Auswahl von GPU-Kapazität ausführen können.
So funktioniert kontinuierliches Batching in vLLM
In der aktuellen V1-Architektur von vLLM füllt der Scheduler bei jedem Schritt ein Token-Budget aus laufenden und wartenden Anfragen. Eine Anfrage verfolgt, wie viele Tokens bereits berechnet wurden; der Scheduler weist Arbeit zu, um diese Lücke zu schließen. Dieselbe Schleife verarbeitet Chunked Prefill, Präfix-Caching und spekulatives Decoding. Dies ist ein genaueres mentales Modell als ein Diagramm eines einzigen statischen Batches, das bis zum Abschluss ausgeführt wird. Eine Beschreibung des Schedulers finden Sie in der vLLM-Architekturübersicht.
Stellen Sie sich drei eingehende Anfragen vor: eine kurze Chat-Antwort, einen langen Dokument-Prompt und einen weiteren kurzen Chat. Bei einem festen Batch könnte der zweite kurze Chat auf die Batch-Grenze der langen Anfrage warten. Mit kontinuierlichem Batching kann er bei einem späteren Scheduling-Schritt berücksichtigt werden, während die ersten Anfragen aktiv bleiben. Die Aufnahme ist weiterhin durch das Token-Budget, Sequenzgrenzen und den verfügbaren KV-Cache-Speicher eingeschränkt. Kontinuierliches Batching garantiert weder keine Warteschlangen noch ein schnelleres Ergebnis für jede Anfrage.
PagedAttention adressiert einen anderen Teil des Problems: das Speichern und Verwalten des Attention-KV-Cache in Blöcken. Es hilft der Engine, Speicher flexibler zu nutzen, während der Scheduler entscheidet, welche Anfragen Rechenleistung erhalten. Wenn Sie diese Rollen getrennt betrachten, können Sie besser diagnostizieren, ob geringer Durchsatz durch Scheduling, KV-Cache-Druck, lange Prompts oder einen vorgelagerten Engpass verursacht wird. Das vLLM-PagedAttention-Design beschreibt den Speichermechanismus.
Die Einstellungen, die ein Batch bestimmen
| Einstellung | Was sie begrenzt | Worauf Sie bei Änderungen achten sollten |
|---|---|---|
max_num_batched_tokens |
Tokens, die in einer Scheduler-Iteration verarbeitet werden | Durchsatz, Zeit bis zum ersten Token, Inter-Token-Latenz und Fortschritt bei langen Prompts |
max_num_seqs |
Sequenzen, die in einer Iteration verarbeitet werden | Laufende Anfragen, Speicherreserven und Tail-Latenz |
| Chunked Prefill | Teilt ein langes Prefill auf mehrere Scheduling-Schritte auf | Latenz bei langen Prompts und Interferenzen mit Decoding-Anfragen |
| Queue- oder Aufnahmegrenze | Anfragen, die warten oder ausgeführt werden dürfen | Wartezeit in der Queue, Ablehnungsrate und ob Überlastung die Aufrufer erreicht |
| KV-Cache-Kapazität | Aktiver Kontext, der auf die GPU passt | Preemption, Neuberechnung und Out-of-Memory-Fehler |
Diese Einstellungen interagieren miteinander. Eine Erhöhung des Token-Budgets kann den Durchsatz für einen Workload verbessern und die interaktive Latenz für einen anderen verschlechtern. Eine Erhöhung der Anzahl aufgenommener Sequenzen kann die Parallelität steigern, verbraucht jedoch auch mehr KV-Cache. Version, Modellarchitektur, Kontextlängen und Hardware beeinflussen alle das Ergebnis. Lesen Sie die Referenz zur Scheduler-Konfiguration für das Verhalten Ihrer installierten vLLM-Version und ändern Sie anschließend jeweils nur eine Einstellung.
Wenn der KV-Cache keine neue Arbeit aufnehmen kann, kann vLLM eine laufende Anfrage preempten und ihren Fortschritt später neu berechnen. Eine steigende Anzahl von Preemptions warnt davor, dass das bloße Hinzufügen weiterer eingehender Anfragen zum Batch nicht kostenlos ist. Die Architekturübersicht erläutert die Regeln für Scheduling und Preemption.
Ein Benchmark, der dem Produktionsverkehr entspricht
Vergleichen Sie Einstellungen für kontinuierliches Batching nicht mit einem einzelnen kurzen Prompt, der so schnell gesendet wird, wie es der Client zulässt. Erstellen Sie drei Anfragegruppen aus Ihren eigenen Logs oder einem datenschutzsicheren Trace:
- Kurze interaktive Chats mit knappen Prompts und Antworten.
- Anfragen mit langem Kontext, großen Prefills und moderaten Ausgabelängen.
- Agenten- oder RAG-Anfragen mit wiederholten Präfixen, variierenden Ausgabelängen, Abbrüchen und Bursts.
Halten Sie Modellrevision, Tokenizer, GPU-Typ, vLLM-Version und Anfrage-Trace zwischen den Durchläufen konstant. Variieren Sie die angebotene Anfragerate von unterhalb der erwarteten Last bis zu dem Punkt, an dem Wartezeit in der Queue oder Fehler inakzeptabel werden. Der offizielle Leitfaden zu vllm bench serve dokumentiert Steuerelemente für Anfragerate und Datensatz. Zeichnen Sie den genauen Befehl, die Konfiguration und die Trace-Version auf, damit der Vergleich wiederholt werden kann.
Erfassen Sie für jeden Durchlauf abgeschlossene Anfragen pro Sekunde, Ausgabe-Tokens pro Sekunde, p50- und p95-Zeit bis zum ersten Token, p95-Inter-Token-Latenz, p95-End-to-End-Latenz, Wartezeit in der Queue, Fehler und den Höchststand der GPU-Speichernutzung. Die Referenz zu Produktionsmetriken von vLLM enthält Gauges für laufende und wartende Anfragen sowie Histogramme für Wartezeit in der Queue, Zeit bis zum ersten Token und Preemptions. Eine hilfreiche Scorecard ist:
| Durchlauf | Angebotene Anfragen/s | Abgeschlossene Anfragen/s | p95 erster Token | p95 Warteschlange | p95 Ende-zu-Ende | Fehlerrate | Unterbrechungen |
|---|---|---|---|---|---|---|---|
| Baseline | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen |
| Änderung des Token-Budgets | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen |
| Änderung des Sequenzlimits | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen | gemessen |
Füllen Sie diese Tabelle mit Messwerten aus; es gibt keinen universellen prozentualen Gewinn, den Sie von einem anderen Modell oder Anbieter übernehmen können. Wählen Sie die Konfiguration, die Latenz- und Zuverlässigkeitsziele bei den niedrigsten Kosten pro akzeptierter Antwort erfüllt, und nicht diejenige mit dem höchsten Token-Durchsatz für sich allein.
Ein enttäuschendes Ergebnis diagnostizieren
Wenn kontinuierliches Batching ineffektiv erscheint, suchen Sie nach der Einschränkung, bevor Sie ein weiteres Flag ändern.
Wartende Anfragen nehmen zu, während der GPU-Speicher weiterhin ausreichend ist. Prüfen Sie Zulassungsgrenzen, ein niedriges Sequenzlimit, die CPU- Tokenisierung und die clientseitige Parallelität. Ein Scheduler kann eine GPU nicht mit Anfragen auslasten, die sie nie erreichen.
Die Zeit bis zum ersten Token steigt bei langen Prompts. Trennen Sie im Benchmark Prefill-intensive von Decode-intensivem Traffic. Überprüfen Sie gestückeltes Prefill und Token-Budget-Einstellungen und vergleichen Sie die Verteilung langer Prompts statt nur den Durchschnitt.
Der Durchsatz verbessert sich, aber die p95-Latenz verschlechtert sich. Der Server akzeptiert möglicherweise mehr gleichzeitige Arbeit, als das Ziel Ihres interaktiven Dienstes erlaubt. Begrenzen Sie die Zulassung, verwenden Sie ein Warteschlangen-Timeout oder einen separaten Serving-Pool und testen Sie erneut bei derselben angebotenen Last.
Unterbrechungen oder Out-of-Memory-Ereignisse nehmen zu. Die aktiven Kontexte passen möglicherweise nicht in den KV-Cache der GPU. Reduzieren Sie Parallelität oder Kontextlimits, wählen Sie eine GPU mit ausreichend Speicher oder überprüfen Sie Modell- und Präzisionsentscheidungen erneut. Behandeln Sie eine unterbrochene Anfrage nicht als kostenloses Scheduling-Ereignis.
Die GPU-Auslastung ist gering, obwohl Anfragen warten. Untersuchen Sie CPU, Netzwerk, Speicher, Modellladen und Client-Pacing, bevor Sie den Engpass dem kontinuierlichen Batching zuschreiben. Unser vLLM-Bereitstellungsleitfaden deckt das umfassendere Serving-Runbook ab; dieser Artikel konzentriert sich auf Scheduler-Verhalten und Messung.
Wo die GPU-Auswahl in die Entscheidung einfließt
Kontinuierliches Batching kann verbessern, wie Sie eine GPU nutzen, aber es kann kein Modell in Speicher einpassen, den sie nicht hat. Schätzen Sie Gewichte, KV-Cache bei erwarteter Parallelität und Kontextlänge, Laufzeit-Overhead und eine Sicherheitsmarge. Führen Sie anschließend Benchmarks auf der GPU-Konfiguration aus, die Sie mieten möchten. Eine 80-GB-GPU und eine GPU mit größerem Speicher können für dasselbe Modell und denselben Anfrage-Trace unterschiedliches Zulassungs- und Unterbrechungsverhalten zeigen.
Flatkey GPU Compute führt Mietoptionen auf, darunter H100 SXM, H200, B200, B300, A100 80GB und RTX 5090. Konfiguration, Region, Verfügbarkeit und Preis müssen für die ausgewählte Miete bestätigt werden. Bringen Sie einen Benchmark-Trace, die Ziellatenz, Modellrevision und Speicherschätzung mit, wenn Sie Optionen vergleichen. Dadurch dreht sich die Kapazitätsdiskussion um abgeschlossene Arbeit statt um eine herausgestellte GPU- Spezifikation.
Praktische Entscheidungscheckliste
Bevor Sie sich für eine vLLM-Konfiguration für kontinuierliches Batching entscheiden, beantworten Sie diese Fragen:
- Erfüllt das wichtigste Traffic-Szenario die p95-Ziele für die Latenz bis zum ersten Token und die Ende-zu-Ende- Latenz?
- Was passiert bei einem Burst über der normalen Anfragerate: begrenzte Warteschlange, Ablehnung oder ein großer Latenzanstieg?
- Sind Unterbrechungen und KV-Cache-Druck bei der vorgesehenen Kontextlänge stabil?
- Ist das Ergebnis über die exakte Modellrevision und GPU- Konfiguration hinweg reproduzierbar, die Sie einsetzen möchten?
- Unterbieten die Kosten pro akzeptierter Antwort die Alternative, nachdem Wiederholungen und ungenutzte Kapazität berücksichtigt wurden?
Häufig gestellte Fragen
Bedeutet kontinuierliches Batching mit vLLM, dass jede Anfrage sofort ausgeführt wird?
Nein. Eine neu eingehende Anfrage kann bei einem Scheduling-Schritt berücksichtigt werden, aber sie kann weiterhin auf Token-Budget, einen Sequenz-Slot oder KV-Cache-Kapazität warten. Beobachten Sie die Anzeigen für laufende und wartende Anfragen zusammen mit Histogrammen der Warteschlangenzeit, bevor Sie ein interaktives Latenzziel zusagen.
Ist kontinuierliches Batching mit vLLM dasselbe wie gestückeltes Prefill?
Nein. Kontinuierliches Batching beschreibt, wie Anfragen im Laufe der Zeit geplanter Arbeit beitreten und sie verlassen. Gestückeltes Prefill teilt die Prefill- Arbeit eines langen Prompts auf, sodass sie das Token-Budget über Schritte hinweg teilen kann. Beides arbeitet im aktuellen Scheduler zusammen, aber das Einstellen eines Tuning-Parameters ersetzt nicht das Messen des anderen.
Sollte ich die Batch- Größe maximieren?
Nicht automatisch. Ein größerer Batch kann den Durchsatz verbessern und gleichzeitig Warteschlangenzeit, Zeit bis zum ersten Token oder Unterbrechungsdruck erhöhen. Führen Sie denselben Trace bei derselben angebotenen Last aus und vergleichen Sie das gesamte Serviceziel, einschließlich Ausfällen und Kosten pro akzeptierter Antwort.
Kontinuierliches Batching mit vLLM ist eine Scheduling-Methode, kein Benchmark- Ergebnis. Das beste Setup ist dasjenige, dessen Durchsatz, Latenz, Speicher- verhalten und Fehlermodus Sie mit Ihren eigenen Messungen erklären können.
