Nous allons cacher une phrase dans un long prompt, demander à Gemma 4 26B A4B de la retrouver et recommencer en déplaçant cette phrase au début, au milieu puis à la fin du texte, d’abord sur environ 5 000 tokens puis sur environ 20 000.
La question derrière ce petit labo est simple: sur un Mac mini à 32 Go, jusqu’où pouvons-nous charger le contexte avant que le modèle ne commence à « oublier » ce qu’il a lu? Le phénomène a été décrit en 2023 par Nelson F. Liu et ses co-auteurs de Stanford dans Lost in the Middle: How Language Models Use Long Contexts: les modèles qu’ils ont testés exploitaient mieux une information placée au début ou à la fin du contexte que celle enfouie au milieu. Nous allons voir ce qu’il en est pour ce modèle, sur cette machine, avec un test volontairement simple.
Présentation de la maquette
Machine: Mac mini M4, 32 Go de mémoire unifiée.
Logiciel: LM Studio, moteur mlx-llm-mac-arm64-apple-metal-advsimd 1.14.0, interrogé par son API locale. LM Studio expose une API REST 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.
Modèle: google/gemma-4-26b-a4b-qat, format MLX, quantification 4 bits, 15,6 Go de poids, chargé en 22 s avec un contexte de 32 768 tokens. C’est un modèle Mixture-of-Experts dont la fiche Hugging Face annonce une fenêtre allant jusqu’à 256K tokens: nous restons donc très loin du maximum théorique, ce qui est le cas réaliste sur 32 Go.
Attention: nous connaissons la taille des poids, pas la mémoire réellement consommée pendant les essais. Le cache KV grossit avec le contexte et ce labo ne l’a pas mesuré. Pour le voir chez vous, il suffit de garder le Moniteur d’activité (onglet « Mémoire ») ou la commande memory_pressure ouverts pendant l’appel le plus long.
Le prompt est construit toujours de la même façon: une consigne, du texte de remplissage tiré du blog, une « note interne » qui contient le fait à retrouver, encore du remplissage, puis la question. Le marqueur {{TEXTE_BLOG:N}} est remplacé par un segment de N mots extrait des articles du blog, et chaque segment part du début des articles.
Tous les essais tournent à température 0, avec max_tokens à 300, la réflexion désactivée, un appel de chauffe puis une seule répétition mesurée. Une seule mesure par essai, c’est peu: les chiffres qui suivent donnent une tendance sur cette machine, pas une moyenne.
Une note cachée dans 5 000 tokens
Lançons le premier essai, la note placée à 10 % du prompt:
POST http://localhost:1234/v1/chat/completions
{
"model": "google/gemma-4-26b-a4b-qat",
"temperature": 0,
"max_tokens": 300,
"messages": [{"role": "user", "content":
"Voici un long document. Lis-le, puis réponds à la question finale en une phrase courte.\n\n{{TEXTE_BLOG:300}}\n\nNote interne : le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.\n\n{{TEXTE_BLOG:2700}}\n\nQuestion : quel est le code de la fenêtre de maintenance du cluster Orion ?"}]
}Nous obtenons:
Tokens entrée: 5677 | sortie: 21 (réflexion: 0)
TTFT: 15.29 s | durée totale: 16.2 s | génération: 25.1 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.La réponse 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ûte, la génération des 21 tokens ne prend pas une seconde.
Déplaçons la note au milieu, avec deux segments de 1 500 mots ({{TEXTE_BLOG:1500}} avant et après la note, le reste du prompt est identique):
Tokens entrée: 6206 | sortie: 21 (réflexion: 0)
TTFT: 16.34 s | durée totale: 17.2 s | génération: 25.4 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.Le milieu, qui est la zone à risque d’après l’étude de Stanford, ne pose aucun problème ici. Le prompt est un peu plus long (6 206 tokens) parce que deux fois 1 500 mots pris au début des articles ne donnent pas le même texte que 300 + 2 700.
Dernier essai à cette taille, la note à 90 % ({{TEXTE_BLOG:2700}} avant, {{TEXTE_BLOG:300}} après):
Tokens entrée: 5677 | sortie: 21 (réflexion: 0)
TTFT: 7.24 s | durée totale: 8.1 s | génération: 27.3 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.Trois sur trois. Le chiffre qui surprend est ailleurs: avec le même nombre de tokens que le premier essai (5 677, c’est le même texte avec les deux segments inversés), le premier token arrive en 7,24 s au lieu de 15,29 s. Le modèle ne lit pas plus vite un document parce que la réponse est à la fin; nous reviendrons sur cet écart plus bas.
Passons à 20 000 tokens
Nous quadruplons la taille du remplissage. Pour la note à 10 %, le prompt devient:
Voici un long document. Lis-le, puis réponds à la question finale en une phrase courte.
{{TEXTE_BLOG:1200}}
Note interne : le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.
{{TEXTE_BLOG:6000}}
{{TEXTE_BLOG:4800}}
Question : quel est le code de la fenêtre de maintenance du cluster Orion ?Attention: comme chaque segment repart du début 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ès répétitive, ce qui ne ressemble pas à un vrai corpus documentaire.
Tokens entrée: 20931 | sortie: 21 (réflexion: 0)
TTFT: 57.76 s | durée totale: 59 s | génération: 17.5 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.Près d’une minute d’attente pour une phrase de 21 tokens. La réponse reste juste, mais la vitesse de génération tombe de 25 à 17,5 tokens/s: chaque nouveau token doit consulter un cache d’attention quatre fois plus gros.
Lançons la note au milieu, entre deux segments de 6 000 mots:
Tokens entrée: 20260 | sortie: 21 (réflexion: 0)
TTFT: 46.63 s | durée totale: 47.9 s | génération: 18.3 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.Puis à 90 %, après les segments de 6 000 et 4 800 mots, avec 1 200 mots derrière:
Tokens entrée: 20931 | sortie: 21 (réflexion: 0)
TTFT: 35.05 s | durée totale: 36.3 s | génération: 18 tokens/s
Réponse: Le code de la fenêtre de maintenance du cluster Orion est MAINT-7342-K.Six réponses justes sur six, mot pour mot identiques. À 20 000 tokens, soit environ 64 % du contexte chargé, Gemma 4 26B A4B ne perd pas la note, ni au début, ni au milieu, ni à la fin.
| Essai | Position | Tokens entrée | TTFT | Durée totale | Génération | Fait retrouvé |
|---|---|---|---|---|---|---|
| e1 | 10 % | 5 677 | 15,29 s | 16,2 s | 25,1 t/s | oui |
| e2 | 50 % | 6 206 | 16,34 s | 17,2 s | 25,4 t/s | oui |
| e3 | 90 % | 5 677 | 7,24 s | 8,1 s | 27,3 t/s | oui |
| e4 | 10 % | 20 931 | 57,76 s | 59 s | 17,5 t/s | oui |
| e5 | 50 % | 20 260 | 46,63 s | 47,9 s | 18,3 t/s | oui |
| e6 | 90 % | 20 931 | 35,05 s | 36,3 s | 18 t/s | oui |
Position ou cache?
Si nous divisons le nombre de tokens d’entrée par le TTFT, nous obtenons un débit de lecture du prompt: environ 371 tokens/s pour e1, 380 pour e2 et 362 pour e4. Ces trois valeurs sont très proches, ce qui ressemble à un prefill complet calculé à vitesse constante. Le calcul donne 784 tokens/s pour e3, 434 pour e5 et 597 pour e6: ces prompts-là ont été lus plus vite qu’ils ne pouvaient l’être.
L’explication la plus probable tient à la construction du labo et non au modèle. Les essais ont été lancés dans l’ordre, et comme tous les segments partent du début des articles, deux prompts successifs partagent souvent un long préfixe identique:
- e3 commence par la consigne suivie des 2 700 premiers mots, e2 commençait par la consigne suivie des 1 500 premiers mots,
- -> environ la moitié du prompt de e3 était déjà calculée, et son TTFT tombe à peu près de moitié par rapport à e1,
- e6 commence par les mêmes 6 000 mots que e5,
- -> une dizaine de milliers de tokens déjà en cache, et 35 s au lieu de 58.
Un moteur qui conserve le cache KV de la requête précédente et réutilise le préfixe commun produit ce comportement. Cette hypothèse colle bien à e3 et e6, beaucoup moins à l’écart entre e4 et e5, qui ne partagent chacun que 1 200 mots avec leur prédécesseur; nous ne savons pas non plus quel prompt servait à l’appel de chauffe. Pour trancher, il suffit de relancer la série dans l’ordre inverse, ou de donner à chaque essai un préfixe unique (un identifiant aléatoire en tête de prompt).
Ce point a une conséquence très pratique. Dans un usage réel (un assistant qui relit le même document, un RAG qui place toujours le même prompt système en tête), placer la partie stable au début et la partie variable à la fin permet de profiter de ce cache et de diviser le temps d’attente. Je reviendrai sur la méthode de mesure dans le détail, mais si vous comparez des moteurs ou des formats, pensez à casser ce préfixe commun, sans quoi vous mesurez le cache plutôt que le modèle; c’est un des pièges évoqués dans l’article sur la comparaison MLX et GGUF dans LM Studio.
Reste la question de départ, la confiance à accorder au modèle sur 20 000 tokens. Le résultat est net mais le test est facile. La note est isolée, annoncée par « Note interne », et la question reprend ses mots un par un (« code », « fenêtre de maintenance », « cluster Orion »): le modèle n’a qu’à retrouver une correspondance littérale. Les auteurs de NoLiMa ont montré que les résultats des tests de type « aiguille dans une botte de foin » chutent fortement dès que la question et le passage ne partagent plus de mots et qu’il faut une association pour faire le lien. Une question comme « quand pouvons-nous redémarrer les nœuds d’Orion? » serait une épreuve bien plus parlante, tout comme deux codes proches placés à des endroits différents du texte.
Attention aussi au revers de cette bonne mémoire: une phrase glissée n’importe où dans 20 000 tokens est lue et reprise fidèlement, et une instruction cachée dans un document l’est tout autant. C’est le mécanisme qu’exploite l’injection de prompt dans une chaîne RAG locale avec LM Studio et n8n, et la taille du contexte ne protège de rien.
Sur cette maquette, la limite qui apparaît en premier est donc le temps et non la mémoire du modèle: jusqu’à 20 000 tokens la note est retrouvée à chaque fois, mais il faut compter près d’une minute de prefill sans cache et une génération qui perd environ 30 % de sa vitesse. Le prochain palier à mesurer, ce sont 30 000 tokens avec une question reformulée, en surveillant la pression mémoire.
Rémi Vernier
Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.