Stand: 26. August 2026
So ist das Glossar aufgebaut
Die Begriffe stehen nicht nur alphabetisch nebeneinander, sondern unter ihrem
jeweiligen Überbegriff. So wird sichtbar, was zusammengehört:
- Lokale LLM-Inferenz
- Modell und Architektur
- Dense, MoE, Attention, KV-Heads, DeltaNet
- Zahlenformate und Quantisierung
- BF16, FP8, INT4, AWQ, GPTQ, GGUF
- Speicher und Hardware
- VRAM, KV-Cache, Bandbreite, PCIe, NVLink
- Inference-Engines
- vLLM, SGLang, llama.cpp, TensorSharp
- Parallelisierung und Serving
- TP, PP, EP, Batching, PagedAttention
- Spekulatives Decoding
- MTP, EAGLE, DFlash, DSpark, n-gram
Viele Begriffe gehören zu mehreren Bereichen. Der KV-Cache ist zum Beispiel
gleichzeitig ein Architektur-, Speicher- und vLLM-Thema.
Modellnamen in zehn Sekunden lesen
Ein Name wie Qwen3.6-35B-A3B-FP8 ist eine sehr kurze technische Beschreibung:
| Teil |
Bedeutung |
Qwen3.6 |
Modellfamilie und Generation |
35B |
Rund 35 Milliarden Parameter insgesamt |
A3B |
Rund 3 Milliarden Parameter sind pro Token aktiv |
FP8 |
Die Modellgewichte liegen in einem 8-Bit-Gleitkommaformat vor |
Weitere typische Kürzel:
| Schreibweise |
Kurz erklärt |
27B |
27 Milliarden Parameter; B steht für billion |
A10B |
Etwa 10 Milliarden Parameter sind pro Token aktiv |
262k |
Kontextlimit von ungefähr 262.000 Tokens |
1M |
Kontextlimit von ungefähr einer Million Tokens |
TP4 |
Tensor Parallelism über vier GPUs |
TP2+PP3 |
Zwei GPUs pro Tensor-Gruppe und drei Pipeline-Stufen, insgesamt sechs GPUs |
Q4_K_M |
GGUF-Quantisierung mit ungefähr vier Bit pro Gewicht |
W4A16 |
4-Bit-Gewichte, aber 16-Bit-Aktivierungen während der Rechnung |
it / Instruct |
Für Anweisungen und Chat nachtrainierte Variante |
Base |
Grundmodell ohne oder mit wenig Chat-/Instruct-Nachtraining |
Wichtig: Der Name sagt noch nicht, ob das Modell gut, schnell oder mit
einer bestimmten Engine kompatibel ist.
1. Grundbegriffe
| Begriff |
Einfach erklärt |
Verwandt mit |
| LLM |
Large Language Model, also ein großes Sprachmodell. Es berechnet, welches Token wahrscheinlich als Nächstes kommt. |
Modell, Token, Inferenz |
| Local LLM |
Ein Sprachmodell, das auf eigener Hardware statt bei einem Cloud-Anbieter läuft. |
Datenschutz, GPU, Inference-Engine |
| Modell |
Das trainierte Rechennetz samt seinen gelernten Zahlenwerten. Es ist das eigentliche „Gehirn“. |
Architektur, Gewichte |
| Checkpoint |
Ein gespeicherter Stand eines Modells. Ein Checkpoint kann das Original oder eine quantisierte Variante sein. |
Safetensors, GGUF |
| Open Weights |
Die Modellgewichte können heruntergeladen und selbst ausgeführt werden. Das bedeutet nicht automatisch, dass Training, Daten oder Lizenz völlig offen sind. |
Hugging Face, Checkpoint |
| Parameter |
Eine gelernte Zahl im Modell. Milliarden solcher Zahlen bestimmen sein Verhalten. |
Gewicht, B, aktive Parameter |
| Gewicht / Weight |
Ein Parameter, der Eingaben innerhalb des Netzes stärker oder schwächer gewichtet. |
Quantisierung, VRAM |
| Aktive Parameter |
Der Teil eines MoE-Modells, der für ein einzelnes Token tatsächlich benutzt wird. |
MoE, A3B, Decode-Speed |
| Inferenz / Inference |
Das Benutzen eines fertig trainierten Modells, um Antworten zu erzeugen. |
Prefill, Decode |
| Training |
Das Lernen der Gewichte aus sehr vielen Beispielen. Es ist wesentlich teurer als die spätere Inferenz. |
Fine-Tuning, Kalibrierung |
| Fine-Tuning |
Zusätzliches Training eines vorhandenen Modells für bestimmte Aufgaben oder Verhaltensweisen. |
Instruct, Drafter |
| Distillation |
Ein kleineres Modell lernt, die Ausgaben oder internen Signale eines größeren Modells nachzuahmen. |
Draft-Modell, EAGLE, DFlash |
| Token |
Ein Textbaustein. Ein Token kann ein Wort, ein Wortteil, Satzzeichen oder Codefragment sein. Tokens sind nicht dasselbe wie Zeichen oder Wörter. |
Tokenizer, Kontext |
| Tokenizer |
Übersetzt Text in Token-IDs und später wieder zurück. |
Vokabular, Chat-Template |
| Token-ID |
Die Nummer eines Tokens im Vokabular. |
Tokenizer, Struktur-Token |
| Vokabular |
Die komplette Liste der Tokens, die ein Modell kennt. Zwei Modelle können inkompatible Vokabulare haben. |
Tokenizer, Draft-Modell |
| Prompt |
Die Eingabe an das Modell. Dazu gehören oft mehr Daten als nur die sichtbare Nutzerfrage. |
System-Prompt, Kontext |
| System-Prompt |
Verdeckte oder vorangestellte Grundanweisung für Rolle, Regeln und Werkzeuge des Modells. |
Chat-Template, Prefix-Cache |
| Completion |
Der vom Modell neu erzeugte Teil einer Antwort. |
Output-Tokens, Decode |
| Kontext / Context |
Alles, was das Modell im aktuellen Request sehen kann: Regeln, Verlauf, Tool-Ausgaben, Dateien und neue Frage. |
Context Window, KV-Cache |
| Context Window |
Die maximale Zahl an Tokens, die Eingabe und Ausgabe zusammen umfassen dürfen. |
262k, 1M, YaRN |
| Output-Budget |
Obergrenze für die neu zu erzeugenden Tokens. Ein großes Kontextfenster bedeutet nicht automatisch ein ebenso großes Output-Budget. |
max_tokens, Reasoning |
| Reasoning / Thinking |
Vom Modell erzeugte Denkschritte vor der eigentlichen Antwort. Sie können sichtbar, getrennt oder verborgen sein, belegen aber Kontext und Rechenzeit. |
Think-Tokens, Reasoning-Parser |
| Think-Tokens |
Tokens des Denkprozesses. Viele Tausend Think-Tokens können das Kontextfenster füllen, obwohl der Nutzer nur eine kurze Endantwort sieht. |
Reasoning, Kontext |
| Tool-Calling / Function-Calling |
Das Modell fordert strukturiert ein Werkzeug an, etwa Dateilesen, Websuche oder Shell-Befehl. |
Tool-Parser, Agent |
| Agent / agentisch |
Ein Modell arbeitet in mehreren Schritten, benutzt Werkzeuge, prüft Ergebnisse und setzt die Aufgabe fort. |
Tool-Loop, Kontext, Prefix-Caching |
| RAG |
Retrieval-Augmented Generation: Vor der Antwort werden passende Dokumentausschnitte gesucht und in den Prompt eingefügt. |
Retrieval, Kontext, Embedding |
| Halluzination |
Eine plausibel klingende, aber erfundene oder falsche Aussage des Modells. |
Grounding, Verifikation |
2. Modellarchitektur
2.1 Bausteine eines Modells
| Begriff |
Einfach erklärt |
Verwandt mit |
| Transformer |
Die klassische Grundarchitektur moderner Sprachmodelle. Sie verarbeitet Tokens in vielen aufeinanderfolgenden Schichten. |
Attention, Layer |
| Layer / Block |
Eine Rechenschicht des Modells. Ein Token durchläuft viele Layer nacheinander. |
Attention, MLP, PP |
| Embedding |
Zahlenvektor, der ein Token für das Modell darstellt. Ähnliche Bedeutungen können ähnliche Vektoren haben. |
Token, Hidden State |
| Hidden State |
Interne Zahlenrepräsentation dessen, was das Modell an einer bestimmten Stelle „verstanden“ hat. |
EAGLE, DFlash, LM Head |
| Logits |
Rohe Punktzahlen für alle möglichen nächsten Tokens. Sampling macht daraus eine konkrete Auswahl. |
LM Head, Softmax, Sampling |
| LM Head |
Letzte Projektion des Modells. Sie übersetzt den Hidden State in Logits für das Vokabular. |
Logits, Vokabular |
| FFN / MLP |
Rechenblock innerhalb eines Layers, der die Token-Darstellung transformiert. Bei MoE gibt es davon viele alternative Experten. |
MoE, Experte |
| Dense-Modell |
Bei jedem Token werden alle Modellparameter benutzt. Einfacher und oft robust, aber bei großen Modellen speicher- und bandbreitenhungrig. |
MoE, aktive Parameter |
| MoE |
Mixture of Experts. Viele Experten sind gespeichert, aber pro Token wird nur eine kleine Auswahl aktiviert. |
Router, A3B, Expert Parallelism |
| Experte |
Ein spezialisiertes FFN innerhalb eines MoE-Layers. Der Name bedeutet nicht, dass ein einzelner Experte sauber einem Thema wie Mathematik zugeordnet werden kann. |
MoE, Router |
| Gerouteter Experte |
Experte, den der Router je Token auswählt. |
Top-k, Router |
| Shared Expert |
Experte, der unabhängig von der Router-Auswahl immer mitarbeitet. |
MoE, aktive Parameter |
| Router / Gate |
Kleines Netz, das für jedes Token und jeden MoE-Layer die passenden Experten wählt. |
MoE, Quantisierung |
| Top-k Experts |
Anzahl der pro Token ausgewählten Experten, etwa 8 von 256. Nicht mit Sampling-top_k verwechseln. |
Router, MoE |
| A3B / A10B |
Kurzform für ungefähr 3 beziehungsweise 10 Milliarden aktive Parameter pro Token. |
MoE, Decode-Speed |
| Hybrid-Architektur |
Modell mischt unterschiedliche Layer-Arten, etwa volle Attention und DeltaNet. |
DeltaNet, SWA, KV-Cache |
| Rekurrenter Zustand |
Komprimierte Erinnerung, die von Schritt zu Schritt weitergereicht wird. Sie ersetzt in manchen Layern einen wachsenden KV-Cache. |
DeltaNet, SSM |
| SSM |
State Space Model. Verarbeitet Sequenzen über einen kompakten fortlaufenden Zustand statt über volle Attention auf alle alten Tokens. |
Rekurrenz, Hybrid-Modell |
2.2 Attention, Heads und KV-Speicher
Die einfachste Denkweise für Attention lautet: Ein Token stellt eine
Frage an den bisherigen Text und sucht passende Schlüssel und
Inhalte.
| Begriff |
Einfach erklärt |
Verwandt mit |
| Attention |
Mechanismus, mit dem ein Token relevante frühere Tokens gewichtet. |
Query, Key, Value |
| Self-Attention |
Attention innerhalb derselben Tokenfolge. Der Text schaut auf seinen eigenen bisherigen Inhalt. |
Transformer, KV-Cache |
| Query (Q) |
Die aktuelle Suchfrage eines Attention-Heads: „Welche frühere Information brauche ich jetzt?“ |
Key, Attention-Head |
| Key (K) |
Suchschlüssel eines früheren Tokens. Query und Key bestimmen, wie relevant dieses Token ist. |
Query, KV-Cache |
| Value (V) |
Der eigentliche Informationsinhalt, der bei einem passenden Key gelesen wird. |
Key, KV-Cache |
| Attention-Head / Query-Head |
Ein paralleler Blickwinkel der Attention. Verschiedene Heads können unterschiedliche Beziehungen im Text erfassen. |
MHA, GQA |
| KV-Head |
Ein Head, der Key- und Value-Daten erzeugt. Mehrere Query-Heads können sich einen KV-Head teilen. Weniger KV-Heads bedeuten meist einen kleineren KV-Cache. |
GQA, MQA, TP |
| MHA |
Multi-Head Attention. Jeder Query-Head hat eigene Key- und Value-Heads. Flexibel, aber der KV-Cache wird groß. |
Attention-Head, KV-Head |
| GQA |
Grouped-Query Attention. Mehrere Query-Heads teilen sich einen KV-Head. Das spart KV-Speicher mit meist geringem Qualitätsverlust. |
MHA, MQA |
| MQA |
Multi-Query Attention. Alle Query-Heads teilen sich nur einen KV-Head. Sehr speichersparend, aber stärker geteilt. |
GQA, KV-Cache |
| KV-Cache |
Zwischenspeicher für Keys und Values bereits verarbeiteter Tokens. Ohne ihn müsste das Modell bei jedem neuen Token die gesamte Vergangenheit erneut berechnen. |
Kontext, VRAM, PagedAttention |
| KV-Speicher |
Umgangssprachlicher Name für den Speicherplatz des KV-Caches. Er liegt bei GPU-Inferenz meist im VRAM. |
KV-Cache, KV-DType |
| KV-Cache pro Token |
Speicher, den ein weiteres Kontext-Token belegt. Er hängt unter anderem von Layerzahl, KV-Heads, Head-Dimension und Datentyp ab. |
Context Window, BF16-KV |
| Head-Dimension |
Größe des Zahlenvektors eines Attention-Heads. |
KV-Cache, Modellarchitektur |
| Head-Teilbarkeit |
Bei TP muss die Zahl der Attention- und KV-Heads meist durch die TP-Größe teilbar sein. Acht KV-Heads passen etwa zu TP2, TP4 und TP8, aber nicht zu TP6. |
Tensor Parallelism |
| KV-Cache-DType |
Zahlenformat des KV-Caches, etwa BF16, FP8, INT8 oder q8_0. Es ist unabhängig vom Format der Modellgewichte. |
KV-Quantisierung |
| Cache-Eviction |
Ein alter KV-Cache wird entfernt, um Platz für einen anderen Request zu schaffen. Beim nächsten Zugriff muss er neu aufgebaut werden. |
Multi-User, PagedAttention |
2.3 Lange Kontexte und alternative Attention
| Begriff |
Einfach erklärt |
Verwandt mit |
| Full / Dense Attention |
Jedes neue Token kann grundsätzlich auf alle vorherigen Tokens schauen. Genau, aber bei langen Kontexten teuer. |
KV-Cache, quadratische Kosten |
| Quadratische Attention-Kosten |
Verdoppelt man die Sequenzlaenge, können bei voller Attention ungefähr viermal so viele Tokenpaare relevant werden. |
Prefill, Long Context |
| Sliding-Window Attention (SWA) |
Ein Layer schaut nur auf ein begrenztes Fenster der letzten Tokens, etwa 512 oder 2048. |
Hybrid-Modell, lokaler Kontext |
| Sparse Attention |
Nur ausgewählte Teile des Kontexts werden betrachtet. Das spart Rechenarbeit bei langen Kontexten. |
MSA, Indexer |
| MSA |
MiniMax Sparse Attention. Ein Index wählt relevante Kontextblöcke aus, statt immer alles zu lesen. |
Sparse Attention, GQA |
| MLA |
Multi-Head Latent Attention. Keys und Values werden in einer komprimierten latenten Darstellung gehalten, um Speicher und Bandbreite zu sparen. Bekannt aus DeepSeek-Modellen. |
KV-Cache, Attention |
| Lineare Attention |
Verarbeitet die Vergangenheit über einen kompakten Zustand. Aufwand und Speicher wachsen günstiger als bei voller Attention. |
DeltaNet, Rekurrenz |
| DeltaNet |
Familie linearer Attention-Verfahren, die relevante Information in einem festen Zustand fortschreibt. Diese Layer brauchen keinen klassischen, linear wachsenden KV-Cache. |
GatedDeltaNet, Hybrid-Modell |
| GatedDeltaNet |
DeltaNet mit steuernden Gates, die entscheiden, welche Information behalten, aktualisiert oder vergessen wird. |
Rekurrenter Zustand |
| RoPE |
Rotary Position Embedding. Kodiert die Position eines Tokens mathematisch in Query und Key. |
Kontextlänge, YaRN |
| YaRN |
Verfahren, das RoPE für längere Kontexte skaliert. Ein großer konfigurierter Wert garantiert trotzdem keine unveränderte Modellqualität. |
RoPE, Long Context |
| Native Kontextlänge |
Länge, für die Modell und Positionsmechanismus vorgesehen oder trainiert wurden. |
YaRN, Override |
| Kontext-Override |
Runtime-Konfiguration, die ein größeres Fenster erlaubt als der Checkpoint standardmäßig angibt. Technisch startbar ist nicht automatisch qualitativ verlässlich. |
YaRN, max_model_len |
2.4 Multimodalität
| Begriff |
Einfach erklärt |
Verwandt mit |
| Multimodal |
Das Modell kann neben Text weitere Eingaben wie Bilder, Audio oder Video verarbeiten. |
Encoder, Vision |
| Vision-Encoder |
Übersetzt ein Bild in Zahlenvektoren, die das Sprachmodell versteht. |
Multimodal, Embedding |
| Audio-Encoder |
Übersetzt Audio in Modellvektoren. |
Multimodal |
| mmproj |
Separate Projektor-Datei im llama.cpp-/GGUF-Umfeld, die Bildmerkmale an das Sprachmodell anpasst. |
Vision-Encoder, GGUF |
| Language-model-only |
Serving-Modus, der multimodale Encoder nicht lädt. Das spart VRAM, macht den Endpoint aber text-only. |
vLLM, --language-model-only |
3. Zahlenformate und Quantisierung
3.1 Die Grundidee
Quantisierung ist wie das Speichern eines großen Fotos als komprimiertes Bild:
Es braucht weniger Platz und lässt sich oft schneller lesen, kann aber Details
verlieren. Bei einem Modell werden nicht Fotos, sondern Milliarden Zahlen
komprimiert.
| Begriff |
Einfach erklärt |
Verwandt mit |
| Präzision |
Wie genau eine Zahl dargestellt wird. Mehr Bits erlauben meist feinere Werte, brauchen aber mehr Speicher. |
FP16, INT4 |
| Bit |
Kleinste digitale Information, 0 oder 1. Acht Bit ergeben ein Byte. |
BPW, Quantisierung |
| Quantisierung |
Gewichte oder Cachewerte werden mit weniger Bits gespeichert. Ziel sind weniger Speicherverbrauch und oft mehr Geschwindigkeit. |
Dequantisierung, Kalibrierung |
| Dequantisierung |
Quantisierte Zahlen werden während der Rechnung in ein nutzbares Rechenformat zurückübersetzt. |
Marlin, W4A16 |
| Weight Quantization |
Quantisierung der Modellgewichte. Sie bestimmt vor allem Modellgröße, Engine-Kompatibilität und Gewichtsdurchsatz. |
AWQ, GPTQ, GGUF |
| KV-Cache-Quantisierung |
Separate Quantisierung der Attention-Erinnerung. Sie vergrößert den möglichen Kontext, kann aber andere Qualitätsrisiken haben als Gewichtsquantisierung. |
FP8-KV, q8_0-KV |
| Post-Training Quantization (PTQ) |
Ein bereits trainiertes Modell wird nachträglich quantisiert, ohne es komplett neu zu trainieren. |
GPTQ, AWQ |
| Kalibrierung |
Beispieltexte werden durch das Modell geschickt, um herauszufinden, welche Werte besonders empfindlich sind. |
AWQ, GPTQ, Outlier |
| Importance Matrix / imatrix |
Misst bei GGUF-Quants, welche Gewichte für typische Daten wichtig sind und mehr Genauigkeit bekommen sollten. |
GGUF, IQ-Quant |
| BPW |
Bits Per Weight. Durchschnittliche Bitzahl pro Gewicht. Metadaten und gemischte Präzision sorgen dafür, dass ein „4-Bit-Modell“ nicht exakt 4,00 BPW haben muss. |
Quantisierung |
| Mixed Precision |
Empfindliche Teile bleiben hochpräzise, robuste Teile werden stärker quantisiert. |
PrismaQuant, Smart Quant |
| Outlier |
Außergewöhnlich großer Zahlenwert. Ein paar Outlier können bei zu grober Quantisierung überproportional viel Schaden verursachen. |
Scale, Mixed Precision |
| Quantisierungsgruppe |
Gewichte werden in Gruppen gemeinsam skaliert, etwa 32 oder 128 Werte. |
g32, g128, Scale |
Group Size g32 / g128 |
Anzahl Gewichte pro gemeinsamer Quantisierungsskala. Kleinere Gruppen sind flexibler, aber oft speicher- oder kernelteurer. |
GPTQ, AWQ, Marlin |
| Scale |
Umrechnungsfaktor zwischen komprimiertem Zahlenwert und seiner realen Größe. Falsche Skalen können korrekte Rechnungen zerstören. |
FP8, INT4 |
| Zero Point |
Referenzwert einer Integer-Quantisierung. Er legt fest, welcher quantisierte Wert der echten Null entspricht. |
asymmetrische Quantisierung |
| Smart Quant |
Kein festes Dateiformat, sondern die Idee, Router, Attention, Norms und Outlier-Layer stärker zu schützen als robuste Bulk-Gewichte. |
Mixed Precision, MoE |
3.2 Zahlenformate
| Format |
Kurz erklärt |
Typische Einordnung |
| FP32 |
32-Bit-Gleitkomma. Sehr genau, für lokale Inferenz großer Modelle aber meist unnötig groß. |
Referenz, Training |
| FP16 |
16-Bit-Gleitkomma. Halb so groß wie FP32 und ein klassisches Modellformat. |
Safetensors, Aktivierungen |
| BF16 |
Brain Float 16. Ebenfalls 16 Bit, aber mit großem Wertebereich und weniger Nachkommagenauigkeit als FP16. Oft das Master- oder Rechenformat moderner Modelle. |
Training, KV-Cache |
| B16 |
Meist ein Tippfehler oder eine ungenaue Kurzform für BF16. Das standardisierte Format heißt BF16. |
BF16 |
| FP8 |
8-Bit-Gleitkomma. Spart gegenüber BF16 etwa die Hälfte des Gewichts- oder Cache-Speichers. Nicht jede GPU kann FP8 nativ rechnen. |
E4M3, E5M2 |
| E4M3 |
FP8-Variante mit 4 Exponenten- und 3 Mantissenbits. Mehr Genauigkeit, kleinerer Wertebereich. |
FP8-KV, Outlier |
| E5M2 |
FP8-Variante mit größerem Wertebereich, aber weniger Genauigkeit. |
FP8 |
| INT8 |
8-Bit-Ganzzahlformat. Oft robust und etwa halb so groß wie BF16. |
Gewichte, KV-Cache |
| INT4 |
4-Bit-Ganzzahlformat. Sehr kompakt und schnell, wenn Modell, Kalibrierung und Kernel dazu passen. |
GPTQ, AWQ, W4A16 |
| W4A16 |
Gewichte mit 4 Bit, Aktivierungen während der Rechnung mit 16 Bit. |
Marlin, INT4 |
| FP4 |
4-Bit-Gleitkommafamilie. Extrem kompakt, aber stark vom genauen Format und der Hardware abhängig. |
NVFP4, MXFP4 |
| NVFP4 |
NVIDIA-nahes blockskaliertes FP4-Format. Auf Hardware ohne natives FP4 wird oft über spezialisierte Dequantisierungskernel gearbeitet. |
vLLM, Marlin |
| MXFP4 |
Microscaling FP4. Kleine Werteblöcke teilen sich Skalen. Manche Modelle wurden direkt für dieses Format ausgelegt. |
GPT-oss, vLLM |
| Q8_0 |
Einfaches 8-Bit-GGUF-Quant. Groß, aber meist sehr nah an hoher Präzision. |
GGUF, llama.cpp |
| Q4_K_S / Q4_K_M |
GGUF-4-Bit-Quants. S ist kompakter, M bewahrt typischerweise mehr Teile mit höherer Präzision. |
llama.cpp, GGUF |
| Q4_K_XL |
Größeres, qualitätsorientiertes dynamisches 4-Bit-GGUF-Profil. Der genaue Aufbau ist quant-spezifisch. |
Unsloth, GGUF |
| IQ4_XS / IQ3_KS |
Importance-aware GGUF-Quants. IQ bezeichnet eine Familie ausgefeilter Low-Bit-Verfahren, nicht automatisch eine bestimmte Qualität. |
imatrix, ik_llama |
| Ternary / 1.x-Bit |
Gewichte verwenden nur sehr wenige Zustände, oft ungefähr -1, 0 und +1. Extrem kompakt, aber stark modell- und runtimeabhängig. |
UD-TQ1_0 |
3.3 Quantisierungsverfahren und Dateiformate
| Begriff |
Einfach erklärt |
Typische Engine |
| GPTQ |
Post-Training-Verfahren, das Gewichte schichtweise quantisiert und Fehler teilweise kompensiert. |
vLLM, SGLang, ExLlama |
| AWQ |
Activation-Aware Weight Quantization. Schützt Gewichte, die bei echten Aktivierungen besonders wichtig erscheinen. |
vLLM, SGLang |
| AutoRound |
Quantisierungsverfahren, das Rundungsentscheidungen optimiert, statt immer nur auf den nächsten festen Wert zu runden. |
vLLM-kompatible Quants |
| PrismaQuant |
Mixed-Precision-Ansatz: unterschiedliche Modellteile erhalten unterschiedliche Formate wie NVFP4, MXFP8 oder BF16. |
vLLM |
| GGUF |
Dateiformat des llama.cpp-Ökosystems. Es kann Modell, Metadaten und viele flexible Quantisierungsarten enthalten. |
llama.cpp, ik_llama |
| Safetensors |
Sicheres, schnelles Tensor-Dateiformat im Hugging-Face-Ökosystem. Es ist ein Container, keine bestimmte Präzision. |
vLLM, SGLang, Transformers |
| Compressed Tensors |
Hugging-Face-/vLLM-nahes Schema, das quantisierte Tensoren und ihre Quantisierungsregeln beschreibt. |
vLLM, Marlin |
| Shard |
Eine von mehreren Dateien, in die ein großer Checkpoint aufgeteilt ist. Alle Shards zusammen bilden das Modell. |
Safetensors, GGUF |
| Marlin |
Schneller GPU-Kernel für quantisierte Gewichte. Er kombiniert Lesen und Dequantisieren, damit INT4-/FP4-Modelle effizient laufen. |
GPTQ, AWQ, Ampere+ |
| Weight-only Quantization |
Nur die Gewichte sind komprimiert; Aktivierungen werden höherpräzise berechnet. |
W4A16, Marlin |
3.4 Was die Formatnamen nicht sagen
| Missverständnis |
Richtige Einordnung |
FP8 im Modellnamen und FP8-KV seien dasselbe |
Das erste beschreibt meist die Gewichte, das zweite den KV-Cache. Beides kann unabhängig konfiguriert sein. |
| Jedes 4-Bit-Modell sei gleich gut |
Kalibrierung, geschützte Layer, Gruppenbreite und Modellarchitektur sind oft wichtiger als die nackte Bitzahl. |
| BF16 sei immer schneller als INT4 |
BF16 spart Dequantisierung, liest aber viel mehr Daten. Welches Format schneller ist, hängt von Kernel, GPU und Workload ab. |
| FP8 laufe auf jeder GPU mit FP8-Geschwindigkeit |
Ampere-GPUs wie RTX 3090 haben kein natives FP8-Compute. Die Runtime kann FP8 trotzdem speichern und über Fallback-Kernel verarbeiten. |
| GGUF sei eine Quantisierungsstufe |
GGUF ist das Dateiformat. Q4_K_M, Q8_0 oder IQ4_XS sind Quantisierungsarten darin. |
4. Speicher und Hardware
| Begriff |
Einfach erklärt |
Verwandt mit |
| GPU |
Prozessor mit sehr vielen parallelen Recheneinheiten. Gut für die großen Matrixoperationen eines LLM. |
CUDA, VRAM |
| VRAM |
Schneller Speicher direkt auf der GPU. Darin müssen Gewichte, KV-Cache, Arbeitsbereiche und oft CUDA Graphs Platz finden. |
OOM, KV-Cache |
| RAM / System-RAM |
Hauptspeicher des Rechners. Viel größer und billiger als VRAM, für GPU-Inferenz aber über PCIe deutlich langsamer erreichbar. |
Offloading |
| GB vs. GiB |
GB rechnet meist dezimal, GiB binär. 24 GB Herstellerangabe entsprechen nicht exakt 24 GiB nutzbarem Speicher. |
Kapazitätsplanung |
| Speicherbandbreite |
Datenmenge, die pro Sekunde aus einem Speicher gelesen werden kann. Bei Batch 1 bestimmt sie oft die Decode-Speed stärker als Rechenleistung. |
memory-bound, tok/s |
| GDDR / HBM |
Arten von GPU-Speicher. HBM bietet meist sehr hohe Bandbreite und Kapazität, ist aber auf teuren Datacenter-GPUs üblich. |
VRAM, H100/H200 |
| Compute Capability / SM |
NVIDIA-Generationskennung wie SM70, SM86 oder SM90. Sie entscheidet, welche Kernel und Datentypen nutzbar sind. |
CUDA, FP8, Marlin |
| CUDA |
NVIDIAs Plattform für GPU-Programme. Engines verwenden CUDA-Kernel für Modellrechnungen. |
Kernel, Treiber |
| CUDA-Kernel |
Kleine, spezialisierte Funktion, die direkt auf der GPU läuft. Gute Kernel sind entscheidend für Geschwindigkeit. |
Triton, Marlin |
| Tensor Core |
GPU-Recheneinheit für schnelle Matrixoperationen in Formaten wie FP16, BF16, INT8 oder auf neuer Hardware FP8. |
Compute Capability |
| AVX2 / AVX-512 |
CPU-Befehlssätze, die viele Zahlen gleichzeitig verarbeiten. AVX-512 kann CPU-Offloading deutlich beschleunigen, wenn Software und Prozessor es unterstützen. |
CPU-Offloading |
| AMX |
Intel-Matrixeinheiten für schnelle INT8-/BF16-Rechnungen auf neueren Server-CPUs. Besonders relevant für CPU-seitige MoE-Experten. |
Expert-Offloading |
| Memory-bound |
Die Rechnung wartet hauptsächlich auf Daten aus dem Speicher. Typisch für Single-Stream-Decode. |
Bandbreite, Quantisierung |
| Compute-bound |
Die Recheneinheiten sind der Engpass. Das tritt eher bei Prefill, großen Batches oder rechenintensiven Kernels auf. |
TFLOPS, Batching |
| PCIe |
Standardverbindung zwischen CPU, RAM und GPUs. Bei Multi-GPU ersetzt sie auf Consumer-Hardware oft einen schnellen Spezialverbund. |
P2P, AllReduce |
| PCIe x4/x8/x16 |
Anzahl der genutzten PCIe-Lanes. Mehr Lanes bedeuten mehr mögliche Transferbandbreite. |
Multi-GPU, Bifurkation |
| PCIe-Bifurkation |
Ein großer PCIe-Link wird in mehrere kleinere Links geteilt, etwa x16 in zweimal x8. |
Multi-GPU-Rig |
| P2P / Peer-to-Peer |
GPUs tauschen Daten direkt aus, ohne Umweg über CPU-RAM. Ob das wirklich funktioniert, hängt von Treiber und Topologie ab. |
PCIe, NVLink |
| NVLink |
Schnelle direkte NVIDIA-Verbindung zwischen GPUs. Consumer-3090-NVLink verbindet nur begrenzte Paare und ersetzt keinen Datacenter-NVSwitch. |
AllReduce, TP |
| NVSwitch |
Switch, der viele Datacenter-GPUs mit sehr hoher Bandbreite untereinander verbindet. |
NVLink, H100/H200 |
| PCIe Root Complex |
CPU-/Chipsatzbereich, an dem PCIe-Geräte hängen. Transfers über verschiedene Root Complexes können problematisch oder langsamer sein. |
P2P, NCCL |
| NCCL |
NVIDIA-Bibliothek für Kommunikation zwischen GPUs, etwa AllReduce, Broadcast und Send/Receive. |
TP, PP |
| AllReduce |
Alle GPUs kombinieren ihre Teilergebnisse und erhalten danach das Gesamtergebnis. Bei TP passiert das sehr oft. |
NCCL, Tensor Parallelism |
| OOM |
Out Of Memory. Eine Speicheranforderung passt nicht mehr in VRAM oder RAM. |
KV-Cache, Context Window |
| Thermal Throttling |
GPU reduziert ihren Takt wegen zu hoher Temperatur. Ein Modell bleibt erreichbar, kann aber plötzlich viel langsamer werden. |
Dauerlast, Benchmark |
| Power Cap |
Gesetzte Leistungsgrenze einer GPU. Kann Hitze und Lastspitzen reduzieren, ohne memory-bound Decode stark zu bremsen. |
Thermik |
5. Inference-Engines und Serving
5.1 Engines
| Begriff |
Einfach erklärt |
Typische Stärke |
| Inference-Engine / Runtime |
Software, die Checkpoint, GPU-Kernel, Speicher und Requests zusammenbringt. Dasselbe Modell kann je nach Engine sehr unterschiedlich schnell oder stabil sein. |
Serving, Kernel |
| vLLM |
GPU-orientierte Open-Source-Engine für schnellen API-Betrieb. Stärken sind PagedAttention, Continuous Batching, Multi-GPU und OpenAI-kompatibles Serving. |
Safetensors, TP, PP |
| SGLang |
Inference- und Serving-Stack mit starkem Scheduling, Prefix-/Radix-Caching, Multi-GPU und moderner Speculative-Decoding-Unterstützung. |
vLLM, Radix Cache |
| llama.cpp |
Schlanke C/C++-Engine, besonders für GGUF, CPU/GPU-Mischbetrieb und Consumer-Hardware. |
GGUF, Layer Split |
| ik_llama |
llama.cpp-Fork mit zusätzlichen MoE-, Offloading- und Multi-GPU-Experimenten. |
Expert-Offloading, Graph Split |
| TensorSharp |
Lokaler spezialisierter Serving-/Ausführungsstack, unter anderem für DeepSeek-V4-Flash und DSpark. |
GGUF, DSpark |
| Ollama |
Benutzerfreundliche lokale Modellverwaltung auf llama.cpp-Basis. Gut für schnelle erste Tests, nicht immer für maximale Serverleistung. |
GGUF, lokale API |
| Hugging Face Transformers |
Referenznahe Python-Bibliothek für sehr viele Modellarchitekturen. Flexibel und korrektheitsnah, aber nicht immer die schnellste Server-Engine. |
Safetensors, Tokenizer |
| ExLlama / TabbyAPI |
GPU-orientierter Stack für bestimmte Low-Bit-Formate und OpenAI-ähnliches Serving. |
EXL2/EXL3, Quantisierung |
5.2 API und Modellverpackung
| Begriff |
Einfach erklärt |
Verwandt mit |
| Serving |
Ein Modell dauerhaft als Dienst bereitstellen, damit Clients Requests senden können. |
API, Endpoint |
| OpenAI-kompatible API |
Endpunkte und JSON-Struktur ähneln der OpenAI-API. Dadurch können viele Clients lokale Modelle ohne Sonderintegration nutzen. |
/v1/chat/completions |
| Endpoint |
Netzwerkadresse eines Modellservers, etwa http://host:8000/v1. |
Port, API |
| Port |
Nummer eines Netzwerkdienstes auf einem Host. Zwei Dienste können nicht gleichzeitig denselben Host-Port belegen. |
Endpoint |
| Served Model Name |
Modellname, den die API nach aussen meldet und im Request erwartet. Er muss nicht dem Dateinamen entsprechen. |
/v1/models |
| Provider |
Client-Konfiguration, die Endpoint, Modell-ID und Fähigkeiten zusammenfasst. |
OpenCode, API |
| Server-Limit |
Was die Runtime tatsächlich laden und verarbeiten kann. |
max_model_len |
| Client-Limit |
Was der Client maximal sendet. Ein 262k-Server hilft nicht, wenn der Client schon bei 16k kürzt. |
Kontext, Compaction |
| Docker-Image |
Fertiges Softwarepaket mit Engine, Bibliotheken und CUDA-Abhängigkeiten. |
Container, Version |
| Container |
Laufende Instanz eines Images mit Modell-Mounts, Ports und Startargumenten. |
Docker, Healthcheck |
| Healthcheck |
Prüft, ob ein Dienst erreichbar ist. Er beweist nicht, dass die Modellausgabe inhaltlich korrekt ist. |
Smoke-Test, Garbling |
| Smoke-Test |
Kurzer Funktionstest mit bekanntem Ergebnis. Er sollte neben Erreichbarkeit auch den Inhalt prüfen. |
Healthcheck, Verifikation |
5.3 Templates und Parser
| Begriff |
Einfach erklärt |
Verwandt mit |
| Chat-Template |
Formatiert Rollen, Nachrichten, Tools und Thinking in die Tokenfolge, die das Modell aus dem Training kennt. Ein falsches Template kann ein gutes Modell unbrauchbar wirken lassen. |
Jinja, Tokenizer |
| Jinja-Template |
Häufig verwendete Templatesprache für Chat-Templates. |
llama.cpp, Hugging Face |
| Reasoning-Parser |
Trennt Denktext von sichtbarem Antworttext. |
<think>, Serving |
| Tool-Call-Parser |
Erkennt die modelltypische Werkzeugsyntax und wandelt sie in strukturierte API-tool_calls um. |
Tool-Calling |
| Auto Tool Choice |
Das Modell darf selbst entscheiden, ob und welches Werkzeug aufgerufen wird. |
Tool-Parser |
| Structure Token / Special Token |
Token mit Protokollbedeutung, etwa Beginn oder Ende einer Rolle. Es kann problematisch sein, denselben Text als normale Nutzdaten zu behandeln. |
Chat-Template, Tokenizer |
| Garbling / Gibberish |
Zeichensalat, fremde Fragmente oder Nullbytes statt sinnvoller Ausgabe. Ursache kann Modell, Quant, Kernel, Parser, KV-Skala oder Runtime sein. |
Smoke-Test, Korruption |
6. Wichtige vLLM-Begriffe
| Begriff |
Einfach erklärt |
Warum wichtig |
| PagedAttention |
vLLM verwaltet KV-Cache in kleinen Blöcken statt als einen großen zusammenhängenden Speicherbereich. Ähnlich wie Speicherseiten eines Betriebssystems. |
Weniger Verschwendung, flexible Requests |
| KV Block / Page |
Kleinste verwaltete Einheit des paged KV-Caches. |
PagedAttention |
| Continuous Batching |
Der Server mischt laufend Tokens verschiedener Requests in gemeinsame GPU-Schritte. Fertige Requests gehen raus, neue kommen hinein. |
Höherer Gesamtdurchsatz |
| Prefix-Caching |
Ein bereits berechneter identischer Promptanfang wird wiederverwendet. Besonders stark bei stabilen System-Prompts und append-only Tool-Loops. |
Weniger Prefill |
| Automatic Prefix Caching (APC) |
vLLM-Bezeichnung für token-genaues Wiederverwenden passender Prefix-Blöcke. |
Prefix-Caching |
| Radix Cache |
Baumartige Prefix-Verwaltung, besonders bekannt aus SGLang. Gemeinsame Promptanfänge teilen sich Cachezweige. |
Prefix-Caching |
| CUDA Graph |
Vorab aufgezeichnete Folge von GPU-Operationen. Sie reduziert CPU- und Kernel-Launch-Overhead beim Decode. |
Mehr VRAM, weniger Latenz |
| Eager Mode |
Operationen werden normal einzeln gestartet statt über aufgezeichnete CUDA Graphs. Einfacher zu debuggen, oft langsamer. |
--enforce-eager |
| PyTorch |
Weit verbreitete Machine-Learning-Bibliothek, auf der vLLM und viele Modellimplementierungen aufbauen. |
torch.compile, CUDA |
| torch.compile |
PyTorch kompiliert Modelloperationen zu optimierteren Ausführungsgraphen. Der erste Start kann durch Kompilierung lange dauern. |
CUDA Graph, Inductor |
| TorchInductor / Inductor |
Compiler-Backend hinter torch.compile, das optimierte CPU- oder GPU-Kernel erzeugt. |
PyTorch, Triton |
| Triton |
Sprache und Compiler für eigene GPU-Kernel. Nicht mit NVIDIA Triton Inference Server verwechseln. |
Attention-Kernel, JIT |
| JIT-Kompilierung |
Kernel wird beim ersten Bedarf übersetzt. Der erste Request ist deshalb oft langsamer als spätere. |
Cold Start, Triton |
| FlashAttention |
Speicheroptimierter Attention-Kernel, der Zwischenwerte nicht unnötig im VRAM ablegt. |
Prefill, Attention |
| FlashInfer |
Bibliothek mit spezialisierten GPU-Kerneln für LLM-Inferenz, unter anderem für Attention, Sampling und verteilte Pfade. |
Attention Backend, CUDA |
| Attention Backend |
Konkrete Kernel-Implementierung für Attention, etwa Triton, FlashAttention oder FlashInfer. |
Kompatibilität, Speed |
gpu_memory_utilization |
Anteil des GPU-Speichers, den vLLM für Modell, KV-Pool und Arbeitsbereiche einplanen darf. Zu hoch lässt zu wenig Sicherheitsreserve. |
OOM, KV-Pool |
max_model_len |
Maximale Sequenzlaenge, die der Server akzeptieren soll. Sie muss in Speicher und Modellarchitektur passen. |
Context Window |
max_num_seqs |
Maximale Zahl gleichzeitig aktiver Sequenzen. Höher bedeutet mehr Parallelität, aber mehr Cache- und Scheduling-Druck. |
Concurrency |
max_num_batched_tokens |
Obergrenze für Tokens, die ein Scheduler-Schritt gemeinsam verarbeitet. |
Prefill, Batching |
| KV-Pool |
Von vLLM reservierter VRAM-Bereich für die KV-Blöcke aller aktiven Requests. |
PagedAttention, Eviction |
| Scheduler |
Entscheidet, welche Requests und Tokens im nächsten GPU-Schritt bearbeitet werden. |
Continuous Batching |
| Custom All-Reduce |
vLLM-eigener optimierter GPU-Austauschpfad. Auf ungeeigneter P2P-Topologie kann der normale NCCL-Pfad stabiler sein. |
TP, P2P |
| Trust Remote Code |
Erlaubt modellseitigen Python-Code aus einem Repository. Kann neue Architekturen ermöglichen, vergrößert aber das Sicherheitsrisiko. |
Hugging Face, vLLM |
7. Parallelisierung und Offloading
7.1 Mehrere GPUs
| Begriff |
Einfach erklärt |
Typischer Nachteil |
| Single-GPU |
Das ganze Modell läuft auf einer GPU. Einfach und kommunikationsarm, aber durch deren VRAM begrenzt. |
Wenig Gesamtspeicher |
| Tensor Parallelism (TP) |
Jeder Layer wird auf mehrere GPUs aufgeteilt; alle rechnen gleichzeitig an demselben Token. |
Sehr häufige GPU-Kommunikation |
| Pipeline Parallelism (PP) |
Verschiedene Layergruppen liegen auf verschiedenen GPU-Stufen. Daten wandern nacheinander durch die Pipeline. |
Pipeline-Bubbles und zusätzliche Latenz |
| TP+PP |
Kombination: Innerhalb jeder Pipeline-Stufe arbeiten mehrere GPUs tensorparallel. |
Komplexität, Speicherbalance |
| Expert Parallelism (EP) |
MoE-Experten werden über GPUs verteilt. Der Router schickt Tokens zu den jeweils benötigten Experten. |
All-to-All-Kommunikation |
| Data Parallelism (DP) |
Mehrere Modellreplikate bearbeiten unterschiedliche Requests parallel. Anders als TP teilt DP nicht einen einzelnen Layer zwischen den Replikaten. |
Zusätzlicher Gewichts- und Cache-Speicher |
| Layer Split |
llama.cpp verteilt ganze Layer auf GPUs. Flexibel für gemischte Karten, aber ein einzelnes Token durchläuft die Karten weitgehend nacheinander. |
Geringe aggregierte Bandbreitennutzung |
| Tensor Split |
Gewichte und Rechnungen innerhalb eines Layers werden über mehrere GPUs geteilt. |
Kommunikation nach vielen Layern |
| Graph Split |
Experimenteller ik_llama-Pfad, der Teile eines Rechengraphen innerhalb von Layern über mehrere GPUs verteilt. Nicht mit normalem vLLM-TP oder PP gleichsetzen. |
ik_llama, Tensor Split |
| Shard / Sharding |
Aufteilen von Gewichten, Cache oder Daten auf mehrere Geräte. |
Verteilte Kommunikation |
| Rank |
Laufender Prozess beziehungsweise Teilnehmer in einer verteilten GPU-Gruppe. Bei TP4 gibt es typischerweise vier Ranks. |
NCCL |
| Pipeline Stage |
Eine Stufe mit einer Gruppe von Layern. |
PP, Bubble |
| Pipeline Bubble |
Zeit, in der eine Pipeline-Stufe wartet, weil noch keine Arbeit angekommen ist oder eine andere Stufe langsamer ist. |
PP-Durchsatz |
| Homogene GPUs |
Gleiche oder sehr ähnliche GPUs. Das ist für TP und gemeinsame Kernel meist am einfachsten. |
TP |
| Mixed-GPU |
Unterschiedliche GPU-Modelle in einem Setup. Layer Split kann das oft besser als echtes TP. |
langsamste GPU, Kernel-Kompatibilität |
| Bottleneck |
Langsamste Komponente, die die Gesamtleistung begrenzt. Eine einzige langsame GPU kann einen ganzen TP-Verbund bremsen. |
PCIe, Pipeline |
7.2 Speicher auslagern
| Begriff |
Einfach erklärt |
Verwandt mit |
| Offloading |
Teile des Modells oder Caches werden aus dem VRAM in RAM oder auf andere Geräte verschoben. Das schafft Platz, kostet aber Transfers. |
CPU-Offload, PCIe |
| CPU-Offloading |
Gewichte oder Cache liegen teilweise im System-RAM und werden von CPU oder GPU bei Bedarf verarbeitet. |
RAM-Bandbreite |
| Expert-Offloading |
Bei MoE bleiben manche Experten im RAM, während Attention und andere Teile auf der GPU liegen. |
MoE, Expert Cache |
| Statisches Offloading |
Vor dem Start wird festgelegt, welche Layer oder Experten auf CPU und GPU liegen. |
llama.cpp, ik_llama |
| Dynamisches Offloading |
Zur Laufzeit werden gerade benötigte Teile nachgeladen oder gecacht. |
ktransformers, Expert Cache |
| Expert Cache |
Häufig benötigte „heiße“ Experten bleiben im VRAM; seltene „kalte“ Experten liegen im RAM. |
LRU, MoE |
| Hot / Cold Expert |
Häufig beziehungsweise selten vom Router ausgewählter Experte. |
Profiling, Expert Cache |
| LRU Cache |
Least Recently Used. Wenn Platz fehlt, wird der am längsten nicht benutzte Eintrag entfernt. |
Expert Cache, KV-Cache |
8. Request-Ablauf, Geschwindigkeit und Messwerte
8.1 Die zwei Hauptphasen
- Prompt senden
- Prefill: gesamten neuen Prompt einlesen und Cache aufbauen
- Erstes Antworttoken
- Decode: Antwort Token für Token fortsetzen
| Begriff |
Einfach erklärt |
Typische Metrik |
| Prefill / Prompt Evaluation |
Der Eingabetext wird parallel verarbeitet und der interne Cache aufgebaut. Lange kalte Prompts können hier viel Zeit kosten. |
Prompt tok/s, TTFT |
| Decode / Generation |
Das Modell erzeugt die Antwort nacheinander Token für Token. |
Decode tok/s, TPOT |
| TTFT |
Time To First Token. Wartezeit vom Request bis zum ersten Antworttoken. |
Reaktionsgefühl |
| TPOT |
Time Per Output Token. Durchschnittliche Zeit pro weiterem Token nach dem ersten. |
Decode-Speed |
| ITL |
Inter-Token Latency. Zeitabstand zwischen ausgegebenen Tokens. Ähnlich zu TPOT, oft feiner betrachtet. |
Streaming |
| tok/s |
Tokens pro Sekunde. Ohne Angabe von Phase, Kontext, Batch und Messmethode ist die Zahl wenig aussagekräftig. |
TG, Throughput |
| TG |
In der lokalen Dokumentation die reine Token-Generation beziehungsweise Decode-Rate. |
tok/s, TPOT |
| Prompt Throughput |
Wie viele Eingabetokens pro Sekunde im Prefill verarbeitet werden. |
Prefill |
| Output Throughput |
Wie viele Ausgabetokens der Server insgesamt pro Sekunde liefert. Bei mehreren Nutzern kann er steigen, während jeder einzelne langsamer wird. |
Batching |
| Latenz |
Wie lange ein einzelner Nutzer oder Request wartet. |
TTFT, TPOT |
| Durchsatz / Throughput |
Wie viel Arbeit das Gesamtsystem pro Zeit schafft. |
tok/s gesamt, QPS |
| QPS |
Queries Per Second. Anzahl Requests pro Sekunde. |
Serving-Last |
| Concurrency |
Zahl gleichzeitig aktiver Requests oder Sequenzen. |
max_num_seqs, Batching |
| Batch |
Mehrere Eingaben oder Tokens werden gemeinsam berechnet. Das nutzt die GPU besser, kann aber die Latenz pro Nutzer erhöhen. |
Continuous Batching |
| Batch Size |
Zahl gemeinsam verarbeiteter Sequenzen oder Tokens, je nach Kontext des Parameters. |
Throughput, VRAM |
| Microbatch / ubatch |
Kleiner Teil eines größeren Batches, der in einem Rechenschritt verarbeitet wird. |
Prefill, OOM |
| Sequence / Slot |
Aktiver Generationsverlauf mit eigenem Zustand oder Cache. llama.cpp spricht häufig von Slots. |
Parallelität, KV-Cache |
| Streaming |
Antwort wird stückweise geliefert, während sie entsteht. Ein Stream-Chunk ist nicht zwingend genau ein Token. |
TTFT, SSE |
| SSE |
Server-Sent Events. Häufiges HTTP-Format für gestreamte Antworten. |
Streaming |
| Cold Start |
Erster Start oder erster Request ohne warme Kernel, Graphen und Caches. |
JIT, Prefill |
| Warm Run |
Wiederholung nach Initialisierung oder Cache-Aufbau. Meist schneller als ein kalter Lauf. |
Benchmark |
| Cache Hit |
Benötigte Daten wurden im Cache gefunden und müssen nicht neu berechnet werden. |
Prefix-Caching |
| Cache Miss |
Passende Daten fehlen; die Runtime muss neu rechnen. |
Prefill |
| Context Compaction |
Client fasst alten Verlauf zusammen oder entfernt Teile, damit die Session ins Kontextfenster passt. Dabei können Details verloren gehen. |
Client-Limit |
finish_reason |
API-Angabe, warum die Ausgabe endete, etwa stop, length oder Tool-Call. |
Output-Budget, Abbruch |
8.2 Benchmarks und Qualitätsmetriken
| Begriff |
Einfach erklärt |
Misst grob |
| Perplexity / PPL |
Wie überrascht ein Modell von echtem Text ist. Niedriger ist meist besser, aber kleine Unterschiede sagen nicht alles über Agentenqualität. |
Sprachmodellverlust |
| HumanEval |
Kleine Programmieraufgaben mit Tests. |
Codegenerierung |
| MBPP |
Python-Programmieraufgaben für grundlegende Problemlösung. |
Codegenerierung |
| SWE-bench |
Reale Softwarefehler aus GitHub-Repositories müssen behoben werden. Ergebnis hängt auch stark vom Agenten-Harness ab. |
Repo-Coding |
| BFCL |
Berkeley Function Calling Leaderboard. |
Tool-/Function-Calling |
| MMLU |
Wissens- und Multiple-Choice-Aufgaben aus vielen Fachgebieten. |
Allgemeinwissen |
| RULER |
Testfamilie für tatsächliche Nutzung langer Kontexte. |
Retrieval und Long Context |
| Needle Test |
Eine versteckte Information muss aus langem Fülltext wiedergefunden werden. Ein einfacher Single-Needle-Test ist leichter als echtes Repo-Verständnis. |
Long Context |
| Pass@1 |
Anteil der Aufgaben, die beim ersten Versuch bestanden werden. |
Benchmark-Erfolg |
| E2E-Zeit |
Gesamtdauer inklusive Prefill, Decode, Tools, Netzwerk und Wartezeiten. |
Reale Nutzererfahrung |
9. Sampling: Wie das nächste Token ausgewählt wird
| Begriff |
Einfach erklärt |
Wirkung |
| Softmax |
Wandelt Logits in Wahrscheinlichkeiten um. |
Grundlage des Samplings |
| Greedy Decoding |
Immer das wahrscheinlichste Token nehmen. Reproduzierbar, aber nicht automatisch am besten. |
temperature=0 |
| Temperature |
Steuert Zufall und Verteilungsschärfe. Niedrig ist konservativer, hoch vielfältiger und riskanter. |
Sampling |
| Top-p |
Nur die wahrscheinlichsten Tokens berücksichtigen, deren gemeinsame Wahrscheinlichkeit den Wert p erreicht. |
Nucleus Sampling |
| Top-k |
Nur die k wahrscheinlichsten Tokens dürfen ausgewählt werden. Nicht mit Top-k-Experten verwechseln. |
Sampling |
| Min-p |
Tokens unter einer relativen Mindestwahrscheinlichkeit werden ausgeschlossen. |
Sampling |
| Repetition Penalty |
Macht kürzlich verwendete Tokens weniger attraktiv, um Wiederholungsschleifen zu reduzieren. |
Loops |
| Presence Penalty |
Bestraft Tokens, die bereits vorkamen, unabhängig von ihrer Häufigkeit. |
Themenvariation |
| Frequency Penalty |
Bestraft Tokens umso stärker, je häufiger sie schon vorkamen. |
Wiederholungen |
| Seed |
Startwert des Zufallszahlengenerators. Gleicher Seed hilft bei Reproduzierbarkeit, garantiert sie über andere Kernel oder Parallelpfade nicht immer. |
Benchmark |
| Deterministisch |
Gleiche Eingabe liefert unter gleichen Bedingungen dieselbe Ausgabe. Verteilte GPU- und Samplingpfade können kleine Abweichungen erzeugen. |
Seed, Greedy |
10. Spekulatives Decoding
10.1 Der Überbegriff
Spekulatives Decoding beschleunigt die Token-Erzeugung mit einem billigen
„Vorschreiber“. Dieser schlägt mehrere Tokens vor. Das volle Zielmodell prüft
den Block in einem gemeinsamen Schritt und übernimmt nur gültige Vorschläge.
- Spekulatives Decoding
- Ohne Lernmodell
- Modellinterner Drafter
- Gelernter Hilfs-Drafter
- Vorschlag
- Verifikation durch das Zielmodell
- Akzeptieren oder korrekt ersetzen
Die Grundidee ist mit einem schnellen Assistenten und einem gründlichen
Lektor vergleichbar. Der Assistent darf vorarbeiten, aber der Lektor hat das
letzte Wort.
10.2 Gemeinsame Begriffe
| Begriff |
Einfach erklärt |
Verwandt mit |
| Speculative Decoding / Spec Decode |
Überbegriff für Vorschlagen und anschließendes Prüfen mehrerer Tokens. |
Drafter, Target |
| Target Model / Zielmodell |
Das eigentliche große Modell. Seine Verteilung bestimmt letztlich die Ausgabe. |
Verify, Drafter |
| Drafter / Draft Model |
Schneller Hilfspfad, der Kandidatentokens vorschlägt. Er kann ein kleines Modell, ein Zusatzkopf oder ein Suchverfahren sein. |
MTP, EAGLE, DFlash |
| Draft Token |
Vom Drafter vorgeschlagenes Token, das noch nicht endgültig ist. |
Acceptance |
| Draft Block |
Mehrere auf einmal vorgeschlagene Tokens. |
Block Size, Verify |
| Verification / Verify |
Das Zielmodell bewertet die vorgeschlagenen Tokens. Abgelehnte Vorschläge werden nicht blind ausgegeben. |
Target Model |
| Verify Step |
Ein Zielmodell-Schritt, der einen ganzen Kandidatenblock prüft. Je mehr Tokens dabei akzeptiert werden, desto größer der mögliche Gewinn. |
Acceptance Length |
| Acceptance Rate |
Anteil der vorgeschlagenen Tokens, die das Zielmodell akzeptiert. |
Drafter-Qualität |
| Acceptance Length |
Durchschnittliche Zahl übernommener Tokens pro Verify-Schritt. Für Speed oft aussagekräftiger als nur die Prozentzahl. |
Tokens pro Step |
Draft Depth / n_max |
Maximale Anzahl vorgeschlagener Tokens. Zu tief kann trotz mehr Kandidaten langsamer sein, weil Draft und Verify teurer werden. |
Tuning |
| Block Size |
Zahl der Positionen, für die ein Block-Drafter trainiert oder ausgelegt ist. Sie ist methoden- und checkpointspezifisch. |
DFlash, DSpark |
p_min |
Vertrauensschwelle für Draft-Vorschläge. Höher kann schlechte Vorschläge vermeiden, aber auch den möglichen Block kürzen. |
Acceptance, Tuning |
| Rejection Sampling |
Mathematisches Verfahren, das bei probabilistischen Drafts die Zielverteilung korrekt erhält, obwohl Vorschläge von einem anderen Modell kommen. |
Lossless Speculation |
| Lossless / Exact Speculation |
Bedeutet: Die Zielverteilung soll durch das Verfahren unverändert bleiben. Es bedeutet nicht, dass jede Hardware bitgenau denselben Text liefert oder dass Spec Decode immer schneller ist. |
Rejection Sampling |
| Speculation Overhead |
Zusätzliche Zeit und Speicher für Drafter, Kandidaten, Cache und Verifikation. Bei niedriger Akzeptanz kann die Optimierung langsamer als normales Decode sein. |
Break-even |
| Draft-KV-Cache |
Eigener Cache des Drafters. Er kommt zum Cache des Zielmodells hinzu. |
VRAM, Context Window |
| Vokabular-Kompatibilität |
Drafter und Target müssen Kandidatentokens eindeutig gemeinsam verstehen oder eine explizite Abbildung besitzen. |
Tokenizer, EAGLE |
| Co-located |
Drafter und Target laufen auf derselben Maschine beziehungsweise nahe genug für sehr schnelle Verify-Schritte. Ein LAN-Roundtrip pro Tokenblock zerstört meist den Gewinn. |
Latenz |
10.3 Die Verfahren im Vergleich
| Verfahren |
Was ist der Drafter? |
Einfache Erklärung |
Voraussetzung |
| Generisches Draft-Modell |
Kleineres separates Sprachmodell |
Das kleine Modell schreibt vor, das große prüft nach. |
Passender Tokenizer und sehr schneller Draft-Pfad |
| n-gram / Prompt Lookup |
Suche im vorhandenen Kontext |
Wenn eine bekannte Tokenfolge wieder auftaucht, wird ihre frühere Fortsetzung vorgeschlagen. |
Wiederholungen oder Copy-lastige Ausgabe |
| Suffix Decoding |
Suche nach passenden Endstücken |
Nutzt bekannte Suffixe und deren Fortsetzungen als Kandidaten. |
Passende Historie |
| MTP |
Modell-eigene Zusatzköpfe oder Assistant-Layer |
Das Zielmodell wurde darauf trainiert, mehr als nur das unmittelbar nächste Token vorherzusagen. |
Native MTP-Unterstützung des Checkpoints und der Engine |
| EAGLE |
Kleines trainiertes Feature-Level-Draft-Modell |
Nutzt interne Modellmerkmale und vorherige Tokens, um mehrere plausible Fortsetzungen billig zu erzeugen. |
EAGLE-Checkpoint passend zur exakten Modellfamilie |
| DFlash |
Trainierter Block-Drafter |
Sagt einen ganzen Tokenblock parallel statt Token für Token voraus. |
Passender DFlash-Drafter und Runtime-Support |
| DSpark |
DeepSeek4-spezifischer blockweiser MTP-Drafter |
Erzeugt Kandidatenblöcke aus ausgewählten Ziel-Layern; das volle DeepSeek-Ziel prüft sie. |
Passender DSpark-Sidecar und DeepSeek4-Stack |
10.4 MTP
| Begriff |
Erklärung |
| MTP |
Multi-Token Prediction. Das Modell besitzt native Fähigkeiten oder Zusatzgewichte, um mehrere zukünftige Tokens vorzuschlagen. |
| MTP Head / NextN Head |
Kleiner Zusatzkopf, der auf internen Zuständen des Zielmodells aufsetzt und weitere Tokenpositionen vorhersagt. |
| Native MTP |
MTP-Gewichte gehören zum Modellrelease oder zu einem offiziell passenden Assistant-Checkpoint. Es wird kein beliebiges kleines Fremdmodell verwendet. |
| MTP Sidecar |
Separate Datei mit MTP-/Assistant-Gewichten. Sie gehört trotzdem zu genau einer passenden Modellfamilie und ist nicht beliebig austauschbar. |
| MTP-Training |
Das Modell lernt nicht nur Token t+1, sondern auch weitere zukünftige Tokens. Beim Serving kann diese Fähigkeit für Spec Decode genutzt werden. |
MTP ist nicht automatisch ein Speedup. Auf einem Single-GPU- oder
kommunikationsarmen Pfad kann es stark helfen. Bei TP über langsames PCIe kann
der zusätzliche Draft-/Verify-Austausch den Gewinn aufzehren.
10.5 EAGLE, EAGLE-2 und EAGLE-3
| Begriff |
Erklärung |
| EAGLE |
Extrapolation Algorithm for Greater Language-model Efficiency. Ein kleiner trainierter Drafter arbeitet auf internen Features des Zielmodells und erzeugt Kandidaten für spekulatives Decoding. |
| Feature-Level Drafting |
Der Drafter nutzt Hidden States statt nur fertiger Texttokens. Dadurch erhält er mehr Information als ein völlig unabhängiges kleines Sprachmodell. |
| EAGLE-2 |
Weiterentwicklung mit dynamischerer Organisation der Kandidaten. Die Runtime kann aussichtsreiche Draft-Pfade gezielter prüfen. |
| EAGLE-3 |
Neuere EAGLE-Generation, die Informationen aus mehreren Zielmodell-Layern nutzen kann. Sie benötigt einen eigens dafür trainierten Checkpoint und passenden Engine-Pfad. |
| EAGLE Tree |
Statt nur einer linearen Fortsetzung werden mehrere mögliche Kandidatenpfade vorgeschlagen und gemeinsam geprüft. |
Ein EAGLE-Checkpoint für Qwen3 ist nicht automatisch mit Qwen3.6, Llama
oder einer anderen Vokabular-/Architekturversion kompatibel.
10.6 DFlash und DFlash2
| Begriff |
Erklärung |
| DFlash |
Gelernter Block-Drafter für spekulatives Decoding. Er nutzt interne Zustände mehrerer Zielmodell-Layer und sagt mehrere Positionen in einem parallelen, nicht-autoregressiven Durchlauf voraus. |
| Nicht-autoregressiver Draft |
Die Draft-Positionen werden gemeinsam berechnet, statt dass jede Draft-Position erst auf die vorherige warten muss. Das reduziert die Draft-Latenz. |
| DFlash Block Drafter |
Kleines Zusatznetz mit modellabhängiger Layer- und Blockzahl. Lokale Beispiele verwenden unter anderem fünf Drafter-Layer; die Blockgröße ist nicht bei jedem Checkpoint gleich. |
| DFlash2 |
Weiterentwickelter DFlash-Pfad. In der lokalen Qwen3.8-Arbeit sagt ein fünfschichtiger Drafter sieben Tokens in einem Durchlauf voraus und wählt einen zusammenhängenden Pfad aus mehreren Kandidaten. |
| Selector |
Teil des DFlash-Drafters, der aus mehreren Kandidaten pro Position einen konsistenten Tokenpfad bildet. |
| Mask Token |
Platzhalter für Positionen, die ein paralleler Block-Drafter gleichzeitig vorhersagen soll. |
DFlash ist ein Methodenname, kein allgemeines Synonym für „schnelles
Decoding“. Ein DFlash-Drafter muss zur Modellfamilie, zu den erwarteten Hidden
States, zum Vokabular und zur Runtime passen.
10.7 DSpark
DSpark ist im lokalen Bestand der spezialisierte blockweise Drafter für
DeepSeek-V4-Flash. Er gehört zur MTP-/Speculative-Decoding-Ausführung des
DeepSeek4-Stacks.
| Eigenschaft |
Lokale Einordnung |
| Aufgabe |
Kandidatenblöcke vorschlagen |
| Autorität |
Das volle Q8-Zielmodell verifiziert; DSpark entscheidet nie allein über die finale Ausgabe |
| Lokaler Sidecar |
DeepSeek-V4-Flash-DSpark-support.gguf |
| Aufbau |
Drei Stufen, Blockgröße 5, Ziel-Layer 40 bis 42 |
| Engine-Pfad |
TensorSharp-DeepSeek4 mit MTP-Spec-Unterstützung |
DSpark darf nicht mit einem anderen DeepSeek-MTP-Sidecar verwechselt werden.
Dateien mit ähnlichem Zweck können unterschiedliche Architektur, Layerziele,
Blockgrößen und Runtime-Verträge haben.
10.8 n-gram und Prompt Lookup
| Begriff |
Erklärung |
| n-gram |
Folge aus n Tokens. Ein 8-gram besteht aus acht aufeinanderfolgenden Tokens. |
| Prompt Lookup |
Sucht die zuletzt erzeugte Tokenfolge im vorhandenen Prompt und schlägt vor, was dort danach kam. |
| Copy-lastiger Workload |
Ausgabe übernimmt viel bekannten Text, etwa Code umschreiben, Tabellen füllen oder Dokumentteile zitieren. Hier kann n-gram sehr stark sein. |
| Novel Output |
Wirklich neuer Text ohne passende Vorlage im Kontext. Hier ist n-gram meist weniger nützlich. |
n-gram braucht kein gelerntes Zusatzmodell und fast keinen zusätzlichen
Gewichtsspeicher. Es ergänzt MTP oder DFlash, weil es bei exakten Kopierstrecken
stark ist, während gelernte Drafter auch neue Fortsetzungen vorschlagen.
10.9 Warum Spec Decode manchmal langsamer ist
| Ursache |
Einfache Erklärung |
| Niedrige Akzeptanz |
Der Drafter arbeitet, aber das Ziel verwirft viele Vorschläge. |
| Zu großer Drafter |
Das Hilfsmodell kostet fast so viel Zeit wie die gesparte Zielmodellarbeit. |
| Zu tiefer Draft |
Mehr Vorschläge erhöhen Draft-, KV- und Verify-Kosten stärker als die Zahl akzeptierter Tokens. |
| Kurzer Kontext |
Der normale Zielmodellschritt ist bereits billig; der Zusatzaufwand lohnt nicht. |
| Langsame Multi-GPU-Kommunikation |
Draft und Verify lösen zusätzliche Synchronisation über PCIe aus. |
| Hohe Sampling-Zufälligkeit |
Kandidaten sind schwerer vorherzusagen, die Akzeptanz kann sinken. |
| Hohe QPS |
Continuous Batching lastet das Zielmodell schon gut aus; ein zusätzlicher Drafter kann Gesamtdurchsatz kosten. |
| Mehr Cachebedarf |
Draft-KV und Arbeitsbereiche verkleinern den möglichen Kontext oder die Concurrency. |
11. Long-Context- und Cache-Begriffe
| Begriff |
Einfach erklärt |
Verwandt mit |
| Long Context |
Sehr großes Kontextfenster, typischerweise 100k Tokens oder mehr. |
KV-Cache, RoPE |
| Aktiver Kontext |
Tokens, die im aktuellen Request wirklich belegt und beim Decode relevant sind. Ein Server mit 1M max ist bei einem 2k-Prompt nicht automatisch langsam. |
Decode-Speed |
| Kalter Kontext |
Der Prompt ist noch nicht im Cache und muss komplett prefillevaluiert werden. |
TTFT |
| Warmer Kontext |
Ein großer Teil des Prefix oder Zustands ist bereits vorhanden. |
Prefix-Caching |
| Retained Cache |
Ein abgeschlossener Sessionzustand bleibt für spätere Fortsetzung gespeichert. |
Multi-Session, RAM/VRAM |
| Prompt Cache |
Allgemeiner Begriff für gespeicherte Prompt-Zustände. Die genaue Semantik unterscheidet sich zwischen Engines. |
Prefix-Cache, KV-Cache |
| Context Checkpoint |
Gespeicherter Zwischenzustand, zu dem eine Runtime später zurückspringen kann. |
llama.cpp, RAM |
| Needle-in-a-Haystack |
Eine kleine Information wird in sehr viel irrelevanten Text eingebettet und später abgefragt. |
Long-Context-Test |
| Retrieval |
Wiederfinden relevanter Information aus Kontext oder Dokumentindex. |
RAG, Needle |
| Context Degradation |
Modell kann ein großes Fenster technisch verarbeiten, nutzt weit entfernte Informationen aber schlechter oder driftet bei langen Agentenläufen. |
YaRN, Benchmarks |
12. Qualitäts- und Fehlerbegriffe
| Begriff |
Einfach erklärt |
Verwandt mit |
| Quantization Degradation |
Qualitätsverlust durch zu grobe oder schlecht kalibrierte Zahlen. |
Outlier, Router |
| Router Degradation |
MoE-Router wählt wegen Quantisierungsfehlern weniger passende Experten. |
MoE, Smart Quant |
| Loop / Doom Loop |
Modell wiederholt Denken, Tools oder Text, ohne sinnvoll zum Ende zu kommen. |
Sampling, Template, Long Context |
| Instruction Loss |
Frühe Regeln oder Anforderungen werden im langen Verlauf nicht mehr zuverlässig beachtet. |
Kontext, Compaction |
| Reasoning Drift |
Der Denkprozess entfernt sich schrittweise von Aufgabe oder bereits geklärten Fakten. |
Long Context |
| Token Corruption |
Falsche Zahlen in Kernel, Cache oder Kommunikation führen zu kaputten Tokenentscheidungen. |
KV-Skala, P2P, Garbling |
| Silent Corruption |
System läuft und liefert Text, aber der Inhalt ist unbemerkt falsch. Gefährlicher als ein klarer Crash. |
Smoke-Test, Verifikation |
| Model Defect |
Fehler liegt in Verhalten oder Vokabular des Modells selbst und reproduziert über verschiedene Serving-Stacks. |
Struktur-Tokens |
| Runtime Bug |
Modellgewichte sind in Ordnung, aber Engine, Kernel, Parser oder Scheduler verarbeitet sie falsch. |
Version, Backend |
| Regression |
Eine neuere Version verhält sich schlechter als ein zuvor validierter Stand. |
A/B-Test, Version Pinning |
| A/B-Test |
Nur ein Faktor wird zwischen zwei Läufen geändert. So lässt sich eine Ursache besser zuordnen. |
Benchmark, Kontrolle |
| Control / Kontrolllauf |
Vergleichslauf ohne die untersuchte Optimierung. Für MTP wäre das etwa derselbe Build mit Speculation aus. |
A/B-Test |
| Reproduzierbarkeit |
Andere Läufe können unter dokumentierten Bedingungen dasselbe Ergebnis nachvollziehen. |
Seed, Version, Hardware |
13. Software-, Build- und Betriebsbegriffe
| Begriff |
Einfach erklärt |
Verwandt mit |
| Upstream |
Offizielles Hauptprojekt, von dem lokale Forks oder Patches abstammen. |
vLLM, llama.cpp |
| Fork |
Eigene Abzweigung eines Projekts mit zusätzlichen oder veränderten Funktionen. |
ik_llama, Patch |
| Patch |
Änderung an bestehendem Quellcode. |
Fork, Backport |
| Backport |
Neue Funktion wird auf eine ältere, sonst stabile Version übertragen. |
DFlash2, Runtime-Version |
| Commit |
Konkreter gespeicherter Quellcode-Stand. Für reproduzierbare Builds genauer als nur ein Versionsname. |
Git, Build |
| Build |
Aus Quellcode erzeugtes ausführbares Programm oder Container-Image. |
Compiler, CUDA |
| Nightly |
Automatisch erstellter sehr neuer Entwicklungsstand. Enthält aktuelle Funktionen, aber auch mehr Regressionsrisiko. |
vLLM, SGLang |
| Version Pinning |
Eine exakt validierte Version wird festgehalten, statt automatisch immer die neueste zu verwenden. |
Reproduzierbarkeit |
| Driver / GPU-Treiber |
Betriebssystemsoftware zwischen CUDA-Anwendung und GPU. Version und Open-/Proprietary-Variante können Low-Level-Verhalten verändern. |
CUDA, P2P |
| JIT Cache |
Gespeicherte bereits kompilierte Kernel. Nach Löschen oder Update ist der erste Start wieder langsamer. |
Triton, torch.compile |
| Restart Policy |
Docker-Regel, ob ein Container nach Prozess- oder Host-Neustart automatisch wieder startet. |
Healthcheck |
| Watchdog |
Externer Wächter, der einen ungesunden Dienst erkennt und neu startet oder alarmiert. |
Healthcheck |
| Runbook |
Schritt-für-Schritt-Betriebsanleitung mit konkreten Befehlen und Recovery. |
Modelldokumentation |
14. Die wichtigsten Verwechslungen auf einen Blick
| Nicht verwechseln |
Unterschied |
| Modell vs. Engine |
Qwen, DeepSeek oder Gemma sind Modelle; vLLM, SGLang und llama.cpp führen sie aus. |
| Checkpoint vs. Architektur |
Ein Checkpoint ist eine konkrete Gewichtsdatei; die Architektur beschreibt den Aufbau des Netzes. |
| Dateiformat vs. Quantisierung |
Safetensors/GGUF sind Container; BF16, GPTQ-INT4 oder Q4_K_M beschreiben Zahlen beziehungsweise Quantisierung. |
| Gewichts-FP8 vs. FP8-KV |
Das eine komprimiert das Modell, das andere den Kontextspeicher. |
| Gesamtparameter vs. aktive Parameter |
MoE muss alle Gewichte speichern, rechnet pro Token aber nur mit einem Teil davon. |
| Attention-Heads vs. KV-Heads |
Query-Heads stellen parallele Fragen; KV-Heads liefern die geteilten Schlüssel und Werte. |
| Kontextlimit vs. belegter Kontext |
max_model_len=1M ist die Obergrenze; die aktuelle Anfrage kann trotzdem nur 2k Tokens enthalten. |
| Technisch startbar vs. qualitativ nutzbar |
Ein Modell kann 1M Tokens allozieren, ohne bei 1M noch genauso gut zu verstehen. |
| TTFT vs. Decode tok/s |
TTFT ist Warten bis zum ersten Token; Decode tok/s ist Schreibgeschwindigkeit danach. |
| Latenz vs. Durchsatz |
Ein Nutzer will geringe Latenz; ein Serverbetreiber oft hohen Gesamtdurchsatz. Beides kann gegeneinander laufen. |
| TP vs. Layer Split |
TP teilt jeden Layer und rechnet parallel; Layer Split legt ganze Layer auf verschiedene GPUs. |
| MTP vs. generisches Draft-Modell |
MTP ist modellnativ oder modellnah; ein generisches Draft-Modell ist ein separates kleineres LLM. |
| EAGLE vs. DFlash |
Beides sind gelernte Drafter, aber mit unterschiedlicher Architektur und Checkpoint-Semantik. Sie sind nicht austauschbar. |
| DFlash vs. DSpark |
DFlash ist eine Block-Drafter-Familie; DSpark ist hier der DeepSeek4-spezifische blockweise Drafter im MTP-Pfad. |
| Lossless Spec Decode vs. immer gleicher Text |
Die Zielverteilung bleibt mathematisch erhalten; numerische Details, Seeds oder parallele Kernel können trotzdem nahe Entscheidungen anders treffen. |
| Healthcheck vs. korrekte Ausgabe |
HTTP 200 beweist Erreichbarkeit, nicht Intelligenz oder unverfälschte Tokens. |
| Mehr GPUs vs. mehr Speed |
Mehr GPUs geben mehr VRAM. Kommunikation, geringe aktive Parameter oder Pipeline-Bubbles können den Speedgewinn klein machen. |
15. Mini-Entscheidungshilfe
| Frage |
Zuerst auf diese Begriffe schauen |
| Passt das Modell in den Speicher? |
Gewichtsformat, VRAM, KV-Cache, Context Window, CUDA Graphs |
| Warum ist ein MoE trotz vieler Parameter schnell? |
Aktive Parameter, Router, Speicherbandbreite |
| Warum geht TP6 nicht? |
Attention-Heads, KV-Heads, Head-Teilbarkeit |
| Warum wird langer Kontext langsam? |
Prefill, aktiver KV-Cache, Full Attention, TTFT, TPOT |
| Warum hilft vLLM bei mehreren Nutzern? |
Continuous Batching, PagedAttention, Scheduler |
| Warum bringt Prefix-Caching so viel? |
stabiler Prompt-Prefix, Cache Hit, weniger Prefill |
| Warum ist das 4-Bit-Modell schlecht? |
Kalibrierung, Outlier, Router, Attention, Mixed Precision |
| Warum ist MTP nicht schneller? |
Acceptance Length, Speculation Overhead, TP-Kommunikation |
| Welche Spec-Methode gehört wohin? |
MTP modellintern; EAGLE/DFlash gelernte Drafter; DSpark DeepSeek4-spezifisch; n-gram kontextbasiert |
| Warum antwortet ein gesunder Server mit Müll? |
Chat-Template, Parser, KV-Skalen, Runtime-Bug, Quant, P2P |
Quellen und Vertiefung
Externe Grundlagen: