L'arithmétique de la mémoire¶

Ce chapitre établit deux résultats :

La compression « ×5 » annoncée est très loin d'expliquer 10 M de tokens.
10 M de tokens sur une RTX 4090 est arithmétiquement impossible avec toute architecture qui conserve un cache par token.

Tous les calculs sont recalculés par le script de vérification.

Les hypothèses de forme¶

Pokee ne publie pas la forme de son modèle. Il faut donc en poser une, et le faire explicitement.

Hypothèse assumée

Isaac étant partiellement affiné depuis Qwen3.6-27B, on suppose qu'il conserve la forme d'un modèle dense d'environ 30 milliards de paramètres de la famille Qwen 3 :

Paramètre	Valeur	Symbole
Couches	64	\(L\)
Têtes de requête	64	\(H_q\)
Têtes clé/valeur (GQA)	8	\(H_{kv}\)
Dimension par tête	128	\(d_h\)
Dimension des requêtes	8 192	\(d_q = H_q d_h\)

Ces valeurs correspondent à Qwen3-32B, modèle public de la génération précédente. Elles peuvent être fausses de ±50 %, ce qui ne change aucune des conclusions : les écarts établis ci-dessous sont de deux à trois ordres de grandeur.

Étape 1 — Le coût d'un cache classique¶

\[ M_{\text{tok}} = 2 \cdot L \cdot H_{kv} \cdot d_h \cdot b \]

En demi-précision (\(b = 2\) octets) :

\[ M_{\text{tok}} = 2 \times 64 \times 8 \times 128 \times 2 = 262\,144\ \text{octets} = 256\ \text{Kio} \]

À \(n = 10^7\) tokens :

\[ M_{\text{KV}} = 262\,144 \times 10^7 = 2{,}62 \times 10^{12}\ \text{octets} = \mathbf{2{,}62\ \text{To}} \]

Avec la compression ×5 revendiquée par Pokee :

\[ \frac{2{,}62\ \text{To}}{5} = \mathbf{524\ \text{Go}} \]

Premier résultat

524 Go, c'est 2,7 fois la mémoire d'une B200 (192 Go) et 22 fois celle d'une RTX 4090 (24 Go).

La revendication « ≈ 5× de cache KV à VRAM égale » ne peut donc pas être le mécanisme qui permet les 10 M de tokens. Elle décrit tout au plus une optimisation secondaire.

Étape 2 — Le budget réel de chaque GPU¶

Inversons le calcul : combien d'octets par token chaque GPU peut-il réellement consacrer au contexte ?

\[ B_{\text{tok}} = \frac{V_{\text{GPU}} - P_{\text{poids}} - O}{n} \]

Symbole	Signification
\(V_{\text{GPU}}\)	Mémoire vidéo totale
\(P_{\text{poids}}\)	Taille des poids du modèle
\(O\)	Marge pour activations, tampons, fragmentation (2 Gio retenus)
\(n\)	\(10^7\) tokens

RTX 4090 — 24 Gio¶

Poids de 28 milliards de paramètres en 4 bits : ≈ 14 Go.

\[ B_{\text{tok}} = \frac{25{,}77\times10^9 - 14\times10^9 - 2{,}15\times10^9}{10^7} \approx \mathbf{962\ \text{octets/token}} \]

Or une seule couche d'attention complète, même en 8 bits, coûte :

\[ 2 \times 1 \times 8 \times 128 \times 1 = 2\,048\ \text{octets/token} \]

Deuxième résultat — le plus important du rapport

Une RTX 4090 ne peut pas héberger même une seule couche d'attention complète sur 10 M de tokens. Le budget disponible représente 0,47 couche.

La revendication « 10 M de tokens, déployable à partir d'une RTX 4090 » est donc impossible pour toute architecture conservant un cache clé-valeur croissant avec la longueur.

Deux lectures possibles :

Les deux revendications sont disjointes — le modèle tourne sur une 4090 à contexte modeste, et atteint 10 M sur du matériel de centre de données. C'est la lecture la plus probable, et cohérente avec le fait que tous les chiffres de débit sont mesurés sur B200.
Isaac n'a aucune couche à mémoire croissante, et son contexte tient entièrement dans des états de taille fixe. Techniquement possible, mais cela rendrait le rappel exact à 10 M très difficile — or c'est exactement ce que RULER mesure et où Isaac obtient 93,3.

La lecture 1 est de loin la plus vraisemblable.

B200 — 192 Gio¶

Poids en 8 bits : ≈ 28 Go.

\[ B_{\text{tok}} = \frac{206{,}2\times10^9 - 28\times10^9 - 2{,}15\times10^9}{10^7} \approx \mathbf{17\,601\ \text{octets/token}} \]

Soit, en 8 bits :

\[ \frac{17\,601}{2\,048} \approx \mathbf{8{,}6\ \text{couches d'attention complète}} \]

Troisième résultat — celui qui rend l'annonce crédible

Sur B200, le budget autorise environ 8 couches d'attention réelle sur ~64, soit un ratio d'environ 1 couche d'attention pour 7 couches linéaires.

C'est exactement l'ordre de grandeur des architectures hybrides publiques : Jamba (1 pour 8), MiniMax-01 (1 pour 8), Qwen3-Next (1 pour 4), Kimi Linear (1 pour 3).

Les chiffres de Pokee sont donc parfaitement atteignables — mais par une architecture hybride banale, pas par une révolution. Et ils ne sont atteignables que sur du matériel à 192 Go.

Étape 3 — Combien faut-il gagner, au total ?¶

Récapitulons le facteur de réduction nécessaire, sur B200 :

Étape	Octets/token	Facteur cumulé
Décodeur classique, fp16, 64 couches	262 144	×1
Passage en 8 bits	131 072	×2
8 couches d'attention au lieu de 64	16 384	×16
Budget disponible	17 601	atteint

La réduction totale nécessaire est de ×15 environ, dont l'essentiel — un facteur 8 — vient de la suppression de l'attention sur 56 couches sur 64, et non d'une quelconque compression.

À retenir

Le levier dominant n'est pas de compresser le cache, c'est de supprimer le cache sur la grande majorité des couches, en les remplaçant par des couches à état de taille fixe.

Le facteur ×5 annoncé par Pokee, appliqué aux 8 couches restantes, permet ensuite de la marge : soit un contexte plus long, soit plus de couches d'attention, soit un lot de requêtes plus grand.

Ce que ce chapitre n'établit pas¶

Par honnêteté méthodologique :

Il ne prouve pas qu'Isaac a 64 couches ni la forme supposée. Si Isaac avait 32 couches, tous les budgets doubleraient — la conclusion sur la 4090 tiendrait toujours (0,94 couche), celle sur la B200 deviendrait « ≈ 17 couches ».
Il ne dit rien du type de couche à état fixe employé (attention linéaire, SSM, DeltaNet, autre chose).
Il suppose que le contexte réside en mémoire vidéo. Un déchargement vers la mémoire centrale ou un stockage rapide changerait la donne — mais au prix d'une bande passante bien inférieure, ce qui contredirait le débit annoncé.

Le chapitre suivant ferme précisément cette dernière porte.

Chapitre suivant : L'arithmétique du calcul