LLM Inference: Warum KI-Antworten schnell, langsam, teuer oder günstig sind

Eine LLM-Antwort kann in 100 ms eintreffen oder in 5 Sekunden. Sie kann 0,0001 USD kosten oder 0,1 USD. Diese Unterschiede sind keine Magie — sie sind das Resultat konkreter technischer Entscheidungen: Modellgröße, Hardware, Quantisierung, Inferenz-Stack, Batching-Strategie. Wer LLMs in Produktion betreibt, muss diese Mechanik verstehen, sonst zahlt er zu viel oder produziert unbrauchbare User Experience. Dieser Beitrag erklärt die Bausteine.

1. Was bei einer LLM-Antwort passiert

Eine LLM-Inferenz besteht aus zwei Phasen:

1. Prefill. Die gesamte Eingabe (System-Prompt, Kontext, Benutzerfrage) wird in einem Durchgang verarbeitet. Alle Tokens werden parallel berechnet — das ist GPU-effizient und schnell.
2. Decode. Token für Token wird die Antwort generiert. Jeder neue Token hängt von allen bisherigen ab. Diese Phase ist sequenziell und damit die Hauptquelle der Latenz.

Wichtig: Bei langen Eingaben kann das Prefill länger dauern als der Decode. Bei kurzen Eingaben und langen Antworten dominiert der Decode. Beide Phasen haben unterschiedliche Performance-Charakteristiken und Optimierungsstrategien.

2. Prefill und Decode

Prefill ist compute-bound: Die GPU rechnet voll, der Speicher ist eher unkritisch. Auf modernen GPUs verarbeitet Prefill mehrere tausend Tokens pro Sekunde.

Decode ist memory-bandwidth-bound: Das Modell muss bei jedem Token alle Parameter laden, um den nächsten Token zu berechnen. Die GPU-Rechenleistung wird kaum genutzt; der Engpass ist die Speicherbandbreite. Ein A100 hat ~2 TB/s Speicherbandbreite — bei einem 70B-Modell in FP16 (140 GB) sind das maximal etwa 14 Forward-Passes pro Sekunde, also ~14 Tokens pro Sekunde pro Stream.

Konsequenz: Latenz pro Token hängt fast nur von Modellgröße und Speicherbandbreite ab. Wer schnellere Antworten will, muss entweder das Modell schrumpfen (Quantisierung, Distillation) oder die Hardware verbessern (H100, MI300).

3. Der KV-Cache — Segen und Speicherproblem

Würde der Decode-Schritt jedes Mal die gesamte Eingabe neu durchrechnen, wäre die Komplexität quadratisch in der Sequenzlänge. Die Lösung: der KV-Cache speichert die Key- und Value-Tensoren der Attention-Schichten für alle bisherigen Tokens. Bei jedem neuen Token wird nur der eigene Beitrag berechnet und an den Cache angehängt.

Der KV-Cache ist mächtig — aber teuer. Pro Token werden mehrere KB Speicher belegt (abhängig von Modellgröße und Schichtanzahl). Bei einer Anfrage mit 100.000 Tokens Kontext braucht der Cache mehrere GB GPU-Speicher. Das limitiert, wie viele gleichzeitige Anfragen auf einer GPU laufen können.

Moderne Inferenz-Stacks wie vLLM nutzen PagedAttention — eine Speicher-Management-Technik analog zum virtuellen Speicher des Betriebssystems. KV-Cache-Blöcke werden bei Bedarf zugewiesen und freigegeben, was die Speichernutzung dramatisch effizienter macht.

4. Batching und Throughput

Eine einzelne Anfrage nutzt die GPU schlecht aus — sie ist meistens auf Speicherbandbreite gewartet. Mit Batching werden mehrere Anfragen parallel verarbeitet: Das Modell wird einmal aus dem Speicher geladen, dient aber mehreren Anfragen.

Drei Batching-Modi:

• Static Batching. Alle Anfragen im Batch müssen gleichzeitig starten und enden. Schlecht, weil kurze Anfragen auf lange warten.
• Continuous Batching. Anfragen werden dynamisch dem Batch hinzugefügt und entfernt, sobald sie fertig sind. Standard in modernen Stacks (vLLM, TGI).
• Speculative Batching. Spekulative Tokens werden parallel verifiziert (siehe unten).

Continuous Batching erhöht den Throughput um 3–10× gegenüber Static Batching, ohne die Latenz wesentlich zu verschlechtern. Es ist der wichtigste Single-Engineering-Hebel für produktive LLM-Inferenz.

5. FlashAttention und PagedAttention

FlashAttention ist eine speichereffiziente Implementierung der Attention-Berechnung. Statt die Attention-Matrix vollständig zu materialisieren, wird sie in kleinen Blöcken berechnet, die in den GPU-SRAM passen. Resultat: 2–4× schnellere Attention, weniger Speicherverbrauch. Mittlerweile Standard in fast allen Inferenz-Stacks.

PagedAttention (vLLM) bringt das oben erwähnte virtuelle KV-Cache-Management mit. Es macht GPU-Speicher fast doppelt so effizient nutzbar und ermöglicht deutlich mehr parallele Anfragen pro GPU.

In Kombination liefern FlashAttention plus PagedAttention bereits 5–10× besseren Throughput als naive Implementierungen — bei gleicher Antwortqualität.

6. Speculative Decoding und andere Tricks

Speculative Decoding umgeht die Sequenzialität des Decode: Ein kleines, schnelles Draft-Modell schlägt mehrere Tokens vor (zum Beispiel 4–8 auf einmal), das große Modell verifiziert sie parallel. Bei hoher Übereinstimmung sind 2–4× Beschleunigung möglich. Voraussetzung: Ein gutes Draft-Modell, oft ein Distillate des großen Modells.

Medusa Heads sind eine Variante: Statt eines separaten Draft-Modells werden mehrere Vorhersage-Köpfe an dasselbe Modell angehängt, die parallel Tokens schätzen.

Chunked Prefill zerlegt sehr lange Eingaben in Teile, um Spitzen-Speichernutzung zu glätten.

Multi-Query und Grouped-Query Attention reduzieren den KV-Cache-Speicher, indem mehrere Attention-Heads denselben Key/Value-Tensor teilen.

Diese Techniken stapeln sich. Ein moderner Inferenz-Stack mit vLLM, FlashAttention, PagedAttention, Continuous Batching und Speculative Decoding ist 20–50× schneller als eine naive PyTorch-Implementierung — bei demselben Modell.

7. Praxis: Latenz und Kosten gezielt steuern

In Beratungsprojekten haben sich diese Hebel bewährt:

1. Modellgröße passend zum Use Case. Ein 8B-Modell ist 10× günstiger als ein 70B-Modell. Wenn die Qualität reicht, ist die Wahl klar. Distillation kann diesen Hebel ziehen — siehe Model Distillation.
2. Quantisierung. 4-Bit-Quantisierung halbiert den Speicherbedarf und beschleunigt die Inferenz spürbar. Details in QLoRA und Quantisierung.
3. Richtiger Inferenz-Stack. vLLM, TGI oder SGLang statt naiver Transformers-Loops. Faktor 10× Throughput.
4. Continuous Batching mit hoher Batch-Größe. Maximiert GPU-Auslastung.
5. Streaming der Antwort. Auch bei hoher Gesamtlatenz fühlt sich die Anwendung schnell an, wenn die ersten Tokens nach 200 ms erscheinen.
6. Caching von häufigen Anfragen. Identische Prompts müssen nicht jedes Mal neu berechnet werden.
7. Geeignete Hardware. H100, MI300 oder L40S — die Speicherbandbreite ist der entscheidende Faktor, nicht die Roh-FLOPS.

LLM-Inferenz ist 2026 ein präzise vermessbarer Engineering-Bereich. Wer ihn beherrscht, betreibt produktive Anwendungen zu Kosten und Latenzen, die noch vor zwei Jahren unmöglich schienen. Wer ihn ignoriert, verbrennt Budget auf zwei Achsen: zu teure Cloud-APIs oder zu langsame Eigenbetriebe. Mit dem richtigen Stack und der richtigen Hardware-Auswahl wird aus einer GPU-Investition ein produktives System, das jahrelang trägt. Für den breiteren Betrieb siehe LLMOps.