Aller au contenu

Contexte et cache

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 :

« Context Length: 262,144 natively and extensible up to 1,000,000 tokens. »

config.json confirme le premier :

"max_position_embeddings": 262144

Le second n'y figure pas : c'est une capacité obtenue par extension à l'exécution, attribuée à YaRN par la carte de modèle.

262 144 et 1 000 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. Aucune mesure publiée ne documente cet écart, et aucun benchmark du tableau officiel n'évalue le long contexte.

Une prédiction ratée de peu

La première édition de ce rapport prévoyait une extension à 1 010 000 jetons, par analogie avec Qwen3.6-27B et Qwen3.8-Max qui affichent tous deux ce chiffre exact.

La valeur réelle est 1 000 000 — un arrondi commercial plutôt qu'une valeur technique. Écart de 1 %. Voir Le verdict des hypothèses.


Le calcul du cache

Le point décisif, et il n'apparaît dans aucune communication.

Seules 16 couches sur 64 produisent un cache

Les 48 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 16 couches :

\[ c = 16 \times 4\,096 = 65\,536\ \text{octets} = 64\ \text{KiO par jeton} \]

Les résultats

Longueur du contexte Cache clé-valeur
8 192 jetons 0,54 Go
32 768 jetons 2,15 Go
131 072 jetons 8,59 Go
262 144 jetons (natif) 17,18 Go
524 288 jetons 34,36 Go
1 000 000 jetons (étendu) 65,54 Go

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

\[ 48 \times 48 \times 128 \times 128 \times 4\ \text{octets} \approx 0{,}159\ \text{Go} \]

Constant, quelle que soit la longueur. Négligeable devant le reste.


Le contrefactuel

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

\[ 64 \times 4\,096 = 262\,144\ \text{octets par jeton} = 256\ \text{KiO} \]
Architecture Cache à 262 144 jetons Cache à 1 000 000
16 couches complètes (réel) 17,18 Go 65,54 Go
64 couches complètes (hypothétique) 68,72 Go 262,14 Go

L'hybride économise 75 % du cache

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

Concrètement, sur une RTX 4090 de 24 Go avec des poids en 4 bits :

Architecture Contexte utilisable
64 couches complètes ~30 000 jetons
Hybride 3:1 (réel) ~115 600 jetons

Un facteur presque quatre sur ce que le modèle peut réellement faire chez vous. C'est la différence entre « répondre à des questions » et « analyser un dépôt de code ».


Et sans GQA

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

\[ 64 \times 2 \times 24 \times 256 \times 2 = 1\,572\,864\ \text{octets} = 1{,}5\ \text{MiO par jeton} \]

À 262 144 jetons : 412 Go de cache. Plus de sept fois les poids en BF16.

Configuration Cache à 262 144 Facteur
Sans GQA ni hybride 412,3 Go ×24
GQA seul (64 couches) 68,7 Go ×4
GQA + hybride (réel) 17,2 Go ×1

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


Le piège du dimensionnement

Quantifier les poids ne quantifie pas le cache

Poids en 4 bits (13,86 Go), cache en BF16 :

Contexte Total Part du cache
32 768 16,2 Go 13 %
131 072 22,6 Go 38 %
262 144 31,2 Go 55 %
1 000 000 79,6 Go 82 %

Passer de BF16 à 4 bits divise les poids par quatre. Le cache ne bouge pas d'un octet.

La parade — quantifier le cache lui-même en FP8 — est traitée en Le coût du cache clé-valeur.

Mais la situation est bien meilleure que sur un modèle classique

Grâce à l'hybride, le cache ne devient dominant qu'au-delà de 200 000 jetons. Sur un dense classique de même taille, il l'était déjà à 60 000.


La concurrence

Le cache est proportionnel au nombre de séquences actives, pas seulement à leur longueur.

Sur une carte de 48 Go avec des poids en 4 bits (~29,4 Go disponibles) :

Requêtes simultanées Contexte par requête
1 ~445 000 jetons
4 ~112 000 jetons
16 ~28 000 jetons
64 ~7 000 jetons

Dimensionner sur le produit, pas sur la longueur

On teste seul, tout va bien. On met en service, seize utilisateurs se connectent, et le contexte s'effondre.

Pour un usage multi-utilisateur, la grandeur à budgéter est concurrence × contexte.


Le préremplissage

Le cache est un problème de mémoire. Traiter les 262 144 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 16 couches complètes.

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

Soit un quart de ce que coûterait une architecture entièrement en attention complète — mais un quart d'un très grand nombre. Sur un contexte réellement long et une carte grand public, attendez-vous à plusieurs minutes avant le premier jeton.


À retenir

Ce chapitre en cinq points

  1. Contexte natif 262 144, étendu à 1 000 000 par YaRN — et jamais mesuré dans les benchmarks publiés.
  2. Seules 16 couches sur 64 produisent un cache : 64 KiO par jeton.
  3. À 262 144 jetons : 17,18 Go, contre 68,72 Go sans hybride — 75 % d'économie.
  4. Combinée à GQA, l'architecture divise le cache par 24 par rapport à un Transformer classique.
  5. Le cache ne se quantifie pas avec les poids ; il devient dominant au-delà de 200 000 jetons.

Partie suivante : Évaluations.