End-to-End-Inferenz von LLMs: Vorausbefüllung, Dekodierung, KV-Cache und Stichprobenziehung

Von der Tastenbetätigung bis zum gestreamten Token

Dieser Leitfaden führt durch den gesamten Inferenzweg – Tokenisierer, Embeddings, Attention, KV-Cache, Sampling, spekulatives Dekodieren – und beantwortet die schwierigen Fragen in jeder Phase. Das Ziel ist ein für das Mentale Modellieren geeignetes Konzept, kein Verkaufspitch eines Anbieters.

Teil 1 – Zwei Arbeitslasten, nicht eine

Frage 1: Was passiert zwischen der Enter-Taste und dem ersten Wort?

Eine ehrliche End-zu-End-Aufzeichnung:

1. Eingabe. Eine UTF-8-Zeichenkette wie "Was ist Schwerkraft?" erreicht das System. Der Servicestack umhüllt sie in der Regel mit einem Chat-Template, das spezielle Token für System-, Benutzer- und Assistentenantworten enthält.
2. Tokenisierung. Der Text wird in Unterwortsfragmente aufgeteilt und mit ganzzahligen IDs versehen. Dieser Schritt ist reine Zeichenkettenverarbeitung – noch keine neuronale Netzwerkverarbeitung.

Einbettungsabfrage. Jede ID wählt eine Zeile aus der Einbettungsmatrix E ∈ ℝ^(V × d_model) aus, wodurch ein Tensor der Größe (seq_len, d_model) entsteht. Das Positionszeichen wird hier oder später innerhalb der Aufmerksamkeitsmechanik (RoPE) hinzugefügt.

Vorbelegung. Jeder Prompt-Token durchläuft alle N Transformer-Schichten zusammen. Jede Schicht speichert ihre K- und V-Projektionen im KV-Cache. Diese Phase ist rechenintensiv.

LM-Kopf. Nur der versteckte Zustand der letzten Position wird auf die Größe des Wortschatzes projiziert (~128K Logits).

Stichprobenziehung. Softmax wandelt Logits in eine Verteilung um; eine Strategie (greedy, top-k, top-p, Temperaturen usw.) wählt anschließend eine ID aus.

Dekodierungszyklus. Die ID wird hinzugefügt, eingebettet und zusammen mit dem KV-Cache erneut über den Stack weitergeleitet – ein neuer Token pro Schritt – bis eine Stopps Regel ausgelöst wird.

Detokenisierung und Streamen. Die IDs werden zu Textfragmenten; der Server kann bereits gültige Teilstrings sofort an den Client senden.

Die Zeit bis zum ersten Token ist fast immer die Vorausfüllphase. Alles danach gehört zur Dekodierung.

Frage 2: Warum werden die Inferenzprozesse als zwei verschiedene Arbeitslasten bezeichnet?

Vorausfüllen und Dekodieren liegen auf entgegengesetzten Seiten des Roofline-Modells.

Bottleneck FLOPs / Rechenleistung Speicherbandbreite Aritmetische Intensität Hoch ~1–2 FLOPs/Byte bei Batch 1 Über Tokens hinweg Vollständig parallel Streng sequenziell Latenzfaktor TTFT TPOT / ITL Skaliert mit Länge des Prompts Länge der Ausgabe MFU (Batch 1) Oft 40–60% Oft 1–5%

Beim Vorausladen werden die Gewichte einmal geladen und auf Tausende von Tokenvektoren angewendet. Beim Dekodieren werden dieselben Gewichte für einen einzigen Vektor neu geladen – Gigabyte an Daten werden für Millionen von FLOPs bewegt. Die GPU wartet auf den HBM.

Fast jedes Optimierungstrick – Batchverarbeitung, KV-Cache, Quantisierung, spekulatives Dekodieren, FlashDecoding sowie getrennte Vorausbefüllung/Dekodierung – dient dazu, diese unterversorgte Recheneinheit zu versorgen.

Frage 3: Welche Latenzmetriken sind wichtig und welche Einstellungen beeinflussen sie?

• TTFT – hauptsächlich Vorausbefüllung; nimmt mit der Länge des Prompts zu (und wird noch schlimmer, wenn die Aufmerksamkeitsmechanismen dominieren). Unterstützt durch Präfix-Cache, in Blöcken erfolgende Vorausbefüllung, schnellere Aufmerksamkeitsverarbeitung sowie kürzere Prompts.
• TPOT / ITL – hauptsächlich Dekodierung; ungefähr Bytes pro Schritt / Bandbreite. Unterstützt durch Quantisierung, GQA/MQA, spekulatives Dekodieren sowie kleinere Modelle.
• End-to-End ≈ TTFT + TPOT × Anzahl der Ausgabetoken.
• Durchsatz (Tokens/Sekunde/GPU) – eine Flottenmetrik; größere Batches erhöhen ihn, schaden aber in der Regel dem TPOT pro Benutzer.

Durchsatz und Latenz stehen im Widerspruch zueinander. Die Bereitstellungsstrategie besteht darin, einen Punkt auf dieser Kurve auszuwählen.

Frage 4: Warum kann die Dekodierung nicht wie das Vorausfüllen parallelisiert werden?

Die Erzeugung ist autoregressiv: Jedes neue Token hängt von allen vorherigen ab. Beim Vorausfüllen kennt man bereits den gesamten Prompt, sodass die Positionen unter einer kausalen Maske gemeinsam berechnet werden können. Bei der Dekodierung existiert das „Zukünftige“ noch nicht.

Spekulative Dekodierung ist die Lösung: Man erstellt günstige Vermutungen und überprüft sie anschließend in einem parallelen Schritt – wodurch eine sequenzielle Abhängigkeit in eine parallele Überprüfung umgewandelt wird (Teil 8).

Teil 2 – Phase eins und zwei: Eingabe von Text

Frage 5: Was ist ein Token – und warum sind ganze Wörter oder rohe Zeichen die falschen Extreme?

Ein Token ist ein Subwortatom in einem festen Wortschatz. Reine Extreme funktionieren nicht:

• Wortschatzlisten sind unbegrenzt; Tippfehler und seltene Namen werden zu <UNK> und zerstören Informationen, während die Embedding-Tabelle überlastet wird.
• Zeichenschatzlisten vermeiden unbekannte Zeichen, dehnen aber Sequenzen um das 4–5-Fache aus, was die quadratische Aufmerksamkeitsberechnung beeinträchtigt und dazu führt, dass frühe Schichten die Morphologie erneut erkennen müssen.

Subwörter finden einen Mittelweg: Häufige Wörter bleiben als Ganzes erhalten; seltene Formen zerfallen in bedeutungsvolle Fragmente; nichts ist wirklich unbekannt.

Q6. Wie wird BPE trainiert?

Die Byte-Pair Encoding-Methode beginnt mit Zeichen (oder Bytes) und verschmilzt wiederholt das häufigste benachbarte Paar, bis eine gewünschte Größe des Wortschatzes erreicht ist. Die Verschmelzungen werden als gerankte Liste gespeichert. Bei der Inferenz werden dieselben Verschmelzungen gewinnorientiert von links nach rechts angewendet. Das Training basiert auf zählbaren Statistiken und nicht auf Gradientenabstieg – doch die resultierende Segmentierung prägt alles danach.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE – Verschmelzung nach Häufigkeit; die Dekodierung ist anhand der Verschmelzungstabelle deterministisch.
• WordPiece (BERT-Zeit) – ähnliche Verschmelzungen, jedoch nach Wahrscheinlichkeit bewertet; verwendet oft ##-Markierungen für Fortsetzungen.
• Unigram / SentencePiece – startet mit einer großen Kandidatenliste und fällt sie durch mithilfe eines Unigramm-LM aus; kann Segmentierungen stochastisch auswählen und verarbeitet Rohbytes/Unicode sauber, ohne sprachspezifische Prätokenisatoren.

Heutige Produkt-LLMs neigen dazu, BPE- oder SentencePiece-Varianten auf Byte-Ebene zu verwenden.

Q8. Warum BPE auf Byte-Ebene?

Die Arbeit mit Rohbytes garantiert, dass jede Zeichenkette kodierbar ist – keine unerklärlichen Unicode-Fehler. Das Vokabular lernt weiterhin gängige mehrbyteige Einheiten, sodass Englisch effizient bleibt, während seltene Schriftsysteme sanft in Byte-Backups übergehen.

Q9. Warum haben Modelle Schwierigkeiten, die Buchstaben in „strawberry“ zu zählen?

Weil das Modell niemals Zeichen sieht; es sieht Token-IDs. Wenn „strawberry“ aus einem oder zwei Teilen besteht, bedeutet die Anweisung „zähle die r’s“ eine Struktur, die bereits vor der ersten Schicht weggeworfen wurde. Aufgaben auf Zeichenebene erfordern entweder einen Tokenisierer, der die Zeichen beibehält, oder ein externes Tool.

Q10. Bedeuten Token-IDs für sich genommen etwas?

Nicht wirklich. Eine ID ist lediglich ein Index in der Embedding-Tabelle dieses Modells. Die ID 100 in einem Tokenisierer steht in keiner Beziehung zur ID 100 in einem anderen. Vermischen Sie niemals Tokenisierer verschiedener Modelle.

Q11. Probleme mit Produktions-Tokenisierern

• Chat-Vorlagen und spezielle Token müssen der Trainingsdaten entsprechen.
• Anfangsleerzeichen werden oft zu eigenen Tokenen – „Hello“ ≠ „Hello“.

Durch Trunkierung können Systemanweisungen stillschweigend weggelassen werden, wenn man Zeichen statt Token zählt.

Mehrsprachige Byte-Fallbacks erhöhen Länge und Kosten.

Bild-/Audio-multimodale Sonder-Token ändern die Komprimierungsregeln.

Q12. Kompromisse bei der Größe des Wortschatzes

Eine größere V-Größe verkürzt Sequenzen und verbessert die Mehrsprachigkeit, erhöht aber die Parameter für Embeddings sowie LM-Heads (V × d_model jeweils) sowie die Kosten für die Dekodierung mit Softmax. Typische Werte in der modernen Praxis liegen bei etwa 32K–150K; darüber hinaus entstehen zunehmende Kosten für Speicher und Bandbreite bei abnehmender Effizienz.

Q6. Wie wird BPE tatsächlich trainiert

Byte-Pair Encoding ist eine Komprimierungsmethode, die zur Wortschatzvermittlung wiederverwendet wird:

1. Starten Sie den Wortschatz mit Basissymbolen (bei bytebasiertem BPE: alle 256 Bytes).
2. Darstellen Sie das Korpus als Sequenzen dieser Symbole.
3. Zählen Sie benachbarte Paare und wählen Sie das häufigste aus.

Führen Sie die Kombination dieser beiden Einheiten zu einem neuen Symbol durch, fügen Sie es dem Wortschatz hinzu und dokumentieren Sie die entsprechende Rangfolge der Kombinationsregel.

Wiederholen Sie diesen Vorgang, bis die gewünschte Größe erreicht ist (zum Beispiel etwa 100K–128K in modernen Systemen).

Ergebnisse: eine Karte von Symbolen zu IDs sowie eine geordnete Liste der Kombinationen. Bei der Kodierung werden die Kombinationen in dieser Reihenfolge gierig durchgeführt – deterministisch, ohne globale Suche nach der kürzesten Segmentierung.

Nuance: Die Kombinationen optimieren die Frequenz, nicht linguistische Aspekte. ing wird zu einem Token, weil es häufig vorkommt. Morphologische Eleganz spielt dabei nur eine untergeordnete Rolle.

Q7. BPE vs WordPiece vs Unigram / SentencePiece

• BPE (GPT-Reihe, Llama): Kombinationen auf Grundlage der Frequenz; deterministische Kodierung.

WordPiece (BERT-Zeit): ähnlicher Algorithmus, wählt jedoch solche Zusammenfassungen aus, die unter einem Unigramm-Modell die Wahrscheinlichkeit der Trainingsdaten maximieren – indem bewertet wird, wie informativ ein Paar zusammengefasst im Vergleich zu getrennt ist.

Unigramm LM (oft über SentencePiece; T5/Gemma-Klasse): startet mit vielen Tokenen und entfernt anschließend jene, deren Wegfall die Wahrscheinlichkeit am wenigsten beeinträchtigt. Die probabilistische Segmentierung ermöglicht Subwort-Regulierung (Auswahl alternativer Trennungen während des Trainings).

SentencePiece ist eine Bibliothek, die BPE oder Unigramm anwenden kann. Ihr praktischer Vorteil besteht darin, dass sie Rohzeichen mit einem sichtbaren Leerzeichenmarker behandelt, wodurch die Tokenisierung rückgängig gemacht werden kann und keine Vor-Tokenisierung von Leerzeichen nötig ist – was für Chinesisch, Japanisch und Thailändisch entscheidend ist.

Q8. Byte-basiertes BPE ist wichtig, weil…

Unicode-Zeichens Initialen würden etwa 150.000 Startwerte benötigen und trotzdem <UNK>. Der Ausgangspunkt bei UTF-8-Bytes bedeutet, dass jede Zeichenkette – Emojis, kyrillische Schriftzeichen, fehlerhafte Bytes – kodiert werden kann. Es kommt zu keinem OOV-Fehler.

Kosten: Emojis können mehrere Token verbrauchen; nicht-lateinische Schriftsysteme kosten oft 2–4-mal so viel wie Englisch für dieselbe Bedeutung, wodurch Nutzer, die keine Englisch sprechen, früher auf Rate Limits und Kontextgrenzen stoßen. Größere Wortschatze (Sprünge von 32.000 auf 128.000) dienen teilweise dazu, diese Ungleichheit zu verringern.

Q9. Warum „Wie viele r’s gibt es in Strawberry?“ fehlschlägt

Das Netzwerk sieht niemals Buchstaben; es sieht IDs. Wenn strawberry aus mehreren Teilwörtern besteht, erfordert die Zählung der Zeichen die Wiederherstellung der Schreibweise aus Embeddings und anschließende Aggregation – es gibt keine eingebauten Operationen zum Durchlaufen der Zeichen. Dasselbe Problem tritt bei Anagrammen, Palindromen, Umkehrungen sowie naiver Arithmetik auf, wenn die Zifferngruppierung bei verschiedenen Zahlen unterschiedlich ist. Moderne Tokenisierer zwingen manchmal gezielt zu Zifferntrennungen, um die Arithmetik lernfähig zu machen.

Q10. Token-IDs isoliert

Eine ID ist ein Index in die Tabellen dieses Modells. Der Vergleich von Tokenisierern ist sinnlos. Selbst „spezielle“ IDs unterscheiden sich zwischen den verschiedenen Modellfamilien.

Q11. Probleme in der Produktion

Es ist zwingend erforderlich, das Trainings-Chat-Template sowie die Spezial-Token-Gruppe zu verwenden. Anfangsleerzeichen gelten oft als echte Token. Das Zählen der Zeichen, wenn die API stumm nach Tokens abrechnet, führt zur Kürzung der Anweisungen. Multimodale Sentinel-Token ändern die Packungsmethode. Cache-Schlüssel müssen die Tokenisierungs-Version enthalten. Eine fehlerhafte Handhabung von BOS/EOS durch einen Fehler von eins stört die Stop-Bedingungen sowie die Prüfungen der Logprobabilitäten.

Q12. Kompromisse bei der Größe des Wortschatzes

Eine größere V-Wert verkürzt Sequenzen und erleichtert die multilinguale Packung, erhöht jedoch die Parameter für Embeddings, LM-Head sowie den Decode-Softmax. Ab etwa 100K–200K muss man in der Regel mehr Speicher/Raumbandbreite bezahlen, um nur geringe Verbesserungen der Qualität zu erzielen – es sei denn, die multilinguale Abdeckung erfordert es.

Teil 3 – Embeddings

Q13. Embedding: gather vs matmul

Eine Zeilenabfrage entspricht dem Multiplizieren eines One-Hot-Vektors mit E. Kernels nutzen das Verfahren „gather“; die Mathematik bleibt linear.

Q14. Kontextbezogen oder nicht?

Die Eingabezeilen sind nicht kontextbezogen. Der Kontext entsteht durch die Aufmerksamkeit über verschiedene Schichten. Die Retrieval-Embeddings sind in der Regel tiefere Zustände und nicht die Zeile der Eingabentabelle.

Q15. Gewichtsverknüpfung

Um Parameter zu sparen, werden die Embedding-Gewichte mit dem LM-Head geteilt (durch Transponieren) – das ist bei kleineren Modellen üblich. Große LLMs trennen die Gewichte oft, um Qualität zu gewährleisten. Verknüpfte Heads stellen keine zusätzliche unabhängige d × V-Matrix dar.

Q16. Positionsinformationen

Absolute Embeddings fügen Vektoren pro Index hinzu. RoPE rotiert Q/K, sodass relative Abstände in den Scores erscheinen und mit dem KV-Caching zusammenarbeiten. Relative Bias-Schemata sind Alternativen; RoPE dominiert bei neuen LLMs.

Q17. RoPE und Erweiterung auf lange Kontexte

Die relative Geometrie von RoPE liefert bessere Extrapolationen als naive absolute Tabellen. Erweiterungen (Position interpolierung, skalierende Verfahren unter Berücksichtigung von NTK, YaRN usw.) skalieren die Rotationsfrequenzen neu, sodass längere Kontexte ohne erneutes Training stabil bleiben.

Frage 18: Der √d_model-Faktor

Wenn Token- und Positionsvektoren zusammengefügt werden, können die Skalen miteinander kollidieren; das Multiplizieren der Embeddings mit √d_model gleicht dies aus. Rotationsbasierte RoPE-Strukturen überspringen oft diese Multiplikation.

Teil 4 – Der Transformer-Block

Fragen 19–23: Mechanismen der Aufmerksamkeit (erweitert)

x → MultiHeadSelfAttention → Add & Norm → FFN → Add & Norm → out

Attention(Q, K, V) = softmax(QKᵀ / √d_k) V

Abfragen suchen, Schlüssel bewerben, Werte liefern. Softmax über skalierte Werte ergibt Mischgewichte. Teilen Sie durch √d_k, damit die Scores nicht bei zunehmender Breite saturieren. Mehrere „Köpfe“ diversifizieren die Unterräume. Kausale Masken schreiben −∞ in verbotene Zukünfte, sodass die Masse des Softmax genau null ist – Nullwerte in der Maske würden dennoch durchsickern. Bei reinem Dekodieren mit Cache enthält die Schlüsselsammlung keine zukünftigen Positionen, weshalb die Maske implizit ist; das Vorausfüllen erfordert dennoch Maskierung (oder einen kausalen Kern).

Q24–Q26. Formen, Kosten, Residuen

Jede Projektion hat eine Größe von etwa d × d (unter GQA modifiziert). FFNs dominieren mit einer Erweiterung um etwa das 4-fache. Der Aufwand für die Attention-Funktion skaliert mit O(n² d); bei FFNs mit O(n d²). Kurze Prompts: Begrenzung durch Gewichte/FFNs. Lange Kontexte: Attention und KV-Speicher dominieren. Residuen ermöglichen es, tiefe Stack-Strukturen durch Gradientenwege und additive Anpassungen trainierbar zu halten.

Q27–Q30. Normen, FFN-Breite, Aktivierungen, MoE

RMSNorm überspringt die Mittelwertberechnung und ist günstiger als LayerNorm. Pre-norm stabilisiert sehr tiefe Netze im Vergleich zur klassischen Post-Norm-Methode. Breite FFNs (~4×) ermöglichen eine höhere Kapazität pro Token zwischen den Attention-Mixern. Nichtlinearitäten verhindern, dass gestapelte lineare Schichten kollabieren; SwiGLU gewann viele LLM-Ablationstests. MoE leitet Tokens an wenige Expert-FFNs weiter, sodass sich die Parameter schneller skalieren als die FLOPs pro Token – memory-intensiv, rechensparend.

Q31–Q32. Tiefe/Breite und Attention-Varianten

Die Tiefe wiederholt das Mischen; die Breite bereichert die Merkmale. Die Labore wählen innerhalb der Daten- und Clusterbegrenzungen aus. MHA speichert K/V pro Token; MQA teilt ein K/V über mehrere Abfragen hinweg; GQA teilt es pro Gruppe; MLA komprimiert die KV-Werte weiter. Die Kosten für den Datendienst haben die Branche in dieser Reihenfolge vorangetrieben.

Teil 5 – Der KV-Cache

Q33. Was ist der KV-Cache – und warum nur K und V?

In Schritt t der Dekodierung kommt ein neuer Token an. Seine Abfrage q_t muss Schlüssel und Werte für die Positionen 1..t berücksichtigen. Die Schlüssel und Werte für 1..t−1 hängen nur von früheren Tokenen sowie festgelegten Gewichten ab. Durch Kausalität wird sichergestellt, dass das Einfügen des Tokens t diese vorherigen K/V-Tensoren nicht überschreiben kann – sie sind unveränderlich –, weshalb sie einmal berechnet und gespeichert werden.

Die Abfragen unterscheiden sich: Für den aktuellen Schritt benötigen Sie nur q_t. Ältere Abfragen haben bereits ältere Ausgaben erzeugt und werden niemals wieder gelesen, wodurch das Caching von Q zu einem verschwendeten Speicher ist.

Ohne Cache würde das Ausgeben des Tokens t den gesamten Präfix erneut ausführen – eine Arbeit, die mit der Länge stark ansteigt. Mit dem Cache ist die Aufmerksamkeit in jedem Schritt linear zur aktuellen Länge, und der FFN erfordert effektiv konstante Rechenleistung pro neues Token. Die Generierung wird somit linear zur Anzahl der Dekodierschritte, anstatt quadratisch zu den Durchläufen.

Q34. Bestimmen Sie die Größe des KV-Caches mit einer realen Zahl

KV bytes = 2 (K and V)
         × n_layers
         × n_kv_heads × d_head
         × seq_len
         × batch_size
         × bytes_per_element

Setzen Sie ein GQA-Layout im Stil von Llama-3–70B ein: achtzig Schichten, acht Schlüssel/Wert-Headern, jeweils einhundertzweiundzwanzig Dimensionen pro Head, gespeichert in zweibaytigen Floats.

Multiplizieren Sie diese Faktoren: zwei Tensor (K und V) × achtzig × acht × einundzwanzig/zwanzig × zwei Bytes ergeben fast 320 KB pro Token jeder laufenden Sequenz.

Erweitern Sie das auf ein Gespräch mit 8.000 Token, dann liegt die Menge bei etwa 2,6 GB pro Benutzer. Bei 128.000 Kontext-Token weist dieselbe Formel auf Dutzende von GB hin – genug, damit ein einzelnes Gespräch bereits einen großen Teil einer H100-klassigen Maschine belegt, noch bevor die Gewichte berücksichtigt werden.

Kontrafaktisch ohne GQA (64 KV-Head): Die Zahl für 8.000 Token steigt auf etwa ~21 GB pro Sequenz. GQA ist der Unterschied zwischen Dutzenden gleichzeitiger Benutzer und nur wenigen.

Die Gewichte stellen eine einmalige, feste Gebühr dar. Der KV-Cache hingegen ist eine pro Benutzer, pro Token, unbegrenzte Gebühr. Er legt die maximale Batch-Größe fest, was wiederum die Durchsatzrate bestimmt und letztendlich den Betrag pro Million Token ergeben wird. Deshalb wird er in Diagrammen als Hauptengpass des Arbeitsspeichers bezeichnet.

Q35. Warum die Dekodierung durch den Arbeitsspeicher begrenzt wird – die Rechenlogik

Betrachten wir ein 70B-fp16-Modell, das in einem Batch einen Token erzeugt:

• Bewegte Bytes: ~140 GB an Gewichten plus einige GB für den KV-Cache ≈ 142 GB.
• FLOPs: ≈ 2 × 70e9 × 1 = 140 GFLOPs.
• Intensität: ≈ 1 FLOP/Byte.

Ein H100 bietet eine Bandbreite von etwa 3,35 TB/s über HBM sowie ca. 1000 TFLOPs im fp16-Modus. Der Punkt, an dem die Rechenleistung von der Bandbreite eingeholt wird, liegt bei Hunderten von FLOPs pro Byte. Bei 1 FLOP/Byte werden nur ein winziger Bruchteil der maximalen Rechenkapazitäten genutzt – die GPU dient hauptsächlich als Speicherschlepper.

Reale Rechenzeit ≈ 142 GB / 3,35 TB/s ≈ 42 ms → etwa 24 Token pro Sekunde allein durch die Bandbreite. Reale Systeme liegen im Zweifachen dieses Wertes, was zeigt, wie stark die Bandbreitenbeschränkungen die Leistung bestimmen.

Folgerung: Die Erhöhung der Batch-Größe kostet fast nichts für den Gewichtstransport, solange nicht die Rechenleistung begrenzt ist. Der Wechsel von Batch 1 auf 32 ermöglicht die Wiederverwendung derselben Gewichtsdaten für 32 Sequenzen und kann dadurch die Token-Durchsatzrate erhöhen. Diese Amortisierung ist das zentrale wirtschaftliche Prinzip bei der Bereitstellung von LLMs.

Q36. Wenn das Batching „kostenlos“ ist, warum dann nicht 512?

Weil jede Sequenz ihren eigenen KV-Speicherbedarf hat und der Cache mit Batch × SeqLen skaliert:

GPU memory = model weights + KV cache + activations + fragmentation overhead

Beispiel: 140 GB an Gewichten auf 2×H100 (160 GB) lassen etwa 20 GB für den Cache übrig. Bei 320 KB pro Token entspricht das insgesamt etwa 65.000 Token im Batch. Schon sechzehn Benutzer mit 4K Kontextmenge erschöpfen bereits diesen Budgetrahmen.

Durch die Obergrenze für die Größe von KV wird die Batch-Größe begrenzt, was wiederum die Durchsatzleistung einschränkt. GQA, MLA, Cache-Quantisierung, Paging sowie Eviction-Policies sind Durchsatzfunktionen, die sich als Speichermechanismen ausgeben.

Q37. PagedAttention und das Fragmentierungsproblem

Naive Server reservieren pro Anfrage einen kontinuierlichen KV-Bereich bis zu max_seq_len. Das versagt auf zwei Arten:

• Interne Fragmentierung – eine 100-Token-lange Aufgabe, die 4096 Slots reserviert hat, verschwendet den größten Teil der Allokation.
• Externe Fragmentierung – befreite Bereiche unterschiedlicher Größe hinterlassen Lücken, in die keine neuen Bereiche mehr platziert werden können.

Der gemeldete Verschwendungsfaktor bei naiven Allokatoren liegt oft im Bereich von 60–80% des KV-Speichers.

PagedAttention (von vLLM populär gemacht) übernimmt das Konzept der virtuellen Speicher in Betriebssystemen: fest definierte Blöcke (z. B. 16 Token) sowie eine Blocktabelle, die logische Positionen mit physischen Blöcken innerhalb eines Pools verknüpft. Im Laufe der Generierung werden weitere Blöcke zugewiesen.

Vorteile:

• Die Fragmentierung nimmt ab → oft 2–4× mehr parallele Sequenzen auf denselben GPUs möglich.
• Vorzeichengeteilte Nutzung / Kopieren bei Schreiben – viele Anfragen mit demselben Systemprompt teilen sich physische Blöcke, solange ihre Suffixe identisch sind; ideal für Agenten, RAG-Anweisungen und Few-Shot-Beispiele.
• Strahlen sowie parallele Beispiele teilen sich das gemeinsame Vorzeichen, anstatt es zu klonen.

Der Preis dafür sind Indirektheit sowie ein Attention-Kern, der Daten aus nicht kontinuierlichen Blöcken sammelt.

Q38. Statische vs kontinuierliche Batching

Statisches Batching wartet darauf, eine Batch-Gruppe zu füllen, führt alle Sequenzen im Einklang mit der längsten aus und füllt ggf. mit Platzhaltern auf. Kurze Anfragen warten auf längere; GPUs verbrauchen Ressourcen an diesen Platzhaltern.

Kontinuierliches (iterationenbasiertes) Batching baut die Batch-Gruppe bei jedem Dekodierungsschritt neu auf: Abgeschlossene Sequenzen werden entfernt, neue treten ein, und die GPU ist nur mit aktiven Token beschäftigt. Die Latenzvarianz sinkt und die Leistung steigt deutlich – das ist in modernen Engines (vLLM, TensorRT-LLM usw.) selbstverständlich.

Q39. In Blöcken erfolgendes Vorausfüllen sowie Trennung von Vorausfüllen und Dekodieren

Ein Vorausfüllvorgang mit mehreren Tausend Token kann die GPU monopolisieren und die Dekodierung für interaktive Benutzer verlangsamen. In Blöcken erfolgendes Vorausfüllen teilt lange Anfragen in Abschnitte auf, die mit den Dekodierungsschritten abwechseln, sodass die TTFT-Zeit etwas steigt, während die TPOT-Zeiten weiterhin konstant bleiben.

Disaggregation geht noch weiter: Es werden Vorausfüllvorgänge in rechenoptimierten Pools durchgeführt und Dekodierungen in memorieneroptimierten Pools, wobei KV-Daten über das Netzwerk übertragen werden. Dadurch erhöht sich die Orchestrierungskomplexität, doch jede Phase wird dem Hardware-Setup zugeordnet, das tatsächlich ausgelastet wird.

Q40. Verkleinerung von KV-Daten jenseits von GQA

Mögliche Ansätze sind:

• MQA / GQA / MLA – weniger oder komprimierte KV-Einheiten.
• Quantisierte Caches (im Stil von INT8/FP8/NF4) – in der Regel nahezu verlustfrei für K/V-Daten.
• Fensterbasierte / schwebende Aufmerksamkeit – entfernung weit entfernter Token, sofern die Aufgabe es zulässt.
• Ausschließungs- / Streaming-Strategien für extreme Szenarien.
• Cross-Layer-Neuverwendung – Forschungsideen, die Projektionen über verschiedene Ebenen hinweg teilen.

Jeder dieser Ansätze opfert etwas an Qualität oder Allgemeingültigkeit, um große Vorteile in Bezug auf den Speicherverbrauch zu erzielen.

Q41. Präfix-Caching – bei Architekturänderungen

Falls viele Anrufe ein langes, unveränderliches Präfix teilen (Systemanweisungen, Tool-Schemata, abgerufener Kontext), vermeidet das Caching dieses Präfixes die erneute Berechnung. Architekturen bevorzugen daher stabile Präfixe und veränderliche Suffixe: Volatiler Benutzertext wird am Ende platziert, während der gemeinsame Stamm exakt gleich bleibt, damit die Cache-Schlüssel zutreffen. Produktbeschreibungen und Anweisungscompiler werden somit zu Faktoren für die Leistung.

Q42. Wann wird der KV-Cache ungültig?

Jederzeit, wenn vorherige Token geändert werden, nicht nur hinzugefügt: bei der Neugenerierung mitten in einer Konversation, beim Überschreiben einer Systemanweisung, beim Wechsel der Tool-Definitionen oder bei anwendbaren nicht-kausalen Änderungen. Präfix-Caches müssen nach der genauen Token-Identität (sowie Version des Templates) gespeichert werden. Sampling-Parameter machen K/V-Daten nicht ungültig – sie ändern lediglich, wie aus Logits die nächste ID entsteht – doch das Ändern des Modell-Adapters, des Entwurfsmodells oder der RoPE-Skala während des Betriebs kann dies bewirken.

Teil 6 – LM-Head (linear + softmax)

Frage 43: Was der LM-Head tut und seine Strukturen

Der letzte Block gibt h ∈ ℝ^(seq_len × d_model) aus. Nach einer finalen Normalisierung erzeugt eine lineare Abbildung die Vokabular-Logits:

logits = h @ W_lm      W_lm ∈ ℝ^(d_model × V)

Für d_model = 4096 und V = 128.000 enthält W_lm 524 Mio. Parameter und liefert für jede bewertete Position einen 128K breiten Vektor.

Frage 44: Gibt es während der Dekodierung Logits für jede Position?

Nicht unbedingt. Der Prefill kann bei der Trainierung oder für bestimmte APIs viele Positionen bewerten, doch die normale Dekodierung benötigt nur den versteckten Zustand der letzten Position. Frühere Positionen haben bereits ihre Token ausgewählt.

Frage 45: Kosten des LM-Heads bei der Dekodierung

Jeder Schritt multipliziert einen d-Vektor mit d × V – was zu einer Anzahl von FLOPs im Bereich von 2 × d × V sowie einem vollständigen Lesen eines potenziell ungebundenen Heads führt. Bei großen Werten von V ist dies mit einer FFN-Schicht vergleichbar und rechtfertigt die Verwendung von adaptivem Softmax, parallelem Aufteilen des Wortschatzes sowie gebundenen Embeddings, sofern dies zulässig ist.

Q46. Logits gegenüber Wahrscheinlichkeiten

Logits sind unbegrenzte Scores. Softmax normalisiert sie:

p_i = exp(z_i) / Σⱼ exp(z_j)

Vergessen Sie nicht die Shift-Invarianz: Das Hinzufügen einer Konstante zu allen Logits ändert die Wahrscheinlichkeiten nicht – das ist die Grundlage stabiler Implementierungen sowie der Temperatur als Skalierung der Differenzen.

Q47. Numerisch stabiles Softmax

Die naive Berechnung von exp(z_i) führt in fp16 bei mäßigen Logits zu Überlauf und kann dazu führen, dass eine ganze Zeile auf Null gesetzt wird, was 0/0 erzeugt. Die Lösung besteht darin, zunächst den Maximalwert der Zeile abzuziehen:

p_i = exp(z_i − max(z)) / Σⱼ exp(z_j − max(z))

Der größte Term wird zu exp(0) = 1; die übrigen liegen in (0, 1]. Online-Algorithmen (wie FlashAttention) kombinieren dies mit matmul, um enorme Bewertungsmatrizen zu vermeiden.

Q48. Perplexität

Die Perplexität ist exp(durchschnittliche negative log-likelihood) bezüglich der Tokens – sie gibt an, wie „überrascht“ das Modell ist. Sie wird aus derselben logits/softmax-Phase berechnet. Eine niedrigere Perplexität in einem bestimmten Bereich deutet auf eine bessere Kalibrierung der nächsten Token hin, ist aber kein direkter Maßstab für Nützlichkeit oder Sicherheit.

Teil 7 – Stichprobenstrategien

Nach dem LM-Head erhält man einen Vektor aus Logits. Durch Stichprobenziehung wird dieser Vektor zum nächsten ID.

Q49. Gierige Dekodierung – und warum sie enttäuscht

Greedy wählt immer argmax. Es ist deterministisch und kostengünstig, doch oft langweilig oder lokal stur: Früh auftretende Token mit hoher Wahrscheinlichkeit können die Sequenz in repetitive, hochwahrscheinliche Schleifen locken, die von Menschen als schlechter eingestuft werden als Alternativen mit etwas geringerer Wahrscheinlichkeit. Verwenden Sie es für anfällige Extraktionsaufgaben; vermeiden Sie es als Standardlösung für offene Prosa.

Q50. Warum nicht Beam Search?

Beam Search behält die B besten Teilhypothesen bei. Er ist nützlich, wenn das Ziel kurz und eingeschränkt ist (zum Beispiel bei Übersetzungen). Bei offenen Chat-Dialogen erzeugt er in der Regel allgemeinen, hochwahrscheinlichen und sicheren Text, erfordert B× Rechenleistung und funktioniert schlecht mit diversitätsbasierten Ansätzen wie nucleus. Die meisten LLM-Anwendungen haben ihn zugunsten von Sampling-Methoden aufgegeben.

Q51. Top-k

Bewahren Sie nur die k größten Logits auf, renormalisieren Sie sie und ziehen Sie anschließend ein Sample. Einfach, doch k ist unpräzise: Manchmal spielt die Wahrscheinlichkeitsdichte außerhalb der Top-k-Gruppe trotzdem eine Rolle; manchmal enthält die Top-k-Gruppe unerwünschte Werte, wenn die Verteilung schmal ist. Ein fester k kann sich nicht an die Schärfe der Verteilung anpassen.

Q52. Top-p (Kern)

Sortieren Sie nach Wahrscheinlichkeit, behalten Sie die kleinste Menge bei, deren kumulierte Masse ≥ p beträgt, und ziehen Sie anschließend ein Sample. Wenn das Modell sich sicher ist, schrumpft der Kern; bei Unsicherheit weitet er sich aus. Genau diese Anpassungsfähigkeit ist der Grund, warum Top-p den festen Top-k-Wert in vielen Implementierungen als Standard ersetzt hat. Typische p-Werte liegen bei etwa 0,9–0,95 und werden je nach Produkt angepasst.

Q53. Temperatur – Mathematik und Intuition

p_i = exp(z_i / T) / Σⱼ exp(z_j / T)

Teilen Sie die Logits vor der Anwendung von Softmax durch T.

• T → 0 – Die Lücken zwischen den Wahrscheinlichkeiten werden enorm; die Verteilung kollabiert auf den argmax-Wert (greedy Ansatz).
• T = 1 – Unskalierte Verteilung des Modells.

T > 1 — Vereinfachung; mehr Überraschungselemente und Risiko der Inkohärenz.

In der Implementierung fügt die Temperatur allein keine „Zufälligkeit“ hinzu – sie verändert lediglich die Verteilung, aus der der Sampler zieht.

Q54. Reihenfolge: Temperatur gegen Trunkierung

Wenden Sie zunächst die Temperatur auf die Logits an, danach den top-k-/top-p-Filter auf die resultierende Verteilung (oder alternativ eine Trunkierung der temperierten Wahrscheinlichkeiten). Die Trunkierung vor Anwendung der Temperatur verändert, welche „Schwänze“ vorhanden sind, und ist in der Regel die falsche Vorgehensweise. Dokumentieren Sie die von Ihrem Server verwendete Reihenfolge – stillschweigende Änderungen beeinflussen das Verhalten.

Q55. Strafen für Wiederholung, Häufigkeit und Vorhandensein

• Wiederholung/Häufigkeit — Tokens, die bereits gesehen wurden, werden abgewertet, oft in Abhängigkeit von ihrer Anzahl.
• Vorhandensein — Ein Token wird einmal bestraft, sobald es überhaupt aufgetaucht ist, unabhängig von der Anzahl.

Sie bekämpfen Schleifen bei kreativer Dekodierung, können aber absichtliche Wiederholungen (Code, Poesie, juristische Formulierungen) schädigen. Man sollte milde Strafen sowie strenge Stoppsregeln vor aggressiven Einschränkungen bevorzugen.

Q56. Jenseits von top-p

Min-p-Schwellenwerte in Bezug auf die höchste Wahrscheinlichkeit (p_i ≥ min_p × p_max), die bei hoher Temperatur und diffuser Masse besser funktionieren. Mirostat sowie verwandte Controller zielen auf ein bestimmtes Überraschungsniveau ab. In der typischen Produktion konzentriert man sich weiterhin auf Temperatur + top-p, wobei min-p an Bedeutung gewinnt.

Q57. Warum variiert die Temperatur bei 0 trotzdem?

Selbst „gierige“ Stack-Strukturen unterscheiden sich in Bezug auf:

• nicht-deterministische GPU-Reduzierungen sowie gefusionierte Kerne.
• verschiedene Batching-/kontinuierliche-Batch-Pläne.
• spekulative Ausführungspfade sowie numerisch unterschiedliche Implementierungen von Softmax.
• Standard-Strafen, Stoppsätze und Vorlagen auf Serverseite.

Routing-Störungen durch MoE, sofern aktiviert.

Bit-stabile Strategien erfordern gesperrte Kernel, eine Batch-Größe von 1 sowie identische Softwareversionen – was in Mehrbenutzer-Umgebungen selten vorkommt.

Frage 58: Erzwingen von JSON oder einem Schema

Die verfügbaren Optionen sind:

1. Aufforderung zum Einsatz von JSON (anfällig).
2. Eingeschränkte Dekodierung / Grammatikmasken – illegale Token werden bei jedem Schritt eliminiert (Regex, JSON-Schema, CFG).
3. Nutzung von Tools/Funktionen mit APIs, die Nebenkanäle statt freier Texte analysieren.
4. Nachträgige Korrektur (letzter Ausweg).

Eingeschränkte Dekodierung ist die zuverlässige Lösung für Systeme, in denen Gültigkeit zwingend erforderlich ist.

Frage 59: Bewertung der Sampling-Einstellungen

Halten Sie das Modell fest und prüfen Sie Temperaturen sowie Top-P-Werte an einer beschrifteten Datensammlung: Erfolg der Aufgabe, Toxizität, Vielfalt (distinct-n), Wiederholungsrate, Latenz. Bevorzugen Sie eine Offline-Bewertung zusammen mit einer Online-A/B-Testung unter Verwendung klarer Produktmetriken. Tunen Sie nicht anhand eines einzigen ausgewählten Prompts.

Teil 8 – Spekulative Dekodierung

Frage 60: Kernidee

Ein günstiges Entwurfs-Modell schlägt mehrere zukünftige Token vor; das Ziels-Modell überprüft sie in einem parallelen Vorwärtslauf über den Entwurfsbereich. Der angenommene Präfix wird als Ausgabe verwendet; bei der ersten Ablehnung wird ein Ersatz aus der Zieldistribution gezogen und der Rest verworfen. Sie verwenden den größten Teil der Kapazität des Zielsystems für die parallele Überprüfung anstelle von seriellen Schritten mit jeweils einem Token.

Frage 61: Warum sich die Ausgabedistribution nicht ändert

Die Akzeptanz nutzt das Verhältnis zwischen dem Zielwert p und dem Entwurftoken q, sodass die akzeptierten Tokens zusammen mit dem restlichen Resampling p genau rekonstruieren:

P(emit x) = q(x)·min(1, p(x)/q(x)) + P(reject)·p'(x)

Der akzeptierte Pfad trägt min(q,p) bei; das restliche Resampling füllt max(0, p−q) auf. Die Summe ergibt p. Daher ist die spekulative Dekodierung im Vergleich zur herkömmlichen Zielwert-Resampling-Methode verlustfrei – es handelt sich um eine Beschleunigung des Systems, nicht um eine Annäherung am Modell.

Q62. Erwartete Beschleunigung

Mit einer Akzeptanzrate von α und einer Entwurflänge von k beträgt die erwartete Anzahl der Tokens pro Zielwert-Forward-Schritt:

E[tokens] = (1 − α^(k+1)) / (1 − α)

Auch wenn jedes Entwurftoken fehlschlägt, erhält man dennoch eins Token aus dem Verifizierungsprozess des Zielwerts. Bei einem Entwurfskostenwert c im Verhältnis zu einem Zielwert-Schritt:

speedup ≈ E[tokens] / (1 + k·c)

Beispiel: α=0,8, k=4 → Erwartung von etwa 3,36 Tokens; bei c=0,05 → etwa 2,8×. Veröffentlichte Erfolge liegen meist im Bereich 2–3×. Bei großen Werten für k nehmen die Vorteile ab, da die Überlebenswahrscheinlichkeit als α^k abnimmt.

Q63. Wann Spekulation schadet

Niedrige Akzeptanz (schwierige Anfragen, Domainwechsel, schwache Entwürfe), zu hohe Kosten für die Erstellung von Entwürfen oder Kernel, die keine effiziente parallele Überprüfung ermöglichen. In solchen Fällen übersteigt die zusätzliche Belastung den Nutzen – Entscheidung anhand des gemessenen α.

Q64. KV-Cache bei Ablehnung

Cacheneinträge für abgelehnte Positionen (sowie die Entwürfe) werden zurückgesetzt. Implementierungen begrenzen die Länge der Checkpoints und kürzen sie ab; Fehler hier führen zu Störungen in zukünftigen Berechnungen. Akzeptierte Tokens behalten ihre K/V-Werte bei.

Q65. Moderne Varianten

Medusa / mehrköpfige Entwurfsverfahren, entwurfsbasierte Verarbeitung auf Feature-Ebene im Adlerstil, Prompt-Abfragen / N-Gramm-Entwürfe direkt aus dem Kontext sowie kaskadierte Entwurfsverfahren. Dasselbe Prinzip der Überprüfung mit dem Zielwert.

Q66. Baumartige Aufmerksamkeit

Die Entwürfe können einen Baum von Kandidaten vorschlagen, nicht nur eine lineare Kette. Die Baumartige Aufmerksamkeit überprüft mehrere Äste in einem einzigen Zielvorgang, wodurch die Anzahl der akzeptierten Ergebnisse pro Aufruf steigt, sofern das Verknüpfen von Ästen kostengünstig ist.

Teil 9 – Detokenisierer und Streaming

Q67. Die Detokenisierung ist keine einfache umgekehrte Karte

Detokenisierer müssen Raummarkierungen rückgängig machen, Byte-Fallbacks handhaben, mehrere Token zu Graphemen zusammenfassen und verhindern, dass unvollständige UTF-8-Daten ausgegeben werden. Bei der streambasierten Detokenisierung wird bis zum Erreichen eines vollständigen Zeichens oder Teils gewartet, bevor dieser sicher ausgesendet werden kann – andernfalls sehen die Clients Ersatzzeichen.

Q68. Wie das Streaming funktioniert und was gemessen werden sollte

Server geben Tokens (oder Teilstränge) ab, sobald sie erzeugt werden. Messen Sie TTFT, TPOT sowie die Zeit bis zum ersten lesbaren Zeichen nach dem Enttokenisieren im Puffer. Für die Benutzererfahrung des Clients ist diese letzte Zahl wichtiger als die Rohdaten der Token-Zeitstempel.

Q69. Stopps sequenzen sind schwierig

Stopps können Grenzen zwischen Tokens überschreiten (\n\n im Vergleich zu einem Token, das beide Zeilenumbrüche enthält). Sie müssen den decodierten Text (oder ein sorgfältig ausgewähltes Token-Fenster) überprüfen, nicht nur die Gleichheit der einzelnen IDs. Bei Überschneidungen mit teilweise generierten Stopps muss ein Rückschritt vorgenommen werden, damit der Stopptext nicht angezeigt wird.

Q70. Was beendet eine Generierung?

EOS / spezielle Stopp-IDs, abgegleiche Stoppstrecken, maximale Token-Limits, Kündigung seitens des Clients oder ein Server-Watchdog. Verwenden Sie lieber eine explizite EOS-Behandlung, die mit dem Chat-Template übereinstimmt.

Teil 10 – FlashAttention, Quantisierung, Roofline

Q71. FlashAttention – präzise Aussagen

FlashAttention berechnet die Aufmerksamkeit ohne dass die vollständige n × n-Score-Matrix in HBM materialisiert wird, wobei Tiling-Verfahren sowie online-berechnete Softmax-Statistiken genutzt werden. Dadurch wird der Speicherdurchsatz verringert und es werden längere Sequenzen bzw. größere Batch-Größen ermöglicht. Es ändert nicht das mathematische Ergebnis der Aufmerksamkeit (abgesehen von numerischen Faktoren); es handelt sich um einen auf I/O ausgerichteten Algorithmus, nicht um ein anderes Modell.

Q72. Hilft es beim Dekodieren?

Beim Dekodieren mit Cache wird oft mit einer q-Länge von 1 auf die in Cache gespeicherten n-Schlüssel reagiert – der klassische Vorteil von FlashAttention (enorme quadratische Scores) ist dadurch geringer. Varianten wie FlashDecoding helfen zwar weiterhin dabei, Bandbreitepfade für KV-Daten zu nutzen, doch das Dekodieren bleibt ohne große Batch-Größen von Lasten durch Gewichtsladungen dominiert.

Q73. Quantisierung

Speichern/verarbeiten Sie Gewichte (und manchmal Aktivierungen/KV) in kompakteren Formaten (FP8, INT8, INT4, …). Speicher und Bandbreite nehmen im Allgemeinen mit der Bitbreite ab; der Qualitätsverlust hängt von der Methode ab (GPTQ, AWQ, smooth quant, …). Eine Faustregel aus Praxiserfahrungen: 8-Bit ist oft nahezu kostenlos; 4-Bit kostet etwas mehr, manchmal liegt der Aufwand im Bereich des Rauschniveaus – messen Sie immer an Ihren eigenen Aufgaben.

Q74. Roofline in einem Absatz

Zeichnen Sie die erreichbaren FLOPs gegenüber der arithmetischen Intensität auf. Die Vorausbelegung liegt in Richtung des Rechen-Rooftops; die Dekodierung im Batch-1-Betrieb befindet sich nahe am Bandbreiten-Rooftop bei etwa 1 FLOP/Byte. Optimierungen, die die Intensität erhöhen (Batching, weniger Bits pro nützlichem FLOP), bringen Sie näher an die Kante des Rooftops; reine Kernel-Optimierungen können das bestehende Limit nicht überschreiten.

Q75. Aufteilen eines großen Modells auf mehrere GPUs

Tensor parallel teilt die Schichten in Teilmengen auf (erfordert schnelle Interkonnektierung). Pipeline parallel weist Bereiche der Schichten verschiedenen Prozessoren zu (Risiko von „Bubble-Effekten“). Expert parallel teilt die MoE-Experten auf. Replica / data parallel kopiert das Modell zur Steigerung der Durchsatzrate. In echten Implementierungen werden diese Ansätze kombiniert; KV-Daten müssen entweder partitioniert oder in Einklang mit der Aufbaustruktur der Attention-Mechanismen repliziert werden.

Teil 11 – Whiteboard-Zahlen

• 70B fp16-Gewichte: 70e9 × 2 ≈ 140 GB.
• Vorwärts-FLOPs: ~2 × Parameter · Tokens (Ordnungskraft).
• KV-Daten pro Token (Llama-3-70B-class GQA): ~Zwei · Schichten · kv_heads · head_dim · dtype_bytes – etwa ein Drittel eines Megabytes pro Token.

Batch-1 Dekodierungsrate in Tok/S: ~Bandbreite / weight_bytes (Klasse H100: Dutzende von Tok/S im fp16-Modus, bevor andere Modelle vorn liegen).

Embedding + ungebundener LM-Head bei V=128K, d=4096: jeweils etwa 524 M Parameter.

Parameter von Attention vs FFN: in einem Standardblock etwa im Verhältnis 1:2 (4d² gegenüber etwa 8d²).

Teil 12 – Einschränkungen der Diagramme

Häufige Lehrdiagramme lassen aus: Chat-Vorlagen vor der Tokenisierung, die Auswirkung von GQA/MQA auf die Breite des KV-Speichers, Details zur Abfolge der Stichprobenziehung, das Puffern beim Dekodieren, paginierten KV-Speicher sowie spekulative Überprüfungsschleifen. Betrachten Sie Diagramme als Karten, nicht als Verträge.

Fazit

Inferenz ist ein Prozess von Bytes zu fließendem Text, bei dem prefill durch Rechenleistung begrenzt und decode durch Bandbreite begrenzt ist, der KV-Cache den Großteil des Speichers bei Mehrbenutzeranwendungen einnimmt, und jede bedeutende Optimierung – GQA, Paging, kontinuierliches Batching, Quantisierung, FlashAttention, Spekulation – dazu dient, die Arbeit in Richtung der optimalen Eigenschaften des Hardwares zu lenken, ohne das mathematische Modell stärker zu verändern, als beabsichtigt.

Einsatzbeispiel A – Praktische Vergleiche zwischen Prefill und Decode hinsichtlich der Kosten

Wenn Sie eine Flotte dimensionieren, beginnen Sie mit der Aufteilung nach der Dachlinie. Vorausgefüllte Aufgaben nutzen gerne Tensor-Kerne: Lange Anfragen bei Code-Assist oder RAG-Dumps können eine hohe MFU-Zahl zeigen, sofern die Kerne leistungsfähig sind. Die Dekodier-Aufgaben in Batch 1 ähneln zufälligen Speichermessungen – dieselben 70B-Modelle verarbeiten Daten über HBM für eine einzige GEMV-Berechnung. Deshalb wirkt ein Produkt, das 500-Token lange Antworten liefert, selbst auf Top-GPUs langsam, es sei denn, man verwendet Batching, Quantisierung oder spekulative Methoden.

TTFT-Regressionen bedeuten in der Regel, dass die Anfragen (Historie, RAG, Tool-Schemata) ohne Präfix-Caching gewachsen sind. TPOT-Regressionen deuten meist darauf hin, dass das Batching zusammengebrochen ist, die Bandbreite gesunken ist oder der KV-Druck zu kleinen Batches geführt hat. Die End-to-End-Latenz hängt nicht von einem einzigen Faktor ab: Kürzere Antworten verkürzen die TPOT-Zeiten um den Faktor N; das Caching von Systemanfragen hilft bei TTFT; spekulative Dekodierung verbessert die TPOT-Zeiten, wenn die Akzeptanz hoch ist.

Die auf den Dashboards angezeigten Durchsatzmetriken lassen sich leicht manipulieren, indem große Datensätze verwendet werden, was die Interaktion für die Benutzer erschwert. Veröffentlichen Sie daher sowohl die Anzahl der Tokens pro Sekunde pro GPU als auch den p50/p95 TPOT unter einer realistischen Mischung. Kontinuierliches Batching versorgt die GPU stetig, ohne die Belastung durch statische Datensätze; in Blöcken vorbereitete Daten verhindern, dass ein einzelner 32K-Aufruf die Dekodierung aller anderen blockiert.

Eine getrennte Vorbereitung und Dekodierung ist ein architektonisches Eingeständnis, dass diese beiden Arbeitslasten unterschiedliche Rechner erfordern. Vorbereitungs-Knoten können eine höhere Rechenleistung aufweisen; Dekodier-Knoten benötigen hingegen Speicherkapazität und Bandbreite für KV-Daten. Das Netzwerk muss die KV-Daten effizient übertragen, sonst geht der Vorteil verloren. Nicht jedes Team sollte das von Anfang an umsetzen – aber jedes Team sollte wissen, warum dieses Muster existiert.

Erfundenes Wissen B – Tokenisierer und mehrsprachige Kosten

Die Universalität von BPEs auf Byte-Ebene ist sowohl ein Vorteil als auch eine Herausforderung. Englisch-fokussierte Chat-Apps schätzen die Kosten für Hindi, Thailändisch oder sozialen Text mit vielen Emojis falsch ein. Wenn Ihr Gewinnmodell von englischen Tokens pro Sekunde ausgeht, kann eine Mehrsprachenerweiterung heimlich das Budget aufbrauchen. Wählen Sie bei wichtigen Nutzerströmen Tokenisierer mit umfassenderem Mehrsprachensupport; messen Sie die Anzahl der Tokens pro Grapheme-Cluster an echten Korpora und nicht am Lorem Ipsum.

Chat-Vorlagen sind Teil der Identität des Modells. Ein einziger fehlender spezieller End-Token kann zu unvollständigen Generierungen oder Abbrüchen führen. Speichern Sie die Version der Vorlage zusammen mit der Modellrevision in Ihrem Registry-System. Wenn das Problem „Das Modell ignoriert den Systemprompt“ auftritt, tokenisieren Sie beide Seiten und vergleichen Sie die IDs, bevor Sie die Gewichte dafür verantwortlich machen.

Digitenrichtlinien sind für Tabellenkalkulations-Assistenten und Mathematiklehrer von Bedeutung. Wenn 1000 und 1.000 unterschiedlich behandelt werden, verwandeln sich Spaltenalgorithmen in Glücksscheine. Verwenden Sie bei der Erstellung von Rechengeräten auf Basis von LLMs lieber Tokenisierer mit expliziten Regeln für Ziffern oder leiten Sie die Arithmetik an andere Tools weiter.

Einsatz von C – Aufmerksamkeit, GQA und Speicher

Die Geschichte der Multi-Head Attention ist die Spezialisierung innerhalb eines Budgets. Bei GQA geht es um KV-Bytes. Der Wechsel von MHA zu GQA kann die Größe des Caches um etwa das Verhältnis der Abfrageschädel zu den KV-Gruppen verringern – oft um das 4–8-fache – bei nur geringem Qualitätsverlust, sofern dafür trainiert wird. MQA ist das Extremfall; MLA sowie verwandte Kompressionsverfahren bekämpfen denselben Engpass mit unterschiedlicher Algebra.

Kausales Maskieren mit negativer Unendlichkeit ist keine Pedanterie: Jeder endliche Maskenwert führt zu Leckagen. Trainingsfehler, die versehentlich zukünftige Aufmerksamkeitsmechanismen ermöglichen, erzeugen Modelle, die bei von Lehrdaten vorgegebenen Metriken stark erscheinen, aber bei echtem autoregressivem Einsatz versagen. Kernel zur Dekodierzeit, die von einer bestimmten Cache-Struktur ausgehen, müssen der Trainingsgeometrie entsprechen (Anzahl der Heads, RoPE-Basis, Skalierung).

Residuen und Vornormalisierung sind der Grund, warum 80–100 Schichtstapel üblich sind. Wenn eine benutzerdefinierte Architektur sie „zur Vereinfachung“ entfernt, ist mit Trainingsinstabilität zu rechnen, bevor irgendeine Cleverness entsteht. Die Steuerung von SwiGLU ist ein Qualitätsfaktor mit Auswirkungen auf den Speicherverbrauch – man muss wissen, ob der eigene Stack diese Funktion nutzt.

Erfundenes Wissen D – KV-Paginierung und Präfixstrategie

PagedAttention betrachtet KV als einen Haufen Blöcke. Folgen davon:

• Agentenframeworks mit großen gemeinsamen Systemanweisungen sollten dieses Präfix kanonisieren, damit die Block-Hashes kollidieren.

Few-shot-Bibliotheken sollten die Beispiele in einer stabilen Reihenfolge halten; das Umordnen führt zu vermehrten Fehlern beim Zugriff auf den Cache.

Personalisierungsfelder sollten nach dem gemeinsamen Stamm stehen.

Debug-Tools sollten die Trefferquoten der Blocktabelle genauso anzeigen wie CDN-Dienste die Cache-Trefferraten.

Die Invalidation des Präfix-Caches ist ein Korrektheitsproblem, nicht nur eines der Leistung. Wenn sich das Schema einer Tool-Struktur ändert, aber die Cache-Schlüssel dies ignorieren, verwendet das Modell veraltete KV-Einträge für neue Anweisungen – das sind subtile, aber problematische Fehler. Erfassen Sie in den Schlüssel die Tokenisierer-ID, das Template-Hash, die LoRA-ID sowie den RoPE-Scale-Wert.

Bei Speicherdruck ist eine Eviction-Strategie erforderlich: LRU für inaktive Gespräche, feste Obergrenzen für den Kontextinhalt oder Komprimierung durch Zusammenfassung. Was auch immer Sie wählen, machen Sie es dem Produkt zugänglich – stille Trunkierung ist ein Vertrauensproblem.

Einsatz von Softmax, Sampling und Determinismus im Detail

Stabile Softmax-Verarbeitung ist in fp16/bf16-Pfaden zwingend erforderlich. Verschmolzene Kerne verbergen den Max-Subtract-Schritt, doch eigener Forschungskodier kann weiterhin zu Überlaufproblemen führen. Die Perplexität bleibt ein nützliches Indikator, wenn man Kerne oder Quantisierungsverfahren ändert: Anstiege deuten darauf hin, dass sich die Verteilung verändert hat.

Die Abfolge der Stichprobenentnahme sollte unit-getestet werden: zunächst Temperaturanpassung, anschließend Trunkierung, danach Strafmaßnahmen und schließlich die Ziehung der Stichproben. Wechseln Sie die Reihenfolge in einem Testfall und beobachten Sie, wie sich die Referenzdaten unterscheiden. Die eingeschränkte Dekodierung für JSON sollte belastungstestet werden; die Erstellung von Masken kann bei naiver Implementierung CPU-beschwert sein.

Temperatur null bedeutet deterministische Ausgabe – das ist eine Marketingaussage, keine mathematische Garantie auf echten GPUs. Wenn Sie auditfähige Wiederholbarkeit benötigen, speichern Sie die generierten IDs (oder RNG-Samen sowie die für Batch 1 gesperrten Kerne). Für die meisten Anwendungen reicht die Wiederholbarkeit innerhalb einer Version aus – dokumentieren Sie das entsprechend.

Einsatz von F – Spekulative Dekodierungsoperationen

Verlustfreie Spekulation ist mächtig, weil Produktbesitzer eine Qualitätsverschlechterung fürchten. Dennoch müssen die Betriebsabteilungen die Akzeptanzrate nach Prompt-Klassen überwachen. Die Code-Vervollständigung wird oft gut akzeptiert; kreative, offene Chats hingegen möglicherweise nicht. Eine an die jüngste Akzeptanz angepasste Entwurfslänge ist besser als eine statische Schätzung.

Baumspezulation hilft, wenn der Entwurf kostengünstig Alternativen vorschlagen kann. Korrektheitsprüfungen für KV-Rollbacks sollten in der CI enthalten sein: Sie sollen gezielt während des Laufs abgelehnt werden und sicherstellen, dass die anschließenden Aufmerksamkeitswerte mit einer nicht-spekulativen Basis übereinstimmen.

Entwurfsmodelle müssen den Tokenisator (oder eine kompatible Zuordnung) mit dem Zielmodell teilen. Nicht übereinstimmende Tokenisatoren erzeugen stille „Mülldaten“, die so aussehen, als hätte die Spekulation das Modell dümmer gemacht.

Einsatz von G – Streaming-UX und Stopps

Die Benutzer wahrnehmen die Flüssigkeit durch enttokenisierte Zeichen und nicht durch rohe IDs. Puffern Sie, bis Unicode gültig ist; leeren Sie bei Möglichkeit den Puffer bei Leerzeichen für eine bessere Chat-Nutzerschnittstelle. Überlappende Stopps Sequenzen erfordern sorgfältiges Rückgängigmachen, damit der Client den Stopptext niemals sieht. Maximaler Token-Limit sollte bei Möglichkeit ein klares Fortsetzungszeichen hinzufügen, sofern das Produkt eine Fortsetzung zulässt.

Einsatz von FlashAttention und Quantisierung

FlashAttention ermöglicht längere Vorausfüllungen und dichtere Batch-Größen, indem es HBM spart. Betonen Sie dies, behaupten Sie aber nicht, dass dadurch die Dekodierphysik neu geschrieben wird. Quantisierung ist das Hebelwerk beim Dekodieren: Weniger Bytes pro Gewichtsladung erhöhen die effektive Anzahl der Tokens pro Sekunde. Überprüfen Sie dies in Ihrem Evaluations-Set – insbesondere bei Toolaufrufen und der Wiedergabe langen Kontexts – bevor Sie behaupten, 4-Bit-Quantisierung sei verfügbar.

Die Betrachtung der Dachlinie sorgt dafür, dass Argumente ehrlich bleiben: Wenn man durch Bandbreitenbeschränkungen eingeschränkt ist, führt der Kauf mehrerer TFLOPS ohne erhöhte Bandbreite (oder weniger Bytes) zu Enttäuschungen. Wenn die Rechenleistung bei der Vorausbefüllung das Problem ist, sind bessere GEMM-Verfahren sowie eine effektivere Blöckplanung wichtiger als das Reduzieren der KV-Datenmenge.

Einsatz im Detail I – Realitäten mehrerer GPUs

Für die Tensor-Parallelisierung ist eine schnelle Interkonnektivität erforderlich, sonst kommt es bei allen Reduzierungsoperationen zum Stillstand. Bei der Pipeline-Parallelisierung sind Mikrobatchs nötig, um Verzögerungen zu verbergen. Die Kombination dieser Ansätze mit kontinuierlichem Batchen sowie paginierten KV-Daten erklärt, warum Inferenz-Engine große Codebasen sind. Wenn jemand vorschlägt, das Modell einfach in Teile aufzuteilen, sollte man fragen, welche Dimension dabei berücksichtigt wird und was mit der KV-Anordnung geschieht.

Einsatz im Detail J – Aufbau der Pipeline

Ein Anfragenpfad, den man sich merken sollte:

1. Template erstellen sowie Tokenisierung auf der CPU durchführen
2. Embedding und Vorausbefüllung mit kausaler Aufmerksamkeit durchführen, KV-Daten schreiben (GPU, rechenleistungsbedingt)

LM-Head an der letzten Position, anschließend Sampling (GPU mit CPU-Strategie)

Dekodierungszyklus mit Cache, kontinuierliches Batching, optionale Spekulation (GPU, bandbreitenbegrenzt)

Detokenisierung, Stoppschwellenprüfungen, Streaming auf der CPU

Befreien oder Pools von KV-Blöcken im Alloker

Jede Optimierung entspricht einem Pfeil in dieser Liste. Wenn Sie nicht auf den Pfeil verweisen können, überlegen Sie noch nicht über die Inferenz nach – Sie sammeln lediglich Slogans.

Zusätzliche FAQ-artige Erläuterungen

Führt eine Erhöhung der Temperaturen zu einer messbaren Steigerung der Kreativität? Sie erhöht die Entropie der Verteilung des nächsten Tokens. Ob Menschen das Ergebnis als kreativ bezeichnen, hängt von der Aufgabe ab; messen Sie mit Metriken für Vielfalt und Qualität, nicht nur nach „Vibes“.

Ist Gier jemals richtig? Ja – Klassifizierung als Generierung, strukturierte Extraktion mit eingeschränkter Dekodierung sowie einige Bewertungstools. Bei offenen Dialogen ist das in der Regel nicht der Fall.

Kann man den KV-Cache löschen und neu berechnen? Immer – allerdings mit quadratischem Kostenaufwand. Edge-Geräte verwenden manchmal kurze Zeitfenster ohne Cache; Server sollten das fast nie tun.

Warum zeigen Diagramme Softmax innerhalb der Attention-Mechanismen und erneut am LM-Head? Es handelt sich um unterschiedliche Softmax-Funktionen: Eine mischt Werte innerhalb einer Schicht; die andere wandelt Vokabular-Logits in eine kategoriale Verteilung für das Sampling um. Derselbe Funktionskreis, unterschiedliche Aufgaben.

Was sollte ein neuer Ingenieur zuerst auswendig lernen? Die Unterschiede zwischen Prefill- und Dekodierungsengpässen, die Formel für die KV-Bytes pro Token, TTFT gegenüber TPOT sowie dass Batching Latenz gegen Durchsatz eintauscht. Alles Weitere hängt von diesen vier Konzepten ab.

Erweiterte Erklärung – Prefill-Kerne und TTFT-Hebel

Die Qualität der Vorausbefüllung hängt vor allem davon ab, wie schnell man eine Anfrage in einen vorgefertigten KV-Cache umwandeln kann. Attention-Kerne, verschmolzene MLP-Pfade sowie die Art und Weise, wie die Anfrage in Teile aufgeteilt wird, bestimmen die Form der TTFT-Kurve. Wenn Anfragen einen gemeinsamen langen Teil haben, verwandelt das Präfix-Caching die wiederholten Kosten der Vorausbefüllung in eine schnelle Abfrage; bei unterschiedlichen Anfragen muss jede neue Sitzung den vollen Preis zahlen.

Die in Teile aufgeteilte Vorausbefüllung dient sowohl der Fairness als auch der Reduzierung der Latenz. Ohne sie kann die Verarbeitung von 40.000 Token die Dekodierung für alle anderen auf der GPU blockieren. Mit ihr können interaktive Ströme weiterlaufen, während die langwierige Aufgabe in Schritten abgewickelt wird. Der Trade-off besteht darin, dass die TTFT-Zeit für die lange Aufgabe selbst etwas höher ausfällt – was in der Regel akzeptabel ist.

Die Platzierung des Präfixes ist eine produktbezogene Entscheidung. Platziere volatilen Benutzertext nach dem festgelegten Stamm, damit die Cache-Schlüssel stabil bleiben. Wenn das Marketing den Systemprompt täglich überschreibt, betrachte dies als Cache-Bust-Ereignis und erwarte, dass TTFT ansteigt, bis der neue Stamm wieder aktiv wird.

Erweiterte Anleitung – Bandbreitenrechnungen in Worten erklären

Stell dir vor, du liest den gesamten Gewichtsatz aus HBM einmal pro generiertem Token bei einer Batch-Größe von eins. Die Rechenintensität sinkt auf etwa eine nützliche Multiplizieren-Akkumulieren-Operation pro übertragenem Byte. Hardware, die bei dichten GEMM-Aufgaben hervorragt, wirkt untätig, weil sie auf die Speicherkontroller wartet. Durch Batching wird jede Gewichtsladung in mehreren Sequenzen wiederverwendet; Quantisierung verringert die Last selbst; spekulative Überprüfungen verwandeln mehrere serielle Schritte in eine parallele Prüfung. Das sind verschiedene Wege, denselben Zweck zu erreichen.

Wenn jemand behauptet, ein Kernel sei beim Dekodieren „2× schneller“, fragen Sie, unter welchem Dach er sich befunden hat. Wenn die Leistung durch Bandbreitenbeschränkungen eingeschränkt ist, kann eine reine ALU-Optimierung keine Verdopplung der Geschwindigkeit erzielen. Falls außerdem die übertragenen Bytes reduziert werden, glauben Sie ihnen erst nach einem Screenshot des Profilers.

Erweiterte Anleitung – Bereitstellungsrichtlinien und SLOs

Schreiben Sie SLOs getrennt für TTFT und TPOT. Eine Version, die die Durchsatzrate verbessert, während sich der p95-Wert für TPOT verdoppelt, stellt eine Rückschritt für die Benutzererfahrung im Chat dar – auch wenn das Kapazitätsdashboard dies positiv wertet. Kontinuierliche Batching-Parameter (maximale Anzahl an Tokens pro Batch, maximale Warteschlange, Priorität zwischen Dekodierung und Vorausfüllung von Datenblöcken) sind die praktischen Einstellmöglichkeiten hinter diesen SLOs.

Die Zulassungskontrolle gehört neben der KV-Verwaltung: Ablehnen oder in die Warteschlange setzen Sie neue Sitzungen, wenn der prognostizierte Cache-Speicherwert einen bestimmten Schwellenwert überschreitet. Andernfalls erscheinen OOM-Ausfälle den Clients als zufällige Fehler des Modells.

Erweiterte Anleitung – Überprülliste für Tokenisierungsoperationen

Vor der Veröffentlichung eines Modells:

1. Frieren Sie die Tokenisierungsdateien sowie den Chat-Vorlagen-Text im selben Artifact-Store wie die Gewichte ein.
2. Führen Sie eine Gold-Testung mit einigen mehrsprachigen Zeichenfolgen und Emojis durch, um unerwartete Token-Längen zu überprüfen.
3. Führen Sie bei Produkten, die Mathematik berechnen, eine Gold-Testung mit zeichenzahlreichen Zeichenfolgen durch.
4. Stellen Sie sicher, dass die IDs der Stop-Token mit den Endmarkern der Vorlage übereinstimmen.
5. Stellen Sie sicher, dass die logprob-Tools denselben Tokenisierer wie bei der Inferenz verwenden.

Überspringen Sie einen dieser Schritte, und Sie werden an einer „Modellqualität“ feilen, die in Wirklichkeit auf eine Abweichung im Packaging beruht.

Erweiterte Anleitung – Attention-Varianten als Zeitlinie

Frühe Large Language Models nutzten vollständige MHA-Strukturen und bezahlten dies durch den Einsatz von Cache. Der Produktionsdruck führte zur Einführung von MQA und anschließend GQA als Kompromiss, den die meisten Grenzkontrollpunkte übernahmen. MLA sowie verwandte Konzepte mit niedrigem Rang für KV-Strukturen setzen diese Entwicklung fort: Man bewahrt die Reichweite der Abfragen, während die Menge an gespeicherten Daten pro Token reduziert wird. Beim Lesen wissenschaftlicher Arbeiten sollten Aussagen in „Bytes pro KV-Token“ sowie „Qualitätsunterschied in unseren Bewertungen“ umgerechnet werden – Marketingbegriffe wie „effiziente Aufmerksamkeit“ sind ansonsten bedeutungslos.

Erweiterte Erläuterung – Paginierte KV-Strukturen und Mehrbenutzerverhalten

Die Mathematik der Fragmentierung ist bei kontinuierlichen Reservierungen besonders schwierig. Durch Paginieren wird dies in ein Problem des Zuweisers mit festen Blöcken umgewandelt. Mehrbenutzer-Cluster sollten Zuweisungsfehler verfolgen, Latenz aus Blocktabellen übernehmen sowie die Trefferquote prüfen. Ein plötzlicher Rückgang der Trefferquote deutet oft auf eine Änderung im Template-Format oder einen stillen Anstieg der Tokenisierungsparameter hin.

Der Copy-on-Write-Share zwischen Strahlen und parallelen Beispielen ist für decodierende Verfahren im Stil von Suchalgorithmen nicht optional; ohne ihn verdoppelt sich der Speicherverbrauch unnötig mit der Breite des Strahls.

Erweiterte Anleitung – Sampling für Produkte

Standardeinstellungen für den Versand, die zur Aufgabe passen:

• Extraktion/Tool-Parameter: niedrige Temperatur, eingeschränkte Dekodierung, gieriger oder kleiner Kern.
• Support-Chat: mittlere Temperatur, Kern in der typischen 0,9-Bandbreite, geringe Strafe bei Wiederholungen, falls Schleifen auftreten.
• Kreative Brainstorming: höhere Temperatur, Berücksichtigung von min-p, stärkere Warnungen für den Benutzer bezüglich der Varianz.

Protokollieren Sie das Sampling-Tupel zusammen mit jeder Antwort für Support-Anfragen. Ohne dieses ist „Das Modell sagte gestern X“ nicht beantwortbar.

Erweiterte Anleitung – Einführung der spekulativen Dekodierung

Führen Sie den Einsatz hinter einer Flagge durch. Messen Sie die Akzeptanz am Endpunkt. Deaktivieren Sie den Prozess, wenn α unter einen Break-Even-Wert fällt, der aus Ihrem Entwurfskostenwert c und der Entwurfslänge k abgeleitet wird. Behalten Sie stets einen nicht-spekulativen Kanarienvogel-Traffic-Anteil bei – er dient als zuverlässige Qualitätsreferenz.

Sichern Sie dafür, dass abgelehnte Pfade KV-Daten entfernen. Fügen Sie einen Chaos-Test hinzu, der unter Last mittels Sequenzabbrüche erzwingt wird.

Erweiterte Anleitung – Details zum Streaming-Protokoll

Entscheiden Sie, ob das Übertragungsformat Tokens, enttokenisierte Zeichenketten oder beides streamt. Clients, die unterschiedlich re-tokenisieren, werden sich in Bezug auf die Grenzen nicht einigen. Verwenden Sie lieber eine serverseitige Enttokenisierung mit expliziten „Flush“-Ereignissen, sobald ein vollständiger Graphem-Cluster bereit ist. Dokumentieren Sie, wie Stopps Sequenzen entfernt werden, damit der UI-Code sie nicht doppelt verarbeitet.

Erweiterte Anleitung – Akzeptanztests für Quantisierung

Vor der Aktivierung von 4-Bit-Gewichten in der Produktion:

• Führen Sie den Standard-eval-Testkatalog aus.
• Führen Sie die Tool-Aufruf-Fixtures aus.
• Führen Sie Langkontext-Needle-Tests durch.
• Vergleichen Sie bei Bedarf die Ablehnungs-/Sicherheitstests.
• Vergleichen Sie p95 TPOT und VRAM-Werte.

Falls die Qualität innerhalb des vereinbarten Epsilons liegt und die Latenzvorteile real sind, veröffentlichen Sie das Produkt. Andernfalls bleiben Sie bei 8 Bit für dieses Modell.

Erweiterte Anleitung – Schritt-für-Schritt-Lösungen in Prosa

Der Speicherbedarf für einen Checkpoint mit siebzig Milliarden fp16-Parametern beträgt allein für die Gewichte etwa hundertvierzig Gigabyte. Ein Vorwärtslauf kostet im Bereich von zwei FLOPs pro Parameter pro Token. Das Wachstum der KV-Strukturen ist linear zu den aktiven Tokens sowie zur Anzahl der tatsächlich gespeicherten Schlüssel/Wert-Blöcke. Die Dekodiergeschwindigkeit bei Batch-Eins hängt von der Speicherkapazität geteilt durch die Anzahl der pro Schritt verarbeiteten Bytes ab. Embedding-Tabellen sowie ungebundene LM-Blöcke können bei großen Wörterbüchern jeweils Hunderte Millionen von Parametern verbrauchen – es handelt sich dabei nicht um Rundungsfehler. Innerhalb eines Blocks enthalten die Feed-Forward-Pfade in der Regel etwa doppelt so viele Projektionsparameter wie die Attention-Mechanismen.

Erweiterte Erklärung – Wie man Diagramme verständlich macht

Wenn Sie den Ablauf für Anfänger zeichnen, sollten Sie die weggelassenen Komponenten annotieren: Vorlagen, Pagen, kontinuierliches Batchen, Spekulation sowie Buffers zur Enttokenisierung. Andernfalls implementieren Ingenieure das Diagramm und sind im Produktivbetrieb überrascht.

Zusätzlicher Abschluss – Wie „Fertigstellung“ für den Inferenzbetreiber aussieht

Man kann ohne Präsentationsfolien erklären, warum ein bestimmtes Problem TTFT im Vergleich zu TPOT beeinträchtigt hat. Man kann die KV-Memory-Bestimmung für ein vorgeschlagenes Konkurrenz- und Kontextziel abschätzen. Man kann angeben, welches Mittel – Batch, Quantisierung, GQA, Spekulation, Präfix-Cache – auf das Symptom zutrifft. Tokenisatoren und Templates werden als versionierte Abhängigkeiten behandelt. Das ist die betriebliche Kompetenz für LLM-Inferenzen; alles Weitere sind Details, die man nachschlagen kann.

Narrativ zu einem Fallstudienbeispiel – Ein interaktiver 70B-Dienst

Nehmen wir an, man stellt ein 70B-fp16-Chatmodell auf einem Paar hochspeicherfähiger GPUs zur Verfügung. Allein die Gewichte beanspruchen etwa hundertvierzig Gigabyte, sodass das Paar bereits vor Beginn jeder Konversation fast voll ist. Der verbleibende Speicher muss für KV-Daten aller aktiven Sitzungen, Aktivierungen sowie für Fragmentierung des Allocators ausreichen.

Sie legen ein Produktziel fest: sechzehn gleichzeitige Benutzer, Kontexte mit viertausend Token sowie streambasierte Antworten. Eine grobe Berechnung ergibt mehrere hundert Kilobyte pro Token; sechzehn mal viertausend multipliziert mit diesem Wert ergeben Dutzende von Gigabytes – das ist zu viel für den verbleibenden Speicher. Sofort tauchen Optionen auf: Auf einen GQA-Checkpoint umsteigen, den Cache quantisieren, die Konkurrenz reduzieren, den Kontext verkürzen oder GPUs hinzufügen. Genau diese arithmetischen Überlegungen machen den Unterschied zwischen der vagen Frage „Wir brauchen mehr GPUs“ und einem präzisen Kapazitätsplan aus.

Außerdem bemerken Sie Spitzenwerte bei TTFT zu Beginn jeder Stunde, wenn viele Clients mit identischen Systemanfragen wieder verbunden werden. Das Präfixcaching beseitigt diese Spitzen, sobald der Stamm festgelegt ist. Wenn nach einer Anpassung der Anfrage der Stamm nicht festgelegt wird, erscheint das in der Metriken-Anzeige wie eine Regression des Modells.

Kasustudienbeschreibung – Agentenschleifen und Cache-Schlüssel

Ein Agent sendet in jeder Runde dasselbe Tool-Schema. Wenn das Schema-JSON mit instabiler Schlüsselreihenfolge serialisiert wird, fehlen die Präfix-Hashes und es müssen täglich Tausende von Tokens nachgefüllt werden. Eine kanonische JSON-Kodierung wird somit zu einer Optimierung für die Inferenz. Ebenso verhindert das Einfügen des Benutzerprofils vor dem Schema den Austausch zwischen Nutzern; das Einfügen danach bewahrt den gemeinsamen Tool-Stamm.

Kasusstudie – Spekulative Dekodierung bei Code versus Chat

An einem Endpunkt für Code-Vervollständigung akzeptiert ein kleines Entwurfsmodell, das mit ähnlichen Daten trainiert wurde, die meisten Tokens; die End-zu-End-Latenz sinkt um etwa das Zweifache. An einem offenen kreativen Endpunkt bricht die Akzeptanz ein und dasselbe Entwurfsmodell verschwendet Kapazität. Feature-Flags pro Route sind effektiver als ein globales Spekulationsschalter.

Kasusstudie – Fehler in Stoppszenarien

Ein Team setzt einen Stop-Punkt für eine Markdown-Grenze fest. Die Hälfte der Zeit besteht die Grenze aus einem Token; die andere Hälfte ist geteilt. Die Benutzer sehen anschließend nachfolgende Backticks. Die Lösung überprüft die decodierten Textfenster und rollt den Stop-Punkt zurück. Stopps, die nur aus der Token-ID bestanden, waren der ursprüngliche Fehler.

Kasusstudie – Die Überraschung durch Quantisierung

Vierbitige Gewichte verbesserten die Leistung pro Token um etwa 40% auf einem durch Speichermangel eingeschränkten Decodeweg. Die Auswertungen durch Tool-Aufrufe sanken um drei Punkte. Der Kompromiss: 8-Bit für Tool-Routen, 4-Bit für ausführlichere Blog-Entwürfe. Ein Modellartefakt, zwei Bereitstellungsprofile – ermöglicht durch die Routing-Logik am Gateway.

Praktische Checkliste – Bereitschaft für den Start

• [ ] Die Roofline-Geschichte ist für Vorausfüllung und Decodierung dokumentiert
• [ ] KV-Bytes pro Token wurden am tatsächlichen Checkpoint gemessen
• [ ] Konkurrenzfähigkeit × Kontextbudget passen mit Puffer zu der GPU-Speicherkapazität
• [ ] Kontinuierliches Batching ist mit einer Decodierungs-Prioritätsrichtlinie aktiviert

[ ] Die Präfix-Cache-Schlüssel beinhalten Template, Tokenisierer, LoRA und RoPE-Skala

[ ] Die Sampling-Tupel werden pro Antwort protokolliert

[ ] Beschränkte Dekodierung für jedes JSON-Vertragsmuster

[ ] Stream-basierte Enttokenisierung unvollständiger UTF-8-Daten

[ ] Stoppszenarien werden über Token-Grenzen hinweg getestet

[ ] Spekulative Dekodierung wird je nach gemessener Akzeptanz aktiviert

[ ] Quantisierung wird anhand von task-spezifischen Bewertungen überprüft

[ ] Der parallele Plan für Tensor/Pipeline entspricht der tatsächlichen Vernetzung

Praktische Checkliste – Incident-Triage

1. Ist TTFT oder TPOT defekt?
2. Hat sich die Länge des Prompts oder die Zusammensetzung der Batch-Gruppe geändert?
3. Ist das KV-Gedächtnis nahe am Limit?
4. Haben sich die Versionen des Tokenisierers/Templates geändert?
5. Hat sich ein Kernel-/Quantisierungs-Flag geändert?
6. Wird die spekulative Dekodierung nur unzureichend akzeptiert?
7. Sind wir aufgrund von Bandbreiten- oder Rechenbeschränkungen eingeschränkt?

Arbeiten Sie die Liste in der Reihenfolge ab; die meisten Seiten mit dem Text „Das Modell ist heute dumm“ lassen sich bis zum vierten Schritt lösen.

Glossar an einem Ort

TTFT – Zeit bis zum ersten ausgesendeten Token nach Beginn der Anfrage. TPOT / ITL – Durchschnittliche Zeit zwischen aufeinanderfolgenden Tokens. Prefill – Parallelverarbeitung der Anfrage zur Befüllung von KV. Decode – Autoregressive Schritte, die neue Tokens erzeugen. KV Cache – Gespeicherte Schlüssel/Werte für frühere Tokens. GQA – Gruppierter Abfrachtabgleich zur Reduzierung der KV-Köpfe. PagedAttention – Blöcken basierende Zuweisung von KV. Nucleus (top-p) – Anpassungsweise Abschneidung des Wahrscheinlichkeitschwanzes. Speculative decoding – Beschleunigung durch Vorerstellung und anschließende Überprüfung. Roofline – Modell, das Intensität in Beziehung zu Spitzenwerten von FLOPs und Bandbreite setzt.

Endgültiger Zusammenfassungspunkt

Betrachten Sie die Inferenz als eine Fertigungslinie. Tokenisierer definieren die Behälter für die Komponenten. Embeddings und Blöcke sind die Maschinen. Der KV-Cache ist der Warenbestand in Bearbeitung, der je nach offenem Auftrag Lagerplatz verbraucht. Sampling ist die Qualitätskontrolle für jede Einheit. Streaming ist der Ladehof. Spekulative Dekodierung ist eine parallele Inspektionsstrecke. Wenn Sie eine Station optimieren, ohne auf den Lagerbestand und die Bandbreite zu achten, entstehen Haufen unvollendeter Arbeit und wütende Kunden – obwohl jede Station für sich „schneller“ erscheint.

Anhang – Vergleich der mentalen Modelle, die Sie in Interviews hören werden

Interviewer fragen oft darum, drei Slogans miteinander in Einklang zu bringen: „Transformer arbeiten parallel“, „Die Dekodierung ist sequenziell“ und „Die Aufmerksamkeit ist quadratisch“. Sie sind alle in unterschiedlichen Kontexten wahr. Training und Vorausfüllen nutzen die Parallelität zwischen bereits vorhandenen Positionen. Die Dekodierung kann ohne Spekulation keine zukünftigen Token im Voraus erzeugen. Der quadratische Term der Aufmerksamkeit spielt besonders dann eine große Rolle, wenn die Sequenzlänge im Verhältnis zu den durch die Breite gesteuerten Matmul-Operationen groß ist. Eine gute Antwort nennt zunächst den Kontext, bevor sie den Slogan darlegt.

Eine weitere häufige Falle besteht darin, die Anzahl der Parameter mit der Dekodiergeschwindigkeit gleichzusetzen. Die Parameter bestimmen die Anzahl der pro Schritt bewegten Bytes; Layout (GQA), Datentyp und Batching bestimmen hingegen, wie diese Bytes in Tok/s umgerechnet werden. Zwei 70B-Modelle können aufgrund dieser Faktoren in der interaktiven Latenz um das Zweifache voneinander abweichen.

Eine weitere Falle besteht darin, Sampling als „nur RNG“ zu betrachten. Temperatur, Trunkierung, Strafen und Einschränkungen verändern jeweils die kategoriale Verteilung; RNG wählt lediglich aus dem Verbleibenden aus. Das Beheben seltsamer Ausgaben beginnt mit der Protokollierung dieser Tupel.

Anhang – Minimale Gleichungen, die man sich merken sollte

KV-Bytes ≈ 2 × Schichten × kv_heads × head_dim × Bytes × seq_len × Batch. Intensität bei der Dekodierung von Batch 1 ≈ 2 × Parameter / weight_bytes ≈ O(1) FLOP/Byte für dichte fp16-Daten. Erwartete spekulative Token pro Überprüfung ≈ (1 − α^(k+1)) / (1 − α). Stabilität von Softmax: Max-Wert vor der Exponentialfunktion subtrahieren. Kausalmaske: In verbotene Werte −∞ schreiben, nicht null.

Falls Sie diese Gleichungen an einer Tafel neu ableiten und jeden Symbol erklären können, übertreffen Sie bereits die meisten vagen Erklärungen.

Anhang – Wo man sich weiter vertiefen kann

Nach dieser Tour durch die Pipeline sind natürliche Schritte: das Lesen eines PagedAttention-ähnlichen Allokationspfades in einem laufenden Engine, das Profilieren eines Vorfüll- und eines Dekodierungs-Schritts mit einem Herstellerspezifischen Profiler sowie die Implementierung einer kleinen, gierigen Dekodierungs-Schleife mit einem expliziten KV-Cache in NumPy oder PyTorch, um die Strukturen kennenzulernen. Diese Übungen verwandeln das oben genannte Wissen in muskuläres Gedächtnis, ohne dass eine vollständige Trainingsumgebung erforderlich ist.

Noch ein Schritt – Metriken mit den Problemen der Nutzer verknüpfen

Wenn in einem Support-Ticket steht „die KI ist langsam“, muss das übersetzt werden. Wenn ein Ladeindikator vor jedem Text erscheint, sollten TTFT-Faktoren untersucht werden: Länge der Eingabeanfrage, „kalte“ Präfixe, Überlastung bei der Vorfüllung oder ein fehlender Cache. Wenn der Text schnell angezeigt wird, aber anschließend langsam weiterlädt, sollten TPOT-Faktoren geprüft werden: Übergröße der Batch-Größen, KV-Memory-Probleme, die zu kleinen Batch-Größen führen, unquantisierte Gewichte auf einer kabelgebundenen Karte oder deaktivierte Spekulationen auf einem früher erfolgreichen Weg.

Falls im Ticket steht „Die Antworten sind nach Dienstag schlechter geworden“, vergleichen Sie vor dem Neutraining der Samplesätze, Template-Hashes sowie Quantisierungsflaggen. Regressionsmodelle im Dienstbetrieb tarnen sich ständig als Intelligenzregressionen.

Wenn im Ticket steht „Es erfindet JSON“, hören Sie auf, die Temperatureinstellungen anzupassen, und verwenden Sie stattdessen eingeschränkte Dekodierungsmethoden. Sampling kann keine Grammatik durchsetzen; Masking hingegen schon.

Capacity-Planning-Treffen laufen besser, wenn jemand drei Zahlen an die Tafel schreibt: Bytes pro KV-Token, Zielkonkurrenzgrad sowie Zielkontextmenge. Multiplizieren Sie diese Werte, addieren Sie die Gewichtsbelastung und vergleichen Sie das Ergebnis mit der GPU-Gedächtnismenge. Argumente über „KI-Magie“ enden – stattdessen beginnt die reine Mathematik der Ressourcenplanung.

Daran liegt der Sinn dieser gesamten Prozessbeschreibung: Das Unbekannte durch messbare Werte ersetzen und diese wiederum durch Hebel ersetzen, die Sie tatsächlich bedienen können.

Fazit zum Umfang

Diese Überarbeitung bleibt im Rahmen des Inferenzprozesses: Was passiert, nachdem die Gewichte vorhanden sind, wenn ein Client Text sendet, und bevor das Operations-Team mit der Feinabstimmung beginnt. Aspekte während des Trainings – Datemischungen, Optimierer, parallele Trainingspläne – sind äußerst wichtig, gehören aber zu einem anderen Thema. Wenn Sie unter Druck die Aufteilung von Vorausfüllung und Dekodierung, die KV-Last sowie die Zusammensetzung der Stichproben im Kopf behalten können, haben Sie bereits die Grundstruktur, an der sich die anderen Themen anschließen.

Leseeinheit

Nehmen Sie eine Produktionsanfrage aus Ihren Protokollen. Notieren Sie die Anzahl der Eingabetoken, die Anzahl der Ausgabetoken sowie den beobachteten TTFT/TPOT-Wert, sofern diese verfügbar sind. Schätzen Sie den KV-Speicherverbrauch mithilfe der Formel pro Token für die Schicht- und Kopfstruktur Ihres Modells. Prüfen Sie, ob die Anfrage eher durch rechenintensive Vorausbelegung oder durch bandbreitenbegrenzte Dekodierung beeinflusst wurde. Nennen Sie einen Hebel – Präfixcache, Batch-Größe, Quantisierung, GQA oder Spekulation – der den für Sie wichtigsten Metrikenwert verändern würde. Wenn Sie diese Übung ohne erneutes Öffnen dieses Artikels abschließen können, hat die Überarbeitung ihre Wirkung gezeigt.

Halten Sie ein kurzes persönliches Cheat Sheet bereit: Vorausfüllen versus Dekodieren, Formel für KV-Bytes, TTFT versus TPOT sowie Reihenfolge der Sampling. Überprüfen Sie es vor Kapazitätsbewertungen und bevor Sie das Modell für auftretende Fehler verantwortlich machen. Solche kleinen Gewohnheiten führen zu zuverlässiger Intuition. Üben Sie, den Ablauf in weniger als zwei Minuten laut zu erklären; Flüssigkeit unter Zeitdruck ist der eigentliche Test des Verständnisses. Üben Sie, den Ablauf in weniger als zwei Minuten laut zu erklären; Flüssigkeit unter Zeitdruck ist der eigentliche Test des Verständnisses. Üben Sie, den Ablauf in weniger als zwei Minuten laut zu erklären; Flüssigkeit unter Zeitdruck ist der eigentliche Test des Verständnisses.