BenchZgxFury

Les meilleures valeurs observées parmi les mesures sélectionnées. Un débit (tok/s) plus élevé est meilleur ; une latence (TTFT = délai avant le premier token, TPOT = délai entre deux tokens) plus basse est meilleure.

Un résumé rédigé automatiquement à partir des mesures affichées (il suit les filtres) : ce qu'il faut en retenir, famille par famille.

Un serveur LLM sert plusieurs utilisateurs à la fois : la concurrence est le nombre de requêtes simultanées. Le débit agrégé (tokens générés par seconde, toutes requêtes confondues) augmente avec la concurrence, tandis que la latence par utilisateur se dégrade. Le TTFT est le temps d'attente avant le premier mot, le TPOT le temps entre deux mots (p50 = valeur médiane, p99 = cas défavorable vécu par 1 % des requêtes). Chaque point est la médiane de plusieurs répétitions. Les pointillés gris sont des chiffres publiés (référence) pour le même modèle et le même profil.

Le goodput est la quantité de travail utile servie en respectant un objectif de qualité de service (SLO) : ici TTFT p99 ≤ ms et latence inter-token p99 ≤ ms. La barre indique combien d'utilisateurs simultanés la machine supporte sans dépasser ces seuils ; la courbe montre la part des requêtes conformes (« attainment ») à mesure que la charge augmente.

Micro-benchmark de llama.cpp sans serveur : pp = traitement du prompt (prefill, tokens/s), tg = génération de texte (tokens/s). Le suffixe _d4096 signifie que le contexte contient déjà 4096 tokens, ce qui ralentit les deux phases.

Score (%) sur des tâches standard : raisonnement mathématique (GSM8K), connaissances et raisonnement (MMLU-Pro), sciences, code, compréhension d'images. Un modèle quantifié (NVFP4, FP8, GGUF…) est plus rapide et plus compact mais peut perdre en précision : quand sa version BF16 est aussi évaluée, l'écart (« delta ») au-delà de points est signalé comme une alerte.

Le RTFx (real-time factor) indique combien de secondes d'audio sont transcrites par seconde : 1000× signifie qu'une heure d'audio est traitée en 3,6 s. Le WER (taux d'erreur mots, %) mesure la précision : plus bas = mieux.

Les modèles d'embedding transforment un texte en vecteur pour la recherche sémantique (RAG). On mesure le nombre de requêtes par seconde selon la longueur du texte (256, 512 ou 2048 tokens) et la concurrence, la latence p99, et la qualité de recherche (score MTEB moyen, plus haut = mieux).

Mêmes indicateurs que pour les LLM, mais les requêtes contiennent une image (512 px ou 1024 px) ou une vidéo. Le traitement de l'image allonge surtout le TTFT.

Nombre d'images 1024×1024 (30 étapes) produites par seconde selon la taille du lot (batch), latence par image, mémoire GPU au pic, et durée par clip pour la génération vidéo.

Latence avant la première réponse audio selon le nombre de conversations simultanées (workers). Si le serveur n'a pas pu démarrer (attendu sur architecture aarch64 pour certaines dépendances), le tableau go / no-go indique l'étape bloquante.

Matrix-Game 4.0 (Skywork) remplace le rendu graphique d'un vrai jeu par un modèle de diffusion vidéo : le jeu natif tourne en bas-poly, et le GPU « repeint » chaque image en temps réel à partir de cette vue et des commandes du joueur. Deux scènes sont mesurées : Doom (ancient-egypt, tir à la première personne) et kart (racing, course). Trois débits d'images par seconde : FPS modèle = images produites par le modèle seul, FPS en ligne = images effectivement servies au client pendant la session (ce que voit le joueur), FPS encodé = images sorties de l'encodeur vidéo H.264. On relève aussi le délai avant la première image, le démarrage du serveur, la latence par bloc d'images (chunk) et la VRAM au pic. Le clip montre la vue double bas-poly | rendu pour juger à l'œil. Un rendu OpenGL logiciel (sans EGL NVIDIA) est signalé : ses FPS ne sont pas représentatifs.

Chaque modèle reçoit la même consigne et doit produire, à température 0, sept jeux HTML5 complets en un seul fichier (snake, breakout, flappy, invaders, tetris, doom, kart), selon plusieurs modes : skills (une seule réponse, avec des fiches de bonnes pratiques identiques pour tous les modèles), agent (l'agent pi écrit le fichier, le teste lui-même et le corrige, avec les mêmes skills) et éventuellement oneshot (consigne seule). Les légendes indiquent « modèle · mode ». Le fichier généré est chargé dans un Chromium sans écran pendant 15 s avec des touches injectées : on vérifie qu'il se charge, démarre et tourne sans planter, on compte les images rendues et les erreurs console. Un modèle juge local note ensuite le code sur 10 (complétude par rapport à la consigne, jouabilité, qualité du code) ; la note globale en est la moyenne. La mention « auto-évaluation » signale que le juge est le modèle évalué, ce qui peut biaiser la note. Cliquez une vignette pour jouer au jeu généré et comparer les modèles à la main.

La diarisation découpe un enregistrement en tours de parole attribués à chaque locuteur. Le DER (taux d'erreur de diarisation, %) est la part du temps mal attribuée : plus bas = mieux. Il se décompose en parole manquée, fausse alarme (parole détectée à tort) et confusion entre locuteurs. Le RTFx indique combien de secondes d'audio sont traitées par seconde ; en mode streaming, on mesure en plus la latence de traitement de chaque chunk audio.

Puissance, température et horloge du GPU relevées chaque seconde pendant une mesure (nvidia-smi dmon), puis, quand elle a été relevée, l'activité du processeur et de la mémoire de la Station toutes les 2 s (CPU total, cœurs occupés, conteneurs serveur et client, mémoire utilisée). Le nuage de points met en relation la puissance moyenne et le débit pour estimer l'efficacité énergétique (tokens par seconde et par watt).

Chaque ligne est un enregistrement JSON. Cliquez sur un en-tête pour trier, tapez pour filtrer, exportez en CSV. Les mesures en échec affichent leur message d'erreur au survol.