Un modèle 27B compressé à deux bits par poids

Un modèle 27B compressé à deux bits par poids

Le 9 octobre, Underdog AI a publié Saluki 27B, une version compressée du modèle Qwen 3.8 27B. La compression est agressive : deux bits par poids, ce qui enferme le tout dans un fichier d'environ 7,89 gigaoctets. Underdog affirme que le résultat conserve environ 96 pour cent des performances de l'original sur les benchmarks, et que sur les tâches d'appel d'outils il dépasse même le modèle de taille complète. Il est distribué sous licence Apache 2.0 pour les flux de travail d'agents en local.

Les chiffres ressemblent à une coquille. Réduire un modèle au quart de sa profondeur de bits se paie d'ordinaire par une grosse perte de qualité. Saluki affirme que ce n'est pas le cas, et que sur la seule tâche qui compte le plus pour les agents, il s'est amélioré.

Pourquoi la quantification à deux bits est difficile

Les poids d'un modèle sont stockés sous forme de nombres, et le nombre de bits par poids détermine la précision que chacun conserve. En 16 bits, un poids peut prendre l'une de plusieurs dizaines de milliers de valeurs. En deux bits, il peut en prendre une sur quatre. Vous demandez à un réseau bâti sur des distinctions fines de s'exprimer avec un vocabulaire quasi inexistant.

La raison pour laquelle cela échoue le plus souvent, c'est que les erreurs se cumulent. Arrondissez chaque poids un peu et la couche est légèrement fausse. Empilez des dizaines de couches légèrement fausses et la sortie s'éloigne fort de l'original. La plupart des travaux de quantification considèrent quatre bits comme un plancher pratique et acceptent une certaine perte de qualité en dessous.

Les méthodes qui descendent plus bas n'arrondissent pas simplement plus fort. Elles décident quels poids peuvent se permettre d'être grossiers et lesquels doivent rester précis, et elles affinent souvent le modèle compressé ensuite pour réparer les dégâts. Faire tenir deux bits ensemble est un processus soigneux et ciblé, pas une opération brutale.

Le résultat sur l'appel d'outils est la partie intéressante

Que Saluki égale l'original sur les benchmarks généraux est notable. Qu'il le dépasse sur l'appel d'outils est plus étrange, et cela pointe vers quelque chose de réel. L'appel d'outils est une tâche structurée : le modèle doit produire un nom de fonction et des arguments corrects, et de petites incohérences font tout échouer. Un modèle légèrement plus bruité peut produire une sortie légèrement plus variée, ce qui, dans ce contexte, peut signifier qu'il trébuche moins sur les cas limites.

Il y a aussi une explication plus simple. Si le processus de compression a inclus un affinage sur des données d'usage d'outils, le modèle obtenu n'est pas seulement plus petit, il est aussi plus étroit dans la bonne direction. Un spécialiste peut battre un généraliste sur sa spécialité tout en perdant sur tout le reste. La lecture honnête, c'est que Saluki est un modèle compressé qui a aussi été orienté vers le travail d'agent, et que ces deux changements expliquent ensemble le résultat.

La densité d'intelligence est la métrique qui compte ici

Underdog présente l'amélioration comme un gain d'intelligence par gigaoctet, environ 7,5 fois l'original. Ce cadrage est exactement le bon pour le cas de l'agent local. Quand vous faites tourner un modèle sur votre propre machine, la contrainte n'est pas le score au benchmark. C'est de savoir si le modèle tient dans votre mémoire et laisse de la place aux applications autour de lui.

Un modèle 27B en pleine précision exige du matériel sérieux. Le même modèle à environ huit gigaoctets tourne sur un ordinateur portable, et c'est sur un portable qu'une bonne partie du travail d'agent se fait réellement : lire des fichiers, exécuter des commandes, vérifier des résultats. La valeur de la compression n'est pas esthétique. C'est la différence entre un modèle capable que vous pouvez exécuter en local et un modèle capable que vous ne pouvez que louer.

Pourquoi les modèles d'agents locaux convergent vers cette taille

Saluki est l'un de plusieurs petits modèles sous licence ouverte qui apparaissent pour faire le travail répétitif au sein de systèmes plus vastes. Le schéma est constant : un modèle d'environ 7 à 30 milliards de paramètres, fortement compressé, sous licence permissive, visant la boucle serrée d'un agent.

La logique est la même à chaque fois. Un agent appelle son modèle de nombreuses fois par tâche, donc le coût et la latence par appel dominent l'expérience. Un modèle assez petit pour tourner en local supprime à la fois l'aller-retour réseau et la facture par token, et cela change la façon dont on peut utiliser l'agent. Vous arrêtez de compter les appels à votre propre assistant.

Il y a une seconde raison, plus discrète. Les modèles exécutés en local n'envoient vos données nulle part, ce qui compte pour quiconque travaille sur du code ou des documents qu'il n'est pas autorisé à téléverser. Pour ce public, la compression n'est pas une optimisation de coût. C'est le seul moyen d'obtenir un modèle capable, tout court.

L'argument des petits fichiers, en un chiffre

Il est utile de rendre la différence de taille concrète. Un modèle de 27 milliards de paramètres en 16 bits occupe environ 54 gigaoctets avant toute surcharge d'exécution. Cela ne tient pas sur la plupart des portables, et ne tient pas dans la mémoire qui reste une fois que le système, un navigateur et un éditeur ont pris leur part. En deux bits, le même nombre de paramètres tombe près de 8 gigaoctets, ce qui tient, et tient à côté des outils que l'agent est censé piloter.

C'est tout l'argument en faveur de la compression à basse précision dans un contexte d'agent local. Il ne s'agit pas de faire tourner un modèle qui ne pouvait pas tourner du tout auparavant, même si cela en fait partie. Il s'agit de faire tourner un modèle assez confortablement pour que l'agent puisse l'appeler de façon répétée sans que la machine le remarque, parce qu'un agent qui ralentit tout le système est un agent que personne ne garde allumé.

Ce qu'il faut vérifier avant d'y croire

Les modèles compressés méritent un scepticisme particulier. Le benchmark mis en avant peut tenir alors que le modèle se dégrade sur les entrées longues et désordonnées que produit le vrai travail. Les dégâts de la quantification apparaissent souvent d'abord sur les formats inhabituels, les contextes longs et les langues rares, dont aucun benchmark court ne rend compte.

Ce que deux bits décrit compte aussi. La profondeur de bits par poids, la taille des groupes, et le fait que certaines couches soient gardées à une précision supérieure changent tous le sens du chiffre. Deux bits dans un schéma n'est pas la même chose que deux bits dans un autre, et la différence n'est pas évidente à partir d'une fiche de modèle.

Ce que tout cela signifie

Le débat sur la frontière porte sur le plus grand modèle que quiconque peut entraîner. Un débat parallèle, tout aussi lourd de conséquences, porte sur le plus petit modèle qui reste assez bon pour être utile sur votre propre matériel. Saluki 27B se situe dans le second débat, et il avance une affirmation précise et vérifiable : que deux bits suffisent pour le travail que les agents font réellement.

Si cette affirmation tient en dehors du benchmark, elle abaisse le plancher de ce qu'une personne peut exécuter en local, et c'est généralement à un plancher plus bas que se construit la vague de produits suivante. Le modèle n'est pas l'histoire. Le rétrécissement du modèle l'est.

Il vaut la peine de rappeler que ce domaine est jeune. Les méthodes qui font fonctionner les poids à deux bits s'écrivent encore, et chaque sortie est autant une démonstration d'une technique de compression qu'un produit. Saluki est intéressant moins pour ce qu'il est aujourd'hui que pour ce qu'il prouve qu'il est désormais possible de faire passer dans un tuyau étroit. Le prochain modèle de cette lignée sera plus petit, plus affûté, ou les deux, et le plancher baissera encore.