KI-Inference optimieren: Latenz, Throughput und Kosten im Gleichgewicht

Die drei Dimensionen der Inference-Optimierung

Bevor Sie optimieren, sollten Sie festlegen, was „schnell“ für Ihre Anwendung bedeutet. Relevante Kennzahlen sind:

• Time to First Token (TTFT): die Zeit bis zum ersten ausgegebenen Token. Für Chat-Anwendungen die wichtigste Größe, weil sie bestimmt, wie reaktionsschnell das System wirkt.
• Inter-Token-Latenz: die Zeit zwischen zwei Token, also die Lesegeschwindigkeit der Antwort.
• Throughput: die Gesamtmenge an Token pro Sekunde über alle parallelen Anfragen. Entscheidend für Batch-Verarbeitung und viele gleichzeitige Nutzer.
• Kosten pro Anfrage: die Serverkosten geteilt durch die tatsächlich verarbeitete Last.

Diese Ziele stehen teilweise im Konflikt. Größere Batches erhöhen den Durchsatz, können aber die Latenz einzelner Anfragen verlängern. Die Kunst liegt darin, die richtige Balance für Ihren Anwendungsfall zu finden und sie anhand von Messwerten zu überprüfen.

Quantisierung: weniger Speicher, mehr Geschwindigkeit

Quantisierung speichert die Modellgewichte mit geringerer Genauigkeit, etwa in 8 oder 4 Bit statt 16 Bit. Bei 4 Bit sinkt der Speicherbedarf der Gewichte als Richtwert auf rund ein Viertel. Weil die Textgenerierung stark von der Speicherbandbreite abhängt, steigt dadurch meist auch die Geschwindigkeit.

Ein Modell der 70B-Klasse belegt in 16 Bit rund 140 GB und passt damit auf keine einzelne Karte dieser Klasse. In 4 Bit sind es rund 40 GB – das läuft auf einer RTX PRO 6000 mit 96 GB und lässt Platz für Kontext und parallele Anfragen. Der Qualitätsverlust ist bei aktuellen Verfahren oft gering, hängt aber vom Modell und der Aufgabe ab. Prüfen Sie ihn deshalb immer mit einem eigenen Testset aus realen Anfragen. Wie viel Speicher welches Modell benötigt, zeigt unser VRAM-Guide.

Serving-Framework: PagedAttention und Continuous Batching

Der größte Einzelhebel für den Durchsatz ist oft nicht die Hardware, sondern die Inference-Software. vLLM verwaltet den KV-Cache – den Zwischenspeicher für bereits verarbeitete Token – mit PagedAttention in kleinen Blöcken, ähnlich wie ein Betriebssystem Arbeitsspeicher verwaltet. Dadurch wird weniger VRAM verschwendet und mehr Anfragen passen gleichzeitig auf die GPU.

Continuous Batching sorgt dafür, dass neue Anfragen sofort in laufende Batches aufgenommen werden, statt auf das Ende des vorherigen Batches zu warten. Die GPU bleibt so gleichmäßig ausgelastet. Gegenüber einer Verarbeitung Anfrage für Anfrage ist der Durchsatzgewinn bei parallelen Nutzern erheblich. Einen Vergleich gängiger Frameworks finden Sie im Beitrag vLLM vs. Ollama vs. TGI.

Weitere Stellschrauben im Serving:

• Prefix Caching: Gleiche Systemprompts oder wiederkehrende Dokumentpassagen werden nur einmal berechnet – besonders wirksam bei RAG und Assistenten mit langen Anweisungen.
• FP8-KV-Cache: halbiert den Speicherbedarf des Caches gegenüber 16 Bit und erlaubt längere Kontexte oder mehr parallele Anfragen.
• Begrenzung der Kontextlänge: Wer nicht 128.000 Token braucht, sollte sie nicht reservieren. Eine realistische Maximallänge schafft Platz für mehr gleichzeitige Nutzer.

Speculative Decoding: schneller antworten bei gleicher Qualität

Beim Speculative Decoding schlägt ein kleines, schnelles Draft-Modell oder ein speziell trainierter Draft-Kopf (etwa nach dem EAGLE-Verfahren) mehrere Token im Voraus vor. Das große Modell prüft diese Vorschläge in einem einzigen Rechenschritt und übernimmt die passenden. Weil das große Modell jeden Vorschlag verifiziert, bleibt das Ergebnis inhaltlich gleichwertig.

Der Effekt ist dort am größten, wo Ausgaben vorhersagbar sind: Code, strukturierte Formate wie JSON und formelhafte Texte. Bei sehr hoher paralleler Last kann der Vorteil schrumpfen, weil die GPU dann ohnehin ausgelastet ist. Speculative Decoding ist daher vor allem ein Werkzeug für niedrige Latenz, weniger für maximalen Gesamtdurchsatz.

Praxis-Empfehlungen nach Anwendungsfall

Interaktive Anwendungen (Chat, Assistenten): Optimieren Sie auf Time to First Token und Inter-Token-Latenz. Nutzen Sie Prefix Caching für lange Systemprompts, begrenzen Sie die Batchgröße und prüfen Sie Speculative Decoding.

Batch-Verarbeitung (Dokumentenanalyse, Klassifikation): Optimieren Sie auf Durchsatz. Große Batches, Quantisierung und hohe GPU-Auslastung senken die Kosten pro Dokument deutlich. Die Latenz einzelner Anfragen ist hier zweitrangig.

Kostensensible Anwendungen: Oft ist ein kleineres Modell mit gutem Retrieval die bessere Wahl als ein großes Modell ohne Kontext. Ein Secure Cloud RAG liefert dem Modell die relevanten Informationen, sodass eine kleinere und damit günstigere GPU ausreicht.

Häufige Fehler bei der Optimierung

• Ohne Messung optimieren: Legen Sie vorher Zielwerte fest und messen Sie mit realistischen Anfragen, nicht mit einem einzelnen kurzen Prompt.
• Qualität nicht prüfen: Jede Quantisierung und jede neue Modellversion gehört vor dem Rollout auf ein eigenes Testset.
• Ollama in Produktion für viele Nutzer: Für Tests hervorragend, für hohe Parallelität sind vLLM oder SGLang meist besser geeignet.
• Monitoring vergessen: Ohne Kennzahlen zu Latenz, Warteschlange und VRAM bleiben Engpässe unsichtbar. Mehr dazu im Beitrag Monitoring und Observability für KI-Workloads.

Auf unseren Managed KI-Servern richten wir den Inference-Stack passend zu Ihrem Anwendungsfall ein und überwachen die relevanten Kennzahlen im laufenden Betrieb.