Decode, prefill et consommation électrique selon les niveaux de précision

Chaque déploiement LLM local a 2 vitesses qui comptent — et elles réagissent différemment au bouton de précision. Cette page explique pourquoi passer de FP16 à INT4 peut tripler votre vitesse de génération mais à peine modifier votre temps de traitement de prompt, et comment mesurer le compromis sur votre propre matériel.

Two speeds that matter

Le débit de decode est la vitesse à laquelle le modèle génère des tokens après avoir commencé à répondre, mesuré en tokens par seconde (tok/s). Il détermine la rapidité avec laquelle une réponse de chat ou une complétion de code apparaît à l’écran. La latence de prefill est le temps que le modèle prend pour traiter votre entrée avant de générer le 1er token, mesuré en millisecondes par token (ms/token). Elle détermine la pause entre appuyer sur Entrée et voir la sortie commencer à défiler. Différentes charges de travail privilégient différentes vitesses :

Workload	What matters most	Why
Interactive chat	Decode throughput	Short prompts, long replies — generation dominates
Document analysis	Prefill latency	Long prompts (10K+ tokens), short replies — input processing dominates
Coding agents	Both	Moderate prompts, long multi-turn output — you feel both
Batch processing	Total throughput	Decode and prefill both contribute to wall-clock time

Le temps jusqu’au premier token (TTFT) combine la latence de prefill avec tout délai de planification ou de file d’attente. Pour un seul utilisateur sur du matériel local, le TTFT est approximativement égal au temps de prefill. Sous charge concurrente, la mise en file d’attente s’ajoute au TTFT indépendamment.

What precision means for speed

La précision contrôle combien de bits représentent chaque poids dans le modèle. Moins de bits signifie des poids plus petits, ce qui change 2 choses : la quantité de mémoire que le modèle occupe et la quantité de données que le GPU lit par token.

Precision	Memory multiplier	Typical quality impact	Supported hardware
FP16 / BF16	1.0x (baseline)	None — full fidelity	All GPUs
FP8 (E4M3)	0.5x	<2% on modern models	Ada/Hopper/Blackwell (SM89+)
INT8 (W8A8)	0.5x	1-3% loss	Most GPUs with INT8 tensor cores
INT4 (W4A16, GPTQ, AWQ)	0.25x	2-5% loss	All GPUs (dequantized at runtime)
NVFP4	0.25x	1-3% loss	Blackwell / DGX Spark (SM121)

La colonne qualité est approximative. Les modèles plus récents entraînés avec du quantization-aware training (QAT) perdent moins de qualité à des précisions plus basses. Voir QAT concepts pour les détails.

How precision affects decode vs prefill differently

C’est l’idée clé : le decode et le prefill touchent différents goulots d’étranglement matériels, donc le même changement de précision les affecte de manière inégale.

Decode is memory-bandwidth-bound

Pendant le decode, le modèle génère 1 token à la fois. Pour chaque token, il lit la matrice de poids entière depuis la mémoire et effectue un petit amount de calcul par poids. Le GPU passe la plupart de son temps à attendre que les données arrivent de la mémoire, pas à faire des calculs. Des poids plus petits = moins de données à lire = decode plus rapide. L’accélération est approximativement proportionnelle à la réduction de mémoire :

FP16 → FP8 : ~1.8-2.0x decode speedup
FP16 → INT4 : ~2.5-3.5x decode speedup
FP16 → NVFP4 : ~2.5-3.0x decode speedup

Prefill is compute-bound

Pendant le prefill, le modèle traite tous les tokens d’entrée en parallèle. Il lit les poids une fois mais effectue une grande multiplication matricielle sur tous les tokens du prompt. Le GPU passe la plupart de son temps à faire des calculs, pas à attendre la mémoire. La quantification aide moins le prefill car le calcul est le goulot d’étranglement, pas les lectures de poids :

FP16 → FP8 : ~1.3-1.5x prefill speedup
FP16 → INT4 : ~1.2-1.5x prefill speedup
FP16 → NVFP4 : ~1.3-1.5x prefill speedup

Practical implication

Quand la précision diminue, le decode s’améliore plus vite que le prefill. À INT4, un modèle qui semblait lent en FP16 génère du texte rapidement mais fait toujours une pause notable sur les prompts longs. Cette asymétrie guide les recommandations ci-dessous par charge de travail.

Power draw across precision levels

Une précision plus basse réduit la consommation d’énergie pour 2 raisons : moins de lectures mémoire (l’accès mémoire domine le coût énergétique) et une arithmétique plus simple (une multiplication INT4 coûte moins cher qu’une multiplication FP16).

DGX Spark power envelope

La puce GB10 de DGX Spark a un TDP d’environ 40W partagé entre le CPU Grace et le GPU Blackwell. Voici les plages de puissance observées pendant l’inférence :

Precision	Idle power	Decode load	Prefill load
FP16	8-12W	30-38W	35-40W
FP8	8-12W	25-33W	30-38W
NVFP4	8-12W	22-30W	28-35W

Consumer GPU power expectations

GPU	FP16 decode load	INT4/FP8 decode load	Savings
RTX 4090 (450W TDP)	300-400W	200-300W	~25% less at INT4
Strix Halo (120W TDP)	80-110W	60-85W	~20% less at INT4

Cost of 24/7 serving

Pour un DGX Spark tournant en continu en charge de decode :

Precision	Avg power	Monthly kWh (approx)
FP16	34W	~24 kWh
FP8	29W	~21 kWh
NVFP4	26W	~19 kWh

Sur un GPU grand public comme le RTX 4090 à 10 heures/jour :

Precision	Avg power	Monthly kWh (approx)
FP16	350W	~105 kWh
FP8	250W	~75 kWh
INT4	200W	~60 kWh

Benchmark methodology

Lancez ces tests sur votre propre configuration pour voir comment la précision affecte votre modèle et votre matériel spécifiques.

Measure decode throughput

Générez un nombre fixe de tokens de sortie depuis un prompt court et mesurez les tokens par seconde.

# 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

Measure prefill latency

Mesurez le temps que le modèle prend pour produire son 1er token à différentes longueurs de prompt.

# 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

Notez le temps jusqu’au premier token (TTFT) depuis la sortie. Répétez à 512, 1024, 4096, et 8192 tokens d’entrée.

Measure power draw

# 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

What to report

Remplissez ce tableau pour chaque niveau de précision que vous testez :

Metric	FP16	FP8	INT4 / NVFP4
Decode (tok/s)
Prefill (ms/token, 4K prompt)
Prefill (ms/token, 16K prompt)
TTFT (s, 8K prompt)
Power at decode load (W)
Power idle (W)

Real-world decision table

Choisissez la ligne qui correspond à votre charge de travail principale :

Your use case	Prioritize	Recommended precision	Why
Interactive chatbot	Decode speed	Q4_K_M or FP8	Short prompts, long replies — decode dominates your experience
Document analysis	Prefill speed	FP16 or FP8	Long prompts (10K+ tokens) — prefill dominates latency
Laptop / battery operation	Power efficiency	INT4 (Q4_K_M, AWQ)	Smallest memory footprint, lowest power draw
Multi-user serving	Both	FP8 with batching	Balance quality and throughput; FP8 KV cache doubles concurrency
Maximum output quality	Quality only	FP16 / BF16	Accept higher memory and power cost for zero quantization loss
DGX Spark deployment	Decode + memory fit	NVFP4	Native SM121 support, 75% size reduction, fits large models in 128GB

Why not always use INT4?

La quantification INT4 (GPTQ, AWQ, Q4_K_M) réduit la qualité de manière notable sur les modèles plus petits et les tâches de suivi d’instructions. Sur les modèles de moins de 13B paramètres, l’écart de qualité entre FP16 et INT4 peut dégrader la sortie. Sur les modèles 70B+, l’écart se réduit car le modèle a plus de capacité pour absorber le bruit de quantification. Testez votre modèle spécifique avant de vous engager.

Does KV cache precision affect these numbers?

Oui. Le cache KV FP8 (défini avec --kv-cache-dtype fp8 dans vLLM) réduit de moitié la mémoire du cache KV indépendamment de la quantification des poids. Il a un impact minimal sur la vitesse de decode mais vous permet de faire tenir des contextes plus longs ou plus d’utilisateurs simultanés. Voir DGX Spark memory tuning pour les tableaux de dimensionnement.

How does context length change decode speed?

Le decode lit le cache KV entier à chaque token. Les conversations plus longues construisent des caches plus grands, donc le decode ralentit à mesure que le contexte grandit. Un modèle à 4K de contexte peut générer à 40 tok/s mais chuter à 25 tok/s à 32K de contexte sur le même matériel. Voir KV cache and context pour la mécanique.

Quick benchmark commands

Utilisez-les comme points de départ pour comparer les précisions sur un seul modèle.

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 affiche un tableau de comparaison montrant les vitesses de traitement de prompt (pp) et de génération de texte (tg) côte à côte.

Ollama built-in 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

Compare across precisions

Lancez le même prompt à chaque précision et notez les résultats dans un tableau :

Precision	pp (ms/token)	tg (tok/s)	Memory (GB)
FP16
FP8
Q4_K_M

Pour des résultats les plus reproductibles, réchauffez le modèle avec 1 requête avant de mesurer, fermez les autres charges de travail GPU, et lancez au moins 3 répétitions. Rapportez la valeur médiane.

Next steps

DGX Spark memory tuning

Dimensionnement du cache KV, compromis de lots et paramètres d’ajustement pour 128GB de mémoire unifiée.

vLLM on DGX Spark

Installation, configuration NVFP4 et commandes de lancement optimales.

Test your deployment

Tests de bout en bout via Tokios — latence, streaming et comparaison de clients.

Quantization concepts

Explication approfondie de GPTQ, AWQ, GGUF et des compromis de quantification.

Matériel et compatibilité

Servir et connecter votre runtime

Connecter un client ou une app

Comparer

Decode, prefill et consommation électrique selon les niveaux de précision

Two speeds that matter

What precision means for speed

How precision affects decode vs prefill differently

Decode is memory-bandwidth-bound

Prefill is compute-bound

Practical implication

Power draw across precision levels

DGX Spark power envelope

Consumer GPU power expectations

Cost of 24/7 serving

Benchmark methodology

Measure decode throughput

Measure prefill latency

Measure power draw

What to report

Real-world decision table

Quick benchmark commands

vLLM benchmark suite

llama.cpp benchmark

Ollama built-in evaluation

Compare across precisions

Next steps

DGX Spark memory tuning

vLLM on DGX Spark

Test your deployment

Quantization concepts

​Two speeds that matter

​What precision means for speed

​How precision affects decode vs prefill differently

​Decode is memory-bandwidth-bound

​Prefill is compute-bound

​Practical implication

​Power draw across precision levels

​DGX Spark power envelope

​Consumer GPU power expectations

​Cost of 24/7 serving

​Benchmark methodology

​Measure decode throughput

​Measure prefill latency

​Measure power draw

​What to report

​Real-world decision table

​Quick benchmark commands

​vLLM benchmark suite

​llama.cpp benchmark

​Ollama built-in evaluation

​Compare across precisions

​Next steps

DGX Spark memory tuning

vLLM on DGX Spark

Test your deployment

Quantization concepts

Two speeds that matter

What precision means for speed

How precision affects decode vs prefill differently

Decode is memory-bandwidth-bound

Prefill is compute-bound

Practical implication

Power draw across precision levels

DGX Spark power envelope

Consumer GPU power expectations

Cost of 24/7 serving

Benchmark methodology

Measure decode throughput

Measure prefill latency

Measure power draw

What to report

Real-world decision table

Quick benchmark commands

vLLM benchmark suite

llama.cpp benchmark

Ollama built-in evaluation

Compare across precisions

Next steps