Les benchmarks publics de LLM m'ont induit en erreur sur Opus 4.7
Un ami m'a demandé la semaine dernière comment Opus 4.7 s'en sortait sur GrandpaCAD. Je l'ai écarté d'un revers de main. Voici les données que je lui ai balancées :
- Débit OpenRouter. Gemini 3.1 tourne autour de 62 tokens/seconde en 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 ceux de Gemini, 10 fois plus que ceux de Kimi.
Trois sources indépendantes, toutes allant dans le même sens : plus rapide, meilleur et moins cher ailleurs. Pour être honnête, j'ignorais les mises à jour de Claude depuis un moment. Sonnet 4.5 a perdu face à Gemini sur cette charge de travail précise l'année dernière, et je n'ai même jamais pris la peine de faire tourner un modèle Opus car le prix par token m'avait effrayé avant même l'évaluation. Claude Code me semble aussi lent dans mon travail au 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 celui-ci).
| Métrique | Opus 4.7 | Gemini 3.1 | GPT 5.5 | Kimi K2.6 |
|---|
| Score pondéré | 0.587 | 0.556 | 0.501 | 0.545 |
| Adhérence | 0.584 | 0.614 | 0.591 | 0.481 |
| Taux de réussite | 85,7 % | 76,2 % | 90,5 % | 66,7 % |
| Taux d'erreur | 9,5 % | 0,0 % | 0,0 % | 14,3 % |
| Relances de code (moy) | 0.19 | 0.24 | 0.10 | 0.52 |
| Durée moyenne | 0m 32s | 1m 32s | 1m 46s | 0m 53s |
| Coût moyen | 0,10 $ | 0,21 $ | 0,94 $ | 0,02 $ |
| Coût total du benchmark | 2,04 $ | 4,48 $ | 19,79 $ | 0,51 $ |
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 on compte les tokens. Mais les modèles qui réfléchissent consument des tokens que vous ne voyez pas, et ce qui compte vraiment, c'est le temps réel passé sur votre prompt. Opus réfléchit moins, il livre plus vite. Je peux exécuter trois générations Opus le temps que Gemini en finisse une seule.
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 deux fois moins cher que Gemini, un dixième du prix 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 terminé, Opus est l'option bon marché.
Pourquoi la 3D est le benchmark LLM avec le signal le plus fort
C'est la partie sur laquelle je reviens sans cesse. Si vous lisez des textes générés par 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 recoins que vous ne remarquerez pas avant des mois : de subtiles dérives factuelles, des biais silencieux, un raisonnement qui semble correct mais qui ne tient pas la charge en profondeur.
Le code est une étape au-dessus. Un code qui ne compile pas, ne compile pas. Vous interceptez les erreurs de logique aux frontières 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 il ne le fait pas. Le support de téléphone maintient le téléphone ou il bascule. Les pieds de la chaise touchent le sol ou ils flottent. Vos yeux repèrent une 3D ratée en 200 millisecondes, de la même manière que vous repérez une faute orthographique dans votre propre nom. Il n'y a pas de couche intermédiaire abstraite où les bugs peuvent se cacher. La reconnaissance des formes pour les objets physiques est le plus ancien module de votre cortex visuel, et il ne se trompe pas.
C'est pourquoi les classements 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 générer réellement un modèle imprimable à partir d'un vrai prompt utilisateur et de le regarder réussir ou échouer. Le fossé 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. Pas parce que je suis intelligent, mais parce que la 3D ne pardonne pas, contrairement au texte et au code.
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 du prix d'Opus)
- L'inférence la plus rapide sur le bon fournisseur (Baseten l'enregistre jusqu'à 120 tokens/seconde, le double du taux typique)
J'ai commencé ce test en pensant que Kimi allait l'emporter haut la main. Un tiers du prix, le double de la vitesse, et un ELO 3D plus élevé que le modèle contre lequel je le testais.
Ce ne fut pas le cas. Kimi K2.6 a eu l'adhérence la plus basse (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é presque le triple de relances de code par rapport à Opus.
Donc : l'ELO 3D public plaçait Kimi au sommet, le fournisseur lui a donné le débit le plus rapide du test, et le prix par token était imbattable. Trois signaux distincts annonçant un gagnant. Les générations réelles étaient 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 problème totalement différent.
GPT 5.5 en priorité est plus précis. Il est aussi trop lent pour le déployer.
GPT 5.5 avec le niveau de service prioritaire a obtenu le taux de réussite le plus élevé (90,5 %) et le taux d'erreur de code le plus bas (0,10 relance en moyenne). C'est un modèle véritablement solide.
Il est aussi lent. La génération moyenne a pris 1m 46s, 3,3 fois plus lente qu'Opus 4.7. Et la façon dont les utilisateurs de GrandpaCAD travaillent réellement est itérative : prompt, observation visuelle du résultat, ajustement, nouveau prompt. La vitesse fait l'expérience. Je préfère donner à un utilisateur trois tentatives rapides sur le modèle qu'il souhaite plutôt que de le faire attendre pour un modèle plus poli mais plus lent. L'écart de taux de réussite est réel (90,5 % contre 85,7 %) mais il est de moins de cinq points de pourcentage, et trois générations d'Opus battent presque toujours une génération de GPT 5.5 en pratique.
La question du coût est secondaire mais frappante une fois qu'on aligne les chiffres. Le niveau prioritaire augmente le prix de l'API de 2,5 fois, et le coût de génération moyen 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 juger la différence visuelle par vous-même.
Pourquoi je ne fais plus confiance aux benchmarks publics
Deux raisons.
Premièrement, les benchmarks ELO 3D mesurent la mauvaise chose. Les votes de préférence côte à côte sur la qualité de rendu ne valent pas un test de bout en bout pour savoir si un prompt a produit un modèle imprimable utile. Kimi était le canari dans la mine sur ce coup. Il a dominé le classement et a fini dernier sur le vrai travail.
Deuxièmement, les laboratoires ont tendance à publier leurs propres benchmarks. L'article de benchmark du Composer 2 de Cursor (mars 2026) en 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. Le schéma est général : si un chiffre est publié par l'entité qui bénéficie de sa valeur élevée, traitez-le comme du marketing jusqu'à preuve du contraire.
Le seul benchmark auquel je fais confiance maintenant est celui que j'exécute sur ma propre charge de travail, avec 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-le sur de la vraie génération de code 3D. Si vous déployez des résumés juridiques, testez sur des résumés juridiques. Votre benchmark gère presque certainement des données qui sont en désaccord avec les benchmarks publics pour les mêmes modèles, car ces derniers 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 d'utilisateurs), Opus 4.7 gagne sur la vitesse, le coût et le score pondéré. GrandpaCAD utilise maintenant Opus 4.7 par défaut.
Si vous voulez les données brutes, la page /evals répertorie 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é, est dans comparaison des LLM de pointe pour la génération 3D. Le classement évolue vite.
