Poids ouverts, recettes fermées : ce que disent quatre rapports sur les modèles téléchargeables

L'argument des poids ouverts repose sur une promesse : on obtient le fichier, donc on obtient le contrôle. Quatre documents publiés entre mai et septembre 2026 testent combien de cette promesse survit au contact des mesures. Ils ne s'accordent guère. Ils s'accordent sur un point : « ouvert » fait moins de travail que les titres le laissent supposer.

Le chiffre de quatre mois et ce qu'il cache

Mozilla a publié la version 1.1 de son rapport State of Open Source AI le 15 septembre, en utilisant des données courantes au 1er septembre, selon Tom's Hardware. Le résultat principal : le meilleur modèle ouvert traînait le leader fermé de trois points sur l'Artificial Analysis Intelligence Index à 60 % du prix, et était en retrait de deux points derrière Claude Fable 5 à 30 % du prix. L'estimation ajustée de Mozilla sur les données de horizon de tâche METR situe l'écart ouvert-fermé à environ 4,4 mois, en ligne avec l'estimation de quatre mois d'Epoch AI.

METR évalue les modèles selon la longueur de la tâche, mesurée en temps de travail humain, qu'ils accomplissent la moitié du temps. Selon l'estimation ajustée de Mozilla, les modèles fermés gèrent des tâches qui prennent 8 à 12 heures à des experts humains. Les modèles ouverts y parviennent environ quatre mois plus tard, avec une capacité qui double tous les 3,9 mois contre 5,5 pour les fermés, selon les calculs de Mozilla. Tom's Hardware note une réserve que Mozilla porte elle-même : le chiffre de quatre mois et le prix token de 30 % sont mesurés API à API sur des points d'accueil hébergés, au prix catalogue.

Le graphique matériel est le plus inconfortable

Le même rapport inclut un graphique qui se situe mal à côté du titre principal. Le meilleur modèle ouvert qui tient sur un serveur obtient un score de 52,6 ; le meilleur qui tient sur une GPU obtient 40. La chute depuis le sommet est de 10 et 23 points respectivement, un écart plus large que quatre mois de progression de capacité.

Le checkpoint natif MXFP4 de Kimi K3 pèse environ 1,56 To répartis en 96 shards, et la configuration de service de Mozilla liste 64 accélérateurs ou plus, tandis que vLLM demande au moins huit GPU GB300, avec plusieurs nœuds pour le trafic de production. La formulation du rapport lui-même est que c'est ouvert mais non exécutable par la plupart de ceux qui le détiennent. Tom's Hardware a placé le besoin mémoire près de 1,5 To en juillet. Il y a des exceptions. L'Inkling-Small de Thinking Machines, sous licence Apache 2.0, a une version NVFP4 qui tient sur une B300 avec un plancher de 180 Go. C'est un point de données réel, et c'est un modèle.

Poids ouverts ne veut pas dire open source, et la différence porte

La Open Source Initiative a rendu la distinction explicite dans une publication du 19 septembre. Les modèles d'IA ont trois composants principaux : les données d'entraînement, les poids et paramètres, et le code utilisé pour la préparation des données et l'entraînement. Les publications à poids ouverts publient les poids. Elles ne publient pas le reste.

Les poids ouverts vous permettent d'exercer certaines libertés, mais pas toutes, et seulement dans une certaine mesure. Le vrai Open Source AI vous permet d'exercer les quatre libertés sans restriction.

Les quatre libertés en question sont l'utilisation, l'étude, la modification et le partage sans demander la permission au titulaire des droits. L'OSI évalue la valeur de la demande de l'écosystème Open Source à 8 800 000 000 000 $ et soutient que les modèles à poids ouverts limitent la modification et empêchent l'étude complète, car sans code et données d'entraînement, on ne peut pas inspecter pourquoi un modèle a produit une sortie. Le rapport de Mozilla, selon Tom's Hardware, compte 16 publications ouvertes notables, aucune desquelles ne livre la recette de données requise par la définition de la Open Source Initiative.

Ce que la recherche sur la mémorisation ajoute aux luttes sur le droit d'auteur

Un article sur arXiv, d'abord soumis le 18 mai 2025 et révisé jusqu'au 20 juillet 2026, mesure combien de 200 livres 14 LLM à poids ouverts retiennent réellement. Les auteurs sont A. Feder Cooper, Mark A. Lemley, Allison Casasola, Ahmed Ahmed, Aaron Gokaslan, Amy B. Cyphert, Christopher De Sa, Daniel E. Ho et Percy Liang.

Leur cadrage est tranchant : les plaignants et les défendeurs dans les procès sur le droit d'auteur de l'IA générative font des affirmations générales et opposées sur la mémorisation, et les deux positions, dit l'article, simplifient dramatiquement la relation entre mémorisation et droit d'auteur. Sur plus de 3 000 expériences, les auteurs trouvent que la plupart des LLM ne mémorisent pas la plupart des livres, ni entiers ni en partie. Mais les exceptions comptent. Llama 3.1 70B mémorise entièrement certains livres, y compris Harry Potter et la Pierre philosophale, selon l'article. La mémorisation y est assez étendue pour que le livre entier puisse être extrait de manière déterministe presque mot pour mot en utilisant ses premiers mots comme invite. Les auteurs déclarent que les résultats ont des implications importantes pour les affaires de droit d'auteur, bien que pas celles qui favorisent sans ambiguïté un côté ou l'autre.

Les déploiements plus petits et plus étranges

Toute publication à poids ouverts ne cherche pas la frontière. Superwhisper a publié S1-mini, un normalisateur de texte de 0,6B paramètres fine-tuné depuis Qwen/Qwen3-0.6B, sous Apache 2.0 plus une clause de nommage. Il fait un seul travail : réécrire la sortie brute de la transcription vocale en texte écrit propre. Sur un ensemble retenu de 7 519 cas anglais, il atteint 94,8 % de précision token, et la version quantifiée est un fichier de 462 MiB qui tourne sur un CPU de laptop. La carte du modèle est franche : ce n'est pas un modèle de discussion et il ne suivra pas les instructions générales.

La carte du modèle documente aussi une particularité de comptage du Hub : la barre latérale rapporte 0,8B paramètres parce que l'embedding de 155,6M paramètres est compté deux fois, donnant 751,6M éléments de tenseur contre 596,0M paramètres uniques. La mise en page est héritée de Qwen3-0.6B, qui rapporte 0,8B sur le Hub pour la même raison.

Le raisonnement d'un acheteur, et ses limites

Un compte rendu de déploiement par James Cruce, publié le 22 septembre, décrit le choix de Laya, un modèle de décision à poids ouverts de 421M paramètres avec un encodeur ModernBERT-large et une limite de 1 024 tokens, plutôt que le service Jev hébergé de TypeSafe. L'éditeur de Laya l'a entraîné sur quatre flux de travail synthétiques : observabilité d'agent, service client, traitement de factures et incidents de sécurité.

Cruce est explicite sur ce que la comparaison prouve. TypeSafe liste Jev à 0,042 $ par million de tokens d'entrée sans charge pour les tokens de sortie et des choix de jusqu'à 255 options. Laya tourne sur une API loopback-only sur son Mac Studio avec un M3 Ultra et 256 Go de mémoire unifiée, donc les décisions de routine ne quittent jamais la machine. Il déclare clairement que la confidentialité et le contrôle étaient les raisons décisives et que le coût était un effet secondaire, sans chiffre d'économie à donner. Il n'a pas testé si Laya bat Jev en général.

Il signale aussi que la carte du modèle avertit que Laya est trop confiant et a besoin d'une calibration spécifique au domaine, et qu'une réponse tapée peut être structurellement parfaite et factuellement fausse. Sa conclusion est étroite : le traiter comme un recommandateur dans un programme, jamais comme une source d'autorisation ou de vérité.

Ce qui tient

Les quatre documents pointent dans la même direction sans dire la même chose. Les données de Mozilla disent que les poids ouverts sont proches en capacité et beaucoup moins chers au prix catalogue hébergé, tandis que son propre graphique matériel dit que les modèles au sommet ne sont pas quelque chose que la plupart des gens peuvent exécuter. L'OSI dit que l'étiquette est étirée au-delà de ce qu'elle signifie. L'article sur la mémorisation dit que les arguments en tribunal des deux côtés sont trop larges par rapport à ce que montrent les expériences. Le compte rendu de Cruce dit que la raison décisive pour choisir les poids ouverts peut être le contrôle sur l'endroit où vont les données, pas la position au benchmark.

La légende du graphique de Mozilla elle-même lit : « l'écart se réinitialise à chaque cycle de publication ». Ses données s'arrêtent au 1er septembre, et les tableaux en direct ont bougé depuis. Artificial Analysis est passé à l'index v4.3 avec un ensemble d'évaluation différent ; le tableau en direct a Claude Fable 5.1 à 53 sur son réglage d'effort le plus haut avec Kimi K3 à 44. Le tableau Terminal-Bench 2.1 de vals.ai, mis à jour le 11 septembre, est mené par GPT-6 Astra à 87,27 % avec Fable 5.1 à 85,02 %.

Un élément supplémentaire reste non résolu dans le dossier. K3 porte une allégation détaillée dans l'avis conjoint NSA/CISA/FBI AA26-251A du 8 septembre, que le rapport de Mozilla énonce comme « affirmée, et non démontrée » : que Moonshot a extrait des données de Claude Fable 5 pour entraîner K3 par distillation. Le 17 juillet, Artificial Analysis avait K3 à 57 contre 60 de Fable 5. Le 1er septembre, Mozilla l'avait deux points en retrait. Si cet écart réduit vient d'un entraînement indépendant ou de l'extraction alléguée, ce n'est pas quelque chose que l'un de ces quatre documents établit.