Aller au contenu

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 :

\[ \alpha(t) = \operatorname{attn\_scale} \cdot \log\!\left(\left\lfloor \frac{t+1}{\operatorname{floor\_scale}} \right\rfloor + 1\right) + 1 \]
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\).

\[ M_{\text{Scout}}(n) = \underbrace{2 \cdot 12 \cdot 8 \cdot 128 \cdot b \cdot n}_{\text{12 couches globales}} \;+\; \underbrace{2 \cdot 36 \cdot 8 \cdot 128 \cdot b \cdot 8192}_{\text{36 couches à fenêtre, constant}} \]

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 :

  1. Aiguille dans une botte de foin (needle in a haystack) sur toute la plage jusqu'à 10 M.
  2. 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.