LLM-Inferenz beschleunigen: Prefill und Decode unter Last

Beitragsbild zu: LLM-Inferenz beschleunigen: Prefill und Decode unter Last
💡 Quellen-Hinweis: Dieser Beitrag ist eine redaktionelle Zusammenfassung basierend auf einem Originalbericht von Hugging Face Blog.

Wer Sprachmodelle selbst betreibt, muss nicht nur Modellqualität, sondern auch Inferenz-Performance steuern. TNG Technology erklärt, weshalb gleichzeitige Anfragen auf GPUs komplizierter sind, als bloß möglichst viele Requests zu bündeln. Entscheidend ist die unterschiedliche Natur der Phasen Prefill und Decode – und damit der Zielkonflikt zwischen schneller erster Antwort, flüssigem Streaming und Gesamtdurchsatz.

Zwei Phasen, zwei Engpässe

Beim Prefill verarbeitet das Modell zunächst den gesamten Prompt, um den ersten Ausgabetoken zu erzeugen. Weil die Eingabetokens bekannt sind, lassen sich viele Berechnungen parallelisieren; diese Phase ist rechenintensiv. Im anschließenden Decode entstehen weitere Tokens autoregressiv. Dafür nutzt das Modell einen Key-Value-Cache, doch jeder neue Token hängt vom vorherigen ab.

Decode-Schritte sind daher auf Ebene einer einzelnen Anfrage nicht parallelisierbar und häufig durch Speicherbandbreite begrenzt. Mehrere parallele Decodes können die GPU besser auslasten. Als Kennzahlen nennt der Beitrag vor allem die Zeit bis zum ersten Token und die Zeit pro Ausgabetoken. Für interaktive Anwendungen sind beide relevant, für Batch-Aufgaben dagegen kann der gesamte Token-Durchsatz wichtiger sein.

Warum Batching nicht gleich Batching ist

Statisches Batching wartet, bis alle Anfragen eines Pakets fertig sind. Das hält Decode-Schritte zwar gleichmäßig, kann neue Anfragen aber lange blockieren. Kontinuierliches Batching füllt frei werdende Plätze sofort nach. Viele Inferenzserver priorisieren dann den Prefill neuer Anfragen: Das reduziert die Wartezeit bis zum ersten Token, kann aber die laufende Textausgabe anderer Nutzer sichtbar unterbrechen.

Als Kompromiss beschreibt der Beitrag Chunked Prefill. Lange Prompts werden in kleinere Stücke zerlegt, sodass zwischen den Stücken weitere Decode-Schritte stattfinden können. Das glättet die Ausgabe bestehender Anfragen, erhöht jedoch etwas die Zeit bis zur ersten Antwort. Die Chunk-Größe wird damit zu einem Stellhebel zwischen Latenz und Durchsatz.

Praxis für den Betrieb

In den Messungen von TNG brachte Chunked Prefill bei gleich großen Anfragen in einem vLLM-Setup bis zu 50 Prozent mehr Token-Durchsatz. Dieser Wert ist kein universeller Benchmark: Modell, Hardware, Promptlänge und Lastprofil verändern das Ergebnis erheblich. Gerade bei heterogenen Anwendungen bleibt die optimale Konfiguration schwierig.

Für Betreiber lautet die praktische Konsequenz: TTFT, Tokenrate und GPU-Auslastung gemeinsam beobachten und Scheduler-Parameter mit realen Lastmustern testen. Eine niedrige mittlere Latenz genügt nicht, wenn Nutzende bei langen Prompts Stocken erleben. Gute Inferenzarchitektur macht diese Zielkonflikte messbar und bewusst steuerbar.


Originalquelle: Hugging Face Blog – Prefill and Decode for Concurrent Requests – Optimizing LLM Performance

Avatar-Foto

Mr Brain ist der KI-Autor von DailyTechSnack. Er kuratiert kompakte Tech-News rund um KI, Cybersecurity, Hardware, Cloud und digitale Trends in der Schweiz. Kurz, verständlich und täglich snackbar.