Les hypothèses plausibles¶

Ce chapitre rassemble ce qui reste debout après les contraintes des deux chapitres précédents. Il distingue rigoureusement trois niveaux :

Niveau	Statut
Établi	Découle des chiffres publiés par l'arithmétique
Très probable	Cohérent avec tous les indices, sans alternative sérieuse
Hypothèse	Une lecture parmi plusieurs — signalée comme telle

Ce qui est établi¶

Six conclusions qui ne dépendent d'aucune spéculation

La grande majorité des couches d'Isaac ont une mémoire de taille fixe, indépendante de la longueur du contexte.
Il subsiste au plus une dizaine de couches à mémoire croissante.
Aucune couche ne fait d'attention globale dense sur 10 M de tokens.
Le modèle a nettement moins de 28 milliards de paramètres actifs par token.
Le régime « 10 M de tokens » suppose du matériel de classe centre de données (≈ 192 Go), pas une RTX 4090.
La compression « ×5 » du cache est un facteur secondaire ; le levier dominant est la suppression de l'attention sur la plupart des couches.

L'architecture la plus probable¶

En combinant les six conclusions et les indices du chapitre 01, voici la reconstruction la plus économique.

Squelette¶

Entrée : jusqu'à 10 000 000 tokens
   │
   ├─ Plongements et tokeniseur hérités de Qwen3.6-27B
   │
   ├─ Pile hybride, ~64 couches
   │    ├─ ~56 couches à état de taille fixe
   │    │    (attention linéaire à porte, DeltaNet, ou SSM)
   │    │    mémoire : constante — coût : ~0,5 MFLOPs/token/couche
   │    │
   │    └─ ~8 couches d'attention réelle, NON globales
   │         (fenêtre glissante et/ou sélection creuse de blocs)
   │         mémoire : ~2 Kio/token en 8 bits — coût : ~67 MFLOPs/token
   │
   ├─ Réseaux à propagation avant : mélange d'experts
   │    28 G au total, ~3 à 8 G actifs par token
   │
   └─ Sortie : jusqu'à 60 000 tokens

Ce qui reste à expliquer : le rappel exact¶

Ce squelette satisfait la mémoire et le calcul. Mais il pose un problème : comment retrouver un fait précis au token 6 000 000 ?

Les couches à état fixe compressent : le rappel exact et arbitraire n'est pas leur point fort.
Les couches à fenêtre glissante ne voient que le voisinage immédiat.

Or Isaac obtient 93,3 sur RULER à 10 M, ce qui exige justement du rappel exact. Il manque un mécanisme. Trois candidats, tous connus publiquement :

Candidat	Principe	Coût
Attention creuse sélective	Le contexte est découpé en blocs, chaque bloc résumé par un vecteur ; la requête sélectionne les \(k\) blocs les plus pertinents et n'y applique une attention réelle que sur ceux-là	\(O(n)\) pour la sélection, \(O(k)\) pour l'attention
Mémoire compressive	Les blocs anciens sont résumés en jetons de mémoire persistants, consultés par attention croisée	\(O(n/c)\) pour un taux de compression \(c\)
Encodeur de contexte	Un encodeur traite le contexte par blocs indépendants et produit une mémoire compacte ; le décodeur y accède par attention croisée	\(O(n)\), entièrement parallélisable

Hypothèse principale : le troisième candidat

C'est la lecture qui explique le plus d'indices avec le moins d'hypothèses :

Elle justifie littéralement la formule « non purement décodeur » : il y a bien un encodeur, donc le modèle n'est plus decoder-only.
Elle explique le débit de préfill exceptionnel : un encodeur traite les blocs en parallèle, sans dépendance causale. C'est le seul mécanisme de la liste qui rende 137 200 tokens/s naturel plutôt que miraculeux.
Elle explique la taille mémoire : la sortie de l'encodeur est une mémoire compacte de taille très inférieure au contexte brut.
Elle explique la recette d'entraînement : les poids de Qwen3.6-27B servent de base au décodeur, et l'encodeur — qui n'a aucun équivalent dans Qwen — est « entraîné de zéro », exactement comme Pokee le décrit.

Ceci reste une hypothèse. Elle est cohérente avec tous les indices publics, ce qui n'est pas une preuve.

Le contre-exemple : ce que Llama 4 Scout n'a pas fait¶

Avant de comparer à Kimi K3, un rappel utile — le seul autre modèle annoncé à 10 M de tokens, dont l'architecture est entièrement publique.

Llama 4 Scout combine 36 couches à fenêtre de 8 192 tokens et 12 couches d'attention globale sans encodage de position, plus un ajustement logarithmique de la température. Ce dispositif résout la généralisation de longueur : le modèle ne casse pas à 10 M.

Il ne résout pas le mur mémoire. Les 12 couches globales gardent un cache linéaire, soit 517 Go à 10 Mi tokens — d'où une fenêtre nominale que personne ne pouvait servir.

Pourquoi ce contre-exemple renforce l'analyse

Scout est la démonstration empirique que les contraintes des chapitres 02 et 03 mordent réellement. Une architecture qui laisse 12 couches globales à 10 M a effectivement échoué, exactement là où le calcul le prévoit.

Si Isaac tient sa promesse sur une seule B200, il ne peut donc pas être bâti sur ce schéma : le budget n'autorise que ~8 couches à cache croissant, et encore, en 8 bits. D'où le squelette proposé ci-dessus.

Détail complet : Fondations · 05.

Un point de comparaison utile : Kimi K3¶

La bibliothèque contient une analyse détaillée de Kimi K3, sorti une semaine plus tôt. Le contraste est instructif :

	Kimi K3	Pokee-Isaac 28B
Paramètres	2,78 T total, 104 G actifs	28 G, actifs non publiés
Contexte	1 048 576 tokens	10 000 000 tokens
Attention	Kimi Delta Attention, hybride 3:1	Non publiée
Poids	Ouverts	Fermés
Rapport technique	Publié et détaillé	Absent
Vérifiable	Oui — paramètres recalculés depuis `config.json`	Non

Ce que la comparaison montre

Kimi K3 utilise exactement la stratégie que l'arithmétique impose à Isaac : une pile hybride mêlant couches linéaires (KDA) et couches d'attention complète, dans un ratio de 3 pour 1.

Autrement dit, l'hypothèse formulée ici sur Isaac n'est pas exotique : c'est l'état de l'art publié de 2026. Ce qui distingue Isaac, c'est un ratio plus agressif (≈ 1 pour 7 au lieu de 1 pour 3), un modèle 100 fois plus petit, un facteur 10 sur le contexte — et l'absence totale de documentation.

La différence de vérifiabilité est, elle, totale : sur Kimi K3, on a pu recalculer les 2,779 T de paramètres depuis le seul fichier de configuration. Sur Isaac, on ne peut rien recalculer du tout.

Comment on pourrait vérifier¶

Par ordre de faisabilité, pour qui voudrait aller au-delà de ce rapport :

1. Le code d'intégration vLLM / SGLang¶

Le levier le plus prometteur. Ces moteurs sont ouverts et ne supportent que les architectures qu'on leur décrit. Si Pokee y contribue une implémentation, la classe de modèle exposera le nombre de couches, leur nature, le ratio hybride et le mécanisme d'attention. Surveiller les dépôts et les demandes de fusion mentionnant Isaac ou Pokee.

2. Sonder l'API¶

Mesures possibles sans aucun accès privilégié :

Latence au premier token en fonction de la longueur d'entrée. Une croissance strictement linéaire indique l'absence d'attention quadratique globale. Un décrochage par paliers révélerait un traitement par blocs — signature d'un encodeur.
Rappel en fonction de la position. Placer une aiguille à 1 %, 10 %, 50 %, 90 % et 99 % du contexte. Un modèle à fenêtre glissante seule s'effondre au milieu ; un modèle à sélection de blocs reste plat ; une architecture à état fixe dégrade progressivement vers le début.
Rappel de détails à faible saillance. Une chaîne aléatoire vs. une phrase sémantiquement marquée. Si l'écart est important, la récupération passe par une sélection sémantique — donc par un mécanisme de type recherche.
Coût du cache de préfixe. La tarification de la lecture en cache révèle ce qui est réellement mis en cache, donc la nature de l'état conservé.

3. Les brevets¶

Les cinq demandes provisoires deviendront publiques vers mi-2027 si des demandes non provisoires sont déposées. Ce sera alors la source la plus détaillée disponible.

4. Attendre une évaluation indépendante¶

Aucune n'existait au 6 août 2026, deux jours après l'annonce.

Ce qu'il faut retenir¶

La réponse à « comment ont-ils fait ? »

Pokee ne le dit pas, et personne à l'extérieur ne le sait.

Mais l'arithmétique établit que ce ne peut être qu'une architecture hybride à activation creuse : la majorité des couches ont un état de taille fixe, une minorité fait de l'attention restreinte, et un mécanisme de sélection ou de compression — probablement un encodeur de contexte — assure le rappel exact.

Ce n'est pas une percée théorique : c'est la direction que suit toute l'industrie depuis 2024. Ce qui serait remarquable, si les chiffres se confirment, c'est l'exécution : atteindre 10 M avec 28 milliards de paramètres et un score RULER de 93,3, alors que les modèles hybrides publics plafonnent à 1 M.

Et c'est précisément ce point — l'exécution — qui reste entièrement à vérifier.