Les benchmarks publics de LLM sont pour la plupart à jeter

Un ami m'a demandé la semaine dernière comment Opus 4.7 s'en sortait sur GrandpaCAD. Je l'ai expédié. Voici les données avec lesquelles je l'ai rembarré :

• Débit OpenRouter. Gemini 3.1 se situe autour de 62 tokens/seconde p50. Opus (la dernière fois que j'ai vérifié) était autour de 45.
• Benchmark Design Arena 3D. Kimi K2.6 a 1369 ELO, Gemini 3.1 a 1320, Opus 4.5 a 1299.
• Prix des tokens. Les tokens Opus coûtent environ 3 fois plus cher que Gemini, 10 fois plus cher que Kimi.

Trois sources indépendantes, toutes pointant dans la même direction : plus rapide, meilleur, moins cher ailleurs. Pour être juste, j'ignorais les mises à jour de Claude depuis un moment. Sonnet 4.5 a perdu contre Gemini sur cette charge de travail exacte l'année dernière, et je n'ai même jamais pris la peine d'exécuter un modèle Opus car le prix par token m'a fait fuir avant même l'évaluation. Claude Code me semble aussi lent dans mon travail quotidien, ce qui n'a fait que renforcer cette idée. Alors pourquoi s'embêter à lancer l'évaluation ?

Je l'ai lancée quand même. Les chiffres sont revenus complètement inversés.

Ce que la suite d'évaluation a réellement montré

J'ai exécuté mon harnais d'évaluation standard sur quatre modèles de pointe : Opus 4.7 en réflexion automatique, Gemini 3.1 avec un budget de réflexion moyen, GPT 5.5 avec service_tier: priority, et Kimi K2.6 sur Baseten (le fournisseur le plus rapide que j'ai pu trouver pour lui).

Quelques éléments ressortent.

Opus 4.7 est le plus rapide. 32 secondes par génération. Gemini 3.1 prend 1m 32s. GPT 5.5 prend 1m 46s. Le graphique de débit d'OpenRouter indique que Gemini est plus rapide en tokens-par-seconde, et c'est vrai si vous mesurez les tokens. Mais les modèles qui réfléchissent brûlent des tokens que vous ne voyez pas, et ce qui compte vraiment, c'est le temps d'horloge sur votre prompt. Opus réfléchit moins, déploie plus tôt. Je peux compiler trois générations Opus dans le temps qu'il faut à Gemini pour en finir une.

Opus 4.7 a le score pondéré le plus élevé. 0.587, devant Gemini 3.1 (0.556) et GPT 5.5 (0.501).

Opus 4.7 coûte la moitié de Gemini, un dixième du coût de GPT 5.5. 0.10 $ par génération contre 0.21 $ contre 0.94 $. Les comparaisons de prix des tokens ne tiennent pas compte des budgets de réflexion ou du nombre de tokens que chaque modèle dépense réellement. Par modèle 3D généré, Opus est la solution économique.

Pourquoi la 3D est le benchmark LLM le plus révélateur que vous puissiez lancer

C'est le point sur lequel je reviens sans cesse. Si vous lisez du texte de GPT 5.5, Opus 4.7, et Gemini 3.1 côte à côte, vous ne pouvez vraiment pas dire lequel est le plus intelligent. Ils ont tous l'air compétents, ils gardent tous le fil, et les différences se cachent dans des endroits que vous ne remarquerez pas pendant des mois : une dérive factuelle subtile, un biais discret, un raisonnement qui semble correct et ne tient pas vraiment la charge.

Le code est une étape au-dessus. Du code qui ne compile pas, ne compile pas. Vous détectez les erreurs de logique à la limite des tests unitaires. Mais il y a encore des bugs qui se cachent pendant des mois car ils ne se déclenchent que sur des entrées spécifiques.

La 3D est différente. Le crochet se connecte à la plaque murale ou ce n'est pas le cas. Le support de téléphone tient le téléphone ou il bascule. Les pieds de la chaise touchent le sol ou ils flottent. Vos yeux repèrent une 3D cassée en 200 millisecondes, de la même manière que vous repérez une faute de frappe dans votre propre nom. Il n'y a aucune couche intermédiaire abstraite où les bugs peuvent se cacher. La reconnaissance de motifs pour les objets physiques est le plus ancien module de votre cortex visuel, et il ne rate rien.

C'est pourquoi les graphiques ELO 3D publics divergent si fortement des performances 3D dans le monde réel. Voter sur un rendu côte à côte n'est pas la même chose que de réellement générer un modèle imprimable à partir d'un vrai prompt utilisateur et de le regarder réussir ou échouer. L'écart est énorme.

Je pense que la suite d'évaluation de GrandpaCAD s'est retrouvée, par accident, à être l'un des benchmarks avec le signal le plus fort qui existe pour le raisonnement des modèles de pointe. Non pas parce que je suis intelligent, mais parce que la 3D est impitoyable d'une manière que le texte et le code ne sont pas.

Le piège Kimi K2.6

Kimi K2.6 est le modèle le plus intéressant de cette comparaison. Il semblait imbattable sur le papier :

• Le plus haut ELO 3D sur Design Arena (1369, devant Gemini et Opus)
• Le moins cher dans mon benchmark (0.02 $ par génération, un cinquième d'Opus)
• L'inférence la plus rapide sur le bon fournisseur (Baseten le chronomètre jusqu'à 120 tokens/seconde, le double du taux habituel)

Je me suis lancé en me disant que Kimi allait l'emporter. Un tiers du prix, le double de la vitesse, et un ELO 3D supérieur à celui du modèle contre lequel je le testais.

Ce ne fut pas le cas. Kimi K2.6 a eu l'adhérence la plus faible (0.481), le taux d'erreur le plus élevé (14.3 %) et le taux de réussite le plus bas (66.7 %). Il a aussi nécessité près du triple de tentatives de code par rapport à Opus.

Donc : l'ELO 3D public plaçait Kimi au sommet, le fournisseur lui donnait le débit le plus rapide du test, et le prix par token était imbattable. Trois signaux distincts indiquant un gagnant. Les générations réelles ont été les pires des quatre.

L'ELO mesure la préférence entre deux rendus statiques. Il ne mesure pas si un modèle peut prendre un vrai prompt utilisateur, écrire du code OpenSCAD ou Python qui ne plante pas au premier essai, et produire un résultat imprimable. C'est un tout autre problème.

GPT 5.5 priority est plus précis. Il est aussi trop lent à déployer.

GPT 5.5 avec le niveau de service priority a eu le taux de réussite le plus élevé (90.5 %) et le taux d'erreur de code le plus bas (0.10 tentatives en moyenne). C'est véritablement un modèle solide.

Il est aussi lent. La génération moyenne a pris 1m 46s, 3.3 fois plus lent qu'Opus 4.7. Et la façon dont les utilisateurs de GrandpaCAD travaillent concrètement est itérative : prompt, observation visuelle du résultat, ajustement, nouveau prompt. La vitesse, c'est l'expérience. Je préfère donner à un utilisateur trois tentatives rapides pour le modèle qu'il veut plutôt que de le faire attendre un modèle fignolé plus lent. L'écart de taux de réussite est réel (90.5 % contre 85.7 %) mais il représente moins de cinq points de pourcentage, et trois générations Opus battent presque toujours une génération GPT 5.5 en pratique.

La question du coût est secondaire mais frappante une fois que vous mettez les chiffres côte à côte. Le niveau priority multiplie le prix de l'API par 2,5, et le coût moyen d'une génération sur cette charge de travail était de 0.94 $ contre 0.10 $ pour Opus.

Pour le même benchmark, GPT 5.5 m'a coûté 19.79 $. Opus m'a coûté 2.04 $.

J'ai posté une comparaison côte à côte d'Opus 4.7 et GPT 5.5 sur le même prompt si vous voulez voir la différence visuelle.

Quatre manières dont les benchmarks publics mentent

Quatre raisons qui reviennent sans arrêt.

Premièrement, les benchmarks 3D publics mesurent la mauvaise chose. Le vote de préférence côte à côte sur la qualité de rendu n'est pas la même chose qu'un test de bout en bout sur la question "ce prompt a-t-il produit un modèle imprimable et utile". Kimi a été le canari dans la mine sur ce point. Il a dominé le classement et fini dernier sur le travail réel.

Deuxièmement, les performances des modèles de pointe sont en dents de scie. Andrej Karpathy a décrit cela lors d'une récente interview :

Je veux aller dans une station de lavage pour laver ma voiture et c'est à 50 mètres. Dois-je y aller en voiture ou à pied ? Et les modèles de pointe actuels vous diront d'y aller à pied car c'est très proche. Comment est-il possible que le modèle de pointe Opus 4.7 puisse simultanément refactoriser une base de code de 100 000 lignes ou trouver des vulnérabilités zero-day et pourtant me dise de marcher jusqu'à cette station de lavage ? C'est insensé.

C'est la forme des capacités de pointe aujourd'hui. Un modèle peut être de classe mondiale sur une fraction des problèmes et se tromper avec aplomb sur une autre qui semble plus facile de l'extérieur. Les bords en dents de scie ne s'alignent même pas d'un labo à l'autre, c'est pourquoi deux classements évaluent les mêmes modèles différemment. Les benchmarks publics mesurent leur fraction. Votre charge de travail se trouve sur une fraction différente. Vous ne pouvez pas prédire le classement de votre fraction à partir du leur, vous pouvez seulement le lancer et voir.

Troisièmement, une seule exécution n'est pas un benchmark. La version la plus courante de ça en ligne est "J'ai demandé une fois à Opus de me faire une landing page, je n'ai pas aimé le résultat, donc Opus est moyen". Les modèles sont bruités. Le même prompt le même jour vous donne des sorties différentes avec des défauts différents à des vitesses différentes. Une seule exécution ne vous apprend presque rien. Deux exécutions vous en disent un peu plus. D'ici à ce que vous ayez lancé vingt prompts sur quatre modèles, vous pourrez commencer à tracer une courbe, et la courbe ne correspond presque jamais à ce qu'une seule exécution aurait suggéré. Les chiffres du tableau ci-dessus proviennent d'un balayage de base de 21 prompts par modèle. Le balayage étendu exécute 84 prompts par modèle. Dans les deux cas, plus d'une fois. Si j'avais jugé l'un d'entre eux sur une seule tentative "fais-moi un truc", j'aurais couronné un gagnant différent à chaque fois.

Quatrièmement, les laboratoires publient leurs propres benchmarks. L'article de benchmark sur Composer 2 de Cursor (mars 2026) est un exemple récent. Lisez-le et décidez par vous-même du poids à accorder aux chiffres qu'un labo publie sur son propre modèle. Si l'entité qui publie le chiffre bénéficie du fait que ce chiffre soit élevé, considérez cela comme du marketing jusqu'à preuve du contraire.

Le seul benchmark en lequel j'ai confiance maintenant est celui que j'exécute sur ma propre charge de travail, face à mes propres prompts, sous mon propre harnais d'évaluation. Tout le reste, c'est de la décoration.

Décidez pour votre cas d'usage. Puis testez pour votre cas d'usage.

Si vous déployez un produit de génération de code 3D, testez sur de la vraie génération de code 3D. Si vous déployez un produit de résumé juridique, testez sur du résumé juridique. Votre benchmark sera presque certainement en désaccord avec les benchmarks publics pour les mêmes modèles, car les benchmarks publics mesurent des moyennes sur des tâches qui ne sont pas les vôtres.

Pour ma charge de travail (texte-vers-3D, OpenSCAD et Blender, vrais prompts utilisateurs), Opus 4.7 l'emporte sur la vitesse, le coût et le score pondéré. GrandpaCAD exploite désormais Opus 4.7 par défaut.

Si vous voulez les données brutes, la page /evals consigne chaque exécution, y compris celles qui ont planté. La méthodologie se trouve dans comment nous testons l'agent de modélisation 3D. Le benchmark précédent, où Gemini 3 a gagné, se trouve dans comparaison des LLM de pointe pour la génération 3D. Le classement évolue vite.