Résumé exécutif¶
Le problème que DeepSeek attaque¶
Un agent qui travaille longtemps produit peu de texte et en lit énormément. Un appel d'outil, une lecture de fichier, un retour de test : chaque tour rallonge le contexte de milliers de jetons que le modèle doit relire. La charge de travail devient dominée par l'entrée.
Deux coûts en découlent, et ils ne se réduisent pas de la même façon :
- le calcul du préremplissage, proportionnel au nombre de jetons d'entrée qui ne sont pas déjà en cache ;
- le stockage du cache clé-valeur, qui doit rester en mémoire vive graphique pendant la génération et sur SSD entre deux tours pour être réutilisé.
Les travaux antérieurs de DeepSeek (attention creuse dans V3.2 puis V4) avaient déjà cassé le coût de calcul de l'attention. Il restait la mémoire. C'est le sujet exclusif de V4.1-Flash.
Les quatre mécanismes¶
1. CED — l'encodeur-décodeur causal¶
Les 40 couches sont coupées en deux : un encodeur causal de 20 couches et un décodeur de 20 couches. Le cache global du décodeur n'est pas produit par chaque couche du décodeur à partir de son propre état ; il est projeté directement depuis l'état caché de sortie de l'encodeur.
Conséquence : le préremplissage n'exécute que la moitié du réseau. 8 G de paramètres activés par jeton en préremplissage contre 16 G en décodage — un rapport de 2 exactement, que le recalcul retrouve à 2,06.
2. CSA2 — le partage du cache entre couches¶
Chaque couche d'attention reçoit statiquement l'un de trois modes :
| Mode | Cache principal | Clés d'indexeur | Indices Top-K |
|---|---|---|---|
| Full | calculé | calculées | calculés |
| Reindex | réutilisé | réutilisées | recalculés |
| Reuse | réutilisé | réutilisées | réutilisés |
Sur 40 couches, quatre seulement écrivent un cache : les couches 2, 8 et 14 dans l'encodeur, la couche 20 dans le décodeur. Les 36 autres lisent celui de leur source. Chaque couche garde en revanche sa propre requête et sa propre fenêtre glissante locale.
3. Le cache principal en FP4¶
Le cache principal est stocké en E2M1 avec une échelle E4M3 par bloc de 16 canaux, soit 4,5 bits par canal. Les clés d'indexeur utilisent le MXFP4 de l'OCP — E2M1 avec échelle E8M0 par bloc de 32 — soit 4,25 bits par canal.
Le calcul complet donne :
C'est exactement le chiffre annoncé. Le détail figure au chapitre Le cache KV en FP4.
4. SWA Bounded Replay¶
La fenêtre glissante de chaque couche produit son propre cache local. Le reconstruire exactement après une reprise de session exigerait de rejouer \(L \times n_{\text{win}}\) jetons — 40 × 128 = 5 120. DeepSeek n'en rejoue que \(n_{\text{win}} = 128\) et accepte un état approché.
Ce choix supprime le cache de fenêtre glissante du stockage persistant, ce qui ramène l'empreinte SSD à 1/8 de celle de V4-Flash. C'est le seul des quatre mécanismes qui échange explicitement de l'exactitude contre du stockage.
Le résultat en un tableau¶
| Grandeur | Valeur | Statut |
|---|---|---|
| Paramètres du squelette | 552 G | vérifié (551,93 G recalculés) |
| Paramètres Engram | 196 G | vérifié (196,61 G recalculés) |
| Activés / jeton (préremplissage) | 8 G | vérifié (7,61 G) |
| Activés / jeton (décodage) | 16 G | vérifié (15,70 G) |
| Contexte | 1 048 576 jetons | lu dans config.json |
| Cache global | 890 o/jeton | vérifié exactement |
| Cache à 1 M de jetons | 0,87 Gio | conséquence directe |
| Corpus de pré-entraînement | 45 T jetons multimodaux | revendiqué |
| Licence | MIT, poids inclus | vérifié |
Ce que le modèle sait faire¶
Sur les mesures publiées par DeepSeek, V4.1-Flash égale ou dépasse les modèles fermés de pointe sur les tâches agentiques — 90,6 sur Terminal-Bench 2.1 contre 89,1 pour Opus-5, 74,2 sur DeepSWE v1.1 contre 74,0 — tout en restant nettement derrière sur le raisonnement le plus difficile : 36,8 sur HLE contre 56,3 pour Opus-5.
Ce profil est cohérent avec la conception : un modèle optimisé pour ingérer beaucoup et agir longtemps, pas pour concentrer un maximum de connaissance dans ses poids.
Ce que le modèle coûte¶
Les 552 G de paramètres restent 552 G. Le gain porte sur le cache et sur le calcul par jeton, pas sur la mémoire nécessaire pour héberger les poids. En FP4 pour les experts et FP8 pour le reste, il faut environ 300 à 350 Go rien que pour charger le modèle, auxquels s'ajoutent 196 G de paramètres Engram stockés en FP8 — soit environ 196 Go supplémentaires, que l'implémentation garde en mémoire hôte et préextrait par RDMA.
Le détail est au chapitre Matériel et coûts.
Les limites reconnues par DeepSeek¶
Le rapport technique consacre une section entière à ce sujet, ce qui est assez rare pour être noté :
Frontières de robustesse, section 6 du rapport technique
« Des erreurs de sélection potentielles dans CSA2 et la reconstruction approchée d'état dans SWA Bounded Replay peuvent encore causer une dégradation des capacités dans des cas limites non testés. »
Autrement dit : deux des quatre mécanismes centraux sont des approximations dont le domaine de validité n'est pas entièrement caractérisé.