Gemma : le KV cache qui cesse de suivre le contexte

Gemma 4 est là, sans notice

Google a publié Gemma 4 en avril 2026, dernier-né de ses modèles ouverts. Comme toute la lignée, il tient un contexte de 256K tokens sans que la mémoire ne s’effondre, et ce tour de force repose sur une idée d’attention précise, qu’on va décortiquer : alterner des couches d’attention locale, bornées, et de rares couches globales qui voient tout. Les fichiers de configuration publiés le confirment.

Seul hic : Gemma 4 n’a pas de rapport technique. Pour comprendre pourquoi ce schéma marche, et surtout pour le voir mesuré, il faut se tourner vers la génération précédente (Gemma 3), qui a tout documenté, ablations chiffrées comprises. C’est donc par Gemma 3 qu’on ouvre le capot, avant de revenir à ce que Gemma 4 affine. Et tout part du poste mémoire que ces deux modèles cherchent à dompter.

Le vrai coupable : le KV cache

On parle beaucoup de la taille des poids : « ce modèle de 27 milliards de paramètres tient-il sur ma carte ? ». Mais dès que le contexte s’allonge, un autre poste de mémoire prend le dessus, et il est plus sournois parce qu’il grossit pendant que vous générez : le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire .

Rappelons le mécanisme. À chaque token, l’attention calcule une clé et une valeur, et les conserve pour que les tokens suivants puissent « regarder en arrière ». En attention pleine, chaque couche garde donc le KV de tous les tokens déjà vus, et la mémoire occupée croît linéairement avec la longueur de la séquence, multipliée par le nombre de couches. Pour un modèle de la classe Llama-3 8B en 16 bits, cela représente de l’ordre de 4 Go à 32K tokens, 16 Go à 128K, et près de 128 Go à un million de tokens [estimation, voir Sources]. À ce régime, le cache dépasse de loin le poids du modèle : c’est lui qui décide combien de requêtes vous pouvez servir en parallèle, et jusqu’où vous pouvez pousser le contexte.

La question d’ingénierie devient alors : peut-on garder un long contexte sans que la mémoire suive le contexte ? Gemma répond par une asymétrie assumée entre deux types de couches.

Fenêtre glissante : voir moins pour stocker moins

La première brique est l’attention à fenêtre glissante fenêtre glissante Sliding Window Attention. Attention où chaque token n'attend que les W tokens précédents, au lieu de tout l'historique. Le KV cache de la couche est alors plafonné à W (souvent via un buffer circulaire), au lieu de croître avec la longueur de la séquence. (sliding window attention). L’idée : au lieu de laisser un token regarder tout le passé, on le limite aux W derniers tokens. Une couche à fenêtre de 1024 ne « voit » jamais plus de 1024 positions en arrière, et c’est tout ce qu’elle a besoin de garder en cache.

La conséquence mémoire est directe. Le KV d’une couche locale n’est plus proportionnel à la longueur de la séquence, mais plafonné à W. On l’implémente avec un rolling buffer : un cache de taille fixe W où le token en position i écrit à l’emplacement i mod W, écrasant le plus ancien. Passé W tokens, le cache cesse de grandir. La mémoire d’une couche locale est donc constante, quel que soit le contexte.

Le compromis saute aux yeux : une couche fenêtrée ne voit pas loin. Mais ce n’est pas aussi limitant qu’il y paraît, et Mistral l’a montré le premier. En empilant les couches, la portée effective se compose : un token de la couche k a accès, indirectement, à des tokens situés jusqu’à W × k positions en arrière, parce que chaque couche relit la sortie de la précédente. Sur Mistral 7B (fenêtre 4096, 32 couches), cela donne une portée théorique d’environ 131 000 tokens, bien au-delà de la fenêtre d’une seule couche. La fenêtre glissante seule, empilée, suffit déjà à propager de l’information loin.

Mistral fenêtre toutes ses couches. Gemma fait un choix différent, et c’est là que se joue l’astuce.

L’astuce de Gemma : cinq couches locales pour une globale

Plutôt que de tout fenêtrer, Gemma alterne : la plupart des couches sont locales (fenêtre glissante), mais une minorité reste en attention pleine, les couches globales, qui voient l’intégralité du contexte. Gemma 2 alternait une couche sur deux (ratio 1:1, fenêtre 4096). Gemma 3 a basculé sur un ratio bien plus agressif : cinq couches locales pour une couche globale, et une fenêtre réduite à 1024 tokens.

Couches locales ×5 Fenêtre glissante 1024 : KV plafonné Bornées

Couche globale ×1 Attention pleine : voit tout le contexte Coûteuse

Motif répété 5:1 sur toute la profondeur Gemma 3 / 4

Dernière couche Toujours globale (Gemma 4) Sortie

Le calcul mémoire devient limpide. Sur six couches, cinq ont un KV plafonné à la fenêtre (1024), une seule grandit avec le contexte. Le KV cache total n’est plus toutes_les_couches × longueur, mais à peu près (couches_locales × 1024) + (couches_globales × longueur). À contexte long, le terme qui explose (celui qui est proportionnel à la longueur) ne s’applique plus qu’à une couche sur six. Vous ne payez le prix fort du contexte que sur un sixième de l’architecture.

Les chiffres publiés par Google le confirment, et surtout ils le chiffrent. Dans le rapport technique de Gemma 3, une ablation mesure la mémoire à 32K tokens : une configuration « tout global » impose un surcoût mémoire de 60 % (le KV cache rapporté au poids du modèle) ; le schéma local/global avec fenêtre 1024 le ramène à moins de 15 % : une réduction d’environ cinq fois du KV cache. Et le plus important : cette économie se fait sans dégradation mesurable. Les auteurs notent un impact « minimal sur la perplexité » même en poussant le ratio jusqu’à sept couches locales pour une globale, et même en rétrécissant nettement la fenêtre.

Pourquoi ça tient ? Parce que les rares couches globales suffisent à porter la longue portée. Le modèle apprend, à l’entraînement, à faire transiter l’information lointaine par ces couches-là, pendant que les couches locales font le gros du travail de proximité à coût mémoire fixe. C’est un pari sur la structure du langage : l’essentiel des dépendances est local, et le peu qui est vraiment longue distance peut emprunter une voie rare mais complète.

Le détail qui change tout : un RoPE par type de couche

Un raffinement de Gemma 3 mérite d’être souligné, parce qu’il révèle le soin d’ingénierie derrière l’idée. Les positions sont encodées par RoPE, dont la « fréquence de base » détermine la portée que le modèle distingue. Gemma applique deux réglages différents selon le type de couche : une base de 10 000 sur les couches locales, portée à un million sur les couches globales (avec un facteur d’échelle pour étendre encore leur portée). Autrement dit, on calibre les couches locales pour le court terme et les couches globales pour le très long terme : chacune reçoit l’encodage positionnel adapté à ce qu’elle est censée voir. Ce n’est pas un détail cosmétique : sans cet ajustement, les couches globales rares peineraient à exploiter pleinement le contexte qu’on leur réserve.

À cela s’ajoute un levier orthogonal et complémentaire : la GQA GQA Grouped-Query Attention. Variante de l'attention où plusieurs têtes de requête partagent un même couple de têtes clé/valeur, au lieu d'une paire K/V par tête. Réduit d'autant la taille du KV cache et la bande passante mémoire, pour une perte de qualité faible. Cas extrême : la MQA (Multi-Query Attention), une seule paire K/V pour toutes les têtes. (Grouped-Query Attention), que Gemma utilise aussi. Là où la fenêtre glissante borne la longueur vue par une couche, la GQA réduit le nombre de têtes clés/valeurs stockées, sur toutes les couches, locales comme globales. Les deux gains se multiplient. (La GQA aura son entrée détaillée dans l’annuaire des techniques ; ici, retenez qu’elle s’empile proprement sur l’attention locale/globale.)

Ce que Gemma ne fait pas : les attention sinks

Il faut écarter une confusion fréquente. Une autre famille de méthodes, StreamingLLM et ses « attention sinks », attaque aussi le contexte long à mémoire bornée, mais par une voie différente. Le constat de départ : une fenêtre glissante seule s’effondre dès que les tout premiers tokens sortent du cache, parce que le softmax « déverse » son excédent d’attention sur ces positions initiales, qui jouent le rôle de puits. La parade consiste à garder en permanence ces quelques premiers tokens, en plus de la fenêtre, ce qui stabilise la génération jusqu’à des millions de tokens.

Gemma n’utilise pas ce mécanisme. Là où StreamingLLM préserve la stabilité en gardant des tokens-puits, Gemma préserve la longue portée en gardant des couches globales. Et la distinction est importante pour ne pas se tromper sur ce qu’on achète : les attention sinks donnent une stabilité de génération (la perplexité ne s’effondre pas), pas une mémoire du contexte. Le modèle ne réfère pas en arrière au-delà de sa fenêtre. Les couches globales de Gemma, elles, regardent réellement tout le contexte. Deux solutions au même symptôme, deux propriétés différentes.

Retour à Gemma 4 : l’effort mis là où ça compte

Revenons au modèle de tête. Faute de rapport technique, c’est le config.json de chaque variante qui tranche : il confirme d’abord que le 5:1 de Gemma 3 est repris et généralisé : cinq couches locales pour une globale (E4B, 26B, 31B), un 4:1 sur le plus petit (E2B), avec un correctif discret : la dernière couche est désormais toujours globale, là où Gemma 3 pouvait finir sur une couche locale et « gâcher » sa sortie. Fenêtres de 512 tokens (edge) ou 1024 (serveur), contexte jusqu’à 256K.

Mais le plus instructif, c’est où Gemma 4 concentre son effort. Souvenez-vous : les couches globales sont les seules dont le cache grandit avec le contexte. Ce sont donc elles, et elles seules, qu’il faut rendre moins chères : c’est exactement ce que fait Gemma 4, lisible dans la config du 31B. D’abord, il réduit les têtes clés/valeurs des couches globales : seize têtes KV sur les couches locales, mais seulement quatre sur les globales, soit quatre fois moins de KV à stocker, là où ça pèse. Ensuite, il unifie clés et valeurs sur ces couches (attention_k_eq_v) : K et V partagent la même projection, on ne stocke plus qu’un tenseur au lieu de deux, soit encore un facteur deux. Mis bout à bout, une couche globale loge environ huit fois moins de KV qu’une couche locale. La logique est limpide : on rabote le cache précisément sur les couches qui le font enfler. Sur les modèles edge (E2B, E4B), une optimisation de plus s’ajoute : un Shared KV Cache où les dernières couches réutilisent le K/V de couches antérieures (dix-huit à vingt couches concernées), mais elle est réservée à l’on-device ; les modèles serveur s’en passent.

Version	Ratio local:global	Fenêtre	Contexte max	Note
Gemma 2	1:1	4096	8K	alternance une couche sur deux
Gemma 3	5:1	1024	128K	KV cache ÷5 à 32K (ablation)
Gemma 4 (edge, E2B/E4B)	4:1 / 5:1	512	128K	+ Shared KV Cache
Gemma 4 (serveur, 26B/31B)	5:1	1024	256K	globales allégées : 4 têtes KV, K/V unifiés

Deux réserves honnêtes pour finir. D’abord, Google ne publie aucun chiffre quantifié de réduction mémoire pour ces optimisations. Ensuite, ces config.json sont des fichiers vivants, parfois corrigés après coup : le 12B « Unified » est sorti avec son contexte épinglé par erreur à 128K (un bug de métadonnée, depuis corrigé à 256K). On décrit donc des mécanismes confirmés en source primaire, pas des gains chiffrés.

L’autre front : quantifier les poids

L’attention locale/globale s’attaque au KV cache, mais le cache n’est que la moitié de la facture mémoire. L’autre moitié, ce sont les poids, et Gemma les attaque sur un second front : la quantification entraînée (Quantization-Aware Training, QAT QAT Quantization-Aware Training. Plutôt que de comprimer un modèle déjà entraîné (et d'en subir la perte de précision), on le réentraîne brièvement en simulant la quantification, pour qu'il apprenne à vivre en basse précision (souvent int4). Réduit fortement la dégradation par rapport à une quantification post-entraînement naïve. ).

Le principe : plutôt que de comprimer un modèle déjà entraîné en 16 bits (et d’en subir la perte de précision), on le réentraîne brièvement en simulant la quantification, pour qu’il apprenne à vivre en 4 bits. Google publie des points de contrôle QAT de Gemma directement en int4, et l’effet sur l’empreinte est franc.

Modèle	Poids bf16	Poids int4 (QAT)
Gemma 3 27B	54 Go	14,1 Go
Gemma 3 12B	24 Go	6,6 Go
Gemma 3 4B	8 Go	2,6 Go
Gemma 3 1B	2 Go	0,5 Go

Un Gemma 3 27B passe ainsi de 54 Go à 14,1 Go, de quoi le faire tenir sur une seule carte grand public là où la version 16 bits réclamait un GPU datacenter. Les deux leviers sont orthogonaux : le QAT rétrécit les poids, l’attention locale/globale rétrécit le cache. Sur un long contexte, vous avez besoin des deux.

Gemma 3n : l’efficacité poussée pour l’embarqué

Pour voir jusqu’où l’obsession de la mémoire peut aller, il faut regarder Gemma 3n, la déclinaison conçue pour tourner sur un téléphone. Elle empile trois idées, toutes orientées vers le même but : réduire ce qui doit résider dans la mémoire de l’accélérateur.

La première, les Per-Layer Embeddings PLE Per-Layer Embeddings. Technique de Gemma 3n qui décharge les volumineuses tables d'embeddings hors de la mémoire de l'accélérateur (vers la RAM de l'hôte) et ne les réinjecte que couche par couche. Seul le cœur transformeur réside en VRAM : un modèle de ~5 Md de paramètres tient alors dans l'empreinte d'un 2 Md. : les tables d’embeddings, volumineuses, n’ont pas besoin de séjourner dans la VRAM. Gemma 3n les décharge vers la RAM de l’hôte et ne les réinjecte, couche par couche, qu’au moment voulu. Le résultat est frappant : un modèle dont le compte réel approche cinq milliards de paramètres ne mobilise dans l’accélérateur que son « cœur » transformeur, environ deux milliards pour la variante E2B. On loge, de fait, un 5B dans l’empreinte d’un 2B.

La deuxième, MatFormer MatFormer Matryoshka Transformer. Architecture imbriquée (comme des poupées russes) : un grand modèle contient des sous-modèles plus petits, parfaitement fonctionnels, activables à la volée selon le budget mémoire de la machine, depuis un seul jeu de poids. (Matryoshka Transformer) : le modèle est imbriqué comme des poupées russes. Un E4B contient un E2B parfaitement fonctionnel, qu’on active à la volée selon le budget de la machine : un seul jeu de poids, plusieurs tailles d’exécution.

La troisième, le KV Cache Sharing : les couches du haut réutilisent directement les clés/valeurs calculées par une couche du milieu, ce qui double le débit de prefill par rapport à un Gemma 3 4B. C’est l’ancêtre du Shared KV Cache qu’on a vu réapparaître, généralisé, dans Gemma 4.

Aucune de ces trois techniques ne touche à la qualité du modèle ; toutes attaquent l’endroit où il s’exécute. C’est la philosophie de l’attention locale/globale, déclinée jusqu’à l’extrême de la contrainte embarquée.

Conclusion : et si on supprimait le cache, au lieu de le borner ?

Gemma attaque la mémoire sur trois fronts : le cache (attention locale/globale), les poids (QAT) et l’empreinte d’exécution (Gemma 3n). L’attention locale/globale en reste la pièce maîtresse : une réponse élégante à un problème concret. Elle borne la croissance du KV cache en pariant que la longue portée tient sur une fraction des couches, et les chiffres montrent que le pari est tenu, cinq fois moins de cache, sans perte mesurable. C’est une optimisation de l’attention, pas une rupture avec elle : il reste un cache, simplement plus petit.

Reste une question qui dérange : et si le cache croissant n’était pas une fatalité du tout ? C’est le pari d’une autre famille d’architectures, les modèles à espace d’états, Mamba et ses hybrides, qui remplacent le cache qui enfle par un état de taille constante. Elles ne bornent pas le problème, elles le suppriment, au prix d’un compromis différent, sur le rappel exact. Ce pari, ses chiffres et ses limites sont le sujet d’un dossier dédié.

Sources et méthode

Étiquettes : fait vérifié (source primaire), estimation (ordre de grandeur), hypothèse (raisonnement assumé).

Architecture d’attention de Gemma

• Fait : Gemma 2 : alternance 1:1, fenêtre 4096, contexte 8192 (arXiv:2408.00118, août 2024) : « We alternate between a local sliding window attention and global attention in every other layer ».
• Fait : Gemma 3 : ratio 5:1, fenêtre 1024, contexte 128K (1B : 32K) (arXiv:2503.19786, mars 2025) : « a pattern of 5 local layers for every global layer » ; « 1:1 is used in Gemma 2 models, and 5:1 is used in Gemma 3 ».
• Fait : RoPE différencié : base 10 000 (local) / 1 000 000 (global), facteur d’échelle 8 (rapport Gemma 3).
• Fait : GQA présente dès Gemma 2 (num_groups = 2 sur 9B/27B).

Gain mémoire

• Fait : Rapport Gemma 3, §5.2 : « the “global only” configuration results in a memory overhead of 60%, while this is reduced to less than 15% with 1:3 and sliding windows of 1024 ». Impact perplexité « minimal… even with 7-to-1 ». À cadrer : ablation 2B texte seul, config 1:3.
• Fait : Empreinte 32K (Table 3) : 27B bf16 72,7 Go / int4 32,8 Go.
• Estimation : KV cache classe Llama-3 8B : ~4 Go (32K) / ~16 Go (128K) / ~128 Go (1M) ; corroboré par HeadInfer (arXiv:2502.12574).

Comparaisons

• Fait : Mistral 7B : fenêtre 4096, 32 couches, portée effective W × profondeur ≈ 131K, rolling buffer cache de taille constante (arXiv:2310.06825).
• Fait : StreamingLLM / attention sinks (arXiv:2309.17453) : garder les premiers tokens stabilise la génération (jusqu’à 4 M tokens) ; stabilité ≠ mémoire du contexte. Gemma n’utilise pas de tokens-puits, c’est un choix d’architecture, aucun mécanisme de sink dans sa config. Sur le phénomène sous-jacent des poids massifs, voir « House of Cards » (arXiv:2410.01866), contexte général, sans lien spécifique à Gemma.

Gemma 4

• Fait : Sortie 2 avril 2026, Apache 2.0 (blog.google). Absence de rapport technique : les config.json Hugging Face par variante font foi (HF blog).
• Fait (config.json) : Ratio 5:1 (E4B 42 couches, 26B-A4B 30, 31B 60) ; 4:1 (E2B 35) ; dernière couche toujours globale. Fenêtres 512 (edge) / 1024 (serveur) ; contexte 128K (edge) / 256K (12B, 26B, 31B).
• Fait (config.json 31B) : 32 têtes de requête ; 16 têtes KV sur les couches locales, 4 sur les globales (facteur 4) et clés/valeurs unifiées sur les globales (attention_k_eq_v: true, encore un facteur 2 → ~8× moins de KV par couche globale). Shared KV Cache (num_kv_shared_layers) actif sur edge seulement (E2B 20, E4B 18 ; 26B/31B = 0).
• Fait : 26B-A4B : MoE 128 experts (top-8) + 1 expert partagé toujours actif, 25,2 Md total / 3,8 Md actifs.
• Réserve : Aucun gain mémoire chiffré publié pour ces optimisations. Le config.json du 12B a affiché 128K à la sortie, bug de métadonnée corrigé depuis à 262144 (256K), discussion #21.

Note de méthode. L’article s’ancre sur Gemma 3, seule version avec rapport technique et ablations chiffrées. Gemma 4 est présenté à partir des config.json publiés et de la model card, en signalant ce qui n’est pas vérifiable en source primaire. Les chiffres de KV cache génériques sont des estimations d’ordre de grandeur, dépendantes de la configuration (GQA, précision, batch).