Le précédent Llama 4 Scout¶
Pokee-Isaac n'est pas le premier modèle annoncé avec 10 millions de tokens de contexte. Meta l'a fait seize mois plus tôt, avec Llama 4 Scout, en avril 2025.
Ce chapitre est indispensable pour lire l'annonce de Pokee, car il explique un mot : dans « the world's first real 10M-token context », l'adjectif « real » n'est pas un effet de style. C'est une pique adressée à Meta — et c'est aussi ce qui rend la revendication de Pokee testable.
Ce que Meta a annoncé¶
| Caractéristique | Llama 4 Scout |
|---|---|
| Paramètres actifs | 17 milliards |
| Paramètres totaux | 109 milliards |
| Experts | 16 (mélange d'experts) |
| Contexte annoncé | 10 000 000 tokens |
| Architecture | iRoPE — couches d'attention entrelacées, sans encodage de position |
| Longueur d'entraînement | 256 000 tokens |
| Poids | Ouverts |
| Date | Avril 2025 |
La ligne qui explique tout
Meta indique explicitement que Scout est « pré-entraîné et post-entraîné avec une longueur de 256 K ».
Les 10 M annoncés sont donc obtenus par extrapolation — un facteur 39× au-delà de tout ce que le modèle a jamais vu à l'entraînement.
C'est précisément le mécanisme décrit dans Entraînement · 02 : une architecture peut continuer à fonctionner bien au-delà de sa longueur d'entraînement sans pour autant y être compétente.
Comment Meta a fait, mécaniquement¶
Ici, contrairement à Pokee, on peut lire l'architecture. Les poids sont
ouverts et le config.json est public. Voici les valeurs réelles de
Llama 4 Scout :
| Paramètre | Valeur |
|---|---|
num_hidden_layers |
48 |
hidden_size |
5 120 |
num_attention_heads |
40 |
num_key_value_heads |
8 |
head_dim |
128 |
attention_chunk_size |
8 192 |
no_rope_layers |
motif [1,1,1,0] × 12 → 12 couches NoPE sur 48 |
attn_temperature_tuning |
true |
floor_scale |
8 192 |
attn_scale |
0,1 |
num_local_experts |
16 |
num_experts_per_tok |
1 |
max_position_embeddings |
10 485 760 (= 10 × 1024²) |
Trois mécanismes s'y combinent.
1. Alterner RoPE local et NoPE global¶
Trois couches sur quatre utilisent l'encodage de position rotatif (RoPE) et sont restreintes à des blocs de 8 192 tokens — c'est le chunked attention. Elles ne voient que leur voisinage immédiat.
La quatrième n'a aucun encodage de position (NoPE) et voit tout le contexte.
Pourquoi retirer l'encodage de position
Un encodage de position paramétré échoue au-delà des portées vues à l'entraînement : le modèle rencontre des valeurs de rotation qu'il n'a jamais traitées, et son comportement devient imprévisible.
Une couche sans encodage de position n'a pas ce problème — rien dans son calcul ne change entre le token 200 000 et le token 9 000 000. Elle traite la séquence comme un ensemble non ordonné.
C'est ce qui rend l'extrapolation possible. Ce n'est pas ce qui la rend bonne : une couche qui ignore l'ordre ne peut pas, seule, raisonner sur une chronologie.
Le « i » d'iRoPE signifie interleaved — entrelacé — et, selon Meta, évoque aussi l'objectif de contexte infini.
2. Réchauffer l'attention quand la séquence s'allonge¶
Problème connu : plus la séquence est longue, plus la fonction softmax dilue les scores d'attention vers zéro. À 10 M de tokens, chaque token reçoit en moyenne un poids de \(10^{-7}\) : l'attention devient une moyenne uniforme, c'est-à-dire plus rien.
La parade de Meta consiste à amplifier les requêtes en fonction de leur position, uniquement sur les couches NoPE :
| Symbole | Signification | Valeur |
|---|---|---|
| \(t\) | Position du token dans la séquence | 0 à 10 485 759 |
| \(\operatorname{attn\_scale}\) | Intensité de l'ajustement | 0,1 |
| \(\operatorname{floor\_scale}\) | Palier de discrétisation, en tokens | 8 192 |
| \(\alpha(t)\) | Facteur appliqué aux requêtes | 1,0 à ≈ 1,72 |
Les requêtes sont multipliées par \(\alpha(t)\) avant le calcul de l'attention, ce qui rend la distribution plus piquée et compense la dilution.
Valeurs concrètes, recalculées :
| Position | \(\alpha(t)\) |
|---|---|
| 8 192 | 1,069 |
| 256 000 (fin de l'entraînement) | 1,347 |
| 1 000 000 | 1,481 |
| 10 485 760 | 1,716 |
Le correctif est très doux
Sur toute la plage, la température ne monte que de 1,0 à 1,72 — croissance logarithmique. C'est un ajustement, pas une refonte.
Rien dans ce mécanisme n'a été appris au-delà de 256 K : c'est une correction analytique appliquée à l'inférence, calibrée sur deux constantes fixées à la main. Cela explique qu'elle empêche le modèle de casser, sans pour autant lui apprendre à raisonner à ces longueurs.
3. Un mélange d'experts très creux¶
Scout active 1 seul expert sur 16 par token (num_experts_per_tok: 1), plus
un expert partagé : 17 G de paramètres actifs sur 109 G au total.
À noter pour la suite du rapport : le seul autre modèle à revendiquer 10 M est donc lui aussi à activation creuse — ce qui va dans le sens de la déduction faite sur Isaac en Architecture · 03.
Pourquoi ça n'a pas marché : le mur mémoire est resté debout¶
C'est le point décisif, et il se calcule. Le chunked attention limite le cache des 36 couches RoPE à 8 192 tokens — donc constant. Mais les 12 couches NoPE voient tout le contexte et gardent un cache linéaire en \(n\).
En demi-précision :
| Terme | Valeur |
|---|---|
| Si les 48 couches étaient globales | 2,06 To |
| 36 couches à fenêtre de 8 192 | 1,21 Go constants |
| 12 couches NoPE globales | 49 152 octets/token |
| Total à 10 485 760 tokens | ≈ 517 Go |
Le chunked attention fait gagner un facteur 4. Il reste 517 Go.
Le diagnostic, en une phrase
Meta a résolu la généralisation de longueur, pas le mur mémoire.
iRoPE empêche le modèle de casser à 10 M de tokens. Il ne fait rien pour que 10 M de tokens tiennent dans un GPU. Les 12 couches globales conservent exactement le problème décrit dans Fondations · 02.
Ce que cela donnait sur le matériel de 2025¶
| Machine | Contexte réellement servable |
|---|---|
| 1× H100 80 Go, poids en 4 bits | ≈ 451 K tokens |
| 8× H100 640 Go, poids en 8 bits | ≈ 10,7 M tokens |
Ce que ces deux lignes expliquent
- Pourquoi les hébergeurs ne servaient que 128 K à 328 K. Un seul H100 plafonne vers 450 K en théorie — et il faut encore de la marge pour traiter plusieurs requêtes à la fois, ce qui divise d'autant.
- Pourquoi les 10 M n'étaient pas exploitables. Ils tiennent, mais il faut un nœud DGX complet — huit H100, de l'ordre de 250 000 $ — dédié à une seule requête, sans aucune marge.
La fenêtre de 10 M n'était donc pas un mensonge. Elle était économiquement absurde, ce qui revient au même pour l'utilisateur.
Et elle n'était même pas la limite la plus contraignante : bien avant de manquer de mémoire, le modèle s'effondrait en qualité — 15,6 % dès 128 K.
Ce que Meta a publié comme preuve¶
Deux choses, et deux seulement :
- Aiguille dans une botte de foin (needle in a haystack) sur toute la plage jusqu'à 10 M.
- Vraisemblance négative cumulée sur 10 millions de tokens de code.
Pourquoi ces deux preuves ne prouvent presque rien
- L'aiguille dans une botte de foin est le test que Fondations · 04 qualifie de « beaucoup trop facile » : l'aiguille est sémantiquement étrangère au remplissage, le modèle n'a qu'à repérer ce qui détonne.
- La vraisemblance cumulée mesure la perplexité, c'est-à-dire à quel point le modèle est surpris par le texte. Un modèle peut avoir une perplexité excellente tout en étant incapable de répondre à une question sur ce texte. Ce n'est pas une mesure de rappel.
Ni RULER, ni MRCR, ni aucune tâche de raisonnement multi-sauts à longue portée n'a été publiée.
Ce que les évaluations indépendantes ont trouvé¶
C'est ici que le précédent devient instructif — et c'est exactement ce qui manque aujourd'hui à Pokee-Isaac.
| Mesure | Llama 4 Scout | Comparaison |
|---|---|---|
| Aiguille dans une botte de foin @ 10 M | « parfait » (Meta) | — |
| fiction.liveBench @ 128 K | 15,6 % | Gemini 2.5 Pro : 90,6 % |
| Contexte effectif estimé (RULER) | ≈ 5 à 6,5 M | vs 10 M annoncés |
| Dégradation observée en pratique | massive au-delà de ≈ 120 K | — |
Le chiffre à retenir
15,6 % à 128 000 tokens sur un test de compréhension exigeant, pour un modèle vendu avec 10 000 000 tokens de contexte.
Autrement dit : Scout s'effondre à 1,28 % de sa fenêtre annoncée, sur des tâches qui demandent de relier plusieurs éléments plutôt que d'en retrouver un seul.
La formule qui résume le mieux le diagnostic indépendant : la fenêtre de Scout fonctionne comme un index de recherche, pas comme une mémoire de travail. Retrouver un fait enfoui dans 10 M de tokens et raisonner sur plusieurs faits dispersés dans les mêmes 10 M sont deux capacités différentes.
S'y est ajoutée, à la même période, la controverse sur LMArena — Meta y ayant soumis une version « expérimentale » ajustée pour la préférence humaine, différente du modèle publié. Cela a durablement abîmé la confiance dans les chiffres annoncés de la série.
Ce que ce précédent change pour lire Pokee¶
1. « Premier vrai 10 M » est une revendication, pas un fait¶
Le mot « real » distingue Pokee de Scout. Mais il ne peut être validé que par le type de preuve que Meta n'avait pas fourni — et que Pokee ne fournit pas davantage : une évaluation indépendante, sur un protocole publié, avec des tâches de raisonnement et non de simple récupération.
2. Le panel de comparaison de Pokee n'inclut pas Llama 4 Scout¶
Une absence remarquable
Le panel retenu par Pokee — GPT-5.6 Luna, Gemini 3.5 Flash Lite, Claude Haiku 4.5, Nemotron 3 Super, Qwen 3.5 122B — ne comporte pas le seul autre modèle revendiquant 10 M de tokens.
C'est ce qui permet d'écrire que « tous les concurrents tombent à 0,0 au-delà de 2 M » : aucun modèle du panel n'accepte cette longueur. Scout, lui, l'accepte.
Deux lectures, et rien ne permet de trancher :
- Scout aurait obtenu un score faible mais non nul, ce qui aurait affaibli le graphique en tout-ou-rien ;
- Scout, modèle d'avril 2025 aux poids ouverts, n'était plus jugé pertinent dans un panel de modèles économiques d'API de 2026.
La seconde est défendable. La première reste possible.
3. Le bon réflexe est l'écart entre le test facile et le test dur¶
C'est la leçon transposable, et elle s'applique aux deux modèles :
| Modèle | Test facile | Test dur | Écart |
|---|---|---|---|
| Llama 4 Scout | NIAH @ 10 M : « parfait » | fiction.liveBench @ 128 K : 15,6 % | effondrement |
| Pokee-Isaac 28B | RULER @ 512 K : 96,7 | MRCR v2 @ 512 K : 74,3 | −22 points |
À retenir — et c'est à l'avantage de Pokee
Sur ce critère, Isaac se comporte beaucoup mieux que Scout : perdre 22 points entre un test de récupération et un test de discrimination fine n'a rien à voir avec un effondrement de 84 points.
Et surtout : c'est Pokee qui publie le chiffre défavorable. Meta ne l'a jamais fait — il a fallu attendre des tiers.
C'est le meilleur argument en faveur d'Isaac disponible aujourd'hui. Il reste invérifiable, mais il est d'une nature différente de celui de Meta : Pokee documente sa propre dégradation, Meta l'avait passée sous silence.
Le tableau des revendications à 10 M¶
| Llama 4 Scout | Pokee-Isaac 28B | |
|---|---|---|
| Date | Avril 2025 | Août 2026 |
| Paramètres | 109 G total / 17 G actifs | 28 G total / actifs inconnus |
| Architecture | iRoPE, documentée | « non purement décodeur », non documentée |
| Longueur d'entraînement | 256 K (déclarée) | Inconnue |
| Poids | Ouverts | Fermés |
| Preuve publiée | NIAH + perplexité | RULER + MRCR |
| Évaluation indépendante | Oui — accablante | Aucune |
| Couches à cache linéaire | 12 sur 48, non compressées | ≤ 10 environ (déduit) |
| Cache KV à 10 M | ≈ 517 Go (calculé) | ≈ 176 Go au plus (déduit) |
| Contexte servi en pratique | souvent 128 K chez les hébergeurs | inconnu |
La conclusion honnête
Pokee publie de meilleures preuves que Meta ne l'avait fait, et une architecture moins documentée. C'est exactement l'inverse du compromis de Meta.
L'histoire de Llama 4 Scout ne dit pas qu'Isaac exagère. Elle dit qu'une revendication de 10 M s'est déjà révélée creuse une fois, que le seul moyen de le savoir a été l'évaluation indépendante, et qu'à ce jour elle n'existe pas pour Isaac.
Ce que Scout valide dans l'analyse d'Isaac
Scout est un cas réel qui confirme l'arithmétique de ce rapport. Avec 12 couches à cache linéaire non compressé, il dépasse largement ce que Architecture · 02 identifie comme tenable sur un GPU unique — et c'est exactement ce qui s'est produit : 517 Go de cache, une fenêtre inexploitable, des hébergeurs qui plafonnent à 128 K.
Si Isaac atteint réellement 10 M sur une seule B200, il ne peut donc pas être un iRoPE. Il lui faut soit beaucoup moins de couches globales, soit une compression bien plus agressive, soit — l'hypothèse retenue en Architecture · 04 — des couches à état de taille fixe doublées d'un mécanisme de récupération.
Scout montre à quoi ressemble le contre-exemple : résoudre la généralisation de longueur sans toucher au mur mémoire produit une fenêtre nominale, pas une fenêtre utilisable.
Fin des fondations. La partie suivante : Présentation.