{"id":1301,"date":"2026-11-08T13:30:00","date_gmt":"2026-11-08T12:30:00","guid":{"rendered":"https:\/\/remivernier.com\/?p=1301"},"modified":"2026-11-08T13:30:00","modified_gmt":"2026-11-08T12:30:00","slug":"gemma-4-26b-contexte-long-information-perdue","status":"publish","type":"post","link":"https:\/\/remivernier.com\/index.php\/2026\/11\/08\/gemma-4-26b-contexte-long-information-perdue\/","title":{"rendered":"Gemma 4 26B en contexte long: l’information se perd-elle?"},"content":{"rendered":"

Nous allons cacher une phrase dans un long prompt, demander \u00e0 Gemma 4 26B A4B de la retrouver et recommencer en d\u00e9pla\u00e7ant cette phrase au d\u00e9but, au milieu puis \u00e0 la fin du texte, d’abord sur environ 5 000 tokens puis sur environ 20 000.<\/p>\n

La question derri\u00e8re ce petit labo est simple: sur un Mac mini \u00e0 32 Go, jusqu’o\u00f9 pouvons-nous charger le contexte avant que le mod\u00e8le ne commence \u00e0 \u00ab oublier \u00bb ce qu’il a lu? Le ph\u00e9nom\u00e8ne a \u00e9t\u00e9 d\u00e9crit en 2023 par Nelson F. Liu et ses co-auteurs de Stanford dans Lost in the Middle: How Language Models Use Long Contexts<\/a>: les mod\u00e8les qu’ils ont test\u00e9s exploitaient mieux une information plac\u00e9e au d\u00e9but ou \u00e0 la fin du contexte que celle enfouie au milieu. Nous allons voir ce qu’il en est pour ce mod\u00e8le, sur cette machine, avec un test volontairement simple.<\/p>\n

Pr\u00e9sentation de la maquette<\/h2>\n

Machine: Mac mini M4, 32 Go de m\u00e9moire unifi\u00e9e.<\/p>\n

Logiciel: LM Studio, moteur mlx-llm-mac-arm64-apple-metal-advsimd 1.14.0, interrog\u00e9 par son API locale. LM Studio expose une API REST<\/a> qui renvoie directement des statistiques comme le nombre de tokens par seconde et le temps jusqu’au premier token (TTFT): ce sont ces valeurs que nous relevons.<\/p>\n

Mod\u00e8le: google\/gemma-4-26b-a4b-qat, format MLX, quantification 4 bits, 15,6 Go de poids, charg\u00e9 en 22 s avec un contexte de 32 768 tokens. C’est un mod\u00e8le Mixture-of-Experts dont la fiche Hugging Face<\/a> annonce une fen\u00eatre allant jusqu’\u00e0 256K tokens: nous restons donc tr\u00e8s loin du maximum th\u00e9orique, ce qui est le cas r\u00e9aliste sur 32 Go.<\/p>\n

Attention: nous connaissons la taille des poids, pas la m\u00e9moire r\u00e9ellement consomm\u00e9e pendant les essais. Le cache KV grossit avec le contexte et ce labo ne l’a pas mesur\u00e9. Pour le voir chez vous, il suffit de garder le Moniteur d’activit\u00e9 (onglet \u00ab M\u00e9moire \u00bb) ou la commande memory_pressure<\/code> ouverts pendant l’appel le plus long.<\/p>\n

Le prompt est construit toujours de la m\u00eame fa\u00e7on: une consigne, du texte de remplissage tir\u00e9 du blog, une \u00ab note interne \u00bb qui contient le fait \u00e0 retrouver, encore du remplissage, puis la question. Le marqueur {{TEXTE_BLOG:N}}<\/code> est remplac\u00e9 par un segment de N mots extrait des articles du blog, et chaque segment part du d\u00e9but des articles.<\/p>\n

\n\n<\/marker><\/defs>\ne1 (10 %)<\/text>\n\n\n\n\ne2 (50 %)<\/text>\n\n\n\n\ne3 (90 %)<\/text>\n\n\n\n\n\nnote interne (MAINT-7342-K)<\/text>\n\nquestion<\/text>\n\ntexte du blog (remplissage)<\/text>\n<\/svg>
Position de la note dans les trois prompts d’environ 5 000 tokens<\/figcaption><\/figure>\n

Tous les essais tournent \u00e0 temp\u00e9rature 0, avec max_tokens<\/code> \u00e0 300, la r\u00e9flexion d\u00e9sactiv\u00e9e, un appel de chauffe puis une seule r\u00e9p\u00e9tition mesur\u00e9e. Une seule mesure par essai, c’est peu: les chiffres qui suivent donnent une tendance sur cette machine, pas une moyenne.<\/p>\n

Une note cach\u00e9e dans 5 000 tokens<\/h2>\n

Lan\u00e7ons le premier essai, la note plac\u00e9e \u00e0 10 % du prompt:<\/p>\n

POST http:\/\/localhost:1234\/v1\/chat\/completions\n{\n  \"model\": \"google\/gemma-4-26b-a4b-qat\",\n  \"temperature\": 0,\n  \"max_tokens\": 300,\n  \"messages\": [{\"role\": \"user\", \"content\":\n    \"Voici un long document. Lis-le, puis r\u00e9ponds \u00e0 la question finale en une phrase courte.\\n\\n{{TEXTE_BLOG:300}}\\n\\nNote interne : le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.\\n\\n{{TEXTE_BLOG:2700}}\\n\\nQuestion : quel est le code de la fen\u00eatre de maintenance du cluster Orion ?\"}]\n}<\/code><\/pre>\n
Nous obtenons:<\/p>\n
Tokens entr\u00e9e: 5677 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 15.29 s | dur\u00e9e totale: 16.2 s | g\u00e9n\u00e9ration: 25.1 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
La r\u00e9ponse est juste et reprend la formulation de la question. Sur 16,2 s d’appel, 15,29 s passent avant le premier token: c’est la lecture du prompt (le prefill) qui co\u00fbte, la g\u00e9n\u00e9ration des 21 tokens ne prend pas une seconde.<\/p>\n
D\u00e9pla\u00e7ons la note au milieu, avec deux segments de 1 500 mots ({{TEXTE_BLOG:1500}}<\/code> avant et apr\u00e8s la note, le reste du prompt est identique):<\/p>\n
Tokens entr\u00e9e: 6206 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 16.34 s | dur\u00e9e totale: 17.2 s | g\u00e9n\u00e9ration: 25.4 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
Le milieu, qui est la zone \u00e0 risque d’apr\u00e8s l’\u00e9tude de Stanford, ne pose aucun probl\u00e8me ici. Le prompt est un peu plus long (6 206 tokens) parce que deux fois 1 500 mots pris au d\u00e9but des articles ne donnent pas le m\u00eame texte que 300 + 2 700.<\/p>\n
Dernier essai \u00e0 cette taille, la note \u00e0 90 % ({{TEXTE_BLOG:2700}}<\/code> avant, {{TEXTE_BLOG:300}}<\/code> apr\u00e8s):<\/p>\n
Tokens entr\u00e9e: 5677 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 7.24 s | dur\u00e9e totale: 8.1 s | g\u00e9n\u00e9ration: 27.3 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
Trois sur trois. Le chiffre qui surprend est ailleurs: avec le m\u00eame nombre de tokens que le premier essai (5 677, c’est le m\u00eame texte avec les deux segments invers\u00e9s), le premier token arrive en 7,24 s au lieu de 15,29 s. Le mod\u00e8le ne lit pas plus vite un document parce que la r\u00e9ponse est \u00e0 la fin; nous reviendrons sur cet \u00e9cart plus bas.<\/p>\n
Passons \u00e0 20 000 tokens<\/h2>\n
Nous quadruplons la taille du remplissage. Pour la note \u00e0 10 %, le prompt devient:<\/p>\n
Voici un long document. Lis-le, puis r\u00e9ponds \u00e0 la question finale en une phrase courte.\n\n{{TEXTE_BLOG:1200}}\n\nNote interne : le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.\n\n{{TEXTE_BLOG:6000}}\n\n{{TEXTE_BLOG:4800}}\n\nQuestion : quel est le code de la fen\u00eatre de maintenance du cluster Orion ?<\/code><\/pre>\n
Attention: comme chaque segment repart du d\u00e9but des articles, les 1 200 premiers mots apparaissent trois fois dans ce prompt et le bloc de 4 800 mots est contenu dans celui de 6 000. La botte de foin est tr\u00e8s r\u00e9p\u00e9titive, ce qui ne ressemble pas \u00e0 un vrai corpus documentaire.<\/p>\n
Tokens entr\u00e9e: 20931 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 57.76 s | dur\u00e9e totale: 59 s | g\u00e9n\u00e9ration: 17.5 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
Pr\u00e8s d’une minute d’attente pour une phrase de 21 tokens. La r\u00e9ponse reste juste, mais la vitesse de g\u00e9n\u00e9ration tombe de 25 \u00e0 17,5 tokens\/s: chaque nouveau token doit consulter un cache d’attention quatre fois plus gros.<\/p>\n
Lan\u00e7ons la note au milieu, entre deux segments de 6 000 mots:<\/p>\n
Tokens entr\u00e9e: 20260 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 46.63 s | dur\u00e9e totale: 47.9 s | g\u00e9n\u00e9ration: 18.3 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
Puis \u00e0 90 %, apr\u00e8s les segments de 6 000 et 4 800 mots, avec 1 200 mots derri\u00e8re:<\/p>\n
Tokens entr\u00e9e: 20931 | sortie: 21 (r\u00e9flexion: 0)\nTTFT: 35.05 s | dur\u00e9e totale: 36.3 s | g\u00e9n\u00e9ration: 18 tokens\/s\nR\u00e9ponse: Le code de la fen\u00eatre de maintenance du cluster Orion est MAINT-7342-K.<\/code><\/pre>\n
Six r\u00e9ponses justes sur six, mot pour mot identiques. \u00c0 20 000 tokens, soit environ 64 % du contexte charg\u00e9, Gemma 4 26B A4B ne perd pas la note, ni au d\u00e9but, ni au milieu, ni \u00e0 la fin.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Essai<\/th>\nPosition<\/th>\nTokens entr\u00e9e<\/th>\nTTFT<\/th>\nDur\u00e9e totale<\/th>\nG\u00e9n\u00e9ration<\/th>\nFait retrouv\u00e9<\/th>\n<\/tr>\n<\/thead>\n
e1<\/td>\n10 %<\/td>\n5 677<\/td>\n15,29 s<\/td>\n16,2 s<\/td>\n25,1 t\/s<\/td>\noui<\/td>\n<\/tr>\n
e2<\/td>\n50 %<\/td>\n6 206<\/td>\n16,34 s<\/td>\n17,2 s<\/td>\n25,4 t\/s<\/td>\noui<\/td>\n<\/tr>\n
e3<\/td>\n90 %<\/td>\n5 677<\/td>\n7,24 s<\/td>\n8,1 s<\/td>\n27,3 t\/s<\/td>\noui<\/td>\n<\/tr>\n
e4<\/td>\n10 %<\/td>\n20 931<\/td>\n57,76 s<\/td>\n59 s<\/td>\n17,5 t\/s<\/td>\noui<\/td>\n<\/tr>\n
e5<\/td>\n50 %<\/td>\n20 260<\/td>\n46,63 s<\/td>\n47,9 s<\/td>\n18,3 t\/s<\/td>\noui<\/td>\n<\/tr>\n
e6<\/td>\n90 %<\/td>\n20 931<\/td>\n35,05 s<\/td>\n36,3 s<\/td>\n18 t\/s<\/td>\noui<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Position ou cache?<\/h2>\n
Si nous divisons le nombre de tokens d’entr\u00e9e par le TTFT, nous obtenons un d\u00e9bit de lecture du prompt: environ 371 tokens\/s pour e1, 380 pour e2 et 362 pour e4. Ces trois valeurs sont tr\u00e8s proches, ce qui ressemble \u00e0 un prefill complet calcul\u00e9 \u00e0 vitesse constante. Le calcul donne 784 tokens\/s pour e3, 434 pour e5 et 597 pour e6: ces prompts-l\u00e0 ont \u00e9t\u00e9 lus plus vite qu’ils ne pouvaient l’\u00eatre.<\/p>\n
L’explication la plus probable tient \u00e0 la construction du labo et non au mod\u00e8le. Les essais ont \u00e9t\u00e9 lanc\u00e9s dans l’ordre, et comme tous les segments partent du d\u00e9but des articles, deux prompts successifs partagent souvent un long pr\u00e9fixe identique:<\/p>\n