Le GPU disparaît derrière l’API
Comparer deux GPU est un problème borné. Le modèle, la précision et le lot sont fixés, puis le chronomètre entoure le calcul. Comparer deux services d’inférence ajoute tout ce que cette méthode laisse hors cadre : le routeur, la file d’attente, le scheduler, le cache, le réseau et le nombre de répliques derrière l’adresse HTTP. C’est pourtant cet ensemble que vous achetez quand vous appelez une API.
MLPerf Endpoints déplace donc l’instrument. Le générateur de charge se place devant l’endpoint, comme votre application, puis envoie des requêtes suivant trois profils. Le mode offline les présente toutes à la fois pour chercher le débit maximal. Le mode online les espace selon une loi de Poisson, qui reproduit des arrivées indépendantes autour d’un débit cible. Le troisième maintient un nombre fixe de requêtes en vol : dès qu’une réponse se termine, une autre prend sa place.
Le dernier profil est celui de la publication v0.7 : les 100 fichiers de points de performance utilisent tous load_pattern: concurrency. Il ne demande pas « combien ce serveur produit-il ? », mais « que devient-il avec 32, 512 ou 8 192 requêtes simultanées ? ». À chaque niveau, le harnais enregistre quatre familles de mesures : les requêtes terminées par seconde, le temps jusqu’au premier fragment utile, le temps moyen par token de sortie et la latence de bout en bout. La mesure porte bien sur un endpoint. Elle ne garantit pas pour autant que cet endpoint soit une offre cloud publiquement achetable : plusieurs soumissions v0.7 pointent vers des adresses internes et décrivent une machine complète.
Une courbe, pas un podium
Le mécanisme central apparaît dans les résultats NVIDIA sur GPT-OSS-120B. La machine reste une baie GB300 NVL72, le modèle reste en MXFP4, le jeu de performance reste le même. Le niveau de concurrence et la configuration du serveur sont ajustés ensemble pour chercher plusieurs points de la frontière. À 544 requêtes simultanées, le système termine 101,8 requêtes par seconde. À 22 528, il en termine 775,6. Le débit est multiplié par 7,6, mais les requêtes individuelles paient cette densité.
| Concurrence | Requêtes/s | TTFT p99 | TPOT p99 | Latence totale p99 |
|---|---|---|---|---|
| 544 | 101,8 | 893 ms | 4,24 ms/token | 8,21 s |
| 22 528 | 775,6 | 15,72 s | 23,34 ms/token | 46,51 s |
À 22 528 requêtes en vol, chaque seconde de baie produit bien davantage de réponses. Mais 1 % des requêtes attendent plus de 15,72 secondes avant le premier fragment utile, et 1 % dépassent 46,51 secondes jusqu’à la fin. Ces deux points sont exacts sur la charge publiée. Aucun ne constitue seul « la performance » du système.
La visualisation publique de MLCommons met le TTFT p95 en avant. Le tableau choisit le p99, disponible dans les mêmes fichiers bruts, pour examiner la queue de distribution plus sévèrement. Il ne faut donc pas comparer directement ses valeurs à celles lues sur l’axe p95 du site Endpoints.
Ils ne forment pas non plus une expérience où un seul bouton aurait bougé. Entre les fichiers serveur associés, le lot maximal du décodeur passe de 32 à 512, le lot du serveur de contexte de 4 à 16, le budget de tokens de contexte de 16 384 à 65 536 et le parallélisme de données de l’attention est activé. Les graphes CUDA capturent aussi des lots différents. Le benchmark publie donc deux configurations optimisées sur le même système, pas la sensibilité pure d’une configuration fixe à la concurrence. C’est cohérent avec la recherche d’une frontière de Pareto, mais cela interdit d’attribuer l’écart au seul nombre de requêtes en vol.
Le paquet public ne permet pas de reconstruire avec certitude la topologie du second run. Pour le point 544, le nom du résultat et les fichiers source décrivent quatre serveurs de contexte, dix-sept serveurs de génération et un front-end. Pour le point 22 528, le nom archivé dans results/config.yaml encode ng48_nc24_fe48, tandis que le fichier client et gptoss_config.yaml décrivent vingt-huit serveurs de contexte, onze serveurs de génération et onze front-ends. run_metadata.json confirme 72 GPU, une pile désagrégée et un lot de 512, mais ne tranche pas cette divergence. Les chiffres mesurés restent vérifiables ; leur attribution à une topologie précise ne l’est pas.
Cette forme est une SLO Service Level Objective. Cible de qualité de service qu'un système se donne, par exemple un temps jusqu'au premier token sous 500 ms au 99e percentile. À distinguer du SLA, qui est l'engagement contractuel opposable : en inférence LLM, les SLO abondent et les SLA de latence sont quasi inexistants. . Si votre produit impose un premier fragment sous une seconde au 99e percentile, le second point n’existe pas pour vous, même si son débit est spectaculaire. Nous appellerons ici débit admissible le QPS d’un point retenu seulement après deux contrôles distincts : ses distributions de latence et d’erreur respectent le SLO, puis sa configuration atteint le seuil de qualité fixé sur l’évaluation séparée. Ce terme est une construction analytique de l’article, pas une métrique publiée par MLPerf Endpoints 0.7.
La distinction empêche un classement trompeur. Un fournisseur peut pousser la concurrence jusqu’à remplir sa file et publier beaucoup de requêtes par seconde. Un autre peut s’arrêter plus tôt pour préserver le premier token. Classer les deux sur le seul débit récompense celui qui accepte de dégrader l’expérience, pas celui qui sert mieux la même contrainte.
TTFT, TPOT et QPS ne racontent pas la même attente
Le TTFT mesure l’intervalle entre l’émission de la requête et la réception du premier fragment de contenu ou de raisonnement que le client accepte comme utile. Il contient le trajet HTTP, la file, le prefill et le début du décodage. C’est le délai perçu avant que l’interface commence à répondre. Dans le harnais MLPerf Endpoints, il inclut aussi le trajet par le transport interne du client de mesure. Le client est conçu pour monter à plusieurs dizaines de milliers de requêtes par seconde, mais son coût ne devient jamais mathématiquement nul.
Le nom simplifie une nuance décisive : le client horodate le premier fragment utile reçu, pas le premier token calculé dans le serveur. La configuration NVIDIA fixe stream_interval à 100 sur les deux étages. Dans TensorRT-LLM, cette option regroupe les réponses toutes les 100 itérations, mais exempte explicitement le premier token afin de préserver le TTFT. Elle ne retarde donc pas le premier fragment de 100 tokens. Elle rend en revanche la cadence suivante très grossière, ce qui empêche d’observer les pauses entre chaque token dans ce run.
Le TPOT divise le temps écoulé entre le premier fragment et la fin par le nombre de tokens comptés après ce fragment. C’est une moyenne sur la réponse, pas l’intervalle exact entre chaque paire de tokens. Le regroupement par 100 conserve approximativement cette moyenne sur une longue sortie, mais masque sa régularité. Un endpoint peut donc afficher un bon TPOT et produire des salves séparées par des pauses. Notre dossier sur le scheduler traite le mécanisme qui oppose ce temps au premier token ; ici, la question est différente : deux fournisseurs ont-ils calculé ces grandeurs de la même manière ? Le harnais commun fixe la méthode côté client, mais l’intervalle de streaming reste un paramètre du serveur à contrôler.
Le QPS compte des requêtes, pas du travail. Une requête qui produit 128 tokens et une autre qui en produit 3 700 comptent chacune pour une unité. Les trois modèles de la première publication n’ont précisément pas le même profil : Llama 3.1 8B utilise une charge de résumé courte, tandis que DeepSeek-R1 génère des raisonnements bien plus longs. Diviser leurs QPS l’un par l’autre ne compare ni leurs tokens par seconde, ni leur capacité utile.
La qualité ferme la porte aux raccourcis
Une optimisation de serving peut gagner du débit en réduisant la précision des poids, en tronquant les sorties ou en changeant le modèle derrière son nom commercial. Si la réponse se dégrade, le benchmark n’a pas accéléré le même service. C’est pourquoi MLPerf Endpoints associe la mesure de performance à une phase d’évaluation.
Pour GPT-OSS-120B, la soumission NVIDIA exécute AIME 2025 sur 30 problèmes répétés huit fois, GPQA sur 198 questions répétées cinq fois et LiveCodeBench sur 1 055 tâches répétées trois fois, avec une température de 1. Les scores du point 544 sont respectivement 80,42 %, 73,74 % et 84,61 %. Ceux du point 22 528 sont 78,75 %, 73,84 % et 85,56 %. Cette variation rappelle que l’évaluation est stochastique et propre à chaque run. Comme le dépôt de politiques lié par MLCommons est inaccessible, ces fichiers ne suffisent pas à prouver quel seuil officiel chaque transformation MXFP4 devait franchir. Ils ne prédisent pas non plus la qualité sur du français, des sorties JSON, une base documentaire ou des appels d’outils.
Le premier cycle ne couvre que trois familles de modèles : Llama 3.1 8B, DeepSeek-R1 et GPT-OSS-120B. MLCommons annonce des charges agentiques pour la version 1.0. La couverture actuelle suffit à vérifier que le protocole relie performance et qualité ; elle ne suffit pas à représenter le catalogue d’un fournisseur ni la diversité des applications qui l’appellent.
Il faut aussi distinguer deux usages du mot qualité. Le benchmark mesure l’exactitude des réponses sur ses jeux. Un acheteur attend aussi une qualité de service : taux d’erreur HTTP, refus de surcharge, disponibilité, variation entre régions et comportement pendant une panne. La version 0.7 publie le nombre de requêtes échouées dans chaque exécution, mais elle n’organise pas une campagne de disponibilité sur plusieurs jours. Un run sans erreur n’est pas un engagement de production.
Le coût manque encore à l’équation
MLCommons présente quatre principes : actualité, couverture, comparabilité et contexte. Sa définition de la comparabilité vise des résultats normalisés par le coût ou la puissance. L’annonce promet pour MLPerf Endpoints 1.0 des règles davantage centrées sur l’acheteur et une « normalisation », sans préciser publiquement si la première formule portera sur le prix, la puissance ou les deux. Aucun de ces calculs n’est livré dans la version 0.7.
Les fichiers publics décrivent le matériel, le modèle, la précision, le runtime et les résultats. Ils ne donnent ni tarif horaire normalisé, ni prix par million de tokens, ni puissance mesurée. Une baie interne NVIDIA, un endpoint CoreWeave et un serveur Dell ne peuvent pas être ramenés à une facture commune avec ces seules données. La version 0.7 mesure la capacité. Elle ne calcule pas ce que cette capacité vous coûte.
Le calcul d’achat reste pourtant simple à écrire. Pour une ressource facturée à l’heure :
Pour une API facturée au token, le tarif catalogue remplace le prix horaire, mais le principe reste. Il faut appliquer les prix d’entrée et de sortie aux longueurs réellement observées, ajouter les requêtes retentées après erreur, puis rejeter les points qui violent l’objectif de service. Le coût d’inférence LLM établit cette économie unitaire. MLPerf Endpoints pourrait lui fournir le terme qui manquait : le débit mesuré sous contrainte, à condition que le prix, le modèle et la région soient gelés au même instant.
Ce que v0.7 permet de conclure
La première version permet trois décisions solides. Elle révèle la forme de la courbe d’un système quand la concurrence augmente. Elle compare deux configurations du même modèle sous un générateur de charge commun. Elle publie assez de métadonnées et de résultats bruts pour que le lecteur vérifie le périmètre avant d’interpréter un point.
Elle ne permet pas de désigner « le fournisseur le plus rapide » sans nommer le modèle et la limite de latence. Elle ne permet pas de désigner « le moins cher », puisque le prix et l’énergie manquent. Elle ne mesure ni démarrage à froid, ni limite de débit commerciale, ni panne régionale, ni variation journalière d’un endpoint mutualisé. Elle ne transforme pas non plus les résultats des participants en mesures réalisées par un laboratoire ayant acheté anonymement chaque offre : les organisations soumettent leurs systèmes et leurs configurations au protocole.
Une faiblesse documentaire reste ouverte au gel de cet article. Le dépôt public des résultats renvoie vers mlcommons/endpoints_policies, mais l’adresse web répond 404 et git ls-remote indique que le dépôt est introuvable au 30 août 2026. Le code du harnais, les configurations et les résultats sont publics ; les politiques exactes de v0.7 ne sont pas accessibles depuis leur lien officiel. Cela empêche notamment de vérifier les seuils de validité et de qualité à partir du paquet publié seul.
| Question | Réponse de v0.7 | Mesure encore nécessaire |
|---|---|---|
| Combien de charge ? | QPS et concurrence | Profil horaire réel |
| Quelle attente ? | TTFT, TPOT, latence totale | SLO propre au produit |
| Quelle exactitude ? | Jeux associés au modèle | Évaluation métier interne |
| Combien d'erreurs ? | Échecs pendant le run | Disponibilité sur la durée |
| Quel coût ? | Non normalisé | Tarif, énergie et débit admissible |
Conclusion
MLPerf Endpoints 0.7 ne répond pas encore à la question « quel fournisseur acheter ? ». Il corrige une erreur plus profonde : l’idée qu’un service d’inférence puisse être résumé par un nombre. Le véritable objet est une courbe entre charge, premier token, cadence de génération et qualité, dont chaque acheteur retient une zone différente.
La version 1.0 sera décisive si sa normalisation relie une ressource mesurée, un coût ou une puissance et un point de latence admissible. Diviser simplement un tarif par le QPS maximal recréerait le classement trompeur que le protocole vient précisément d’éviter. Le bon dénominateur est plus exigeant : une configuration qui conserve la qualité et termine la charge dans le temps promis. C’est à cette condition qu’un benchmark de performance devient un instrument d’achat.
Sources et méthode
Date de gel rédactionnel : 30 août 2026. Tous les chiffres sont des faits vérifiés dans les sources primaires de MLCommons et les fichiers de soumission. Les formules de coût sont des dérivations explicites ; aucun tarif fournisseur n’est injecté dans les résultats v0.7.
Annonce et périmètre. MLCommons, « MLPerf Endpoints v0.7: A Foundation Release », 28 juillet 2026 pour les cinq participants initiaux, les trois benchmarks et les quatre principes du projet. La page officielle du benchmark documente le TTFT p95 de la visualisation, les points de fonctionnement, le statut de disponibilité et la revue des résultats. L’annonce promet pour la version 1.0 une normalisation, des règles centrées sur l’acheteur, des charges agentiques et des soumissions continues ; seul le principe de comparabilité précise « coût ou puissance », sans engager explicitement la livraison des deux métriques en v1.0.
Harnais de mesure. Dépôt officiel mlcommons/endpoints pour les trois profils de charge, l’architecture du client, les métriques QPS, latence, TTFT et TPOT, ainsi que les évaluations AIME, GPQA et LiveCodeBench. Les définitions actuelles de TTFT et TPOT ont été vérifiées dans le code et la documentation du client. Le comportement de stream_interval, dont le premier token est exempté, vient de la documentation officielle TensorRT-LLM. Le dépôt MLCommons se déclare encore au statut de développement « Alpha » dans son pyproject.toml au gel rédactionnel. Les résumés v0.7 portent le hash court 629c1bc, qui n’est pas résolu par l’historique public de ce dépôt au 30 août ; nous ne présentons donc pas l’état courant du code comme une révision bit-à-bit du harnais de publication.
Résultats bruts. Dépôt officiel MLPerf Endpoints v0.7, révision b5328511abb79c84b520e3c7775fb2336b773f37. Les 100 fichiers de points ont été contrôlés : tous fixent une charge par concurrence. Le tableau 1 utilise les fichiers point_544 et point_22528. Les requêtes par seconde sont recalculées par n_samples_completed ÷ (duration_ns / 10⁹) ; les autres valeurs sont les 99es percentiles publiés, convertis des nanosecondes vers les millisecondes ou secondes. Les configurations serveur du point 544 et du point 22 528 établissent les changements de lot, de parallélisme d’attention et de graphes CUDA. Leur description de la topologie du point 22 528 contredit toutefois le nom archivé dans le fichier de résultat ; cette divergence est conservée comme réserve.
Modèle, système et qualité. Description de la soumission NVIDIA GPT-OSS-120B pour la baie GB300 NVL72, la précision MXFP4 et la concurrence maximale déclarée. Les résultats d’exactitude du point 544 et du point 22 528 fournissent les tailles, répétitions et scores distincts d’AIME 2025, GPQA et LiveCodeBench.
Limites auditées. Feuille de route officielle, issue #223 pour les travaux de stabilisation, de fiabilité, de couverture et de parité du harnais. Le README des résultats v0.7 renvoie vers https://github.com/mlcommons/endpoints_policies, qui répondait 404 au gel rédactionnel. Cette absence est rapportée comme un état documentaire daté, pas comme la preuve que les règles n’existent nulle part.
Ce que nous ne concluons pas. Les résultats ne sont pas convertis en classement global, en coût par token ou en coût par requête. Aucun chiffre d’un fournisseur n’est transposé à un autre modèle, à une autre région ou à une autre longueur de sortie. Le débit admissible est une définition analytique proposée pour relier performance et achat ; ce n’est pas une métrique publiée par MLPerf Endpoints 0.7.
