Combiner KDA, iRoPE et un encodeur¶
Rappel
Conception spéculative. N'est l'architecture d'aucun modèle existant, et pas celle de Pokee-Isaac.
Trois mémoires, trois métiers¶
Le point de départ est la division du travail que le rapport technique de Kimi K3 formule explicitement : les couches à état fixe portent la position et la récence, les couches sans encodage de position portent le contenu global pur. On ajoute une troisième voie pour ce qu'aucune des deux ne sait faire : le rappel exact à longue distance.
| Couches | Brique empruntée à | Rôle | Mémoire |
|---|---|---|---|
| 48 | KDA (Kimi K3) | Fil narratif, récence, position — mémoire de travail | constante |
| 12 | Fenêtre 8 192 + NoPE + temperature tuning (Llama 4) | Précision locale, extrapolation sans casse | constante |
| 4 | Attention croisée sur mémoire d'encodeur | Rappel exact du contexte lointain | croît en \(n/c\) |
Le tout sur un mélange d'experts creux (≈ 4 G de paramètres actifs) et un encodeur de ≈ 2 G.
Ce que chaque brique apporte, et pourquoi elle ne suffit pas¶
KDA seul — une mémoire associative de taille fixe (\(\mathbf{S}_t \in \mathbb{R}^{128\times128}\) par tête) avec règle delta et oubli par canal. Elle ne croît jamais. Mais c'est une compression avec perte : le rappel exact et arbitraire n'est pas son point fort, et Kimi K3 s'arrête à 1 M de tokens.
Fenêtre + NoPE + température seuls — c'est Llama 4 Scout. Le modèle ne casse pas à 10 M, mais les couches globales gardent un cache linéaire : 517 Go. Fenêtre nominale, pas utilisable.
Encodeur seul — compresse bien, mais un modèle sans mémoire de travail récurrente perd le fil d'une tâche longue.
L'argument décisif pour l'encodeur : le cache de préfixe¶
Ce n'est pas seulement une affaire de mémoire. Le rapport de Kimi K3 documente un problème que Moonshot subit de plein fouet, détaillé dans l'analyse de K3 :
Une couche KDA maintient un unique grand état récurrent par séquence, pas des entrées par jeton. Les instantanés ne sont donc abordables qu'à des frontières rares.
Conséquence : la taille de bloc est forcée à 1 024–6 144 jetons, et à cette granularité « le cache est presque inutile ».
Ce qu'un encodeur change
Une mémoire d'encodeur n'a pas ce défaut. Chaque bloc est encodé indépendamment des autres, donc :
- parallélisable au préfill — aucune dépendance causale entre blocs ;
- cacheable parfaitement — un bloc encodé une fois est réutilisable tel quel, à sa propre frontière ;
- partageable entre requêtes qui partagent un corpus.
C'est ce qui expliquerait à la fois un débit de préfill élevé et un tarif de lecture en cache très bas — les deux caractéristiques annoncées par Pokee.
Le problème ne disparaît pas complètement : les couches KDA restent difficiles à mettre en cache. Mais il se déplace sur la fenêtre récente au lieu de porter sur les 10 M de tokens.
Le budget complet, chiffré¶
Recalculé par le script de vérification, section 6.
Mémoire à 10 M de tokens¶
| Poste | Taille | Croissance |
|---|---|---|
| État KDA, 48 couches | 50,3 Mo | constante |
| Fenêtres de 8 192, 12 couches | 201,3 Mo | constante |
| Mémoire d'encodeur, compression 1:256 | 80,0 Mo | en \(n/c\) |
| TOTAL | 331,7 Mo |
| Symbole | Signification | Valeur |
|---|---|---|
| \(L_{\text{kda}}, L_{\text{fen}}\) | Couches KDA / à fenêtre | 48 / 12 |
| \(H, H_{kv}, d_h\) | Têtes, têtes KV, dimension par tête | 32 / 8 / 128 |
| \(W\) | Fenêtre | 8 192 |
| \(c\) | Taux de compression de l'encodeur | 64 à 1 024 |
| \(d_{\text{mem}}\) | Dimension d'une entrée de mémoire | 1 024 |
| \(b\) | Octets par valeur | 1 (fp8) |
331,7 Mo — soit 1 558 fois moins que Llama 4 Scout
| Machine | Tient ? | Marge |
|---|---|---|
| RTX 4090 24 Go, poids en 4 bits | OUI | 9,3 Go |
| B200 192 Go, poids en 8 bits | OUI | 175,7 Go |
C'est le résultat le plus frappant de l'exercice : ce design rendrait vraie la revendication que le rapport démontre fausse.
Ce n'est pas « 10 M sur une RTX 4090 » qui est impossible. C'est « 10 M sur une RTX 4090 avec un cache par token » qui l'est.
Calcul, en préfill¶
| Poste | GFLOPs / token |
|---|---|
| KDA (48 couches) | 0,10 |
| Fenêtres (12 couches) | 0,81 |
| Attention croisée | 1,28 |
| Couches linéaires (MoE + encodeur) | 12,00 |
| TOTAL | 14,19 |
| Budget pour tenir 137 200 tok/s (FP8 @ 50 % MFU) | 16,4 |
Le poste dominant n'est pas celui qu'on croit
85 % du budget part dans les couches linéaires. Le mélange de tokens — KDA, fenêtres, attention croisée — coûte moins de 2,2 GFLOPs par token, soit 15 %.
C'est la signature d'une architecture à contexte long correctement conçue : à 10 M de tokens, l'attention ne doit plus être le poste dominant. Ce qui contraint le débit, c'est le nombre de paramètres actifs — exactement la conclusion de Architecture · 03.
Le curseur : le taux de compression¶
Tout se joue sur \(c\), le nombre de tokens résumés par entrée de mémoire.
| Compression | Mémoire d'encodeur | Calcul total |
|---|---|---|
| 1:64 | 320,0 Mo | 18,03 GFLOPs/token — hors budget |
| 1:256 | 80,0 Mo | 14,19 |
| 1:1024 | 20,0 Mo | 13,23 |
Compresser 256 tokens en un vecteur est une perte irréversible. On garde ce qui est distinctif, on perd ce qui se ressemble.
Une prédiction testable
Une telle architecture devrait exceller sur RULER — retrouver ce qui détonne dans un remplissage neutre — et décrocher sur MRCR — distinguer des passages quasi identiques.
C'est exactement le profil mesuré chez Pokee-Isaac : 96,7 contre 74,3 à 512 K de contexte.
Un design qui prédit l'anomalie observée sans avoir été construit pour cela est un argument sérieux en faveur de l'hypothèse « encodeur » formulée en Architecture · 04.
Le chapitre suivant propose la solution à ce compromis — et montre qu'on peut, en grande partie, ne pas avoir à choisir.