Decode, Prefill und Leistungsaufnahme über verschiedene Präzisionsstufen

Jedes lokale LLM-Deployment hat 2 Geschwindigkeiten, die zaehlen – und sie reagieren unterschiedlich auf den Praezisionsregler. Diese Seite erklaert, warum ein Wechsel von FP16 zu INT4 Ihre Generierungsgeschwindigkeit verdreifachen kann, Ihre Prompt-Verarbeitungszeit aber kaum beeinflusst, und wie Sie den Kompromiss auf Ihrer eigenen Hardware messen.

Zwei wichtige Geschwindigkeiten

Decode-Durchsatz ist, wie schnell das Modell Tokens generiert, nachdem es mit der Antwort begonnen hat, gemessen in Tokens pro Sekunde (tok/s). Er bestimmt, wie schnell eine Chat-Antwort oder Code-Vervollständigung auf dem Bildschirm erscheint. Prefill-Latenz ist, wie lange das Modell braucht, um Ihre Eingabe zu verarbeiten, bevor es das 1. Token generiert, gemessen in Millisekunden pro Token (ms/token). Sie bestimmt die Pause zwischen dem Druecken der Eingabetaste und dem Beginn des Streaming-Outputs. Verschiedene Workloads legen Wert auf unterschiedliche Geschwindigkeiten:

Workload	Was am wichtigsten ist	Warum
Interaktiver Chat	Decode-Durchsatz	Kurze Prompts, lange Antworten – Generierung dominiert
Dokumentenanalyse	Prefill-Latenz	Lange Prompts (10K+ Tokens), kurze Antworten – Eingabeverarbeitung dominiert
Coding Agents	Beide	Moderate Prompts, lange Multi-Turn-Ausgaben – Sie spueren beides
Batch-Verarbeitung	Gesamtdurchsatz	Decode und Prefill tragen beide zur Echtzeit bei

Time-to-first-token (TTFT) kombiniert Prefill-Latenz mit eventueller Planungs- oder Warteschlangenverzoegerung. Fuer einen einzelnen Benutzer auf lokaler Hardware ist TTFT ungefaehr gleich der Prefill-Zeit. Unter gleichzeitiger Last addiert sich Queuing unabhaengig zu TTFT.

Was Praezision fuer die Geschwindigkeit bedeutet

Praezision steuert, wie viele Bits jedes Gewicht im Modell repraesentieren. Weniger Bits bedeuten kleinere Gewichte, was 2 Dinge aendert: wie viel Speicher das Modell belegt und wie viele Daten die GPU pro Token liest.

Praezision	Speicher-Multiplikator	Typische Qualitätsauswirkung	Unterstuetzte Hardware
FP16 / BF16	1.0x (Basis)	Keine – volle Treue	Alle GPUs
FP8 (E4M3)	0.5x	<2% bei modernen Modellen	Ada/Hopper/Blackwell (SM89+)
INT8 (W8A8)	0.5x	1-3% Verlust	Die meisten GPUs mit INT8-Tensor-Kernen
INT4 (W4A16, GPTQ, AWQ)	0.25x	2-5% Verlust	Alle GPUs (zur Laufzeit dequantisiert)
NVFP4	0.25x	1-3% Verlust	Blackwell / DGX Spark (SM121)

Die Qualitaetsspalte ist ungefaehr. Neuere Modelle, die mit Quantization-Aware Training (QAT) trainiert wurden, verlieren bei niedrigeren Praezisionen weniger Qualitaet. Siehe QAT-Konzepte fuer Details.

Wie sich Praezision unterschiedlich auf Decode vs. Prefill auswirkt

Dies ist der Schlüsselerkenntnis: Decode und Prefill stossen auf unterschiedliche Hardware-Flaschenhaelse, daher wirkt sich dieselbe Praezisionsaenderung ungleich auf sie aus.

Decode ist durch Speicherbandbreite begrenzt

Waehrend des Decodes generiert das Modell 1 Token nach dem anderen. Fuer jedes Token liest es die gesamte Gewichtsmatrix aus dem Speicher und fuehrt eine geringe Menge an Berechnungen pro Gewicht durch. Die GPU verbringt die meiste Zeit damit, auf Daten aus dem Speicher zu warten, nicht mit Mathematik. Kleinere Gewichte = weniger zu lesende Daten = schnellerer Decode. Die Beschleunigung ist ungefaehr proportional zur Speicherreduzierung:

FP16 → FP8: ~1.8-2.0x Decode-Beschleunigung
FP16 → INT4: ~2.5-3.5x Decode-Beschleunigung
FP16 → NVFP4: ~2.5-3.0x Decode-Beschleunigung

Prefill ist durch Rechenleistung begrenzt

Waehrend des Prefills verarbeitet das Modell alle Eingabe-Tokens parallel. Es liest die Gewichte einmal, fuehrt aber eine grosse Matrixmultiplikation ueber alle Prompt-Tokens durch. Die GPU verbringt die meiste Zeit mit Mathematik, nicht mit dem Warten auf Speicher. Quantisierung hilft dem Prefill weniger, da die Mathematik der Flaschenhals ist, nicht das Lesen der Gewichte:

FP16 → FP8: ~1.3-1.5x Prefill-Beschleunigung
FP16 → INT4: ~1.2-1.5x Prefill-Beschleunigung
FP16 → NVFP4: ~1.3-1.5x Prefill-Beschleunigung

Praktische Auswirkung

Je niedriger die Praezision, desto schneller verbessert sich Decode im Vergleich zu Prefill. Bei INT4 generiert ein Modell, das bei FP16 traege wirkte, Text schnell, pausiert aber bei langen Prompts immer noch merklich. Diese Asymmetrie treibt die unten aufgeführten, workload-spezifischen Empfehlungen an.

Stromverbrauch nach Praezisionsstufen

Niedrigere Praezision reduziert den Stromverbrauch aus 2 Gruenden: weniger Speicherzugriffe (Speicherzugriff dominiert die Energiekosten) und einfachere Arithmetik (INT4-Multiplikation kostet weniger als FP16-Multiplikation).

DGX Spark-Stromenveloppe

Der GB10-Chip von DGX Spark hat eine ~40W TDP, die zwischen Grace-CPU und Blackwell-GPU geteilt wird. Hier sind beobachtete Stromverbrauchsbereiche waehrend der Inferenz:

Praezision	Leerlauf-Stromverbrauch	Decode-Last	Prefill-Last
FP16	8-12W	30-38W	35-40W
FP8	8-12W	25-33W	30-38W
NVFP4	8-12W	22-30W	28-35W

Consumer-GPU-Stromerwartungen

GPU	FP16 Decode-Last	INT4/FP8 Decode-Last	Einsparungen
RTX 4090 (450W TDP)	300-400W	200-300W	~25% weniger bei INT4
Strix Halo (120W TDP)	80-110W	60-85W	~20% weniger bei INT4

Kosten fuer 24/7-Betrieb

Fuer einen DGX Spark, der kontinuierlich unter Decode-Last laeuft:

Praezision	Durchschnittlicher Stromverbrauch	Monatliche kWh (ca.)
FP16	34W	~24 kWh
FP8	29W	~21 kWh
NVFP4	26W	~19 kWh

Auf einer Consumer-GPU wie der RTX 4090 bei 10 Stunden/Tag:

Praezision	Durchschnittlicher Stromverbrauch	Monatliche kWh (ca.)
FP16	350W	~105 kWh
FP8	250W	~75 kWh
INT4	200W	~60 kWh

Benchmark-Methodik

Fuehren Sie diese Tests auf Ihrem eigenen Setup durch, um zu sehen, wie sich Praezision auf Ihr spezifisches Modell und Ihre Hardware auswirkt.

Decode-Durchsatz messen

Generieren Sie eine feste Anzahl von Ausgabe-Tokens aus einem kurzen Prompt und messen Sie Tokens pro Sekunde.

# Start the server first
vllm serve <model> --quantization <precision> --max-model-len 8192

# In another terminal
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 5 \
  --request-rate 1 \
  --max-input-len 128 \
  --max-output-len 256

./llama-bench \
  -m <model>.gguf \
  -p 512 \
  -n 128 \
  -ngl 99 \
  --repetitions 3

ollama run <model> --verbose "Write a short paragraph about inference speed."
# The --verbose flag prints eval rate in tok/s

Prefill-Latenz messen

Messen Sie, wie lange das Modell braucht, um sein 1. Token bei variierenden Prompt-Laengen zu produzieren.

# vLLM — vary --max-input-len to test prefill at different prompt sizes
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 3 \
  --request-rate 1 \
  --max-input-len 2048 \
  --max-output-len 1

Notieren Sie Time-to-first-token (TTFT) aus der Ausgabe. Wiederholen Sie bei 512, 1024, 4096 und 8192 Eingabe-Tokens.

Stromverbrauch messen

# Sample power every second during inference
watch -n 1 nvidia-smi --query-gpu=power.draw,power.limit --format=csv

# Reports SoC power on Grace/Blackwell
tegrastats --interval 1000

Was zu berichten ist

Fuellen Sie diese Tabelle fuer jede Praezisionsstufe aus, die Sie testen:

Metrik	FP16	FP8	INT4 / NVFP4
Decode (tok/s)
Prefill (ms/token, 4K Prompt)
Prefill (ms/token, 16K Prompt)
TTFT (s, 8K Prompt)
Stromverbrauch bei Decode-Last (W)
Stromverbrauch im Leerlauf (W)

Entscheidungs-Tabelle fuer die Praxis

Waehlen Sie die Zeile, die zu Ihrem primaeren Workload passt:

Ihr Anwendungsfall	Priorisieren	Empfohlene Praezision	Warum
Interaktiver Chatbot	Decode-Geschwindigkeit	Q4_K_M oder FP8	Kurze Prompts, lange Antworten – Decode dominiert Ihr Erlebnis
Dokumentenanalyse	Prefill-Geschwindigkeit	FP16 oder FP8	Lange Prompts (10K+ Tokens) – Prefill dominiert die Latenz
Laptop / Batteriebetrieb	Stromeffizienz	INT4 (Q4_K_M, AWQ)	Kleinster Speicherbedarf, niedrigster Stromverbrauch
Multi-User-Betrieb	Beide	FP8 mit Batching	Balance zwischen Qualitaet und Durchsatz; FP8 KV-Cache verdoppelt die Parallelitaet
Maximale Ausgabequalitaet	Nur Qualitaet	FP16 / BF16	Akzeptieren Sie hoechere Speicher- und Stromkosten fuer keinen Quantisierungsverlust
DGX Spark Deployment	Decode + Speicher-Fit	NVFP4	Native SM121-Unterstuetzung, 75% Groessenreduzierung, passt grosse Modelle in 128GB

Warum nicht immer INT4 verwenden?

INT4-Quantisierung (GPTQ, AWQ, Q4_K_M) reduziert die Qualitaet bei kleineren Modellen und Instruction-Following-Aufgaben merklich. Bei Modellen unter 13B Parametern kann die Qualitaetsluecke zwischen FP16 und INT4 die Ausgabe verschlechtern. Bei 70B+ Modellen verengt sich die Luecke, da das Modell mehr Kapazitaet hat, Quantisierungsrauschen zu absorbieren. Testen Sie Ihr spezifisches Modell, bevor Sie sich entscheiden.

Beeinflusst die KV-Cache-Praezision diese Zahlen?

Ja. FP8 KV-Cache (eingestellt mit --kv-cache-dtype fp8 in vLLM) halbiert den KV-Cache-Speicher unabhaengig von der Gewichtsquantisierung. Er hat minimalen Einfluss auf die Decode-Geschwindigkeit, ermoeglicht aber laengere Kontexte oder mehr gleichzeitige Benutzer. Siehe DGX Spark memory tuning fuer Groessentabellen.

Wie aendert die Kontextlaenge die Decode-Geschwindigkeit?

Decode liest den gesamten KV-Cache bei jedem Token. Laengere Konversationen bauen groessere Caches auf, daher verlangsamt sich der Decode, wenn der Kontext waechst. Ein Modell bei 4K Kontext kann mit 40 tok/s generieren, aber auf derselben Hardware auf 25 tok/s bei 32K Kontext fallen. Siehe KV-Cache und Kontext fuer die Mechanik.

Schnelle Benchmark-Befehle

Verwenden Sie diese als Ausgangspunkte, um Praezisionen auf einem einzelnen Modell zu vergleichen.

vLLM-Benchmark-Suite

# Launch with a specific quantization
vllm serve <model> --quantization fp8 --max-model-len 8192

# Run the built-in benchmark
python -m vllm.benchmarks.benchmark_serving \
  --model <model> \
  --num-prompts 10 \
  --request-rate 2 \
  --max-input-len 1024 \
  --max-output-len 128

# Repeat with --quantization nvfp4, then compare results

llama.cpp-Benchmark

# FP16 baseline
./llama-bench -m model-f16.gguf -p 512 -n 128 -ngl 99

# Q4_K_M quantized
./llama-bench -m model-q4_k_m.gguf -p 512 -n 128 -ngl 99

# Q8_0 for comparison
./llama-bench -m model-q8_0.gguf -p 512 -n 128 -ngl 99

llama.cpp gibt eine Vergleichstabelle aus, die Prompt-Verarbeitung (pp) und Textgenerierung (tg) Geschwindigkeiten nebeneinander zeigt.

Ollama integrierte Evaluation

# Run with verbose output to see eval speed
ollama run <model> --verbose "Summarize the theory of general relativity in 3 sentences."

# The output includes:
# eval count:   42 generation(s)
# eval duration: 1.8s
# eval rate:    23.3 tokens/s

Vergleich ueber Praezisionen hinweg

Fuehren Sie denselben Prompt bei jeder Praezision aus und notieren Sie die Ergebnisse in einer Tabelle:

Praezision	pp (ms/token)	tg (tok/s)	Speicher (GB)
FP16
FP8
Q4_K_M

Fuer die reproduzierbarsten Ergebnisse waermen Sie das Modell mit 1 Anfrage auf, bevor Sie messen, schliessen Sie andere GPU-Workloads und fuehren Sie mindestens 3 Wiederholungen durch. Berichten Sie den Medianwert.

Naechste Schritte

DGX Spark memory tuning

KV-Cache-Groesse, Batch-Kompromisse und Tuning-Parameter fuer 128GB Unified Memory.

vLLM auf DGX Spark

Installation, NVFP4-Konfiguration und optimale Startbefehle.

Ihr Deployment testen

End-to-End-Tests ueber Tokios – Latenz, Streaming und Client-Vergleich.

Quantisierungskonzepte

Tiefere Erklaerung von GPTQ, AWQ, GGUF und Quantisierungs-Kompromissen.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Decode, Prefill und Leistungsaufnahme über verschiedene Präzisionsstufen

Zwei wichtige Geschwindigkeiten

Was Praezision fuer die Geschwindigkeit bedeutet

Wie sich Praezision unterschiedlich auf Decode vs. Prefill auswirkt

Decode ist durch Speicherbandbreite begrenzt

Prefill ist durch Rechenleistung begrenzt

Praktische Auswirkung

Stromverbrauch nach Praezisionsstufen

DGX Spark-Stromenveloppe

Consumer-GPU-Stromerwartungen

Kosten fuer 24/7-Betrieb

Benchmark-Methodik

Decode-Durchsatz messen

Prefill-Latenz messen

Stromverbrauch messen

Was zu berichten ist

Entscheidungs-Tabelle fuer die Praxis

Schnelle Benchmark-Befehle

vLLM-Benchmark-Suite

llama.cpp-Benchmark

Ollama integrierte Evaluation

Vergleich ueber Praezisionen hinweg

Naechste Schritte

DGX Spark memory tuning

vLLM auf DGX Spark

Ihr Deployment testen

Quantisierungskonzepte

​Zwei wichtige Geschwindigkeiten

​Was Praezision fuer die Geschwindigkeit bedeutet

​Wie sich Praezision unterschiedlich auf Decode vs. Prefill auswirkt

​Decode ist durch Speicherbandbreite begrenzt

​Prefill ist durch Rechenleistung begrenzt

​Praktische Auswirkung

​Stromverbrauch nach Praezisionsstufen

​DGX Spark-Stromenveloppe

​Consumer-GPU-Stromerwartungen

​Kosten fuer 24/7-Betrieb

​Benchmark-Methodik

​Decode-Durchsatz messen

​Prefill-Latenz messen

​Stromverbrauch messen

​Was zu berichten ist

​Entscheidungs-Tabelle fuer die Praxis

​Schnelle Benchmark-Befehle

​vLLM-Benchmark-Suite

​llama.cpp-Benchmark

​Ollama integrierte Evaluation

​Vergleich ueber Praezisionen hinweg

​Naechste Schritte

DGX Spark memory tuning

vLLM auf DGX Spark

Ihr Deployment testen

Quantisierungskonzepte

Zwei wichtige Geschwindigkeiten

Was Praezision fuer die Geschwindigkeit bedeutet

Wie sich Praezision unterschiedlich auf Decode vs. Prefill auswirkt

Decode ist durch Speicherbandbreite begrenzt

Prefill ist durch Rechenleistung begrenzt

Praktische Auswirkung

Stromverbrauch nach Praezisionsstufen

DGX Spark-Stromenveloppe

Consumer-GPU-Stromerwartungen

Kosten fuer 24/7-Betrieb

Benchmark-Methodik

Decode-Durchsatz messen

Prefill-Latenz messen

Stromverbrauch messen

Was zu berichten ist

Entscheidungs-Tabelle fuer die Praxis

Schnelle Benchmark-Befehle

vLLM-Benchmark-Suite

llama.cpp-Benchmark

Ollama integrierte Evaluation

Vergleich ueber Praezisionen hinweg

Naechste Schritte