Les poids ouverts réduisent l'écart, mais celui-ci se réinitialise à chaque cycle

Il s'agit de la version 1.1 d'une évaluation récurrente que Mozilla a publiée pour la première fois sur son blog le 14 juillet. Selon Tom's Hardware, elle repose sur une enquête conjointe de Mozilla et SlashData auprès d'environ 1 400 développeurs, des données de trafic OpenRouter et des indices de benchmarks tiers. Mozilla est une organisation à but non lucratif qui défend les modèles ouverts. TIME a rapporté le 14 juillet que le CTO de Mozilla, Raffi Krikorian, a décrit le rapport comme étant en partie un plaidoyer. Ce cadre compte quand on lit les chiffres.

L'affirmation centrale de Mozilla est que le meilleur modèle ouvert traînait à trois points du leader fermé sur l'Artificial Analysis Intelligence Index, au prix de 60 % de celui-ci, et à deux points derrière Claude Fable 5 pour 30 % du prix. En ajustant les données d'horizon de tâches de METR, Mozilla évalue l'écart ouvert-fermé à environ 4,4 mois, en ligne avec l'estimation de quatre mois d'Epoch AI. METR est une organisation de recherche à but non lucratif qui note les modèles selon la durée des tâches, en temps de travail humain, qu'ils accomplissent la moitié du temps.

Que mesurent réellement les quatre mois

Selon l'estimation ajustée de Mozilla, les modèles fermés traitent des tâches qui prennent 8 à 12 heures aux experts humains. Les modèles ouverts atteignent ce niveau environ quatre mois plus tard. Mozilla calcule un doublement des capacités ouvertes tous les 3,9 mois contre 5,5 mois pour les modèles fermés. Sur le Terminal-Bench 2.1 de vals.ai, qui passe chaque modèle par le même harnais, GLM-5.2 de Z.ai a obtenu un score à un point de Claude Opus 4.7 et à environ quatre points d'Opus 4.8, pour moins d'un cinquième du coût par test.

« Nous voyons la décision de payer pour des modèles fermés comme spécifique à la charge de travail plutôt qu'à l'organisation », a déclaré Krikorian à Ars Technica par e-mail.

L'adoption côté développeurs ne ressemble pas aux revenus. Sur OpenRouter, un marché qui achemine le trafic vers des centaines de modèles, Mozilla a compté huit des dix premiers modèles par volume de tokens en août comme étant à poids ouverts, dont sept construits en Chine. Les fournisseurs fermés ont néanmoins capté 96 % des revenus de la couche modèle sur OpenRouter de mai à septembre 2025, selon la Linux Foundation. Les tokens gratuits ou bon marché et les revenus payants ne sont pas le même marché.

Mozilla recense 16 sorties notables en poids ouverts, mais aucune ne fournit la recette de données exigée par la définition de l'Open Source Initiative. Cette distinction est l'argument central d'un article OSI du 19 septembre intitulé « Open Weights Are Good. Open Source Is Better. ». Les poids ouverts, écrit l'OSI, permettent d'exécuter un modèle localement, de payer un tiers pour l'héberger ou de l'ajuster sur ses propres données. Ils ne permettent pas de l'étudier entièrement, car le code et les données d'entraînement ou un compte détaillé de leur construction ne font pas partie de la sortie.

La réserve matérielle

Le chiffre de 4,4 mois et le prix de 30 % des tokens sont mesurés d'API à API sur des endpoints hébergés au prix du catalogue. Le graphique matériel de Mozilla raconte une histoire plus dure. Le meilleur modèle ouvert qui tient sur un serveur marque 52,6 ; le meilleur qui tient sur un GPU marque 40. La chute depuis le sommet est de 10 et 23 points respectivement, un écart plus grand que ce que quatre mois implique.

Le checkpoint natif MXFP4 de Kimi K3 pèse environ 1.56TB sur 96 shards, selon le rapport. La configuration de service de Mozilla liste 64 ou plus accélérateurs, tandis que vLLM exige au moins huit GPU GB300, avec plusieurs nœuds pour le trafic de production. Tom's Hardware a placé le besoin en mémoire près de 1.5TB en juillet. Le rapport décrit cela comme ouvert mais non exécutable par la plupart de ceux qui le détiennent. Une exception citée est Inkling-Small de Thinking Machines, sous Apache 2.0, dont la version NVFP4 tient sur un B300 avec un plancher de 180GB.

Il y a aussi un problème de timing. Les données du rapport s'arrêtent au 1er septembre. Depuis, Artificial Analysis a déplacé son index vers v4.3 avec un ensemble d'évaluation différent. Le tableau en direct montre Claude Fable 5.1 à 53 sur son réglage d'effort le plus élevé et Kimi K3 à 44, des chiffres que Mozilla n'a pas tracés et qui ne sont pas comparables aux valeurs v4.1.1 qu'il a utilisées. Le tableau Terminal-Bench 2.1 de vals.ai, mis à jour le 11 septembre, est maintenant mené par GPT-6 Astra à 87.27 %, avec Fable 5.1 à 85.02 %. La légende du graphique de Mozilla dit : « l'écart se réinitialise à chaque cycle de sortie. »

K3 porte également une allégation détaillée dans l'avis conjoint AA26-251A du 8 septembre de la NSA, CISA et FBI. L'affirmation, que le rapport de Mozilla énonce comme « alléguée, et non démontrée », est que Moonshot a extrait des données de Claude Fable 5 pour entraîner K3 par distillation, la pratique qui consiste à entraîner un modèle sur les sorties d'un autre. Le 17 juillet, Artificial Analysis plaçait K3 à 57 contre 60 pour Fable 5 ; le 1er septembre, Mozilla le plaçait à deux points derrière.

Petits modèles, tâches étroites

Toute sortie en poids ouverts ne vise pas la frontière. S1-mini de Superwhisper, publié sur Hugging Face, est un normalisateur de texte de 0.6B paramètres pour la sortie de reconnaissance vocale. Il prend une transcription brute ASR et la réécrit en texte écrit : remplisseurs supprimés, faux départs et auto-corrections résolus, ponctuation et majuscules appliquées, nombres parlés, dates, heures, devises et adresses e-mail rendus sous forme écrite. Sur un ensemble retenu de 7 519 cas en anglais, il atteint 94.8 % de précision des tokens, et la version quantifiée est un fichier de 462 MiB qui tourne sur un CPU de portable.

La fiche modèle est inhabituellement franche sur ce qu'elle n'est pas. S1-mini n'est pas un modèle de chat et ne suivra pas des instructions générales. Il est ajusté à partir de Qwen/Qwen3-0.6B et s'attend à une ligne de contrôle en haut de l'entrée spécifiant le style, la structure et le contexte. Omettez le prompt système, changez sa formulation, ou envoyez des valeurs hors des ensembles entraînés, la fiche avertit, et le modèle peut halluciner ou produire une sortie illisible. Il est uniquement en anglais, licencié Apache 2.0 plus une clause de nommage. La barre latérale du Hub rapporte 0.8B paramètres, mais la fiche explique que model.safetensors stocke lm_head.weight comme une copie matérialisée de l'embedding d'entrée, comptant l'embedding de 155.6M paramètres deux fois : 752 éléments de tenseur contre 596 paramètres uniques. La disposition est héritée de Qwen3-0.6B, qui rapporte 0.8B pour la même raison.

Un motif similaire apparaît dans un compte rendu de déploiement du 22 septembre par James Cruce. Il a choisi Laya, un modèle de décision en poids ouverts de 421M paramètres, plutôt que le Jev hébergé de TypeSafe pour les petits choix bornés que ses agents de codage font. Le checkpoint, convaiinnovations/laya-typed-decisions, a un encodeur ModernBERT-large et une limite de 1 024 tokens, et renvoie des réponses typées : un choix parmi des options nommées, un score sur une échelle ordonnée, ou une probabilité pour une affirmation oui/non. Pas de paragraphes à parser. Jev, en revanche, est un service hébergé en accès anticipé au prix de 0.042 $ par million de tokens d'entrée sans charge pour les tokens de sortie, et TypeSafe dit qu'il gère des choix avec jusqu'à 255 options.

La raison de Cruce pour le changement n'était pas le coût. Il voulait des décisions courantes tournant sur son Mac Studio avec les données locales restant locales, et il voulait contrôler le modèle exact, les options permises et le comportement en cas d'échec. Il n'a pas calculé un point d'équilibre et dit n'avoir aucun chiffre d'économies à donner. Il signale aussi des limites : l'éditeur a entraîné Laya sur quatre flux de travail synthétiques, et le routage de modèle n'en fait pas partie, donc le résultat est un déploiement sur un M3 Ultra avec 256GB de mémoire unifiée, pas un verdict général sur Laya contre Jev. La fiche modèle avertit que le modèle est surconfiant et a besoin d'une calibration spécifique au domaine. « Une réponse typée peut être structurellement parfaite et factuellement fausse », écrit-il.

Le paysage juridique autour des poids est tout aussi incertain. Un papier par A. Feder Cooper, Mark A. Lemley et co-auteurs, soumis pour la première fois le 18 mai 2025 et révisé jusqu'au 20 juillet 2026, a mesuré la mémorisation à travers 200 livres et 14 modèles en poids ouverts dans plus de 3 000 expériences. Son résultat va à l'encontre des deux camps des luttes de droits d'auteur. La plupart des modèles ne mémorisent pas la plupart des livres, en entier ou en partie. Mais Llama 3.1 70B mémorise entièrement certains, dont Harry Potter and the Sorcerer's Stone, au point que le livre entier peut être extrait presque verbatim à partir des premiers mots comme prompt. Les auteurs écrivent que leurs résultats ont des implications significatives pour les affaires de droits d'auteur, bien que ce ne soit pas unaniment en faveur d'un camp.

Aucun de cela ne tranche si les poids ouverts gagnent. Les métriques qui semblent meilleures pour l'ouverture, prix par token et part du trafic routé, sont à côté de métriques qui semblent pires, capacité sur serveur unique et GPU unique et part des revenus. La légende de Mozilla est le résumé honnête : l'écart se réinitialise à chaque cycle de sortie.