Contexte 262 K et 1 M¶

L'arithmétique qui justifie toute l'architecture — et le chiffre qu'Alibaba ne publie pas.

Les deux nombres¶

La carte de modèle annonce :

« 262,144 natively and extensible up to 1,010,000 tokens »

config.json confirme le premier :

"max_position_embeddings": 262144

Le second n'apparaît nulle part dans la configuration. C'est une capacité de service, obtenue par extension à l'exécution.

262 144 et 1 010 000 ne se valent pas

Le contexte natif est celui sur lequel le modèle a été entraîné ou adapté. Le contexte étendu repose sur une réinterprétation des positions à l'inférence.

L'extension fonctionne, mais la qualité de rappel s'y dégrade généralement — d'autant plus que l'on s'éloigne du régime d'entraînement.

Aucune mesure publiée ne documente cet écart pour Qwen3.8-Max. Le seul benchmark long contexte du tableau officiel, MRCR v2 (92,9), est évalué à 256 K — dans le contexte natif.

Le chiffre 1 010 000 n'est pas arbitraire : c'est exactement la valeur annoncée pour Qwen3.6-27B, dont la documentation attribue l'extension à YaRN. Il est très probable — mais non confirmé — que la même méthode s'applique ici.

Le calcul du cache¶

Le point décisif, énoncé une fois pour toutes :

Seules 23 couches sur 92 produisent un cache

Les 69 couches DeltaNet maintiennent un état de taille fixe. Elles ne contribuent pas au cache clé-valeur.

Pour une couche d'attention complète :

\[ c_{\text{couche}} = 2 \times H_{kv} \times d_h \times b = 2 \times 4 \times 256 \times 2 = 4\,096\ \text{octets par jeton} \]

Pour les 23 couches :

\[ c = 23 \times 4\,096 = 94\,208\ \text{octets} = 92\ \text{KiO par jeton} \]

Les résultats¶

Longueur du contexte	Cache clé-valeur
8 192 jetons	0,77 Go
32 768 jetons	3,09 Go
131 072 jetons	12,3 Go
262 144 jetons (natif)	24,7 Go
524 288 jetons	49,4 Go
1 010 000 jetons (étendu)	95,2 Go

À quoi s'ajoute l'état récurrent des couches linéaires :

\[ 69 \times 128 \times 128 \times 128 \times 4 = 578\,813\,952 \approx 0{,}58\ \text{Go} \]

Constant. Il ne dépend ni de la longueur, ni du nombre de requêtes en cours — un état par séquence active, certes, mais indépendant de sa longueur.

Le contrefactuel¶

C'est là que l'architecture prend son sens. Quel serait le cache si les 92 couches étaient en attention complète, à configuration identique par ailleurs ?

\[ 92 \times 4\,096 = 376\,832\ \text{octets par jeton} = 368\ \text{KiO} \]

Longueur	23 couches (réel)	92 couches (hypothétique)
262 144	24,7 Go	98,8 Go
1 010 000	95,2 Go	380,6 Go

L'hybride économise 75 % du cache

C'est le chiffre central de ce rapport, et il n'est publié nulle part.

À 380 Go, un contexte d'un million de jetons demanderait cinq GPU H100 dédiés au seul cache, en plus des dizaines nécessaires aux poids. À 95 Go, il tient sur un nœud.

L'attention hybride n'est pas une élégance théorique : c'est ce qui rend le million de jetons commercialement viable à 2 $ le million de jetons d'entrée.

Et sans GQA¶

Poussons le contrefactuel d'un cran. Si le modèle n'avait ni GQA ni hybride — 92 couches d'attention complète à 64 têtes clé-valeur :

\[ 92 \times 2 \times 64 \times 256 \times 2 = 6\,029\,312\ \text{octets} = 5{,}75\ \text{MiO par jeton} \]

À un million de jetons : 6,03 To de cache. Davantage que les poids eux-mêmes.

Configuration	Cache à 1 M	Facteur
Sans GQA ni hybride	6 030 Go	×63
GQA seul (92 couches)	381 Go	×4
GQA + hybride (réel)	95 Go	×1

Les deux optimisations sont multiplicatives : ensemble, elles divisent le cache par 63.

Le service concurrent¶

Un serveur ne traite pas une requête à la fois. Le cache est proportionnel au nombre de séquences actives.

Concurrence	Longueur moyenne	Cache total
1	1 000 000	95,2 Go
10	100 000	95,2 Go
50	32 000	152 Go
200	8 000	152 Go

Le produit concurrence × longueur est ce qui compte. Un fournisseur arbitre en permanence entre servir peu de très longs contextes et beaucoup de courts.

Ce que cela explique du tarif

Qwen facture le même prix sur toute la fenêtre — 2 $ le million de jetons d'entrée, que le contexte fasse mille ou un million de jetons. Peu de concurrents le font.

L'architecture hybride est ce qui rend cette tarification tenable : le coût marginal d'un contexte long y est quatre fois plus faible qu'avec une architecture classique.

Le calcul, pas seulement la mémoire¶

Le cache est un problème de mémoire. Le préremplissage — traiter les 1 010 000 jetons d'entrée avant de générer quoi que ce soit — est un problème de calcul, et il reste quadratique sur les 23 couches complètes.

\[ \text{opérations} \propto 23 \times n^2 \times d \]

À un million de jetons, cela reste considérable : environ un quart de ce que coûterait une architecture entièrement en attention complète, mais un quart d'un très grand nombre.

C'est cohérent avec le délai au premier jeton de 2,72 s mesuré par Artificial Analysis sur des requêtes courtes. Sur un contexte réellement long, attendez-vous à des dizaines de secondes avant le premier jeton.

Récapitulatif mémoire¶

Pour un déploiement complet à contexte plein :

Poste	BF16	FP8	4 bits
Poids	4 892 Go	2 446 Go	1 223 Go
Cache KV à 1 M	95 Go	95 Go	95 Go
État récurrent	0,6 Go	0,6 Go	0,6 Go
Total	4 988 Go	2 542 Go	1 319 Go
GPU H100 (80 Go, 85 % utiles)	74	38	20
GPU B200 (180 Go, 85 % utiles)	33	17	9

Note : le cache ne suit pas la quantification des poids. Quantifier en 4 bits divise les poids par quatre, pas le cache. Sur un déploiement à contexte long et forte concurrence, cette asymétrie devient le facteur dominant.

À retenir¶

Ce chapitre en cinq points

Contexte natif 262 144, étendu à 1 010 000 — probablement par YaRN, non confirmé, et non mesuré dans les benchmarks publiés.
Seules 23 couches sur 92 produisent un cache : 92 KiO par jeton.
À un million de jetons : 95,2 Go, contre 380,6 Go sans hybride — 75 % d'économie.
Combinée à GQA, l'architecture divise le cache par 63 par rapport à un Transformer classique.
Le cache ne se quantifie pas avec les poids ; à contexte long il devient le poste dominant.

Fin de la partie Architecture.

Suite : Évaluations — ce que valent les scores.