Vérification arithmétique¶
Cette annexe documente le script qui recalcule toutes les contraintes de la partie Architecture. Elle existe pour une raison précise : rendre ce rapport falsifiable, alors que les affirmations qu'il analyse ne le sont pas.
Ce que le script établit¶
| # | Résultat | Valeur |
|---|---|---|
| 1 | Cache clé-valeur classique à 10 M de tokens | 2,62 To |
| 1 bis | Le même après la réduction ×5 annoncée | 524 Go |
| 2 | Budget réel d'une RTX 4090, à 10 M de tokens | 962 octets/token, soit 0,5 couche |
| 2 bis | Budget réel d'une B200, à 10 M de tokens | 17 601 octets/token, soit 8,6 couches |
| 3 | Durée de préfill de 10 M à 137 200 tokens/s | 73 s |
| 3 bis | Coût d'un dense 28 G | 56 GFLOPs/token, hors budget même en FP4 |
| 4 | Coût d'une seule couche d'attention globale à 10 M | 1,64 × 10¹⁸ FLOPs, soit 12,1 minutes |
| 5 | Cache KV de Llama 4 Scout à 10 Mi tokens | 517 Go |
| 5 bis | Contexte servable par Scout sur 1× H100 80 Go | ≈ 451 K tokens |
| 6 | Architecture spéculative KDA + fenêtre + encodeur, à 10 M | 332 Mo, 14,19 GFLOPs/token |
| 6 bis | La même avec sélection top-k, compression 1:64 | 12,91 GFLOPs/token |
La section 6 chiffre la proposition de la partie Prospective. Elle ne décrit aucun modèle existant.
La section 5 est d'une nature différente des autres : elle ne repose sur aucune
hypothèse, puisque le config.json de Llama 4 Scout est public. Elle sert de
contrôle — elle montre ce que donne l'arithmétique appliquée à une
architecture entièrement connue, et vérifie que la méthode produit bien des
résultats conformes à ce qui a été observé en pratique (des hébergeurs qui
plafonnaient à 128 K).
Hypothèses, et pourquoi elles ne changent pas les conclusions¶
Ce que le script suppose
Pokee ne publiant pas la forme de son modèle, le script en pose une :
| Paramètre | Valeur retenue | Origine |
|---|---|---|
| Couches | 64 | Qwen3-32B |
| Têtes clé/valeur | 8 | Qwen3-32B |
| Têtes de requête | 64 | Qwen3-32B |
| Dimension par tête | 128 | Qwen3-32B |
| Poids sur RTX 4090 | 14 Go (4 bits) | Estimation |
| Poids sur B200 | 28 Go (8 bits) | Estimation |
| Marge système | 2 Gio | Convention |
| Rendement (MFU) | 50 % | Convention généreuse |
| Crêtes B200 | 2,25 / 4,5 / 9,0 PFLOPs en FP16 / FP8 / FP4 | Spécifications constructeur |
Le choix de Qwen3-32B est justifié par la déclaration de Pokee selon laquelle une partie des poids d'Isaac est affinée depuis Qwen3.6-27B.
Robustesse
Une erreur de ±50 % sur le nombre de couches ou la dimension des têtes déplacerait tous les budgets d'un facteur 2. Aucune conclusion ne changerait, car les écarts établis sont de deux à trois ordres de grandeur :
- RTX 4090 : 0,5 couche disponible. Même avec quatre fois plus de budget, on resterait à 2 couches sur 64.
- Attention globale : 10× hors budget pour une couche. Même à 100 % de rendement, on serait encore 5× au-dessus.
- Dense 28 G : 1,7× hors budget en FP4 à 50 % de MFU. Il faudrait 85 % de MFU en FP4 — jamais observé en production.
Un rendement plus faible que 50 %, plus réaliste, ne ferait que renforcer toutes les conclusions.
Le script¶
Emplacement : /workspace/pokee-isaac-arithmetique/verif_contexte_10m.py
Aucune dépendance. Exécution :
python3 verif_contexte_10m.py
Les formules employées, toutes établies dans Fondations · 02 :
def kv_octets_par_token(layers, bytes_per_value=2, shape=SHAPE):
"""2 tenseurs (K et V) x kv_heads x head_dim valeurs, par couche et par token."""
return 2 * layers * shape["kv_heads"] * shape["head_dim"] * bytes_per_value
def budget_kv_par_token(gpu, n=N_10M):
"""Octets de cache KV disponibles par token, pour un contexte de n tokens."""
vram, poids = GPUS[gpu]
libre = vram - poids - OVERHEAD
return libre / n
def prefill_flops_lineaires_par_token(params_actifs):
"""FLOPs des couches linéaires (projections + FFN) par token, en préfill."""
return 2 * params_actifs
def attention_flops_globale(n, layers, d_q=D_Q):
"""FLOPs d'une attention causale DENSE et GLOBALE sur n tokens.
QK^T puis AV, chacun 2*n^2*d_q FLOPs en non causal, divisé par 2 en causal.
Total par couche : 2 * n^2 * d_q.
"""
return layers * 2 * n * n * d_q
def scout_kv_octets(n, bytes_per_value=2, s=SCOUT):
"""Cache KV de Scout à n tokens : couches globales + couches à fenêtre.
Les 12 couches NoPE voient tout le contexte -> cache linéaire en n.
Les 36 couches RoPE sont limitées à des blocs de 8192 -> cache CONSTANT.
"""
par_token_global = 2 * s["nope_layers"] * s["kv_heads"] * s["head_dim"] * bytes_per_value
couches_chunk = s["layers"] - s["nope_layers"]
fixe = 2 * couches_chunk * s["kv_heads"] * s["head_dim"] * bytes_per_value * s["chunk"]
return par_token_global * n + fixe, par_token_global, fixe
Les constantes de SCOUT (48 couches, 8 têtes KV, head_dim 128,
attention_chunk_size 8192, 12 couches NoPE, floor_scale 8192, attn_scale
0,1) proviennent directement du config.json publié par Meta.
Chaque section se termine par une assert : si une conclusion du rapport
devenait fausse, le script échouerait.
Sortie complète¶
========================================================================
1. Le cache KV d'un décodeur classique à 10M tokens
========================================================================
KV par token (64 couches, GQA 8x128, fp16) : 256 Kio
KV total à 10M tokens : 2.62 To
Après la compression 5x annoncée : 524 Go
========================================================================
2. Ce que chaque GPU peut réellement offrir par token
========================================================================
RTX 4090 24 Go : 962 octets/token -> 0.5 couche(s) d'attention complète en fp8
B200 192 Go : 17601 octets/token -> 8.6 couche(s) d'attention complète en fp8
========================================================================
3. Le budget de calcul imposé par 137 200 tok/s de préfill
========================================================================
Préfill de 10M tokens à 137200 tok/s : 73 s
FP16 @ 50% MFU : 8.2 GFLOPs/token -> au plus 4.1 G paramètres ACTIFS
FP8 @ 50% MFU : 16.4 GFLOPs/token -> au plus 8.2 G paramètres ACTIFS
FP4 @ 50% MFU : 32.8 GFLOPs/token -> au plus 16.4 G paramètres ACTIFS
Coût d'un dense 28B : 56.0 GFLOPs/token
========================================================================
4. L'attention globale dense est-elle possible à 10M ?
========================================================================
1 couche(s) globale(s) : 1.64e+18 FLOPs -> 12.1 min de préfill
8 couche(s) globale(s) : 1.31e+19 FLOPs -> 97.1 min de préfill
64 couche(s) globale(s) : 1.05e+20 FLOPs -> 776.7 min de préfill
Budget disponible : 73 s (soit 10x moins qu'une seule couche globale)
Conclusion : les trois contraintes ne sont satisfaites simultanément
que par un modèle à état de taille FIXE sur la majorité des couches,
attention non globale sur les autres, et activation creuse (MoE).
========================================================================
5. Llama 4 Scout : comment Meta atteignait 10M (config.json public)
========================================================================
Si les 48 couches étaient globales : 2.06 To
36 couches à fenêtre de 8192 : 1.21 Go CONSTANTS
12 couches NoPE globales : 49152 octets/token
-> total à 10485760 tokens : 517 Go
Le chunked attention gagne un facteur 4.0.
1x H100 80 Go (int4) -> 451 K tokens de contexte réel
8x H100 640 Go (fp8) -> 10735 K tokens de contexte réel
Temperature tuning des couches NoPE (log, très douce) :
position 8192 -> facteur 1.069
position 256000 -> facteur 1.347
position 1000000 -> facteur 1.481
position 10485760 -> facteur 1.716
Conclusion : Meta a résolu la GÉNÉRALISATION DE LONGUEUR
(NoPE + température), pas le mur mémoire. Les 12 couches globales
gardent un cache linéaire -> la fenêtre de 10M reste virtuelle.
========================================================================
6. SPÉCULATIF — KDA + attention à fenêtre + encodeur de contexte
========================================================================
État KDA (48 couches) : 50.3 Mo CONSTANT
Fenêtres 8192 (12 couches) : 201.3 Mo CONSTANT
Mémoire d'encodeur (1:256) : 80.0 Mo croît en n/256
TOTAL à 10M tokens : 331.7 Mo
-> 1558x moins que Llama 4 Scout (517 Go)
Tient-il sur les GPU visés par Pokee ?
RTX 4090 24 Go (4 bits) : OUI — 9.3 Go restants
B200 192 Go (8 bits) : OUI — 175.7 Go restants
Coût de calcul en préfill (GFLOPs par token) :
KDA : 0.10
fenetre : 0.81
croisee : 1.28
lineaire : 12.00
TOTAL : 14.19 (budget Isaac : 16.4)
Le curseur : le taux de compression de l'encodeur.
1:64 -> mémoire 320.0 Mo, calcul 18.03 GFLOPs/token
1:256 -> mémoire 80.0 Mo, calcul 14.19 GFLOPs/token
1:1024 -> mémoire 20.0 Mo, calcul 13.23 GFLOPs/token
Avec sélection des top-k blocs (façon NSA) au lieu de tout lire :
k=32 @ 1:64 -> mémoire 320.0 Mo, croisée 1.05 MFLOPs, total 12.91 GFLOPs/token
k=64 @ 1:64 -> mémoire 320.0 Mo, croisée 2.10 MFLOPs, total 12.91 GFLOPs/token
k=128 @ 1:64 -> mémoire 320.0 Mo, croisée 4.19 MFLOPs, total 12.91 GFLOPs/token
-> la sélection rend 1:64 moins cher que 1:1024 sans sélection :
on gagne la fidélité SANS payer le calcul.
OK — toutes les assertions passent.
Exécuté le 6 août 2026.
Ce que le script ne prouve pas¶
Par honnêteté :
- Il ne dit rien du type de couche à état fixe employé.
- 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 les budgets mémoire — mais la bande passante disponible contredirait alors le débit annoncé.
- Il ne teste rien de ce que le modèle produit réellement : c'est une analyse de ressources, pas une évaluation.
- Il ne peut pas exclure que le chiffre de 137 200 tokens/s corresponde à un régime différent de celui décrit (lot de plusieurs requêtes, contexte partiel, cache déjà chaud). Dans ce cas, la contrainte sur les paramètres actifs tomberait — mais celles sur la mémoire resteraient.