Statisch
Batches fester Größe, die auf Füllung warten. In Ordnung für Offline-Jobs, schlecht für interaktiven Traffic, weil alle auf den Batch warten.
Leitfaden KI-Inferenz
Serving-Optimierung
Techniken auf Systemebene, die entscheiden, wie viele Anfragen eine GPU-Flotte bedienen kann und wie schnell: Batching, Speicherverwaltung des KV-Cache, Decode-Beschleunigung, Phasentrennung, Parallelismus und Routing. Latenz, Durchsatz und Kosten ziehen gegeneinander; der Workload entscheidet, welche Ecke gewinnt.
Batching: der erste Durchsatzhebel
Eine einzelne Anfrage lässt den größten Teil einer GPU brachliegen; das Bündeln von Anfragen verteilt jeden Gewichtszugriff auf viele Tokens. Wie Sie bündeln, macht einen Unterschied:
Dynamisch
Batches schließen nach einem Zeitfenster oder einer Größenobergrenze, was die Wartezeit begrenzt. Besser, doch der Batch endet weiterhin im Tempo seines langsamsten Mitglieds.
Kontinuierlich
Der Scheduler arbeitet auf Tokenebene: Fertige Sequenzen verlassen den Batch im Flug, wartende Anfragen kommen sofort hinzu. Das ist der gängige Standard (vLLM, SGLang, TensorRT-LLM) und der größte einzelne Auslastungsgewinn.
Chunked Prefill verfeinert das weiter: Lange Prompts werden in Stücke zerlegt und mit Decode-Schritten verschränkt, sodass ein riesiger Prompt das Token-Streaming aller anderen nicht mehr blockieren kann. Eine Batching-Regel ist eine Latenzregel; messen Sie TTFT und die Latenz zwischen Tokens, nicht nur Tokens pro Sekunde.
KV-Cache-Speicher: Paging, Wiederverwendung, Offload
PagedAttention
Naives Serving reserviert zusammenhängenden KV-Speicher für die maximal mögliche Länge jeder Anfrage und verschwendet den Großteil als Fragmentierung. PagedAttention übernimmt Ideen der virtuellen Speicherverwaltung: Der Cache liegt in Blöcken fester Größe, die bei Bedarf zugeteilt werden, mit einer Blocktabelle, die die logischen Positionen jeder Sequenz auf physische Blöcke abbildet. Der Verschnitt sinkt auf etwa den letzten Teilblock, identische Präfixe können physische Blöcke teilen, und der zurückgewonnene Speicher wird zu größeren effektiven Batches. Von vLLM eingeführt und heute in Serving-Engines Standard; es ist ein Gewinn bei der Speicherverwaltung, kein schnellerer Kernel.
Prefix Caching
Beginnen zwei Anfragen mit bytegleichen Token-Präfixen (gleicher System-Prompt, gleiche Beispiele, gleicher Gesprächsverlauf), lässt sich die Prefill-Arbeit für dieses Präfix einmal berechnen und wiederverwenden, was bei jedem Treffer TTFT und Prefill-Rechenlast senkt. Es verlangt exakte Tokenübereinstimmung, und deshalb zählt Promptdisziplin: statische Inhalte zuerst, veränderliche Werte (Zeitstempel, Nutzerdaten, Anfrage-IDs) so spät wie möglich, deterministische Serialisierung. Verfolgen Sie die Trefferquote; eine niedrige bedeutet meist, dass die Promptvorlage Variabilität in ihren Kopf lässt.
KV-Cache-Offloading
Der Cache wächst linear mit Kontext und Nebenläufigkeit, und der GPU-HBM geht zuerst aus. Offloading lagert kälteren Cache in CPU-RAM, lokale SSDs oder entfernte Speicher aus und holt ihn bei Bedarf zurück, sodass ruhende Chat-Sitzungen und lange geteilte Kontexte kein HBM mehr binden (LMCache ist das sichtbare Open-Source-Beispiel, integriert mit vLLM). Lohnt sich bei langen Kontexten und fortsetzbaren Sitzungen; der Handel ist Übertragungszeit gegen Neuberechnung, messen Sie also beide Wege auf Ihren Speicherstufen.
Spekulatives Decoding: schnellere Tokens, gleiche Verteilung
Decode ist speicherlimitiert, deshalb bleibt in jedem Schritt Rechenleistung übrig. Ein günstiger Drafter schlägt mehrere Tokens vor; das Zielmodell prüft sie in einem Durchlauf und akzeptiert die längste korrekte Folge. Akzeptierte Tokens entstehen zu einem Bruchteil der Kosten; abgelehnte Entwürfe fallen auf normales Decoding zurück, und exakte Prüfverfahren erhalten die Ausgabeverteilung des Zielmodells.
- Drafter: ein kleines separates Modell, zusätzliche Decoding-Köpfe auf dem Zielmodell (Medusa-Stil), Drafting auf Feature-Ebene (EAGLE-Familie) oder einfache n-Gramm-Suche im Prompt. Implementierungen entwerfen oft mehrere Fortsetzungskandidaten und prüfen den ganzen Baum in einem gebündelten Durchlauf.
- Die entscheidende Größe ist die Akzeptanzrate: Ein gut abgestimmter Drafter hilft bei vorhersehbarem Text (Code, strukturierte Ausgabe) sehr; ein unpassender Drafter kann das Serving verlangsamen.
- Wechselwirkungen: Der Drafter kostet Speicher und Scheduler-Komplexität, und die Gewinne schrumpfen bei sehr großen Batchgrößen, wo der Rechenspielraum verschwindet. Forschungsrichtungen behandelt fortgeschrittene Optimierung.
Herausskalieren: Disaggregation, Parallelismus, Routing
Prefill/Decode-Disaggregation
Prefill ist rechenlimitiert und stoßweise; Decode ist bandbreitenlimitiert und gleichmäßig. Gemeinsam untergebracht stören sie sich: Ein langer Prefill bremst den Tokenstrom aller. Disaggregation betreibt die Phasen auf getrennten Worker-Pools, unabhängig skaliert und abgestimmt, wobei der Prefill-Worker den KV-Cache über ein schnelles Netzwerk an einen Decode-Worker schickt. Der Transfer ist die Steuer, also zahlt sich das in Flottengröße aus und schadet im kleinen Maßstab oder bei kurzen Prompts; zu den Frameworks zählen vLLM, SGLang und NVIDIA Dynamo.
Parallelisierungsstrategien
Datenparallelismus repliziert das Modell und verteilt den Traffic. Tensorparallelismus zerlegt einzelne Schichten über GPUs, damit übergroße Modelle passen, zum Preis von Kommunikation in jedem Schritt (er verlangt Verbindungen der NVLink-Klasse). Pipelineparallelismus weist Schichtbereiche Stufen zu, mit Microbatching, um die Pipeline-Blasen zu füllen. Expertenparallelismus verteilt MoE-Experten über Geräte. Reale Deployments kombinieren all das, und die richtige Mischung ist empirisch: Tensorparallelismus erhöht den Bandbreitendruck, während Replikation den KV-Spielraum pro GPU verkleinert. Messen Sie also Konfigurationen, statt aus ersten Prinzipien zu schließen.
Inferenz-Routing
Bei vielen Repliken wird der Router zu einer Optimierungsfläche. Round Robin ignoriert alles, was bei LLMs zählt; bessere Signale sind aktive Last, Speicherspielraum und vor allem Cache-Lokalität: präfixbewusstes oder sitzungsklebendes Routing schickt Anfragen dorthin, wo ihr KV-Zustand schon liegt (konsistentes Hashing auf dem Prompt-Präfix ist der übliche Trick, genutzt von Projekten wie llm-d). Disaggregierte Flotten routen nach Phase, und Prioritäts- oder SLA-Klassen sowie Adapter-Lokalität können in dieselbe Bewertung einfließen. Davon zu unterscheiden ist das Routing zur Modellauswahl zwischen Modellstufen, behandelt in agentische Patterns.
Offline-Batch-Inferenz
Nicht jeder Workload ist interaktiv. Korpora einbetten, Klassifikationen nachziehen, Zusammenfassungen im Durchlauf erzeugen und Evaluierungen fahren vertragen Stunden an Latenz, was das Optimierungsziel vollständig ändert: die Hardware auslasten, freie oder außerhalb der Spitzenzeit verfügbare Kapazität nutzen (Anbieter verkaufen genau dafür vergünstigte Batch-Stufen) und Nachbearbeitung sowie Qualitätsprüfungen einziehen, bevor Ergebnisse verwendet werden. Batch-Arbeit von der interaktiven Flotte fernzuhalten schützt zudem Ihre Latenz-SLOs.
Messen, bevor Sie glauben
- Messen Sie TTFT, Latenz zwischen Tokens, Ende-zu-Ende-Latenz (Median und P99), Durchsatz bei fester Nebenläufigkeit und Kosten pro Anfrage; Ergebnisse aus einer einzigen Zahl verbergen die Abwägungen.
- Nutzen Sie Ihre eigene Trafficform: Längenverteilungen von Prompt und Ausgabe, Nebenläufigkeitsmuster, Cache-Trefferpotenzial. Synthetische gleichförmige Workloads schmeicheln jeder Optimierung.
- Lastgeneratoren für LLM-Serving (GenAI-Perf, LLMPerf oder k6/Locust-Skripte) berichten Metriken auf Tokenebene, die generische HTTP-Werkzeuge übersehen.
- Halten Sie zu jedem Ergebnis Modell, Quantisierung, Hardware, Engine-Version und Konfiguration fest; unbeschriftete Benchmarks lassen sich weder vergleichen noch reproduzieren.
- Qualitätsbenchmarks (Suiten im MMLU-Stil) und Performancebenchmarks beantworten verschiedene Fragen; eine Serving-Änderung sollte sowohl gegen ein Latenzziel als auch gegen eine Genauigkeitsevaluierung geprüft werden.