Un banc de mesure mal monté ne lève pas d'erreur. Il produit des chiffres, et ces chiffres ont exactement l'allure de ceux qu'on attendait. C'est ce qui les rend dangereux : un modèle vraiment lent et un montage défaillant se ressemblent trait pour trait dans un tableau de résultats.
J'ai passé fin août 2026 une campagne de mesure sur trois modèles ouverts servis dans les mêmes conditions. Les résultats sont dans l'article compagnon. Celui-ci raconte les quatre défauts découverts en route, chacun capable à lui seul de publier un chiffre faux d'apparence parfaitement normale. Le fil conducteur est toujours le même : un banc de mesure mesure d'abord son propre montage.
1. Un composant absent, et la capacité est divisée par huit
Premier relevé de charge sur l'un des trois modèles : il tenait 4 conversations simultanées en chat court. « Tenir » est ici un critère fixé avant la mesure et appliqué au palier entier : au moins 15 tokens par seconde et par session, un TTFT au p95 sous 2 s en chat, et zéro préemption. Chiffre bas, mais crédible. Un modèle plus gros que les autres, une carte partagée, on se raconte facilement une explication.
Le composant de calcul que son éditeur prévoit n'était tout simplement pas installé dans l'image. Le moteur d'inférence s'était rabattu sur un remplaçant générique, sans rien signaler, et ce remplaçant provoquait des pointes d'attente qui faisaient échouer le critère de latence. Avec le bon composant installé, le même modèle en tient 32, soit le plafond de mon test.
Un facteur huit. Aucune exception levée, aucun avertissement dans les journaux, un serveur qui démarre et qui répond correctement du début à la fin. Le premier chiffre mesurait mon installation, pas le modèle.
La leçon générale vaut au-delà de ce cas précis : un chiffre bas se lit spontanément comme une propriété du modèle, parce que c'est l'histoire la plus disponible. C'est presque toujours une propriété du montage. Le réflexe utile est d'inverser la charge de la preuve : avant de conclure qu'un modèle est lent, il faut prouver que l'installation est celle que son éditeur documente.
2. Un échec technique indiscernable d'un mauvais résultat
La campagne comporte une étape d'évaluation automatique, où un composant tiers lit chaque réponse et rend un verdict chiffré. On lui avait alloué un budget de 300 mots pour ce verdict.
Sur les réponses longues, ce budget partait entièrement dans la phase de réflexion du composant, qui ne rendait alors rien du tout. Et le harnais, face à une sortie vide, enregistrait la valeur la plus basse de l'échelle. Un échec technique produisait donc exactement la même trace qu'un résultat catastrophique.
Ce défaut aurait été supportable s'il avait été aléatoire : du bruit se dilue. Il ne l'était pas. Il frappait les réponses les plus longues, donc les tâches les plus difficiles, donc inégalement selon les modèles évalués. Un biais qui suit la difficulté n'est plus du bruit, c'est une distorsion orientée. 69 résultats étaient concernés et ont dû être repassés.
La règle qui en sort tient en une ligne : ne jamais coder un échec avec une valeur valide de l'échelle. Un pipeline de mesure doit pouvoir distinguer « ce résultat est mauvais » de « je n'ai pas de résultat », et cette distinction doit exister dans la donnée, pas dans la tête de celui qui la relit.
3. Un banc qui écartait ses propres mesures les plus lentes
L'outil de charge que j'utilisais excluait de son calcul les appels servis en fin de palier. L'intention derrière ce filtre est compréhensible : à la fin d'une rafale, la machine se vide, les dernières requêtes ne sont plus représentatives d'un régime établi.
Sauf que ces appels de fin de palier sont précisément les plus lents, ceux qui ont attendu le plus longtemps derrière les autres. En les écartant, l'outil mesurait sa moitié rapide et annonçait une machine plus performante qu'elle n'est. Le filtre a été retiré, pas affiné : un filtre qu'on ajuste finit toujours par être ajusté jusqu'à ce que le résultat plaise.
Le critère que j'applique désormais : tout filtrage sur un jeu de mesures doit être justifié par une cause physique identifiée, jamais par l'allure de la distribution. « Ces points sont aberrants » n'est pas une justification, c'est une préférence.
4. Un bug que le poste de développement ne pouvait pas voir
Le quatrième défaut a coûté deux interruptions de campagne, machines louées facturées à l'heure comprises. Une erreur de programmation faisait planter le banc sur les machines de test, et restait strictement indétectable sur mon poste de travail : la version de Python installée dessus ne contient plus le mécanisme concerné.
Ce qui rend le cas intéressant, c'est ce qui l'avait laissé passer. Trois relectures de code et 86 tests automatiques ne l'avaient pas vu, et ne pouvaient pas le voir, puisqu'ils tournaient tous dans l'environnement où le bug n'existe pas. Ajouter un quatrième relecteur ou un quatre-vingt-septième test n'aurait rien changé.
La seule parade est structurelle : faire tourner le banc dans l'environnement cible, dans la même image, avant d'y lancer une campagne complète. Une exécution de dix minutes sur la machine louée aurait attrapé ce que trois relectures ont manqué.
Le même problème côté matériel : le nom de la carte louée
Le même piège se rejoue à l'échelle du matériel, et il vaut d'être raconté parce qu'il est complètement invisible sur une facture.
La campagne a tourné sur ce que le loueur facture comme une RTX PRO 6000 Blackwell. C'était en réalité une partition MIG, la moitié d'une carte découpée en deux instances de 48 Go.
MIG, pour Multi-Instance GPU, est un découpage matériel d'une carte en plusieurs cartes logiques indépendantes, chacune avec ses propres unités de calcul, sa tranche de cache et sa mémoire, attribuées par le matériel et non par un ordonnanceur. La page officielle de Nvidia décrit une instance « entièrement isolée avec sa propre mémoire à bande passante élevée, son cache spécial et des cœurs de calcul dédiés ». C'est ce qui permet à un loueur de vendre en deux fois une carte qu'il n'a achetée qu'une fois, et la conséquence pour qui loue est directe : une partition peut exposer 48 Go tout en ne disposant que d'une fraction du calcul et de la bande passante de la carte physique.
Ce qui est relevé sur la machine : nvidia-smi donne 94 unités de calcul allouées sur les 188 de la carte complète. Ce qui est déduit : la bande passante, que je n'ai pas mesurée et qu'aucun outil ne rapporte par partition. Le profil 2g.48gb attribue la moitié des contrôleurs mémoire, ce qui place le plafond théorique autour de 896 Go/s contre les 1 792 annoncés pour la carte entière. La distinction compte : le premier chiffre est un fait, le second un ordre de grandeur qui suit le découpage.
Le détail savoureux est ailleurs. La carte que je déploie réellement, une RTX PRO 5000 Blackwell, affiche 1 344 Go/s. La partition mesurée est donc plus lente d'un tiers que la carte de production, tout en portant le nom d'une carte plus prestigieuse. Publier ces chiffres sous l'étiquette « RTX PRO 6000 » aurait été littéralement vrai et complètement trompeur.
Reste l'isolation annoncée par le constructeur, qui promet que « tout échec sur une application qui est en cours d'exécution sur une instance donnée n'impactera pas les applications qui sont exécutées sur d'autres instances ». Une affirmation dont dépendait toute la campagne : si le locataire de l'autre moitié pollue mes relevés, ils ne valent rien. Dans l'esprit de cet article, je l'ai donc opposée à une mesure plutôt que de la reprendre. Deux pods sur les deux moitiés de la même carte physique, l'un servant 32 conversations simultanées pendant que l'autre générait : 0,5 % d'écart de vitesse sur le second, soit du bruit de mesure. L'affirmation tient sur ce matériel précis, et c'est maintenant un fait vérifié plutôt qu'une ligne de documentation.
De quoi tirer une règle générale, celle qui résume les quatre défauts précédents : la première chose à mesurer sur une machine louée, c'est la machine elle-même, pas le modèle qu'on veut y faire tourner. Relever le nombre d'unités de calcul, le quota de processeurs du conteneur et la bande passante réelle avant de lancer quoi que ce soit, sinon on attribue au modèle ce qui appartient au montage. Et au moment d'écrire les résultats, dire que les débits relevés sont un plancher propre à cette configuration. Les comparaisons entre modèles restent, elles, largement exploitables : en régime de décodage, le coût par token est dominé par le nombre de paramètres activés, si bien qu'un facteur quatre entre une architecture dense et une architecture à experts se retrouvera sur une autre carte. Son ordre de grandeur survit au changement de matériel, pas sa valeur exacte, qui dépend aussi de la quantification, des noyaux de calcul et du régime de charge.
Quand un résultat est trop propre
Un dernier signal, qui n'est pas un défaut avéré mais mérite le même traitement. Sur une série de 24 tâches demandant aux modèles de déclencher une action plutôt que de répondre en texte, les trois modèles ont obtenu exactement le même nombre d'appels corrects. Le même score, trois fois.
Trois architectures différentes qui tombent à l'unité près sur le même score en 24 essais, c'est un motif qui invite à soupçonner l'instrument avant de conclure quoi que ce soit sur les modèles. C'est aussi pourquoi je n'en donne pas la valeur ici : un chiffre qu'on soupçonne ne se publie pas, il se remesure.
Ce que les garde-fous font, et ce qu'ils ne font pas
Il faut être honnête sur la façon dont ces quatre défauts ont été trouvés, parce qu'aucun ne l'a été par un mécanisme automatique. Le composant de calcul absent, en lisant les résultats de charge et en s'étonnant d'un chiffre incohérent. Le budget de l'évaluateur, en inspectant la distribution des résultats et en remarquant un pic anormal sur la valeur la plus basse de l'échelle. Le filtrage des appels lents, par une relecture de code. Le bug de programmation, par des plantages répétés sur les machines louées. Les défauts se trouvent en regardant ses propres résultats avec méfiance, pas autrement.
Le banc a pourtant deux garde-fous, et ils servent à autre chose : ils refusent de certifier une mesure qu'ils ne peuvent pas vérifier. Les deux se sont déclenchés pendant la campagne, dans la même soirée.
Le premier, quand le banc a été piloté depuis un poste de travail au lieu de la machine mesurée : il n'a trouvé aucun quota de processeur à contrôler, et a refusé de valider le palier plutôt que de supposer qu'il disposait de toute la machine. Un générateur de charge bridé mesure sa propre asphyxie et l'attribue au serveur d'en face.
Le second, quand il n'a pas réussi à lire les métriques du serveur à travers le réseau : il a invalidé la mesure au lieu de publier une capacité sans avoir pu vérifier qu'aucune demande n'était partie en file d'attente. Dans les deux cas, il a fallu lui donner explicitement l'information manquante, le nombre de processeurs alloués, ou lui dire d'écarter le critère qu'il ne pouvait pas mesurer, ce qu'il inscrit alors dans son verdict.
La distinction vaut d'être posée nettement, parce qu'on attend souvent d'un garde-fou ce qu'il ne sait pas faire. Un garde-fou ne trouve pas les défauts, il empêche de publier un chiffre qu'on n'a pas pu vérifier. Ce sont deux choses différentes, et la seconde est déjà beaucoup.
C'est un choix de conception qui coûte : un banc qui s'arrête est un banc qu'il faut réparer, et une campagne relancée est une campagne repayée. Celle-ci a d'ailleurs été relancée intégralement après invalidation d'une première version, pour six écarts de protocole. À l'échelle, ce n'est pas cher : une campagne complète coûte une vingtaine de dollars, carte louée et évaluation comprises.
Le vrai coût est de l'autre côté. Un chiffre faux d'apparence normale ne se signale jamais tout seul : il se retrouve dans un dimensionnement, dans une proposition commerciale, puis dans une machine qui ne tient pas la charge annoncée. Publier un chiffre plausible qu'on ne peut pas vérifier revient à mesurer son propre montage et à le vendre comme une propriété du modèle.
Si vous montez votre propre banc, deux réflexes valent mieux qu'un outillage sophistiqué. S'étonner de ce qui devrait surprendre, d'abord : trois modèles d'architectures différentes qui obtiennent exactement le même score, un modèle réputé rapide qui décroche à quatre conversations, une distribution de résultats avec un pic anormal sur la valeur la plus basse. Et ne jamais certifier ce qu'on n'a pas pu vérifier, ensuite. La question avant chaque résultat n'est pas « ce chiffre est-il vraisemblable », un chiffre faux l'est presque toujours, mais : qu'est-ce que ce montage m'empêche de mesurer, et est-ce que je peux le prouver ? Les chiffres, eux, sont dans Trois modèles sur une carte, et la théorie qui les rend prévisibles dans Pourquoi l'inférence LLM est memory-bound.
