Un vocabulaire gelé de 16 Mo rivalise avec un vocabulaire entraînable dans les petits LLM

Dans Gemma 3 270M, la table d'embeddings occupe 168 millions des 268 millions de paramètres, soit près des deux tiers du modèle. Les auteurs d'un nouveau travail, repéré dans les Hugging Face Daily Papers, se sont demandé ce que cette table apporte réellement. Ils l'ont remplacée par une table gelée : des codes de 512 bits, 16 Mo, aucun paramètre entraînable. Ils ont entraîné à partir de zéro un corps de modèle d'architecture Gemma sur 2,05 milliards de tokens, avec un vocabulaire classique d'un côté et un vocabulaire gelé de l'autre. Sur LAMBADA, HellaSwag et PIQA, la version à table gelée s'est montrée meilleure ou égale. Seul ARC-Easy reste à l'avantage de la variante entraînable.

Pourquoi le vocabulaire est devenu le premier poste de dépense

Dans les petits modèles, le vocabulaire pèse plus que tout le reste. Les méthodes de quantification laissent généralement les embeddings en 16 bits : une fois le reste du réseau compressé, c'est donc la table qui occupe l'essentiel du fichier. Le vocabulaire lui-même empêche d'alléger davantage le modèle.

Les auteurs sont partis d'une table d'embeddings préentraînée. Ils l'ont projetée une seule fois par analyse en composantes principales, puis binarisée selon le signe. Le résultat est un ensemble de codes de 512 bits pesant 16 Mo. Cette table ne change pas pendant l'entraînement et ne nécessite aucun gradient. La version entraînable gagne 0,20 nat de loss de validation, mais coûte 2,6 fois plus de paramètres entraînables. Sur les benchmarks pratiques, cet écart est à peine visible.

Corps ternaire et vitesse sur un ordinateur portable

Ensuite, les auteurs ont combiné le vocabulaire gelé avec le corps ternaire BitNet b1.58. Le modèle complet tient en 46 Mo et reste, sur LAMBADA et PIQA, au niveau du modèle float. Sur le CPU d'un ordinateur portable, il génère 615–740 tokens par seconde et occupe 62 Mo de mémoire. À titre de comparaison, le GGUF 8 bits du modèle float sous llama.cpp est cinq à six fois plus lent et exige sept fois plus de mémoire.

Les chiffres clés du travail :

• Table d'embeddings de Gemma 3 270M : 168 millions de paramètres sur 268 millions.
• Vocabulaire gelé : codes de 512 bits, 16 Mo, 0 paramètre entraînable.
• Données d'entraînement : 2,05 milliards de tokens, identiques pour les deux versions.
• Coût de la table entraînable : 2,6 fois plus de paramètres entraînables pour 0,20 nat de loss.
• Modèle ternaire complet : 46 Mo, 62 Mo de mémoire en fonctionnement.
• Vitesse sur CPU d'ordinateur portable : 615–740 tokens par seconde.

Mots rares et nouveaux tokens

Les résultats sur la queue de distribution sont les plus intrigants. Sur les mots rares, la table gelée l'emporte de 1,7–2,3 nat. Le comportement lors de l'extension du vocabulaire est plus frappant encore : après l'entraînement, les auteurs y ont ajouté 10 000 nouveaux mots. Le modèle aux codes gelés a perdu environ 3%, tandis que la qualité du modèle à table entraînable s'est effondrée de 43%. L'explication tient à ce que les nouveaux tokens reçoivent des codes issus du même espace que celui dans lequel le modèle travaille déjà, et non un vecteur auquel le corps du modèle n'est pas adapté.

Les limites existent aussi. L'expérience porte sur une seule architecture, sur un petit corpus de 2,05 milliards de tokens et sur un modèle d'environ 270 millions de paramètres. L'article ne permet pas de dire si le même effet se produirait à plus grande échelle. Les auteurs soulignent qu'ils ont publié les poids, les données et chaque réponse des évaluations : chacun peut donc vérifier les chiffres de son côté.

À qui cela peut servir

Pour ceux qui conçoivent des modèles pour des appareils sans GPU, la conclusion est simple : la taille du vocabulaire mérite d'être traitée comme un poste de budget à part, et non comme un sous-produit du choix du tokenizer. Si une table gelée maintient la qualité sur LAMBADA, HellaSwag et PIQA, les paramètres entraînables peuvent être investis dans le corps du modèle. Un modèle de 46 Mo, qui produit des centaines de tokens par seconde sur un ordinateur portable ordinaire, convient aux suggestions hors ligne, au traitement local de texte et aux assistants embarqués.

Autre avantage : la possibilité d'ajouter de la terminologie après l'entraînement avec très peu de pertes, ce qui compte pour les domaines spécialisés comme la médecine, le droit et le code. Avant tout déploiement, il vaut mieux tester des tâches comme ARC-Easy, où la table entraînable conserve tout de même l'avantage.