Comment je
mesure l'Arena.

9 tests · 2 outils · 1 GPU

Chaque modèle de l'arena passe les mêmes 9 benchmarks sur le même DGX Spark. 5 en closed-loop pour le throughput pur, 4 en open-loop pour le ressenti sous vraie concurrency. Ci-dessous : le pourquoi, le comment, et toutes les commandes une à une. Va avec le guide faire tourner des LLM sur le DGX Spark.

02 Pourquoi 9 benchmarks

Un seul benchmark n'est pas un benchmark. Un modèle qui fait 120 t/s sur une boucle vide peut s'effondrer à 14 t/s par user sous 32 requêtes simultanées. Et un modèle aux tokens/sec rapides peut avoir un TTFT de 4 secondes. Inutilisable pour le chat, parfait pour le batch.

Donc : mesure les deux. Le throughput en isolation (closed-loop) et le comportement sous pression (open-loop). Prompts courts, prompts longs, sorties courtes, sorties longues. C'est comme ça qu'on voit à quoi un modèle est vraiment adapté, pas seulement ce que prétendent les release notes.

benchmarks

runs · seed 42

±2%

run-to-run

03 Deux outils, deux questions

A closed-loop

llama-benchy

À quelle vitesse ce modèle génère-t-il quand personne d'autre n'est sur le canal ?

Closed-loop veut dire : dès qu'une requête se termine, j'envoie directement la suivante. Pas d'attente entre les requêtes, pas de pics de burst, juste du décodage pur. Résultat : tokens/sec par stream, avec un TTFT propre comme référence.

Idéal pour : un seul utilisateur, le batch processing, la complétion de code. Pas représentatif de : une app de chat avec beaucoup de sessions simultanées.

B open-loop

vllm bench serve

Comment tient-il sous X users simultanés qui ne s'attendent pas les uns les autres ?

L'open-loop génère des requêtes selon un processus de Poisson, indépendamment de ce que le serveur fait déjà. À un rate de 0.3 req/s, une nouvelle arrive en moyenne toutes les ~3 secondes, que la réponse précédente soit prête ou non. C'est à ça que ressemble la production.

Résultat : TTFT p50/p95 et tokens/sec par user sous charge. Je rapporte bien les chiffres de TTFT (au-delà de 2s ton app commence à sembler lente), mais ils n'éliminent aucun modèle du classement.

04 Les 9 benchmarks

Chaque carte ci-dessous décrit un benchmark : ce qu'il mesure, avec quels paramètres, et pourquoi ces chiffres sont choisis ainsi. Déplie "view command" pour la commande CLI exacte que je lance.

01 · llama-benchy closed-loop

Chat

Korte prompt, lang antwoord. De vorm die als normale chat moet aanvoelen, TTFT bepaalt of het "snappy" is.

pp (prompt) 1024 tg (gen) 1024 depth 0 concurrency 10 runs 3

De maatstaf voor "voelt het snappy aan?". Korte prompt vraagt weinig prefill, lange output stresst decode. Wat een gewone chat-message er voor de gebruiker uit ziet.

meet → tokens/sec · ttft p50

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model <your-model> \
  --pp 1024 \
  --tg 1024 \
  --depth 0 \
  --concurrency 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

02 · llama-benchy closed-loop

RAG · 8k context

Middelgrote context, een paar documentchunks met antwoord van normale lengte. Toont prefill-kosten zonder de muur te raken.

pp (prompt) 8192 tg (gen) 512 depth 0 concurrency 10 runs 3

8k context is wat een typische RAG-pipeline aanbiedt, 4–8 chunks van een paar honderd tokens elk. Hier wordt prefill voelbaar maar nog niet pijnlijk.

meet → tokens/sec · ttft p50

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model <your-model> \
  --pp 8192 \
  --tg 512 \
  --depth 0 \
  --concurrency 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

03 · llama-benchy closed-loop

Lange output / agents

Korte instructie, veel output. Code-generation, rapporten of gestructureerde agent-output. Stress-test voor decode throughput.

pp (prompt) 256 tg (gen) 4096 depth 0 concurrency 10 runs 3

Dit is waar pure decode-throughput telt. Code-generation, JSON-rapporten, agent traces. Korte instructie, urenlange output.

meet → tokens/sec · ttft p50

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model <your-model> \
  --pp 256 \
  --tg 4096 \
  --depth 0 \
  --concurrency 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

04 · llama-benchy closed-loop

Grote context · 25k

Stress-test met grote prompts. Niet per se chatmateriaal, wel exact waar de prefill-muur zichtbaar wordt en TTFT instort.

pp (prompt) 25000 tg (gen) 256 depth 0 concurrency 10 runs 3

Bij 25k tokens zie je waar het model zijn prefill-budget opmaakt. TTFT springt vaak van honderden ms naar seconden. Belangrijk om te weten waar de muur staat.

meet → tokens/sec · ttft p50

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model <your-model> \
  --pp 25000 \
  --tg 256 \
  --depth 0 \
  --concurrency 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

05 · llama-benchy closed-loop

Multi-turn · kantoorwerk

Vijf beurten per gesprek, tien gesprekken parallel. Dicht bij hoe een team dit echt gebruikt, met groeiende context per turn.

pp (prompt) 2048 tg (gen) 512 depth 4 concurrency 10 runs 3

Realistischer dan single-shot: context groeit per turn, prefix-cache moet werken. Belangrijke check voor agent-flows en conversational apps.

meet → tokens/sec · ttft p50

uvx llama-benchy \
  --base-url http://localhost:8000/v1 \
  --model <your-model> \
  --pp 2048 \
  --tg 512 \
  --depth 4 \
  --concurrency 10 \
  --runs 3 \
  --latency-mode generation \
  --format md

06 · vllm bench serve open-loop

Realistische kantoor-baseline

Random dataset · 4000 tokens in, 500 tokens uit · request-rate 0.3, burstiness 0.7. Een rustig kantoor.

dataset random rate (req/s) 0,30 burstiness 0,7 prompts 200

Een rustig kantoor: paar mensen tegelijk, gemiddelde lengte. Als dit instort heb je een ander probleem dan welk model. Baseline voor alle open-loop tests.

meet → ttft p50/p95 · per-user tps

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model <your-model> \
  --tokenizer <your-model> \
  --served-model-name <your-model> \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 200 \
  --request-rate 0,30 \
  --burstiness 0,7 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

07 · vllm bench serve open-loop

Echte gesprekken · ShareGPT

ShareGPT V3 · gemiddeld 228 tokens per turn · natuurlijk variërend per gesprek. Wat real users doen, niet een synthetische random distributie.

dataset sharegpt v3 rate (req/s) 0,30 burstiness 0,7 prompts 250

Synthetische distributies zijn geen vervanging voor echte data. ShareGPT V3 heeft de natuurlijke spreiding van echte gesprekken, kort, lang, code, prozaïsch.

meet → ttft p50/p95 · per-user tps

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model <your-model> \
  --tokenizer <your-model> \
  --served-model-name <your-model> \
  --dataset-name sharegpt \
  --dataset-path /tmp/ShareGPT_V3.json \
  --num-prompts 250 \
  --request-rate 0,30 \
  --burstiness 0,7 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

08 · vllm bench serve open-loop

Maandagochtend-piek

Random · 4000 in / 500 uit · request-rate 1.5 req/s, burstiness 1.0, max 25 parallel. Wanneer iedereen tegelijk inlogt, zien we de queue groeien?

dataset random rate (req/s) 1,50 burstiness 1,0 prompts 300 max parallel 25

De vraag waar iedereen bang voor is: wat als alle 25 gebruikers tegelijk inloggen? Burstiness 1.0 + max-concurrency 25 simuleert dat moment.

meet → ttft p95/p99 · queue depth

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model <your-model> \
  --tokenizer <your-model> \
  --served-model-name <your-model> \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 300 \
  --request-rate 1,50 \
  --burstiness 1,0 \
  --max-concurrency 25 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

09 · vllm bench serve open-loop

Reasoning workload

Lange chain-of-thought outputs · 1k in / 4k uit · trage rate (0.2 req/s) want elke request kost veel decode-budget. Test of TTFT stabiel blijft.

dataset random rate (req/s) 0,20 burstiness 1,0 prompts 50

Lange thinking-traces eten decode-budget. Trage rate (0.2 req/s) klinkt niet veel maar elke request kost 4k tokens output. Test of langlopende requests TTFT van nieuwe requests blijven blokkeren.

meet → ttft p50 · sustained tps

docker exec vllm-bench vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model <your-model> \
  --tokenizer <your-model> \
  --served-model-name <your-model> \
  --dataset-name random \
  --random-input-len 4000 \
  --random-output-len 500 \
  --random-range-ratio 0.9 \
  --num-prompts 50 \
  --request-rate 0,20 \
  --burstiness 1,0 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90,95,99 \
  --seed 42

05 Hardware & setup

GPU

NVIDIA DGX Spark

128 GB unified · GB10 Blackwell · NVFP4 natif

Server

vLLM 0.19 / 0.20

prefix caching off · async scheduling par env de profil

Quant

BF16 · FP8 · NVFP4

chaque modèle dans les précisions disponibles

Ubuntu 24.04

CUDA 13.0 · conteneur Docker par profil

Warmup

3 runs / chiffre

rapporté en mean ± stddev · seed 42

06 Reproductibilité

Toutes les commandes ci-dessus sont copiables-collables. Pas de flags cachés, pas de tweaks de dataset, pas de seed shopping.

Pour reproduire il te faut : un Spark (ou un GPU Blackwell comparable avec assez de VRAM pour les checkpoints), vLLM 0.19+, et les deux outils de benchmark. Les datasets de prompts sont des défauts vLLM standards : ShareGPT V3 pour l'open-loop, synthetic random pour les baselines.

Tu as un résultat différent ? C'est intéressant. Fais-moi signe. Surtout si tu utilises une autre plateforme : tout l'intérêt est de voir où Spark colle ou non avec d'autres setups.

✓ Seed fixe (42) sur tous les runs
✓ Version de vLLM identique par set de modèles
✓ 3 runs rapportés en mean ± stddev
✓ Chiffres à ±2% run-to-run
✓ Pas de prefix caching dans le profil par défaut
✓ Pas de latency gate : tous les modèles restent visibles, classement sur throughput + quality

Un modèle que tu
aimerais voir dans la suite ?

Envoie un lien huggingface ou une config vLLM. S'il tient sur Spark je le lance et je publie les chiffres, tout simplement, dans le même tableau.

→ Vers l'arena Envoie une suggestion

Comment jemesure l'Arena.

llama-benchy

vllm bench serve

Chat

RAG · 8k context

Lange output / agents

Grote context · 25k

Multi-turn · kantoorwerk

Realistische kantoor-baseline

Echte gesprekken · ShareGPT

Maandagochtend-piek

Reasoning workload

Un modèle que tuaimerais voir dans la suite ?

Comment je
mesure l'Arena.

Un modèle que tu
aimerais voir dans la suite ?