Dans la bibliothèque Ollama, 7 modèles « morts » sur 305 : ils n'écrivent pas de code

Lorsqu'un développeur exécute un modèle de langage sur son propre ordinateur, il télécharge presque toujours un fichier compressé depuis un catalogue public. Cette compression s'appelle la quantification : les poids du modèle sont stockés non pas en 16 bits, mais en 2–8 bits, afin que le fichier tienne en mémoire. Ces fichiers sont publiés par les opérateurs de catalogues ou par des bénévoles, et ni les pages des catalogues ni les métadonnées n'indiquent que le fichier a été testé en conditions réelles.

Les chercheurs ont voulu vérifier cela à l'échelle d'un catalogue entier : ils ont pris les 305 builds éligibles (tags) de la bibliothèque officielle d'Ollama et lancé sur chacun des tâches de programmation. Sept builds, soit 2,3%, se sont révélés inutilisables : ils ont résolu au plus 6 tâches sur 164.

Comment les fichiers morts ont été repérés

L'échantillon couvre 15 familles de modèles : huit spécialisées dans le code, sept généralistes. Cela représente 35 variantes de modèles ; 291 builds sont quantifiés, 14 sont stockés en précision 16 bits classique. S'y ajoutent 22 fichiers populaires de la communauté, issus de 12 dépôts Hugging Face.

La vérification s'est déroulée en deux étapes :

• Filtre rapide. 15 tâches de HumanEval+, choisies parmi les 39 tâches résolues par les 23 configurations Qwen2.5-Coder réputées saines. Un build qui en résolvait moins de 9 sur 15 devenait suspect. La génération prend environ 30 secondes par fichier. • Passage complet. Les suspects ont reçu les 164 tâches de HumanEval+. Un build était déclaré inutilisable s'il résolvait moins de 10% des tâches et accusait en plus un net retard sur la version en haute précision du même modèle.

Tous les tests ont tourné sur une carte graphique RTX 4090, avec décodage glouton et graine fixe (seed 42). Un second passage sur une autre machine a donc produit les mêmes 225 réponses, octet pour octet. Les chercheurs ont aussi découvert une erreur dans le décompte lui-même : à cause de délais d'expiration, la tâche HumanEval/15 était comptée comme échouée presque partout. Après nouvelle vérification des builds suspects, il en restait 39 au lieu de 50, et les sept principaux suspects n'ont pas changé.

Les sept sont des versions fortement quantifiées de modèles de 4 milliards de paramètres ou moins. Cinq relèvent de Qwen et de phi3.5. Deux autres tags concernent llama3.2 à 1 milliard de paramètres. Ils n'ont pas été reconstruits, en raison de la licence des poids d'origine, et la cause de leur défaillance reste donc inconnue. Deux fichiers de la communauté ne fonctionnent pas non plus ; ils ont été examinés séparément avec différents templates de chat.

Les fichiers sont intacts, c'est la recette qui pèche

Les chercheurs ont reconstruit cinq des suspects à partir des poids d'origine, selon la recette indiquée dans les métadonnées, c'est-à-dire sans calibrage. Ils ont ensuite comparé les tenseurs : type, forme et octets. Le résultat est inattendu : les cinq fichiers du catalogue coïncident intégralement avec la reconstruction. La conversion n'a causé aucune corruption. Ce sont des quantifications exactes des poids d'origine, mais elles ne fonctionnent tout simplement pas.

Ils ont ensuite testé le calibrage. Il s'agit de la matrice d'importance (imatrix) : des statistiques d'activation collectées sur un échantillon de texte. Elle indique au quantificateur où l'erreur d'arrondi est la plus dangereuse, ce qui lui permet de choisir plus précisément les échelles des blocs. La matrice a été construite soit sur 100 fragments de WikiText-2 de 512 tokens chacun, soit sur 1,5 Mo de code Python du dépôt llama.cpp.

Voici les résultats :

• Pour Qwen2.5-Coder-3B, sur trois des quatre niveaux de compression défaillants, le score est passé de zéro à 76–113 tâches sur 164, soit 46–69%. La version 4 bits du même modèle en résout environ 80%. • La même recette sans calibrage, appliquée à Qwen2.5-Coder-1.5B, a donné un modèle fonctionnel. La recette seule ne permet donc pas de prédire la panne. • Parmi les 66 builds ayant passé le filtre et vérifiés par échantillonnage, aucun n'est inutilisable.

La première version de l'étude choisissait sa référence d'après l'auteur de la conversion, et non d'après la recette, et qualifiait les fichiers de défectueux. La reconstruction selon la même recette a corrigé cette conclusion.

Que doivent faire les opérateurs de catalogues et les utilisateurs

Des problèmes de fichiers dans les catalogues se sont déjà produits. En 2024, les mainteneurs de llama.cpp ont découvert que certaines conversions utilisaient un prétraitement incorrect du texte avant la tokenisation, et les utilisateurs se plaignaient de plantages. Deux ans plus tard, 26 des 305 tags officiels n'indiquent toujours pas de type de tokenizer.

Les auteurs formulent les recommandations suivantes :

• Avant publication, faire passer les builds à faible nombre de bits par un court test d'exécution de code. Ils ont publié pour cela l'outil quantcheck ainsi que les données de l'audit. • Si un build échoue au test, il faut le calibrer ou ne pas le publier. • Les utilisateurs ne doivent pas considérer un tag de catalogue comme vérifié, surtout à 2–3 bits par poids et sur des modèles de 4 milliards de paramètres ou moins.

L'étude a aussi ses limites. La vérification ne porte que sur des modèles de code, sur une seule bibliothèque officielle et sur un petit échantillon de Hugging Face. Les deux tags défaillants de llama3.2-1B restent inexpliqués. Le filtre repose sur des tâches sélectionnées d'après des builds Qwen sains, et, parmi les modèles deepseek-coder-1.3B, six tags n'obtiennent de toute façon que 1–6 sur 15, même en haute précision, mais c'est une autre histoire. La conclusion principale reste toutefois claire : la conformité exacte à la recette ne garantit pas qu'un fichier fonctionne, et un test bon marché de 30 secondes a détecté ce qui traînait depuis des mois dans le catalogue.