200 edits réels, 0.27 point d'écart : ce que mesurent les benchmarks d'image

Trois chiffres, trois discours différents

Quand un nouveau modèle d'image sort, on vous envoie un communiqué avec un graphique. Sur le graphique, le nouveau modèle est en général en haut, classé selon une métrique choisie par l'éditeur, mesurée sur un jeu de données qu'il a construit lui-même. Tout le monde dans le métier le sait et cite quand même le graphique, parce qu'il n'y a rien d'autre à citer le premier jour.

L'exemple le plus clair ce mois-ci, c'est FLUX 3 Image Klein, la sortie open weights 5.6B de Black Forest Labs le 15 octobre. En une semaine, trois séries de chiffres circulaient, et leur désaccord était instructif.

Les chiffres Elo de l'éditeur : première place en text-to-image, en génération multi-références et en édition d'image parmi les modèles open weights, devant des concurrents plus gros. Face à son propre FLUX.2 klein 9B, il gagne 91 Elo en text-to-image et 70 en édition, avec 38% de paramètres en moins.

Les chiffres de latence de l'éditeur : une latence API médiane de 4.54 secondes en text-to-image et de 7.18 secondes en édition à un mégapixel, plus rapide que les quatre concurrents nommés. La note méthodologique ajoute que le nouveau modèle a été chronométré sur les serveurs de BFL, tandis que les autres l'ont été depuis le client, polling et temps réseau inclus, et qu'un concurrent a été mesuré sur son offre medium plutôt que large.

Le test à l'aveugle d'un tiers : 200 tâches d'édition réelles, 6.93 pour Klein et 7.20 pour Nano Banana 2.1, soit 0.27 point d'écart sur une échelle de dix, le même test relevant que Klein peine sur l'ajustement de pose et la composition multi-images. Coût par image : environ un cinquième de celui du concurrent.

Aucun de ces chiffres n'est malhonnête. Ils répondent à des questions différentes, et la confusion vient de ce qu'on les traite comme une seule et même question.

Ce que l'Elo peut dire, et ce qu'il ne peut pas

L'Elo est un score de préférence. Il dit que lorsqu'on montre deux sorties à des évaluateurs humains en leur demandant laquelle est la meilleure, l'une est choisie plus souvent. C'est une vraie mesure, et c'est la bonne mesure pour "est-ce que ça a l'air meilleur".

C'est aussi une mesure avec un angle mort précis : elle écrase le contexte de la tâche. Un modèle peut gagner une comparaison Elo en moyenne tout en perdant largement sur la seule chose dont vous avez besoin. Si votre travail, ce sont des packshots sur fond blanc, des changements de pose ou la composition de trois références en une scène cohérente, cette moyenne n'est pas la vôtre.

Le résultat le plus utile du test à l'aveugle n'est pas le score. C'est le mode d'échec. Deux cents tâches d'édition réelles, et les erreurs récurrentes portaient sur la pose et la composition multi-références, exactement les tâches où la machinerie de mise en page est censée aider. C'est une phrase bien plus actionnable que "0.27 point derrière", parce qu'elle vous dit quels travaux envoyer ailleurs.

Il y a aussi une question d'échelle qu'il vaut mieux dire franchement. Sur une note humaine en dix points, 6.93 contre 7.20, c'est un petit écart. Il est bien dans la plage où les images précises choisies pour le jeu de test, et le goût des évaluateurs, peuvent inverser le classement. Un écart de cette taille est un indice, pas un verdict.

La colonne des coûts, celle que tout le monde saute

Voilà le chiffre qui aurait dû être dans le titre : un cinquième du coût par image.

Si le modèle A est 4% meilleur et 5 fois plus cher, la bonne réponse pour la plupart des workflows n'est pas "utiliser A". C'est "utiliser B pour les quatre-vingts pour cent d'images faciles et A pour les vingt pour cent difficiles". Ce n'est pas un compromis. La production a toujours fonctionné comme ça, personne ne tourne chaque plan sur la pellicule la plus chère.

Le coût change aussi les comportements. Un modèle qui coûte cinq fois moins, c'est un modèle qu'on peut se permettre de tester : cinq variantes au lieu d'une, une deuxième tentative sur une main ratée, une passe de plus sur un arrière-plan. Le nombre d'itérations est un levier de qualité qui n'apparaît jamais dans un benchmark, et c'est la principale raison pour laquelle les modèles bon marché gagnent en pratique plus souvent que leurs scores ne le laissent croire.

C'est le même schéma dans les données du marché API. Dans l'index gateway de Vercel d'octobre, un seul modèle open weights bon marché a traité près de la moitié des tokens de septembre pour moins de 3% des dépenses. Le volume suit le prix, et quelques pour cent de qualité survivent rarement au contact d'un budget.

Là où les chiffres de l'éditeur comptent encore

Rien de tout cela ne rend les benchmarks officiels inutiles. Deux des affirmations sont structurellement utiles.

L'affirmation sur l'efficacité des paramètres, de meilleurs scores avec 38% de paramètres en moins, est réfutable et importante en termes de direction, parce qu'elle prédit le déploiement, pas seulement la qualité. Un backbone image de 5.6B plus un encodeur texte de 4B et un upsampleur de prompt 9B optionnel, ce n'est pas la même chose qu'un système de 5.6B, et le fait que le petit modèle ait besoin d'un modèle de langage pour écrire de bons prompts est en soi un résultat. Les prompts courts produisent des résultats médiocres ; c'est une contrainte de déploiement déguisée en note de bas de page.

L'affirmation sur la latence est utile aussi, même avec une méthodologie qui avantage l'équipe locale. Quatre à sept secondes au mégapixel pour un modèle exécutable en local, c'est le chiffre qui décide si un outil interactif donne l'impression d'être interactif. Si vous construisez une interface où quelqu'un trace un cadre et attend, c'est ce chiffre qui compte, et il n'est sur aucun graphique Elo.

Comment lire le prochain lancement

Quatre questions, dans cet ordre, et vous pouvez sauter la majeure partie du graphique.

Quel était le jeu de test ? S'il a été construit par l'éditeur, traitez-le comme une démo, pas comme une mesure.

Était-ce à l'aveugle et par un tiers ? Deux cents tâches réelles avec l'identité des modèles masquée valent plus que dix mille comparaisons d'éditeur.

Sur quoi a-t-il échoué ? Le mode d'échec, c'est la décision produit. "Moins bon sur les changements de pose" vous dit où ne pas l'utiliser.

Combien ça coûte ? Normalisez chaque score par le prix avant de comparer, et rappelez-vous que le coût d'une nouvelle tentative fait partie du coût d'un modèle.

Le modèle qui gagne le graphique et celui qui gagne votre pipeline ne sont souvent pas le même, et l'écart entre les deux tient généralement à une colonne que personne ne pense à capturer.

Le constat discret

Les modèles d'image open weights sont devenus assez bons pour que la question ouverte ne soit plus de savoir s'ils peuvent rivaliser. Sur un test à l'aveugle de 200 tâches, un modèle ouvert de 5.6B est arrivé à moins de trois dixièmes de point d'un concurrent fermé, à un cinquième du prix, et les désaccords portaient sur des types de tâches précis plutôt que sur la capacité globale.

C'est un marché mature qui se comporte comme un marché mature : pas de vainqueur unique, du routage par tâche, et une colonne de coûts qui décide de plus de déploiements que n'importe quel benchmark. Les graphiques des éditeurs continueront d'arriver chaque mois. La compétence utile, c'est de savoir lequel des trois chiffres vous regardez réellement.