OPTIC compresse les embeddings par couche de Gemma 4 E4B d'un facteur 100 et préserve 97,8% de la qualité

Des chercheurs de VILA-Lab ont montré que les tables de per-layer embeddings (PLE) de Gemma 4 E4B peuvent être compressées d'un facteur environ 100 sans quasiment perdre en qualité. La méthode OPTIC conserve 97,8% du résultat du modèle BF16 non compressé, en agrégat sur sept benchmarks. Le meilleur des six quantifieurs classiques testés, la quantification par produit (product quantization), n'atteint que 66,3% pour le même taux de compression. Dans le même temps, sur une carte graphique RTX 4090, la consommation de mémoire GPU chute de 29,7%, tandis que le temps d'exécution n'augmente que de 0,40% au maximum.

Pourquoi les tables d'embeddings sont devenues un problème à part entière

Dans les modèles de langage, une tendance se renforce : la capacité augmente non seulement via les calculs du transformeur, mais aussi via les embeddings. Les per-layer embeddings de Gemma 4 illustrent cette approche. Dans la version E4B, ils représentent 35,2% de l'ensemble des paramètres. C'est une part énorme, qui réside en mémoire — une ressource presque toujours limitée sur l'appareil.

D'où le défi : conserver le bénéfice d'embeddings volumineux tout en respectant un budget de déploiement contraint. À une compression de 100×, les méthodes classiques se heurtent à un plafond. Elles encodent chaque vecteur token-couche indépendamment, et il ne reste qu'environ cinq octets par vecteur. Un code aussi minuscule ne peut transporter beaucoup d'information. De plus, la corrélation entre les couches reste inexploitée.

Un seul code par token plutôt qu'un code distinct par couche

OPTIC (Output-Path-fitted, Token-shared Indexed Codes) fonctionne différemment. Pour chaque token, un unique tuple de codes quantifiés est stocké, partagé entre toutes les couches. À chaque couche, un décodeur affine propre le déploie pour reconstruire le vecteur spécifique à cette couche. Le budget d'octets est dépensé une seule fois par token, puis réparti entre les couches.

Le second volet de l'idée porte sur ce qu'il faut ajuster exactement. Les codes et les décodeurs ne sont pas calibrés sur les vecteurs stockés eux-mêmes, mais sur le chemin de sortie du PLE : le vecteur traverse une porte (gate) et une projection de sortie (output projection), et la compression est évaluée sur le résultat après ces étapes. La fonction objectif correspond ainsi à l'usage réel que le modèle fait des embeddings, ce qui évite de gaspiller de la précision sur des détails sans effet sur la sortie.

Les chiffres de l'étude

• Les PLE représentent 35,2% des paramètres de Gemma 4 E4B.
• Pour une compression d'environ 100×, il reste environ cinq octets par vecteur token-couche.
• BF16 E4B à ~100× : OPTIC conserve 97,8% de la qualité du modèle non compressé (agrégat sur sept benchmarks). La quantification par produit, la meilleure des six méthodes classiques testées, donne 66,3%.
• À 594×, OPTIC conserve 90,5%.
• À 1002×, OPTIC conserve 84,1%.
• Version officielle E4B avec poids linéaires en 4 bits et activations en 16 bits (W4A16) : 96,9% à ~100× de compression des PLE.
• Inférence BF16 E4B à partir des codes compacts à ~100× : mémoire GPU inférieure de 29,7% pour le même cache KV (1 Gio), ralentissement d'au plus 0,40%. Mesure effectuée sur RTX 4090.

Le travail avec W4A16 mérite une attention particulière. La quantification des poids du backbone et la compression des PLE traitent des aspects différents du problème, et le résultat de 96,9% montre qu'ils se combinent : OPTIC ne force pas à choisir entre les deux.

À qui et quand cela sera utile

La principale conclusion pratique pour ceux qui déploient Gemma 4 E4B sur du matériel grand public : les PLE ne sont plus un poste de dépense mémoire incontournable. Une économie de 29,7% de VRAM, pour un cache KV identique, signifie soit la possibilité de tourner sur une carte plus modeste, soit davantage de place pour le contexte. Le ralentissement, jusqu'à 0,40%, est quant à lui pratiquement imperceptible.

Pour les développeurs qui construisent des produits d'IA embarqués, le principe lui-même est intéressant. Si les architectures continuent d'accroître la part des embeddings dans les paramètres, ce sont précisément eux qu'il faudra compresser. Un code commun par token, couplé à des décodeurs propres à chaque couche, ainsi qu'un calibrage sur le chemin de sortie, fournissent un schéma opérationnel pour ce type de modèles.

Les auteurs (Jiacheng Liu, Yaxin Luo, Xiaohan Zhao, Peng Sun, Xinyi Shang, Jiacheng Cui, Yonina C. Eldar et Zhiqiang Shen) ont publié le code et le détail de la méthode sur GitHub, dans le dépôt VILA-Lab/optic. Un artefact prêt à l'emploi, avec une compression des PLE d'un facteur 100, est disponible sur Hugging Face sous le nom gemma-4-E4B-it-OPTIC-100x, ce qui permet de vérifier le résultat sur ses propres tâches. Le préprint est disponible sur arXiv sous la référence 2610.31309.