La suite définit les mêmes 11 benchmarks pour chaque modèle sur le même DGX Spark : 6 tests closed-loop pour le débit contrôlé et 5 tests open-loop pour le comportement sous charge. Chaque exécution indique les tests complets, interrompus ou sans données. Complète le guide Faire tourner des LLMs sur DGX Spark.
Une seule mesure de vitesse ne montre pas comment un modèle réagit à une autre charge. Un modèle avec un débit élevé tokens/sec sur un stream peut fortement ralentir sous vingt requêtes simultanées. Un autre peut garder son throughput tout en faisant attendre le premier token. Correct pour le batch, frustrant pour le chat.
Je mesure donc le débit avec une concurrence fixe (closed-loop) et des requêtes arrivant indépendamment (open-loop). Je fais aussi varier la longueur des prompts et des réponses pour observer la vitesse et la latence selon le scénario.
Comment le throughput évolue-t-il avec un nombre fixe de streams simultanés ?
Le closed-loop garde une requête active par stream : la suivante démarre dès que la précédente se termine. La suite teste des niveaux de concurrency fixes de 1 à 20. Chaque cellule tourne trois fois et est publiée en mean ± stddev.
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.
Comment tient-il sous X users simultanés qui ne s'attendent pas les uns les autres ?
L'open-loop planifie les arrivées indépendamment de la charge déjà présente. Le request rate et la burstiness définissent le motif ; à 0,3 req/s, l'intervalle moyen est d'environ 3,3 secondes. Le générateur utilise la seed 42 pour rendre la charge reproductible.
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. Un test open-loop ne compte que si au moins 99 % des requêtes réussissent.
Chaque carte vient directement du contrat de benchmark versionné. Déplie "view command" pour le modèle de commande reproductible et remplace ORG/MODEL et SERVED_MODEL_NAME. Les pages modèle remplissent ces valeurs depuis les métadonnées du run.
Invite courte, réponse longue. La forme qui doit ressembler à une conversation normale ; le TTFT décide si cela paraît réactif.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 1024 \
--tg 1024 \
--depth 0 \
--concurrency 1 5 10 \
--runs 3 \
--latency-mode generation \
--format mdContexte moyen, quelques fragments de documents avec une réponse de longueur normale. Montre le coût du préremplissage sans heurter le mur.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 8192 \
--tg 512 \
--depth 0 \
--concurrency 5 10 20 \
--runs 3 \
--latency-mode generation \
--format mdInstruction courte, beaucoup de sortie. Génération de code, rapports ou sorties structurées d'agents. Test de résistance du débit de décodage.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 256 \
--tg 4096 \
--depth 0 \
--concurrency 1 5 10 \
--runs 3 \
--latency-mode generation \
--format mdCinq tours par conversation, dix conversations en parallèle. Proche de l'usage réel d'une équipe, avec un contexte qui grandit à chaque tour.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 2048 \
--tg 512 \
--depth 4 \
--concurrency 1 5 10 \
--runs 3 \
--latency-mode generation \
--format mdTest de résistance avec de grandes invites. Pas forcément du matériel de chat, mais exactement là où le mur du préremplissage apparaît et où le TTFT s'effondre.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 4096 8192 16384 25000 \
--tg 256 \
--depth 0 \
--concurrency 1 5 10 \
--runs 3 \
--latency-mode generation \
--format mdContexte de 25k avec vingt requêtes simultanées. Cinq et dix sont déjà couverts par le test 05 ; vingt montre où l'ordonnanceur abandonne.
tokens/sec · ttft p50
uvx llama-benchy==0.4.0 \
--base-url http://localhost:8000/v1 \
--model SERVED_MODEL_NAME \
--pp 25000 \
--tg 256 \
--depth 0 \
--concurrency 20 \
--runs 3 \
--latency-mode generation \
--format mdJeu de données aléatoire, 4000 tokens en entrée et 500 en sortie, taux d'arrivée 0,3 avec une irrégularité de 0,7. Un bureau tranquille.
ttft p50/p95 · tokens/sec par utilisateur
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 200 \
--request-rate 0.3 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 07-office-baseline.jsonShareGPT V3, en moyenne 228 tokens par tour, variant naturellement selon la conversation. Ce que font les vrais utilisateurs, pas une distribution synthétique.
ttft p50/p95 · tokens/sec par utilisateur
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name sharegpt \
--dataset-path /tmp/ShareGPT_V3.json \
--num-prompts 250 \
--request-rate 0.3 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 08-sharegpt.jsonLongues chaînes de pensée, 1k en entrée et 4k en sortie, taux d'arrivée lent de 0,2 car chaque requête coûte beaucoup de budget de décodage. Vérifie si le TTFT reste stable.
ttft p50 · tokens/sec soutenus
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 1024 \
--random-output-len 4096 \
--random-range-ratio 0.9 \
--num-prompts 50 \
--request-rate 0.2 \
--burstiness 1.0 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 09-reasoning.jsonAléatoire, 4000 en entrée et 500 en sortie, taux d'arrivée de 1,5 par seconde avec une irrégularité de 1,0 et 25 en parallèle au maximum. Un flux de requêtes indépendant et soutenu.
ttft p95/p99 · profondeur de file
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 300 \
--request-rate 1.5 \
--burstiness 1.0 \
--max-concurrency 25 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 10-monday-peak.jsonSix taux d'arrivée croissants, de 0,1 à 1,0 requête par seconde. À chaque palier, on vérifie si le TTFT p95 reste sous le seuil.
req/s sous le seuil TTFT p95
# 0.1 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 100 \
--request-rate 0.1 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-0.1.json
# 0.2 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 100 \
--request-rate 0.2 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-0.2.json
# 0.3 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 100 \
--request-rate 0.3 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-0.3.json
# 0.5 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 125 \
--request-rate 0.5 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-0.5.json
# 0.7 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 175 \
--request-rate 0.7 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-0.7.json
# 1.0 req/s
docker exec vllm-bench vllm bench serve \
--backend openai-chat \
--base-url http://localhost:8000 \
--endpoint /v1/chat/completions \
--model ORG/MODEL \
--tokenizer ORG/MODEL \
--served-model-name SERVED_MODEL_NAME \
--dataset-name random \
--random-input-len 4000 \
--random-output-len 500 \
--random-range-ratio 0.9 \
--num-prompts 250 \
--request-rate 1.0 \
--burstiness 0.7 \
--percentile-metrics ttft,tpot,itl,e2el \
--metric-percentiles 50,90,95,99 \
--seed 42 \
--save-result \
--result-dir /tmp \
--result-filename 11-rate-sweep-1.0.jsonLes commandes sont construites de manière déterministe à partir du contrat versionné et des métadonnées de chaque run.
Démarre d'abord un serveur vLLM compatible OpenAI avec le modèle et la configuration indiqués dans les métadonnées du run. Utilise ensuite la commande de la page modèle. Le test 08 attend ShareGPT V3 dans /tmp/ShareGPT_V3.json ; les autres tests open-loop génèrent des prompts random synthétiques.
Les runs historiques n'ont pas enregistré l'argv original mot pour mot. Les commandes publiées sont donc signalées comme des reconstructions du contrat et des métadonnées. Le lien source fixe les deux révisions Git utilisées.
Envoie un lien Hugging Face ou une configuration vLLM. Si le modèle tient sur le Spark, je peux le comparer avec les mêmes tests.