BenchZgxFury

HPGuide des tests
Évaluation du serveur d'inférence

Guide des tests réalisés

Ce que mesure chaque test, pourquoi il existe à côté des autres, comment lire ses chiffres et ce qu'une personne doit vérifier elle-même. Les résultats chiffrés et leur interprétation par famille sont dans le dashboard.

contrôle humain : aucun — le chiffre suffit conseillé — un coup d'œil évite une mauvaise lecture requis — regarder, écouter ou jouer avant de conclure

Vue d'ensemble

15 tests · 12 familles

Une ligne par test. « Mesures » compte les enregistrements des runs inclus dans le dashboard (hors exemple).

FamilleTestQuestion à laquelle il répondContrôle humainMesures ok / échecModèles mesurés
Machine Inventaire de la machine Sur quelle machine, quel GPU, quel pilote et quelles versions les mesures ont-elles été faites ? aucun 2 / 0 –
Machine Santé du GPU Le GPU est-il en état de produire des mesures fiables ? conseillé 1 / 0 –
Performance LLM (service) Performance de service LLM Combien de tokens par seconde la machine produit-elle, et quelle latence voit chaque utilisateur, quand la charge monte ? aucun 854 / 5 15
Goodput Goodput (capacité sous objectif de service) Combien d'utilisateurs simultanés la machine sert-elle en respectant les objectifs de latence ? aucun 3 / 3 3
llama-bench (GGUF) llama-bench (GGUF) Quel est le débit brut de llama.cpp pour un fichier GGUF, sans serveur ni réseau ? aucun 24 / 1 3
Qualité des modèles Qualité des LLM (lm-eval) La quantification fait-elle perdre de la justesse par rapport au modèle BF16 de référence ? conseillé 4 / 5 4
Qualité des modèles Qualité multimodale (lmms-eval) Le modèle comprend-il correctement les images et les vidéos ? aucun 2 / 0 2
Jeux 2D (qualité de code) Jeux 2D (qualité de code) Le modèle écrit-il, seul ou en agent, un programme complet qui fonctionne ? requis 50 / 5 4
Vision-langage (débit) Vision-langage (débit) À quel débit le modèle sert-il des requêtes de chat contenant des images ? aucun 20 / 0 2
Reconnaissance vocale Reconnaissance vocale (ASR) Combien d'audio transcrit par seconde, et avec combien d'erreurs ? conseillé 36 / 0 3
Diarisation Diarisation (qui parle quand) Le modèle attribue-t-il correctement chaque passage au bon locuteur, et assez vite ? aucun 0 / 2 –
Voix temps réel (Kyutai) Voix temps réel (Kyutai) Peut-on tenir une conversation vocale en temps réel, et avec combien d'utilisateurs ? requis 2 / 5 2
Embeddings Embeddings Combien de textes vectorisés par seconde, et la recherche retrouve-t-elle les bons documents ? aucun 24 / 4 2
Diffusion (image, vidéo) Génération d'images et de vidéo Combien d'images (ou de clips) la machine génère-t-elle par seconde ? requis 6 / 0 2
Rendu neuronal temps réel Rendu neuronal temps réel (Matrix-Game 4.0) Un modèle de diffusion vidéo peut-il remplacer le rendu d'un jeu en temps réel sur cette machine ? requis 2 / 0 1

Comparer les tests : ce que chacun mesure

Aucun test ne répond seul à « quel est le meilleur modèle ». La matrice montre ce que chacun couvre ; une conclusion solide croise au moins un test de vitesse et un test de justesse de la même catégorie.

TestDébitLatenceCapacité sous SLOJustesse / qualitéTemps réelCoûtMachine
Inventaire de la machine ●
Santé du GPU ●
Performance de service LLM ●●
Goodput (capacité sous objectif de service) ●●●
llama-bench (GGUF) ●
Qualité des LLM (lm-eval) ●
Qualité multimodale (lmms-eval) ●
Jeux 2D (qualité de code) ●●
Vision-langage (débit) ●●
Reconnaissance vocale (ASR) ●●●
Diarisation (qui parle quand) ●●●
Voix temps réel (Kyutai) ●●
Embeddings ●●●
Génération d'images et de vidéo ●
Rendu neuronal temps réel (Matrix-Game 4.0) ●●●

Rangement par catégorie de modèles

Les modèles ne se comparent qu'à l'intérieur d'une même catégorie. Pour chacune : la question posée, les tests qui y répondent, et les modèles du catalogue (mesuré = au moins un résultat valide).

LLM texte et code

Quel modèle et quel moteur servent le plus d'utilisateurs, assez vite, sans perdre en qualité ?

Tests
Modèles du catalogue
  • dfm-mimir-1.5-gguf tier 1
  • ornith-1.5-35b-fp8 tier 1
  • qwen3-coder-next-bf16 tier 1
  • qwen3-coder-next-fp8 tier 1
  • qwen3.8-27b-bf16 tier 1
  • qwen3.8-27b-fp8 tier 1
  • qwen3.8-27b-gguf-q8 tier 1
  • veriloop-e2-bf16 tier 1
  • apertus-1.5-70b tier 2
  • apertus-1.5-8b tier 2
  • dfm-mimir-1.5-gguf-q8 tier 2
  • gpt-oss-120b tier 2
  • normistral-11b-long tier 2
  • normistral-11b-thinking tier 2
  • ornith-1.5-35b-bf16 tier 2
  • qwen3.8-27b-gguf-q4 tier 2
  • qwen3.8-flash-next tier 2
  • qwen3.8-flash-next-fp8 tier 2
  • veriloop-e2-gguf tier 2
  • qwen3-coder-480b-nvfp4 tier 3
  • qwen3.8-27b-nvfp4 tier 3

Audio (transcription, diarisation, voix)

Combien d'heures d'audio par heure de calcul, avec quelle exactitude, et en temps réel ?

Tests
Modèles du catalogue
  • nemotron-3-diarization tier 1
  • qwen3-asr-1.7b tier 1
  • whisper-large-v3 tier 1
  • whisper-large-v3-turbo tier 1
  • qwen3-asr-0.6b tier 2
  • kyutai-stt-1b-en_fr tier 3
  • kyutai-tts-1.6b tier 3
  • moshi tier 3

Embeddings (recherche sémantique, RAG)

Combien de documents indexés par seconde, et avec quelle qualité de recherche ?

Tests
Modèles du catalogue
  • bge-m3 tier 1
  • qwen3-embedding-8b tier 1
  • qwen3-embedding-0.6b tier 2

Fiches des tests

Performance LLM (service) voir les résultats →

Performance de service LLM llm_serve

contrôle humain : aucun

Combien de tokens par seconde la machine produit-elle, et quelle latence voit chaque utilisateur, quand la charge monte ?

Ce qui est mesuré
Délai avant le premier token (TTFT), temps par token (TPOT), latence inter-token (ITL), débit agrégé et par utilisateur, à concurrence 1 à 128, pour chaque profil de charge.
Protocole
vllm bench serve contre le serveur OpenAI du moteur (vLLM, SGLang, llama.cpp, Ollama), longueurs d'entrée et de sortie fixes, --ignore-eos, température 0, prefix cache désactivé, 4 × concurrence requêtes, 3 répétitions, médiane.
Métriques
  • débit agrégé (tok/s) ↑ plus haut = mieux
  • débit par utilisateur (tok/s) ↑ plus haut = mieux
  • TTFT (ms) ↓ plus bas = mieux
  • TPOT (ms) ↓ plus bas = mieux
Intérêt par rapport aux autres tests
C'est la mesure de capacité brute : elle dit combien la machine peut produire. Elle ne dit pas si ce débit est utilisable (c'est le rôle de goodput, qui ajoute des objectifs de latence), ni si les réponses sont justes (c'est le rôle de lm-eval). À l'inverse de llama-bench, elle passe par un vrai serveur HTTP avec des requêtes simultanées : c'est ce que vivra une application.
Comment lire
Le débit agrégé monte avec la concurrence puis plafonne : le plafond est la capacité de la machine pour ce modèle. Le débit par utilisateur, lui, baisse : au-dessous d'environ 20 tok/s, la lecture en direct devient pénible. Comparer FP8 et BF16 d'un même modèle donne le gain de la quantification.
Limites
Les requêtes synthétiques à longueur fixe n'ont pas la variété d'un trafic réel ; le prefix cache, qui aide beaucoup en production (RAG, agents), est volontairement désactivé.
Couverture
854 mesures valides, 5 en échec · Apertus-v1.5-70B bf16, Apertus-v1.5-8B bf16, DFM-Mimir-v1.5-GGUF gguf-bf16, gpt-oss-120b mxfp4, normistral-11b-long bf16, normistral-11b-thinking bf16, Ornith-1.5-35B-A3B bf16, Ornith-1.5-35B-A3B-FP8 fp8, Qwen3-Coder-Next bf16, Qwen3-Coder-Next-FP8 fp8, Qwen3.8-27B bf16, Qwen3.8-27B-FP8 fp8, Qwen3.8-27B-GGUF gguf-q8_0, VeriLoop-E2 bf16, VeriLoop-E2-GGUF gguf-bf16

Goodput voir les résultats →

Goodput (capacité sous objectif de service) goodput

contrôle humain : aucun

Combien d'utilisateurs simultanés la machine sert-elle en respectant les objectifs de latence ?

Ce qui est mesuré
Concurrence maximale pour laquelle 99 % des requêtes respectent TTFT ≤ 500 ms et ITL ≤ 25 ms (par défaut), et débit utile correspondant.
Protocole
GuideLLM, balayage de charge (sweep) puis profil goodput avec SLO ; repli sur le sweep (p99 ≤ SLO) si le profil échoue.
Métriques
  • concurrence max sous SLO ↑ plus haut = mieux
  • débit utile (tok/s) ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Là où llm_serve donne le débit maximal, goodput donne le débit qu'on peut vendre : un moteur qui produit beaucoup mais avec un p99 de 3 s ne sert personne correctement. C'est le chiffre à retenir pour dimensionner un service.
Comment lire
Une concurrence sous SLO de 0 signifie que même un utilisateur seul dépasse l'objectif (souvent le TTFT d'un long contexte).
Limites
Le résultat dépend entièrement des SLO choisis ; changer 25 ms en 50 ms peut doubler la capacité.
Couverture
3 mesures valides, 3 en échec · Ornith-1.5-35B-A3B-FP8 fp8, Qwen3-Coder-Next-FP8 fp8, Qwen3.8-27B-FP8 fp8

llama-bench (GGUF) voir les résultats →

llama-bench (GGUF) llama_bench

contrôle humain : aucun

Quel est le débit brut de llama.cpp pour un fichier GGUF, sans serveur ni réseau ?

Ce qui est mesuré
Débit de prefill (pp, tok/s) et de génération (tg, tok/s) à plusieurs profondeurs de contexte.
Protocole
binaire llama-bench officiel, une requête à la fois, toutes les couches sur le GPU.
Métriques
  • tok/s ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Isole le moteur llama.cpp et le format GGUF des effets du serveur HTTP. Sert à comparer les quantifications GGUF entre elles (Q8, Q4, BF16) et à repérer une perte due au serveur (écart avec llm_serve à concurrence 1).
Limites
Un seul flux, pas de concurrence : ne prédit pas la capacité multi-utilisateurs.
Couverture
24 mesures valides, 1 en échec · DFM-Mimir-v1.5-GGUF gguf-bf16, Qwen3.8-27B-GGUF gguf-q8_0, VeriLoop-E2-GGUF gguf-bf16

Qualité des modèles voir les résultats →

Qualité des LLM (lm-eval) lm_eval

contrôle humain : conseillé

La quantification fait-elle perdre de la justesse par rapport au modèle BF16 de référence ?

Ce qui est mesuré
Score (%) sur gsm8k (raisonnement mathématique), gpqa_diamond (questions d'expert), mmlu_pro (connaissances, 1000 exemples), humaneval (code), et l'écart en points avec la référence BF16.
Protocole
lm-eval-harness sur l'endpoint OpenAI du serveur encore chaud, température 0, tâches génératives uniquement ; la référence BF16 est évaluée dans le même run.
Métriques
  • score par tâche (%) ↑ plus haut = mieux
  • écart vs BF16 (points) ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Le contrepoids des tests de vitesse : un FP8 deux fois plus rapide n'a d'intérêt que si son écart reste dans la tolérance (2 points). Ce n'est pas un classement absolu des modèles entre eux (les tâches sont courtes et échantillonnées), c'est un garde-fou de quantification.
Comment lire
Un écart négatif au-delà de 2 points est une alerte ; quelques dixièmes dans un sens ou l'autre relèvent du bruit.
Limites
Sous-ensembles d'exemples, pas de log-probabilités ; des différences de format de réponse peuvent coûter des points sans erreur de fond.
À vérifier soi-même
En cas d'alerte, lire quelques réponses fausses dans les sorties brutes (format de réponse mal extrait ou vraie erreur ?).
Couverture
4 mesures valides, 5 en échec · Apertus-v1.5-70B bf16, Apertus-v1.5-8B bf16, normistral-11b-thinking bf16, Qwen3.8-27B-FP8 fp8

Qualité multimodale (lmms-eval) lmms_eval

contrôle humain : aucun

Le modèle comprend-il correctement les images et les vidéos ?

Ce qui est mesuré
Score (%) sur MMMU (questions universitaires avec image) et Video-MME (questions sur vidéo).
Protocole
lmms-eval sur l'endpoint servi, réponses consignées (--log_samples).
Métriques
  • score par tâche (%) ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Complète le test vlm, qui ne mesure que le débit avec des images synthétiques sans juger les réponses.
Limites
Sous-ensembles ; scores sensibles au format de réponse.
Couverture
2 mesures valides · Qwen3.8-27B bf16, Qwen3.8-27B-FP8 fp8

Jeux 2D (qualité de code) voir les résultats →

Jeux 2D (qualité de code) codegen

contrôle humain : requis

Le modèle écrit-il, seul ou en agent, un programme complet qui fonctionne ?

Ce qui est mesuré
Sept jeux HTML5 (snake, casse-briques, flappy, invaders, tetris, Doom-like, kart) par modèle et par mode (skills, agent). Preuves automatiques : chargement, boucle d'animation, images rendues en 15 s, exceptions, erreurs console. Note d'un juge LLM (complétude, jouabilité, qualité du code, sur 10). Coût : durée, tokens, tours d'agent.
Protocole
Spécification et invite identiques pour tous, température 0 ; exécution dans Chromium sans écran (Playwright) ; même juge pour tous les modèles d'un run.
Métriques
  • note du juge (/10) ↑ plus haut = mieux
  • exécution complète ↑ plus haut = mieux
  • durée de génération (s) ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Le seul test qui juge un travail de bout en bout plutôt qu'une réponse courte : humaneval vérifie une fonction, codegen vérifie un programme qui tourne. Le mode agent mesure en plus la capacité à utiliser des outils et à se corriger, au prix de plus de temps et de tokens (affiché dans « Coût d'un jeu par mode »).
Comment lire
Une note élevée avec « exécution en échec » est suspecte. Une note obtenue par le modèle qui se juge lui-même est signalée « auto-évaluation ».
Limites
Le juge LLM n'est pas parfaitement reproductible et peut préférer son propre style ; « tourne 15 s sans erreur » ne veut pas dire « amusant » ni « conforme ».
À vérifier soi-même
Jouer aux jeux depuis le dashboard (vignette « jouer », changement de modèle instantané) et confirmer que la note du juge correspond à la jouabilité réelle, surtout pour les premiers du classement.
Couverture
50 mesures valides, 5 en échec · Apertus-v1.5-70B bf16, Apertus-v1.5-8B bf16, Qwen3-Coder-Next-FP8 fp8, Qwen3.8-27B-FP8 fp8

Vision-langage (débit) voir les résultats →

Vision-langage (débit) vlm

contrôle humain : aucun

À quel débit le modèle sert-il des requêtes de chat contenant des images ?

Ce qui est mesuré
TTFT, TPOT, débit agrégé selon la concurrence, avec des images synthétiques de taille fixe (option vidéo).
Protocole
AIPerf, images générées, longueurs de sortie fixes.
Métriques
  • débit agrégé (tok/s) ↑ plus haut = mieux
  • TTFT (ms) ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Montre le coût de l'image : comparé à llm_serve sur le même modèle, l'écart de TTFT est le temps d'encodage visuel. La justesse des réponses est mesurée à part par lmms-eval.
Limites
Images synthétiques sans contenu ; les réponses ne sont pas jugées.
Couverture
20 mesures valides · Qwen3.8-27B bf16, Qwen3.8-27B-FP8 fp8

Reconnaissance vocale voir les résultats →

Reconnaissance vocale (ASR) asr

contrôle humain : conseillé

Combien d'audio transcrit par seconde, et avec combien d'erreurs ?

Ce qui est mesuré
RTFx (secondes d'audio par seconde de calcul), TTFT et latence par concurrence ; WER sur LibriSpeech test-clean (anglais) et FLEURS (français).
Protocole
Script asr_bench (latence, débit, RTFx) et asr_wer contre l'endpoint audio du serveur ; texte normalisé avant calcul du WER.
Métriques
  • RTFx ↑ plus haut = mieux
  • WER (%) ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Vitesse et exactitude sont mesurées sur les mêmes modèles : on voit directement si un modèle « turbo » plus rapide perd en WER. FLEURS en français sert à repérer les modèles qui ne valent que pour l'anglais.
Comment lire
~2,7 % de WER sur LibriSpeech est la référence publiée pour Whisper large-v3 ; le français est toujours plus haut.
Limites
Le WER dépend de la normalisation du texte (ponctuation, chiffres, accents).
À vérifier soi-même
Lire quelques transcriptions françaises : une partie du WER peut venir de la normalisation (chiffres, élisions) plutôt que d'erreurs réelles.
Couverture
36 mesures valides · Qwen3-ASR-1.7B bf16, whisper-large-v3 fp16, whisper-large-v3-turbo fp16

Diarisation voir les résultats →

Diarisation (qui parle quand) diarization

contrôle humain : aucun

Le modèle attribue-t-il correctement chaque passage au bon locuteur, et assez vite ?

Ce qui est mesuré
DER (taux d'erreur de diarisation) décomposé en parole manquée, fausse alarme et confusion de locuteur ; RTFx hors ligne (lots 1 et 8) ; latence par segment en streaming.
Protocole
Nemotron-3-Diarization via NeMo sur VoxConverse test (50 fichiers), pyannote.metrics, collar 0,25 s, chevauchements inclus.
Métriques
  • DER (%) ↓ plus bas = mieux
  • RTFx ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Complète l'ASR pour les réunions et entretiens : la transcription dit quoi, la diarisation dit qui.
Limites
VoxConverse est en anglais, issu de débats télévisés ; un autre type d'enregistrement peut donner un DER très différent.
Couverture
0 mesure valide, 2 en échec

Voix temps réel (Kyutai) voir les résultats →

Voix temps réel (Kyutai) kyutai

contrôle humain : requis

Peut-on tenir une conversation vocale en temps réel, et avec combien d'utilisateurs ?

Ce qui est mesuré
Go/no-go aarch64, latence avant le premier audio, nombre de flux simultanés, facteur temps réel (RTF) pour Moshi (voix à voix), STT et TTS.
Protocole
Serveurs Kyutai officiels, clients synthétiques en parallèle.
Métriques
  • premier audio (ms) ↓ plus bas = mieux
  • RTF ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Le seul test temps réel interactif audio : il ne s'agit plus de débit mais de tenir la cadence de la parole (RTF < 1).
Limites
Ne juge ni la naturalité de la voix ni la pertinence des réponses.
À vérifier soi-même
Écouter des échanges (naturel de la voix, coupures, délai perçu) ; un RTF < 1 n'implique pas une conversation agréable.
Couverture
2 mesures valides, 5 en échec · stt-1b-en_fr bf16, tts-1.6b-en_fr bf16

Embeddings voir les résultats →

Embeddings embeddings

contrôle humain : aucun

Combien de textes vectorisés par seconde, et la recherche retrouve-t-elle les bons documents ?

Ce qui est mesuré
Requêtes/s, tokens/s, latence p50/p99 sur /v1/embeddings à plusieurs tailles d'entrée ; score MTEB moyen sur un sous-ensemble de tâches de recherche FR/EN.
Protocole
AIPerf pour la vitesse, script mteb_eval sur l'endpoint servi pour la qualité.
Métriques
  • requêtes/s ↑ plus haut = mieux
  • MTEB moyen ↑ plus haut = mieux
Intérêt par rapport aux autres tests
Dimensionne l'indexation d'un RAG (vitesse) et le choix du modèle (qualité) ; un petit modèle très rapide n'est utile que si son MTEB reste proche.
Limites
Sous-ensemble MTEB ; ne remplace pas une évaluation sur vos propres documents.
Couverture
24 mesures valides, 4 en échec · bge-m3 fp16, Qwen3-Embedding-8B bf16

Diffusion (image, vidéo) voir les résultats →

Génération d'images et de vidéo diffusion

contrôle humain : requis

Combien d'images (ou de clips) la machine génère-t-elle par seconde ?

Ce qui est mesuré
Images/s par taille de lot et résolution (SDXL, Qwen-Image), secondes par clip (Wan 2.2), latence, mémoire GPU.
Protocole
Pipelines diffusers, nombre d'étapes fixe, invites fixes.
Métriques
  • images/s ↑ plus haut = mieux
  • s par clip ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Seule mesure de capacité sur les modèles d'image : elle compare les modèles à nombre d'étapes égal, pas à qualité égale.
Limites
La qualité des images n'est pas mesurée (ni score automatique ni conservation systématique des images).
À vérifier soi-même
Générer et regarder un échantillon d'images par modèle avec les mêmes invites avant de comparer les débits ; un modèle plus rapide peut produire des images inutilisables.
Couverture
6 mesures valides · Qwen-Image bf16, stable-diffusion-xl-base-1.0 fp16

Rendu neuronal temps réel voir les résultats →

Rendu neuronal temps réel (Matrix-Game 4.0) matrixgame

contrôle humain : requis

Un modèle de diffusion vidéo peut-il remplacer le rendu d'un jeu en temps réel sur cette machine ?

Ce qui est mesuré
Images/s du modèle seul, servies en ligne et encodées ; délai avant la première image ; latence par bloc (p50/p90/p99) ; VRAM au pic ; images perdues. Clip de 20 s en vue double.
Protocole
Serveur du dépôt officiel, client synthétique qui joue des actions 60 s par scène (Égypte, course) et preset (realtime, quality).
Métriques
  • images/s en ligne ↑ plus haut = mieux
  • première image (s) ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Mesure une charge nouvelle (monde génératif interactif) où seul compte le maintien d'une cadence ; aucun autre test ne la couvre.
Comment lire
Autour de 24 images/s le rendu paraît fluide ; sous 15 images/s il est saccadé. Une session « rendu logiciel » n'est pas représentative.
Limites
La latence action → image vue dans un navigateur n'est pas mesurée ; la cohérence visuelle n'est pas notée.
À vérifier soi-même
Regarder les clips en vue double (bas-poly | rendu) et jouer en direct (`benchzgx play`) pour juger la cohérence et la réactivité.
Couverture
2 mesures valides · Matrix-Game-4.0 bf16

Machine

Inventaire de la machine inventory

contrôle humain : aucun

Sur quelle machine, quel GPU, quel pilote et quelles versions les mesures ont-elles été faites ?

Ce qui est mesuré
Nom d'hôte, GPU et mémoire, capacité de calcul, pilote et CUDA, limite de puissance, CPU, RAM, OS, noyau, Docker.
Protocole
Lecture de nvidia-smi, /proc et docker version au début de chaque run ; le résultat est attaché au run.
Intérêt par rapport aux autres tests
Ne compare rien en soi : il rend les autres chiffres comparables entre deux campagnes (même pilote, même limite de puissance). Deux runs avec des inventaires différents ne doivent pas être mélangés sans le signaler.
Limites
Ne vérifie pas le refroidissement ni la température ambiante.
Couverture
2 mesures valides

Santé du GPU health

contrôle humain : conseillé

Le GPU est-il en état de produire des mesures fiables ?

Ce qui est mesuré
Diagnostic DCGM (niveau 2), erreurs ECC non corrigées, erreurs XID récentes, disque libre, bande passante hôte ↔ GPU (nvbandwidth).
Protocole
dcgmi diag -r 2, nvidia-smi -q, journal noyau, nvbandwidth ; avant la campagne.
Métriques
  • échecs DCGM ↓ plus bas = mieux
  • erreurs ECC non corrigées ↓ plus bas = mieux
  • erreurs XID ↓ plus bas = mieux
Intérêt par rapport aux autres tests
Un GPU en défaut produit des débits bas sans message d'erreur. Ce test sépare « le modèle est lent » de « la machine est malade ». À regarder avant toute conclusion de performance.
Limites
Un diagnostic court ne détecte pas un throttling thermique qui n'apparaît qu'après une heure de charge (voir la télémétrie).
À vérifier soi-même
Vérifier la checklist avant campagne (température au repos, refroidissement liquide actif, aucun autre processus GPU).
Couverture
1 mesure valide

Tests à contrôle humain

7 tests

Ces vérifications ne sont pas automatisées et n'entrent dans aucun chiffre. Les faire avant de publier une conclusion.

NiveauTestQuoi vérifier
requis Génération d'images et de vidéoGénérer et regarder un échantillon d'images par modèle avec les mêmes invites avant de comparer les débits ; un modèle plus rapide peut produire des images inutilisables.
requis Jeux 2D (qualité de code)Jouer aux jeux depuis le dashboard (vignette « jouer », changement de modèle instantané) et confirmer que la note du juge correspond à la jouabilité réelle, surtout pour les premiers du classement.
requis Rendu neuronal temps réel (Matrix-Game 4.0)Regarder les clips en vue double (bas-poly | rendu) et jouer en direct (`benchzgx play`) pour juger la cohérence et la réactivité.
requis Voix temps réel (Kyutai)Écouter des échanges (naturel de la voix, coupures, délai perçu) ; un RTF < 1 n'implique pas une conversation agréable.
conseillé Qualité des LLM (lm-eval)En cas d'alerte, lire quelques réponses fausses dans les sorties brutes (format de réponse mal extrait ou vraie erreur ?).
conseillé Reconnaissance vocale (ASR)Lire quelques transcriptions françaises : une partie du WER peut venir de la normalisation (chiffres, élisions) plutôt que d'erreurs réelles.
conseillé Santé du GPUVérifier la checklist avant campagne (température au repos, refroidissement liquide actif, aucun autre processus GPU).

Glossaire

36 termes
Agent (mode)
Mode codegen où le modèle dispose d'outils (lire, écrire, exécuter) et peut tester puis corriger son jeu en plusieurs tours.
BF16
Format numérique 16 bits (bfloat16), précision de référence des poids des modèles ; sert de base de comparaison aux versions quantifiées.
Concurrence
Nombre de requêtes envoyées en même temps au serveur ; simule autant d'utilisateurs simultanés.
Contrôle humain
Vérification qu'une personne doit faire (regarder, écouter, jouer) parce que le chiffre automatique ne suffit pas à conclure.
DCGM
Outil de diagnostic NVIDIA des GPU (Data Center GPU Manager) ; le niveau 2 lance des tests de calcul et de mémoire.
Decode
Phase où le modèle génère les tokens de réponse un par un ; limitée par la bande passante mémoire.
Delta qualité
Écart en points entre le score d'un modèle quantifié et celui de sa référence BF16. Alerte au-delà de 2 points.
DER
Diarization Error Rate : part du temps de parole mal attribuée (manquée, fausse alarme ou mauvais locuteur). Plus bas est mieux.
Embedding
Vecteur numérique représentant le sens d'un texte, utilisé pour la recherche sémantique et le RAG.
FP8
Quantification 8 bits à virgule flottante : environ deux fois moins de mémoire que BF16, souvent plus rapide, perte de qualité généralement faible.
GGUF
Format de fichier de llama.cpp et Ollama, qui embarque poids quantifiés (Q8_0, Q4_K_M…) et métadonnées.
Goodput
Débit utile : la part du trafic servie en respectant les objectifs de latence (SLO).
HBM
Mémoire haute bande passante soudée au GPU (256 Go sur le GB300).
ITL
Inter-Token Latency : temps entre deux tokens consécutifs d'une réponse.
Juge LLM
Modèle de langage qui note un résultat (ici les jeux générés) selon une grille ; pratique mais non parfaitement reproductible.
KV cache
Mémoire où le serveur garde l'état de chaque conversation en cours ; sa taille limite la concurrence et la longueur de contexte.
lm-eval
lm-evaluation-harness : banc d'évaluation standard de la justesse des LLM sur des jeux de questions.
MTEB
Massive Text Embedding Benchmark : batterie de tâches qui mesure la qualité des embeddings.
MTP
Multi-Token Prediction : décodage spéculatif où le modèle propose plusieurs tokens à la fois, vérifiés ensuite ; accélère la génération.
NVFP4
Quantification 4 bits NVIDIA propre aux GPU Blackwell : quatre fois moins de mémoire que BF16.
p50 / p99
Médiane / 99e centile : p99 est la valeur que 99 % des requêtes ne dépassent pas, soit le cas défavorable vécu par 1 utilisateur sur 100.
Prefill
Phase où le modèle lit toute l'invite avant le premier token ; limitée par la puissance de calcul. Domine le TTFT.
Prefix cache
Réutilisation du calcul d'un début d'invite déjà vu ; désactivé pendant les mesures pour ne pas flatter les résultats.
Profil de charge
Couple longueur d'entrée / longueur de sortie (chat 1024/1024, rag 8192/1024, long 32768/1024, agent 4096/2048…).
Quantification
Réduction de la précision des poids (FP8, NVFP4, GGUF Q8/Q4) pour gagner mémoire et vitesse au prix d'une possible perte de qualité.
RAG
Retrieval-Augmented Generation : le modèle répond à partir de documents retrouvés par recherche sémantique.
RTF / RTFx
Facteur temps réel. RTF = temps de calcul / durée audio (temps réel si < 1) ; RTFx = l'inverse (secondes d'audio traitées par seconde, plus haut est mieux).
Skills (mode)
Mode codegen en une seule réponse, avec des instructions de bonnes pratiques identiques pour tous les modèles dans l'invite système.
SLO
Service Level Objective : objectif de latence à respecter (ici TTFT p99 ≤ 500 ms et ITL p99 ≤ 25 ms par défaut).
tok/s
Tokens par seconde. Agrégé : tous utilisateurs confondus (capacité). Par utilisateur : vitesse de lecture perçue.
Token
Unité de texte manipulée par le modèle (en moyenne ¾ de mot en anglais, un peu moins en français).
TPOT
Time Per Output Token : temps moyen par token généré après le premier ; 1000 / TPOT = tok/s vus par un utilisateur.
TTFT
Time To First Token : délai entre l'envoi de la requête et le premier token reçu ; c'est la réactivité perçue.
Télémétrie
Relevé seconde par seconde de la puissance, des températures, des horloges et de la mémoire du GPU (et du CPU) pendant une mesure.
VLM
Vision-Language Model : modèle qui accepte des images (ou vidéos) en entrée en plus du texte.
WER
Word Error Rate : part des mots mal transcrits (substitués, oubliés, ajoutés). Plus bas est mieux.