Optimierung der LLM-Inferenz: Vorausfüllen, Dekodieren und enterprise-geeignete LLMOps
Vorvollfüllung gegenüber Dekodierungsengpässen, kontinuierliches Batching, FlashAttention, Quantisierung, PagedAttention, spekulatives Dekodieren, in Blöcken erfolgende Vorvollfüllung sowie deaggregierte Bereitstellung.
Die Entwicklung leistungsstarker, kosteneffizienter LLM-Dienste bedeutet, unter Berücksichtigung der tatsächlichen Hardware-Beschränkungen zu entwerfen – anstatt nur eine API zu verwenden und zu hoffen, dass die GPUs ständig beschäftigt bleiben.
Frühe Unternehmensbudgets für generatives KI konzentrierten sich auf Training und Feinabstimmung. Sobald die Anwendungen das Labor verlassen, ändert sich die Situation: kontinuierliche Inference-Aufgaben, die von den GPUs abhängen, sowie Latenzsprünge, die sich nicht vorhersagen lassen.
Skalierung erzwingt physische und finanzielle Kompromisse. Schnelle, sparsame Systeme blicken über einfache Abstraktionsschichten hinaus und betrachten, wie die Inference-Aufgaben tatsächlich auf Silizium ausgeführt werden.
1. Zwei Phasen, zwei Engpässe
Jeder Inference-Anfragevorgang teilt sich in Vorbereitung und Dekodierung auf. Jede Phase stößt auf eine andere Hardware-Beschränkung.
Vorbereitung (in der Regel rechenintensiv)
Prefill verarbeitet alle Prompt-Token auf einmal und erstellt parallel Schlüssel-Wert- (KV-)Aktivierungen. Zu lange Prompts führen dazu, dass große Matrixmultiplikationen die Rechenleistung auslasten, wodurch diese Phase rechenintensiv ist. Kurze Prompts oder sehr kleine Batch-Größen können das Verhältnis umkehren: Es gibt nicht genügend Rechenleistung, um den Speicherverkehr zu überlagern, wodurch Prefill speicherintensiv wird. Die Vorbereitungszeit ist die erste Wartezeit des Benutzers.
Dekodieren (in der Regel durch Speicherbreite begrenzt)
Nachdem der Prompt eingegeben wurde, kommen die Tokens nacheinander an. In jedem Schritt werden die vollständigen Modellgewichte sowie der zunehmende KV-Historie aus dem High Bandwidth Memory (HBM) in die GPU-SRAM geladen. Bei kleinen Batch-Größen wiederholt sich dieser Transfer so oft, dass die GPU aufgrund der begrenzten Speicherbreite statt aufgrund der Rechenleistung warten muss.
Eine Nuance bestimmt den gesamten Entwurf. Ein wachsendes Batch-Größe verteilt die gleiche Gewichtsabfrage über viele Sequenzen auf, wodurch die Dekodierung wieder in Richtung einer rechenintensiven Verarbeitung driftet. Genau dieser Übergang ist der Grund für kontinuierliches Batching: Es sorgt dafür, dass die Dekodierung in einem Bereich stattfindet, in dem die arithmetischen Einheiten ständig beschäftigt sind.
Verzögerungsgleichung
Die Gesamtverzögerung einer Anfrage teilt sich in einen Vorausfüllungs- und einen Dekodierungsanteil auf:
T_total = TTFT + (N_tokens − 1) × TPOT
- TTFT (Zeit bis zum ersten Token) umfasst die vollständige Vorausfüllung der Anfrage sowie den ersten Ausgabetoken – das ist das Empfinden des Benutzers bezüglich der initialen Reaktionszeit.
- TPOT (Zeit pro Ausgabetoken), auch Inter-Token-Verzögerung genannt, ist die konstante Kostenfaktor für jeden nachfolgenden Dekodierungsschritt.
- N_tokens gibt die Länge der vollständigen Ausgabe an.
Der Faktor (N − 1) ist beabsichtigt: Das erste Token befindet sich bereits innerhalb von TTFT, daher wird nur der Rest mit TPOT multipliziert. Die Kombination von roher Vorausverarbeitung mit TTFT ist ein häufiger Fehler. TTFT ist für den Benutzer bestimmt und muss diesen ersten Dekodierungsschritt beinhalten.
2. Eingang vor dem Erreichen der GPUs
Der Spitzenverkehr wird die GPUs überlasten, es sei denn, der Eingang prüft, bewertet und filtert zuerst. Ein typischer Ablauf: API-Gateway → mehrschichtiger semantischer Cache → bei Fehlschlag ein intelligenter Router, der die Komplexität bewertet und die Aufgabe entweder in eine Warteschlange für Standardmodelle oder in eine Warteschlange für fortschrittliche Modelle sendet.
Kernkomponenten:
- Mehrschichtiger semantischer Caching: exakte Schlüssel-Wert-Paare zusammen mit Vektorähnlichkeit nach cos θ ≥ τ. Wiederholte Anfragen berühren das Modell nie; Kosten und Latenz sinken gleichzeitig.
3. Ausführungsmotor: kontinuierliches Batching und Speichermanagement
Nach der Routeierung gelangt die Arbeit in den Ausführungsmotor. Statisches Batching verschwendet Kapazitäten, da die gesamte Gruppe auf der längsten Sequenz wartet. Produktionsumgebungen nutzen kontinuierliches Batching (Scheduling auf Iterationsebene), damit die Slots stets ausgelastet bleiben und fertige Sequenzen sofort freigeschaltet werden, sobald das Ende der Sequenz erreicht ist.
Kontinuierliches Batching dient nicht nur der Steigerung der Durchsatzrate. Es ermöglicht außerdem den Übergang vom speicherbegrenzten zum rechenleistungsbedingten Arbeitsmodus, sodass die GPU Arithmetikoperationen durchführen kann, anstatt auf HBM warten zu müssen.
4. Direkter Umgang mit Phasenengpässen
Caching, Routing und Batching steuern den Datenverkehr. Die nächsten Maßnahmen verändern die Phasen selbst.
Vorbefüllung: FlashAttention
Die Kosten für die Vorbefüllung steigen mit dem Quadrat der Prompt-Länge, wenn bei klassischer Attention eine vollständige N×N-Score-Matrix in HBM erzeugt wird. FlashAttention ist ein auf I/O optimierter, gefliester Kernel, der präzise Attention-Berechnungen durchführt, indem er die Datenblöcke über die integrierte SRAM streamt – dadurch wird der HBM-Datenverkehr reduziert, ohne dass Mathematikapproximationen nötig sind. Genaues Ergebnis und kürzere TTFT-Zeiten bei langen Prompts. Er ist standardmäßig in den meisten Bereitstellungsstacks enthalten und wird mit gefragmentierter Vorbefüllung sowie anschließender Aufteilung verwendet.
Quantisierung
Die Dekodierung erfordert Ressourcen zum Übertragen der Gewichte von HBM nach SRAM. Durch Quantisierung werden die Gewichte verkleinert – von FP16 auf FP8, INT8 oder 4-Bit (AWQ, GPTQ) – sodass pro Token weniger Bytes übertragen werden müssen. Dadurch steigt die effektive Bandbreite und mehr Sequenzen passen in den Speicher. Mit einer geringfügigen Abnahme der Genauigkeit zu rechnen ist; diese muss durch eigene Bewertungen nachgewiesen werden.
Paged KV-Cache (PagedAttention)
Historische Schlüssel/Werte erweitern den Token nach und nach, was den Speicherverbrauch stark erhöht. Kontinuierliche Allokationen führen zu Fragmentierung und zwingen zu übermäßiger Ausstattung des Speichers. PagedAttention speichert KV-Daten in Blöcken fester Größe, ähnlich wie die virtuelle Speicherung eines Betriebssystems, wodurch Fragmentierung vermieden wird und größere Batch-Größen auf derselben Hardware möglich werden. In Kombination mit kontinuierlichem Batchen wird eine hohe Konkurrenzfähigkeit erreicht.
Spekulatives Dekodieren
Das sequenzielle, am Speicher gebundene Dekodieren lässt die Rechenressourcen zwischen den Lesevorgängen untätig. Beim spekulativen Dekodieren wird diese Zeit genutzt: Ein kleiner Prozessor erfindet eine kurze Abfolge von Tokens; das Hauptnetzwerk prüft diese Abfolge in einem einzigen gemeinsamen Vorwärtslauf. Akzeptierte Tokens kosten in etwa einen Schritt eines großen Modells.
Die Korrektheit wird gewahrt: Übereinstimmende Präfixe bleiben erhalten; bei der ersten Abweichung wird abgeschnitten und das Zielmodell wird aus einer korrigierten Verteilung neu aufgebrochen. Beim gierigen Dekodieren stimmen die Token exakt mit dem Zielmodell überein; beim Sampling stimmt die Verteilung statistisch überein. Die Geschwindigkeitssteigerung hängt von der Akzeptanzrate der Entwürfe ab, daher ist die Qualität der Entwürfe wichtig.
5. Planung beider Phasen: in Blöcken vorbereiten und Aufteilung
Vorbefüllen und Dekodieren erfordern unterschiedliche Rechenressourcen. Der gemeinsame Einsatz eines GPU-Pools lässt zu, dass ein langes Vorbefüllen die Rechenleistung monopolisiert und die Latenz zwischen den Tokens bei allen anderen Anfragen erhöht. Darauf folgen zwei ergänzende Lösungen.
Vorbefüllen in Blöcken
Anstelle eines einzigen großen Vorausfüllvorgangs sollte der Prompt in Abschnitte unterteilt und mit Dekodierschritten im selben Batch verschachtelt werden (Sarathi / Sarathi-Serve). Dadurch werden die Spitzenwerte bei TTFT für benachbarte Aufgaben abgemildert und rechenintensive sowie memorieneintensive Arbeiten miteinander kombiniert. Kontinuierliches Batching entscheidet, welche Anfragen einen Schritt teilen; das in Blöcken erfolgende Vorausfüllen bestimmt hingegen wie ein aufwändiger Vorausfüllvorgang durchgeführt wird, ohne die Dekodierung zu beeinträchtigen.
Getrennte Verarbeitung
Durch das in Blöcken erfolgende Vorausfüllen wird die Störung zwischen den Aufgaben verringert; durch die getrennte Verarbeitung wird sie beseitigt, indem die verschiedenen Phasen auf unterschiedlicher Hardware ausgeführt werden (DistServe, Splitwise). Das Vorausfüllen erfolgt auf rechenoptimierten Pools, die Dekodierung auf bandbreitenoptimierten Pools, wobei KV-Daten über das Interconnect-Netzwerk übertragen werden. Jede Phase skaliert auf dem Silizium, das am besten zu ihrem Engpass passt.
Es gibt tatsächlich Kompromisse: Der KV-Transfer wird zu einem neuen Engpass, und die Gewichte müssen in beiden Pools gespeichert werden. In größeren Skalen zeigt sich, dass eine phasenspezifische Bereitstellung diesen Aufwand überwiegt. Kleinere Systeme beschränken sich oft bereits auf geteilte Vorausfüllungen.
6. Systemische Auswirkungen und Kompromisse
Produktionsmuster tauschen Leistung gegen Betriebsrisiken und Infrastrukturkosten ein. Die Zahlen ändern sich je nach Hardware, Modell, Traffic und Konfiguration – messen Sie Ihre eigene Arbeitslast statt generische Prozentsätze zu übernehmen.
Mehrschichtiges semantisches Caching – präzise KV-Daten zusammen mit Vektorähnlichkeiten. Bei Treffern wird das Modell ganz vermieden. Kosten: Vektorabfrage (eine bis wenige Zehntel Millisekunden) sowie veraltete oder nahe liegende Antworten, wenn τ zu niedrig ist.
Intelligente Routierung – ein Komplexitätsklassifikator leitet einfache Aufgaben an kleinere Modelle weiter. Dadurch sinken die durchschnittlichen Tokenkosten; falsche Routierungen beeinträchtigen jedoch die Qualität.
Kontinuierliches Batching – Verknüpfung auf Iterationsebene während der Generierung. Höhere Auslastung und Durchsatz bei Konkurrenz; einzelne Anfragen können während der Zusammenstellung in der Warteschlange landen. Statisches Batching eignet sich weiterhin für Offline-Durchsatzaufgaben.
Quantisierung – Gewichte mit geringerer Präzision verringern die Übertragungen von HBM nach SRAM. Mehr Konkurrenz pro GPU; Genauigkeit muss überprüft werden; die Kernel-Unterstützung variiert.
Paged KV – Feste Blöcke beseitigen Fragmentierung. Größere Batch-Größen; erfordern Blockverwaltung sowie einen kompatiblen Attention-Kernel.
Spekulatives Dekodieren – Ein kleiner Vorschlagsteller gibt einen Vorschlag ab; das große Modell prüft diesen gemeinsam. Mehrere Token pro großem Schritt; Empfindlichkeit gegenüber einem zweiten Modell und der Akzeptanzrate.
Für genaue Angaben zu Latenzzeiten oder Kosten sollten Sie diese aus reproduzierbaren Benchmarks der Zielarbeitslast beziehen (veröffentlichte Leistungsstudien oder interne Lasttests) und nicht aus festgelegten Marketingprozenten.
7. Schließen des Kreislaufs
Von dem Prototyp bis zur Produktion bedeutet das, für Hardware zu entwerfen. Trennen Sie die Vorausbefüllung von der Dekodierung, beobachten Sie, wie die Batch-Größe die Dekodierung zwischen memoriellen und rechenintensiven Szenarien verschiebt, speichern Sie vorhersehbare Abfragen im Cache, leiten Sie einfache Aufgaben an kleine Modelle weiter und packen Sie Tokens in kontinuierliche Batches. Gegen die Herausforderungen bei der Dekodierung helfen Quantisierung, paginierte KV-Strukturen sowie spekulative Dekodierungsmethoden, während phasenbedingte Störungen durch gebündelte Vorausbefüllung und Aufteilung vermieden werden. Zusammen ermöglichen diese Ansätze es, Spitzenlasten zu bewältigen, ohne die GPUs zu überlasten.
Überprülliste für die Kapazitätsplanung
Wenn TTFT ansteigt, prüfen Sie die Verteilungen der Prompt-Längen, die Trefferquote des semantischen Caches, die Verfügbarkeit von FlashAttention sowie ob lange Prompts weiterhin den GPU als eine einzige Vorausbelegungsmenge monopolisieren. Wenn TPOT bei hoher Konkurrenz ansteigt, überprüfen Sie die effektive Batch-Größe, den KV-Verweilort, das Quantisierungslevel sowie ob die Dekodierung wieder in den durch Speichermangel begrenzten Betriebsmodus zurückfällt.
Eine praktische wöchentliche Überprüfung beinhaltet drei Fragen: Speichern wir vorhersehbare Abfragen im Cache? Leiten wir triviale Aufgaben von den State-of-the-Art-Modellen ab? Paketieren wir die Dekodierung so, dass die GPUs Rechenoperationen durchführen können anstelle darauf zu warten, dass der HBM bereitsteht? Positive Antworten sind in der Regel besser als der Kauf eines weiteren Rack, bevor die Servicestack-Einstellungen optimiert wurden.
Die Aufteilung in kleinere Einheiten sollte erst auf der Roadmap berücksichtigt werden, nachdem bereits das vorab-Befüllen in Blöcken sowie das kontinuierliche Batching ihre Wirksamkeit unter Beweis gestellt haben. Vernetzungsverkehr und doppelte Gewichte stellen echte Kosten dar; man muss sie berücksichtigen, wenn phasenspezifische Pools bei Ihrer Konfiguration eindeutig eine bessere Leistung erbringen als ein gemeinsames Modellensemble.
Dokumentieren Sie die gemessene Größe der Batch-Gruppen, ab der die Dekodierung auf Ihrer Hardware durch Rechenlast begrenzt wird. Diese einzige Zahl dient besser als jedes allgemeine Diagramm aus einem Blog dazu, Ziele für das kontinuierliche Batching festzulegen.
Anmerkungen für Betreiber
Semantische Caches benötigen Überprüfungen bezüglich TTL und τ; ein zu niedriger Wert führt zu nahe liegenden, aber falschen Antworten. Router benötigen datenbasierte Informationen zur Komplexität, sonst senden sie schwierige Anfragen an zu kleine Modelle. Für das kontinuierliche Batching sind SLOs bezüglich der Warteschlangenlatenz notwendig, damit ein „höherer Durchsatz“ nicht interaktive Probleme verdeckt. Für spekulative Dekodierung sind Dashboards zur Überprüfung der Entwurfsakzeptanz erforderlich – falls die Akzeptanz zurückgeht, haben Sie für ein zweites Modell bezahlt, ohne dass es zu einer Beschleunigung kommt.
Betrachten Sie die Arbeiten als Beweise für Mechanismen, nicht als verlässliche Prozentsatzversprechen. Reproduzieren Sie die Ergebnisse auf Ihren GPUs, mit den jeweiligen Prompt-Längen sowie unter Berücksichtigung der Konkurrenzbedingungen, bevor Sie Einsparungen für Finanzzwecke geltend machen.
Referenzen
Die wichtigsten Arbeiten hinter diesen Mechanismen (die Nummern beziehen sich auf die Autoren, nicht auf Sie):
- Orca distributed transformer serving – Yu et al., OSDI 2022 (USENIX).
- PagedAttention Memory Management – Kwon et al., SOSP 2023 (arXiv:2309.06180).
- GPTQ Post-Training Quantization – Frantar et al., 2022 (arXiv:2210.17323).
- AWQ Activation-Aware Weight Quantization – Lin et al., 2023 (arXiv:2306.00978).
- FlashAttention IO-Aware Exact Attention – Dao et al., NeurIPS 2022 (arXiv:2205.14135).
- Speculative Decoding for Fast Transformer Inference – Leviathan, Kalman, Matias, ICML 2023 (arXiv:2211.17192).