DeepSeek-V4.1-Flash, expliqué pas à pas

Un LLM ne manipule pas des mots mais des tokens. Son unique talent : à partir d'une séquence de tokens, prédire le suivant. Pour écrire une réponse, il prédit un token, l'ajoute à la séquence, puis recommence. C'est la génération autorégressive.

Ce travail se déroule en deux phases très différentes :

• Le prefill : le modèle lit tout le prompt d'un coup. Tous les tokens sont traités en parallèle, ce qui fait de grosses multiplications de matrices. Cette phase est limitée par la puissance de calcul.
• Le decode : le modèle produit la réponse un token à la fois. À chaque pas, il ne calcule qu'un token, mais doit relire tous ses poids et toute sa mémoire du contexte. Cette phase est limitée par la bande passante mémoire.

Pour prédire la suite, chaque token a besoin d'informations venant des tokens précédents. C'est le rôle de l'attention. Chaque token produit trois vecteurs :

• une requête Q (query) : « qu'est-ce que je cherche ? » ;
• une clé K (key) : « voici ce que je contiens », comme l'étiquette d'un tiroir ;
• une valeur V (value) : le contenu du tiroir, l'information réellement transmise.

Le token courant compare sa requête à toutes les clés (produit scalaire). Il transforme ces scores en poids qui somment à 1 (softmax), puis fait la moyenne pondérée des valeurs. Un modèle empile des dizaines de couches qui répètent cette opération. DeepSeek-V4.1-Flash en a 40.

Dans un modèle causal, un token ne regarde jamais le futur. Les clés et valeurs d'un token passé ne changent donc plus jamais. Plutôt que de les recalculer à chaque nouveau token, on les stocke : c'est le cache KV. Il grandit linéairement avec la longueur du contexte :

Ce cache vit à trois étages de mémoire, du plus rapide et rare au plus lent et abondant :

Un agent (assistant de code, automatisation de bureau…) enchaîne des dizaines d'appels d'outils. À chaque tour, la sortie de l'outil (un fichier, un log, une page web) s'ajoute au contexte. Le modèle doit la lire (prefill), puis écrire quelques lignes (decode). Résultat : les charges de travail deviennent très majoritairement en entrée (input-heavy).

Deux mécanismes permettent de tenir le coût :

• Le cache de préfixe : si le début du contexte a déjà été lu, on recharge son cache KV au lieu de le recalculer. Il faut alors stocker ce cache, parfois longtemps, sur SSD.
• Un prefill moins cher : pour les nouveaux tokens, et pour les cas où le cache a été perdu (cache miss), il faut tout recalculer.

Dans un Transformer, chaque couche alterne attention et réseau « feed-forward ». Dans un modèle MoE, ce réseau est découpé en nombreux petits experts. Un routeur n'en active que quelques-uns par token. DeepSeek-V4.1-Flash utilise dans chaque couche 1 expert partagé (toujours actif) et 384 experts routés, dont 6 sont choisis pour chaque token.

C'est pourquoi on distingue paramètres totaux (552 Md, la connaissance stockée) et paramètres activés (le calcul réellement fait pour un token). Particularité de V4.1 : ce second chiffre vaut 8 Md en prefill et 16 Md en decode. Le chapitre 4 explique pourquoi.

Un contexte d'un million de tokens pose un problème : si chaque nouveau token compare sa requête à un million de clés, dans chaque couche, le coût explose. La famille DeepSeek combine donc plusieurs formes d'attention :

• L'attention globale dense regarde tout le passé. Elle est exacte mais son coût croît avec la longueur.
• L'attention à fenêtre glissante (SWA) ne regarde que les n_win = 128 derniers tokens. Son coût et son cache sont bornés.
• L'attention parcimonieuse (sparse) : un petit module, l'indexeur, note toutes les entrées du passé et n'en garde que les 512 meilleures (top-k). L'attention principale ne lit que celles-là, plus la fenêtre locale.

DeepSeek-V3.2 et V4 ont introduit ces attentions parcimonieuses et compressées. Le décor de V4.1 est donc : une branche locale (SWA) dans chaque couche + une branche globale compressée et parcimonieuse.

Dans DeepSeek-V4, chaque couche combine deux branches d'attention :

• une branche globale qui couvre tout le contexte. Elle maintient un KV global, composé du main KV (les entrées lues par l'attention) et de l'indexer K (les clés de l'indexeur qui choisit les entrées à lire) ;
• une branche locale SWA qui maintient le KV SWA des 128 derniers tokens.

Le KV SWA a une taille fixe, quelle que soit la longueur du contexte. Pour les longues séquences, c'est donc le KV global qui domine la mémoire. Il est limité par la capacité de la HBM. De plus, une partie du cache est persistée sur SSD ou en RAM hôte pour réutiliser les préfixes, ce qui ajoute deux contraintes : la capacité de stockage et la bande passante d'entrée/sortie.

Le papier présente la compression comme le fruit d'une optimisation conjointe à trois niveaux. Chacun fait l'objet d'un chapitre de ce cours :

Bilan annoncé : à longueur de séquence égale, V4.1-Flash n'a besoin que d'environ ¼ du cache KV d'exécution (en HBM) et d'environ ⅛ du cache KV persistant (SSD / RAM hôte) de V4-Flash. C'est pourtant un modèle plus gros (552 Md contre 284 Md de paramètres) et plus performant.

Toutes les améliorations se combinent aussi côté calcul. La figure 2 compte les opérations nécessaires pour générer un token selon la longueur du contexte déjà présent. Elle pondère les opérations BF16, FP8 et FP4 par 1, 0,5 et 0,25. Pour V4.1-Flash, la courbe est presque plate : multiplier le contexte par 256, de 4K à 1M tokens, n'augmente le coût d'un token que d'un quart.

Voici la carte générale avant d'entrer dans les détails :

• 40 couches Transformer causales, organisées en un encodeur causal de 20 couches suivi d'un décodeur de 20 couches. Le mot « encodeur » peut surprendre : ici, il reste causal (il ne regarde jamais le futur). Il est simplement la moitié basse du réseau.
• Chaque couche combine une attention globale (CSA2) et une attention locale SWA, sauf les deux premières, en SWA seule.
• Toutes les couches feed-forward sont des DeepSeekMoE standard.
• Un encodeur visuel (DeepSeek-ViT) et un projecteur MLP transforment les images en embeddings traités avec le texte dès le début du pré-entraînement.
• S'y ajoutent quatre briques : Single-Pass mHC (les connexions résiduelles), Engram (une mémoire consultable par hachage), DSpark (décodage spéculatif) et l'indexeur parcimonieux hiérarchique.

Pour les curieux, voici la configuration donnée dans la section 4.2.1 du rapport. Pas besoin de tout retenir : on reviendra sur chaque chiffre important au fil des chapitres.

Dans les workflows d'agents, les appels d'outils génèrent énormément de requêtes de prefill. Quand le cache KV n'est pas disponible (cache miss), il faut tout recalculer. CED s'inspire de YoCo (You Only Cache Once, Sun et al., 2024). Dans YoCo, la moitié haute des couches réutilise directement le cache KV produit par la moitié basse. CED reprend l'idée et ajoute des améliorations structurelles pour augmenter la capacité du cache KV et la profondeur de calcul qui le produit.

Les L/2 = 20 couches du bas forment l'encodeur causal. Pour les couches du haut (le décodeur, l > L/2), les entrées KV globales ne sont pas calculées à partir de leur propre état caché H_l. Elles sont projetées directement depuis l'état caché de la dernière couche de l'encodeur, H_L/2, avec des poids propres à chaque couche :

Combiné avec CSA2 (chapitre 5), c'est la couche du décodeur en mode Full qui calcule son KV global à partir de H_L/2. Les autres couches du décodeur réutilisent ce KV.

Pour l'attention à fenêtre glissante, CED garde le calcul classique couche par couche : les clés et valeurs locales de la couche l viennent bien de son propre état caché H_l. Cela augmente la « profondeur de calcul » du KV local, mais crée une dépendance gênante.

Pour que le décodeur commence à générer, il lui faut le KV SWA des 128 derniers tokens dans chacune de ses couches. Or la fenêtre de la couche 30 dépend des sorties de la couche 29 sur une fenêtre plus large, qui dépendent elles-mêmes de la couche 28 sur une fenêtre encore plus large… Les fenêtres s'empilent. Reconstituer exactement ces états exige de faire passer environ n_win × L/2 = 128 × 20 = 2 560 tokens dans les couches du décodeur.

Pour des interactions multi-tours avec des messages courts, ce surcoût devient important : on rejouerait 2 560 tokens pour n'en lire que quelques centaines de nouveaux. Heureusement, des travaux antérieurs (Chen et al., 2025) ont montré que le champ récepteur effectif de SWA est bien plus petit que le champ théorique n_win × L/2. D'où le Decoder SWA Bounded Replay : le décodeur ne fait passer que les 128 derniers tokens du prompt pour construire son KV SWA. Les états obtenus sont approximatifs, et le papier constate un impact « négligeable » sur la qualité des réponses. Le mécanisme est détaillé au chapitre 8.

Pendant le prefill, presque tous les tokens du prompt ne traversent que les 20 couches de l'encodeur. Seuls les 128 derniers passent aussi dans le décodeur (bounded replay). Un token de prompt n'active donc qu'environ la moitié des paramètres : 8 Md. Un token généré pendant le decode, lui, traverse les 40 couches : 16 Md. Comme les charges d'agents sont dominées par la lecture, c'est le chiffre de 8 Md qui pèse le plus sur la facture.

Les auteurs décomposent le coût du cache KV selon trois dimensions multiplicatives :

• La taille de chaque entrée : GQA réduit le nombre de têtes KV ; MLA (DeepSeek-V2/V3) partage un petit vecteur latent entre toutes les têtes.
• La dimension séquence : on compresse m tokens consécutifs en une seule entrée, comme CSA et HCA dans V4.
• La dimension des couches : certaines couches réutilisent le cache ou les sélections d'autres couches au lieu de garder les leurs.

L'axe des couches avait déjà été exploré. IndexCache réutilise les indices top-k d'une couche à l'autre ; YOIO calcule le routage parcimonieux une seule fois pour tout le réseau ; HySparse fait réutiliser le KV de couches denses par des couches parcimonieuses. Mais chacune de ces méthodes a une limite, selon les auteurs. Réutiliser les indices n'économise pas le stockage du main KV. Partager le routage dans tout le réseau limite la performance. Les designs hybrides gardent des couches d'attention complète. Surtout, aucune ne couvre les trois axes à la fois. CSA2 les combine.

Comme CSA, chaque couche CSA2 contient :

• le main KV : les entrées du cache global, chacune résumant m tokens consécutifs. m = 1, sans compression, est un cas particulier, utilisé dans le décodeur ;
• un indexeur léger : il note chaque entrée du main KV en combinant une indexer Q (calculée pour la requête) et une indexer K (une par entrée), puis garde les 512 meilleures ;
• l'attention principale : la requête (main Q) lit les entrées sélectionnées et le KV SWA local de la couche.

CSA2 simplifie aussi deux choses par rapport à CSA :

1. Dans CSA, avec un ratio m, chaque entrée était fabriquée à partir de 2m entrées d'origine, avec chevauchement entre entrées voisines et un encodage de position absolue. CSA2 supprime le chevauchement et l'encodage absolu.
2. CSA calculait l'indexer K par un chemin de compression séparé, depuis les états cachés. CSA2 obtient l'indexer K par une simple projection du main KV.

Les deux changements simplifient l'implémentation et accélèrent l'entraînement.

Chaque couche CSA2 reçoit, de façon statique (fixée dans l'architecture), l'un des trois modes. Dans les trois cas, la couche calcule sa propre requête (main Q) et son propre KV SWA, et produit une nouvelle sortie d'attention. Les modes diffèrent par la façon dont ils obtiennent trois choses : le main KV, l'indexer K et les indices top-k.

Deux mécanismes distincts sont à l'œuvre, et le papier insiste sur leur découplage :

• Partager le main KV et l'indexer K réduit le stockage du cache.
• Réutiliser les indices top-k évite du calcul d'indexeur.

Le mode Reindex est l'intermédiaire : le stockage est partagé, mais la couche choisit elle-même quelles entrées lire. La sélection peut ainsi évoluer d'une couche à l'autre.

La répartition exacte des modes (section 4.2.1) :

• Encodeur : couches 0 et 1 en SWA pure, puis 18 couches CSA2 avec m = 2, en 3 groupes identiques de 6 couches : 1 Full + 5 Reuse.
• Décodeur : 20 couches CSA2 avec m = 1, en 5 groupes de 4. Premier groupe : 1 Full + 3 Reuse. Quatre groupes suivants : 1 Reindex + 3 Reuse. La couche Full du décodeur calcule son KV global depuis la sortie de l'encodeur (CED).

Le papier annonce 890 octets de KV global par token, sans détailler le calcul. On peut pourtant le reconstituer exactement à partir des hyperparamètres publiés :

• Seules les couches Full stockent un KV global : 3 dans l'encodeur (avec m = 2, soit ½ entrée par token chacune) et 1 dans le décodeur (m = 1, 1 entrée par token). Total : 3 × ½ + 1 = 2,5 entrées par token.
• Une entrée de main KV a 512 canaux. En FP4, cela fait 512 × 4 bits = 256 octets, plus une échelle E4M3 d'1 octet par bloc de 16 canaux (32 octets). Total : 288 octets.
• Une indexer K de dimension 128 au format MXFP4 fait 64 octets, plus 4 échelles d'1 octet (une par bloc de 32). Total : 68 octets.
• 2,5 × (288 + 68) = 2,5 × 356 = 890 octets.

Des travaux antérieurs (Xu et al., 2026) rendaient l'indexeur lui-même parcimonieux : ils notaient d'abord des représentations moyennées par blocs, puis ne regardaient en détail que les meilleurs blocs. Les auteurs remarquent que, dans le décodeur, l'information des indexeurs peu profonds peut naturellement restreindre les candidats des indexeurs plus profonds, sans aucun état supplémentaire.

Le mécanisme, utilisé uniquement dans le décodeur de CED :

Pour une taille de pool fixe, le coût par requête des indexeurs profonds passe de linéaire en la longueur du contexte à constant. Seule la première couche Full continue de parcourir tout le contexte.

DeepSeek-V4 utilisait déjà l'entraînement conscient de la quantification (QAT) pour stocker en FP4 les requêtes et clés de l'indexeur. Cela accélérait l'indexation et réduisait le cache de l'indexeur. Pour ces tenseurs, DeepSeek a choisi le format standard MXFP4 de l'OCP, compatible avec le plus de matériels possible, même si d'autres formats étaient plus précis dans leurs expériences.

V4.1 étend le QAT au main KV. Ici, le FP4 ne sert pas à accélérer des multiplications de matrices, seulement à réduire le stockage. Les valeurs sont décompressées avant l'attention. On peut donc choisir un format plus précis que MXFP4 sans exiger que le matériel sache multiplier nativement dans ce format.

Chaque valeur est un nombre flottant de 4 bits E2M1 : 1 bit de signe, 2 bits d'exposant, 1 bit de mantisse. Il ne peut représenter que 8 amplitudes :

Pour couvrir des valeurs plus grandes ou plus petites, chaque bloc de 16 canaux partage un facteur d'échelle stocké en E4M3 (un flottant 8 bits). C'est le schéma NVFP4, sans sa seconde échelle globale. Pourquoi peut-on s'en passer ? Les auteurs le justifient par un calcul de bornes :

• Le format peut représenter jusqu'à 448 (le max de E4M3) × 6 (le max de E2M1) = 2 688.
• Après normalisation RMS (poids de RMSNorm entraînés ≤ ~1), la norme L2 du vecteur latent de 512 canaux est au plus ≈ √512. La rotation RoPE préserve cette norme, donc aucune valeur ne dépasse ≈ 22,6.
• En pratique, le maximum observé pendant l'entraînement tourne autour de 10.

La marge est énorme. Supprimer l'échelle globale ne coûte donc « aucune perte mesurable de précision » et simplifie la disposition du cache.

• QAT pendant le post-entraînement : le modèle apprend à fonctionner avec un cache FP4.
• Même format pour la partie avec RoPE et la partie sans RoPE du vecteur.
• Quantification après RoPE : quantifier avant n'apportait qu'un gain marginal de précision et aurait ajouté du travail à chaque pas de decode.
• Le KV SWA reste en FP8, car il est plus sensible à la quantification.

Par rapport au main KV en FP8 de V4, ce format divise presque par deux l'empreinte, en HBM comme sur SSD. Une entrée de 512 canaux passe de 512 octets à 288 octets.

Dans le déploiement de V4, un cache persistant sur SSD, avec une politique d'éviction LRU (on jette ce qui a servi le moins récemment), gère séparément deux types de KV :

• le KV global, stocké en entier : un hit permet de réutiliser tout le préfixe ;
• le KV SWA, stocké à deux endroits précis : la fin du prompt et la fin de la réponse. Cela permet de régénérer une réponse ou de continuer une conversation à partir de ce point.

Le cache était dimensionné pour que les deux types restent résidents plus de 72 heures en charge typique. Problème : bien qu'on ne garde que n_win entrées SWA à ces positions, ce KV SWA non compressé occupait près de la moitié de la capacité du cache persistant, surtout dans les conversations à tours courts.

Le rapport de V4 proposait déjà un « Zero SWA Caching » : ne pas stocker le KV SWA et le recalculer s'il manque. Mais la reconstruction exacte exige une passe complète sur L × n_win tokens, un coût jugé prohibitif en production.

Les dépendances SWA s'accumulent de couche en couche (revoir le cône du chapitre 4). Le rejeu borné accepte donc des états approximatifs : il ne rejoue que les n_win derniers tokens et tronque l'attention SWA au segment rejoué. Pour un rejeu commençant à la position s, une requête en position i ne regarde que les clés SWA dans l'intervalle :

La réduction du cache persistant par 8 résulte de deux facteurs qui se multiplient :

Dans un Transformer classique, un seul « flux résiduel » traverse les couches : chaque bloc lit ce flux, calcule, et ajoute son résultat. mHC (manifold-constrained Hyper-Connections, Xie et al., 2026), introduit dans V4, maintient n flux résiduels en parallèle (n = 4 dans V4.1). Pour chaque token, ces flux forment une matrice X_l ∈ ℝ^n×d, mise à jour ainsi :

Idéalement, la transition entre deux blocs serait une seule opération : lire (n + 1)d valeurs (les flux + la sortie du bloc précédent) et en écrire (n + 1)d. Cela donne une borne inférieure de (2n + 2)d de trafic mémoire. V4 utilisait en pratique trois noyaux successifs, à cause des dépendances de données :

Single-Pass mHC décale les coefficients de mélange d'entrée d'un bloc. Chaque bloc utilise les coefficients A produits par le bloc précédent :

En pré-entraînement, DeepSeek garde l'implémentation multi-noyaux : le décalage ne change que les coefficients appliqués par chaque bloc. En déploiement, un noyau fusionné unique, Mega-mHC, fait la mise à jour du résiduel, le mélange d'entrée, la prédiction des coefficients, la pré-normalisation et la conversion FP8. Le résiduel est lu une fois et écrit une fois : on atteint la borne idéale et on divise par deux le trafic mémoire des activations par rapport à l'implémentation d'origine.

Engram (Cheng et al., 2026) est un module de mémoire conditionnelle déjà publié par DeepSeek. L'idée : beaucoup de connaissances sont liées à des suites de tokens précises (« Tour Eiffel », « import numpy as »…). Au lieu de les faire « recalculer » par les couches, on les range dans d'énormes tables d'embeddings, adressées par un hachage des N-grammes qui précèdent le token courant. Pour chaque token, on lit quelques lignes de table : c'est un accès mémoire, pas un calcul lourd.

V4.1 reprend la conception d'origine : compression du vocabulaire (tokenizer compression), hachage multi-têtes, porte (gating) dépendant du contexte, intégration multi-branches. Il y apporte deux modifications :

1. la courte convolution causale est retirée : ses gains ne justifiaient pas la complexité ajoutée dans le moteur d'inférence ;
2. les tables sont optimisées par une mise à jour à momentum suivie d'un équilibrage de Sinkhorn (chapitre 13).

Point crucial pour l'inférence : l'adressage est déterministe. Les lignes à lire ne dépendent que des tokens d'entrée, pas des calculs du réseau. On peut donc les précharger depuis la mémoire de l'hôte par des transferts RDMA en arrière-plan, avant même d'en avoir besoin. Pour le premier module (couche 1), ce préchargement se fait pendant le calcul du premier bloc Transformer. Ainsi, ces 196 Md de paramètres n'occupent pas la précieuse HBM.

À l'entraînement, le même principe permet de lancer le préchargement pour tout le lot local avant que chaque étage du pipeline ne commence. Les tables sont partitionnées par lignes entre des groupes de processus dédiés. Pendant les rollouts de RL, en revanche, elles restent en mémoire GPU pour soulager la mémoire de l'hôte.

Un petit modèle rapide (le drafter) propose plusieurs tokens d'avance. Le grand modèle les vérifie tous en une seule passe, comme un mini-prefill. On garde le plus long préfixe accepté, plus un token que le grand modèle produit lui-même au passage. Si le brouillon est bon, on avance de plusieurs tokens pour le prix d'un pas de decode.

• Le drafter : 3 blocs Transformer avec une fenêtre d'attention glissante de 128 tokens.
• Brouillon semi-autorégressif : une seule passe dans ces blocs calcule les logits de base pour 5 positions de brouillon en parallèle. Une tête de Markov légère modélise ensuite les dépendances entre ces tokens.
• Une tête de confiance prédit, pour chaque position, la probabilité conditionnelle d'acceptation. On en déduit la probabilité de « survie » de chaque préfixe.
• L'ordonnanceur combine ces estimations avec des courbes de débit mesurées sur le moteur. Il choisit dynamiquement, pour chaque requête, combien de tokens vérifier, afin de maximiser le débit total attendu sous la charge actuelle.

Contrairement au module MTP de DeepSeek-V3, entraîné avec le backbone pendant tout le pré-entraînement, DSpark arrive dans une étape dédiée après le pré-entraînement. Seul DSpark est entraîné, le backbone reste gelé. Pendant le post-entraînement, DSpark continue d'être entraîné avec le backbone, mais sans propager de gradient de son objectif vers le backbone. Il reste ainsi aligné sur la politique qui évolue. Il accélère alors à la fois le service en ligne et la génération des rollouts pour le RL et la distillation (OPD).

L'encodeur visuel suit l'architecture Vision Transformer avec plusieurs modifications, toutes pensées pour ressembler davantage à un LLM :

• 2D-RoPE à la place des embeddings de position absolus, pour accepter des résolutions arbitraires ;
• la convolution d'embedding des patchs est remplacée par une projection linéaire, compatible avec l'optimiseur Muon ;
• RMSNorm et SwiGLU, comme dans le backbone ;
• 32 couches, dimension 1 024, 16 têtes. Les résolutions sont supportées jusqu'à environ 1 344 × 1 344 pixels.

Son entraînement se fait en deux étapes, avant l'intégration au backbone :

Pendant le pré-entraînement du modèle complet, l'encodeur visuel reste gelé jusqu'à la phase de décroissance du taux d'apprentissage. Seuls sa normalisation finale et le projecteur restent entraînables. Il est ensuite dégelé et optimisé avec le LLM, avec un taux d'apprentissage plus faible.

DeepSeek équilibre la charge des experts MoE sans perte auxiliaire. Chaque expert a un biais de correction ajouté au score de routage : on le baisse si l'expert est surchargé, on le monte s'il est sous-utilisé. Problème : les tokens d'image et de texte n'ont pas les mêmes préférences. Équilibrer la charge totale peut cacher un fort déséquilibre au sein de chaque modalité.

V4.1 maintient donc deux jeux de biais, un pour le texte et un pour les images. Chaque token choisit ses experts avec les biais de sa modalité, mais pondère leurs sorties avec les scores d'origine. Après chaque pas, les deux jeux sont mis à jour indépendamment, avec une vitesse de 0,001.

Muon peut être vu comme une descente de gradient préconditionnée : il « orthogonalise » la mise à jour d'une matrice de poids avant de l'appliquer (itérations de Newton-Schulz). Le Muon standard utilise un préconditionneur pour toute la matrice des requêtes, donc pour toutes les têtes à la fois. Le Muon par tête découpe d'abord cette matrice tête par tête. Chaque tête reçoit ainsi son propre préconditionneur, ce qui gère mieux l'hétérogénéité entre têtes d'attention. DeepSeek observe qu'il surpasse le Muon standard ; GLM 5 et Kimi-K3 ont fait le même constat.

Appliquer Adam aux 196 Md de paramètres d'Engram aurait fait exploser la mémoire. Adam garde deux états par paramètre (moyenne et variance des gradients). DeepSeek utilise à la place une mise à jour à momentum (un seul état, comme Muon) suivie d'un équilibrage de Sinkhorn. Elle surpasse Adam empiriquement.

La procédure suit le même schéma que Muon, en remplaçant l'orthogonalisation par une normalisation alternée des lignes et des colonnes de la mise à jour :

• une ligne correspond à un token ou à un N-gramme (l'identité à mémoriser), une colonne à une dimension cachée ;
• on divise alternativement chaque ligne, puis chaque colonne, par sa norme. Avec un nombre impair d'étapes (K = 11), on finit par une normalisation des lignes ;
• on multiplie par √n pour passer d'une norme L2 unitaire à un RMS unitaire par ligne ;
• les lignes quasi nulles (norme ≤ τ × moyenne) sont masquées pour la stabilité numérique ;
• le taux d'apprentissage est corrigé par γ = 0,18 pour égaler l'amplitude des mises à jour d'Adam (proche du 0,2 utilisé dans Moonlight).

Résultat : les RMS par ligne et par colonne de la mise à jour sont approximativement égalisés à 1.

Dans la phase contrastive de l'encodeur visuel, la perte est calculée sur tout le lot. Il faut donc rassembler (all-gather) les vecteurs texte et image de toutes les machines, ce qui représente beaucoup de communication. Mais le gradient des vecteurs texte ne dépend que des vecteurs image rassemblés, et inversement. Chaque rassemblement peut donc se faire pendant un calcul utile :

Avec CSA2, une couche peut réutiliser le main KV, l'indexer K ou les indices d'une autre couche. Or ces couches peuvent se trouver sur des étages différents du pipeline, donc sur des GPU différents. Trois mécanismes rendent cela transparent :

• Indexeurs fantômes (shadow indexers) : une réplique légère et exécutable sur chaque étage concerné, avec un seul propriétaire logique des paramètres partagés. Le propriétaire gère l'optimisation et les checkpoints. La synchronisation des paramètres et l'agrégation des gradients gardent les répliques cohérentes.
• Extensions de la charge utile du pipeline : les représentations intermédiaires et les informations de routage parcimonieux voyagent avec les communications point à point existantes quand la source et le consommateur sont de part et d'autre d'une frontière d'étage.
• Gestion des états partagés par micro-lot : on suit la durée de vie de chaque état partagé à travers forward, recalcul des activations et backward. Chacun est libéré dès que son dernier consommateur a fini.

Les deux pipelines sont fusionnés : quand un échantillon existe en version texte et multimodale, la version multimodale remplace l'autre. Le corpus final a un ratio de 7:1 entre tokens texte seul et tokens multimodaux. L'algorithme de remplissage des séquences (best-fit packing) atteint un taux de padding d'au plus 10⁻⁴.

Le lot est fixé à 100,6 millions de tokens pendant tout l'entraînement. L'attention parcimonieuse est entraînée dès le départ à une longueur de séquence de 64K, sans phase d'échauffement en attention dense. La séquence passe à 1M à 34T tokens. Le papier précise : « sans aucune instabilité ».

Le tableau 1 compare trois modèles de base évalués dans le même cadre interne : V4-Flash-Base (284 Md, 13 Md activés), V4-Pro-Base (1,6 T, 49 Md activés) et V4.1-Flash-Base (552 Md, 8 / 16 Md activés). Les écarts de 0,3 point ou moins sont considérés comme équivalents.

Pour mesurer les capacités en conditions réelles de R&D, l'équipe mesure aussi la perplexité sur des corpus internes jamais vus : documentation interne, dépôts de code propriétaires, documents académiques. La métrique est le nombre de bits par octet (BPB, bits-per-byte) : plus il est bas, mieux le modèle « comprime », donc prédit, le texte.

La recette est standard : SFT (fine-tuning supervisé), puis RL (apprentissage par renforcement), puis OPD (distillation on-policy), sans modification par rapport à V4. L'effort porte sur trois étapes :

1. synthétiser des tâches variées et vérifiables, avec leurs solutions de référence et leurs signaux de récompense ;
2. construire procéduralement des environnements d'agents interactifs où collecter et évaluer des trajectoires à bas coût ;
3. filtrer, dédupliquer et calibrer la difficulté.

Chaque tâche est un triplet : (problème, environnement, système de vérification). Sa qualité se juge sur deux axes : la difficulté (non triviale) et la correction (aucun défaut critique dans les trois composantes). Le modèle commence à savoir construire ses propres tâches d'entraînement. DeepSeek l'entraîne donc à en construire de meilleures, avec la difficulté et la correction comme récompenses. Chaque tâche est surveillée toute sa vie : chaque nouvelle utilisation en RL fournit des trajectoires qui permettent de la réauditer.

Le RL asynchrone à grande échelle est poussé dans deux directions : le calcul d'entraînement et le nombre de scaffolds (les « harnais » d'agents : Claude Code, OpenCode, Pi, DeepSeek Harness…). La performance continue de monter avec les pas de RL, que ce soit dans un seul scaffold, entre versions d'un même scaffold ou entre scaffolds hétérogènes.

Deux idées d'ingénierie accompagnent ce passage à l'échelle :

• Séparer le scaffold du contrôle : un sandbox d'agent fait tourner le scaffold et ses outils. Un conteneur worker orchestre le rollout de façon indépendante du scaffold et normalise les interactions dans un format de trajectoire commun. Les deux tournent hors du pool GPU préemptible. Si l'entraîneur est préempté, le rollout peut être suspendu et déchargé avec tout son état.
• Fusionner des modèles pour relancer : on fusionne des checkpoints issus d'entraînements sur différents scaffolds ou configurations pour réinitialiser l'entraînement suivant. On combine ainsi des progrès obtenus par des chemins d'optimisation différents, et on gagne en performance et en efficacité en tokens.

Pour entraîner des agents, il faut des environnements où ils exécutent réellement du code. DSec (DeepSeek Elastic Compute) est la plateforme de sandboxes de DeepSeek. Pour V4.1, la demande est montée à des millions d'instances simultanées.

En RL pour LLM, quelques réponses très longues retardent toujours tout le lot : c'est le problème de la longue traîne. La génération est donc devenue asynchrone pour presque toutes les tâches de RL et d'OPD. Rollout et entraînement partagent les mêmes GPU, en temps partagé. Chaque tâche fixe un maximum d'échantillons « en vol ». Reste à décider quand relancer de nouveaux prompts :

Pendant le RL, on ajoute en tête du prompt système l'instruction suivante :

Pour chaque prompt d'entraînement x, on échantillonne plusieurs réponses à chaque niveau d'effort b. Les réponses de même (x, b) forment un sous-groupe, dans lequel les récompenses sont centrées pour calculer les avantages relatifs, façon GRPO. On ne compare donc jamais directement deux niveaux d'effort entre eux. Le comportement propre à chaque niveau vient d'une pénalité de longueur qui dépend de b :

L'API publique, lancée en septembre 2026, propose trois paliers qui correspondent directement à ce réglage. On change de point de fonctionnement sans toucher aux poids ni aux paramètres de décodage :

L'entraînement n'utilise qu'un nombre fini de niveaux, mais les valeurs intermédiaires donnent des comportements interpolés.

Les gains sont concentrés au début. La plage 60–80 récupère déjà l'essentiel de la précision du réglage maximal, pour moins de la moitié de son budget en tokens. La dernière marche vers 100 allonge les trajectoires d'agent de 1,6 à 1,8× pour des gains marginaux. Le palier max est donc à réserver aux tâches les plus difficiles.

L'annexe détaille les huit benchmarks de raisonnement. La longueur croît de façon régulière, de 2,0 à 3,1× entre les efforts 25 et 100 : de 4,6k à 11,4k tokens sur AIME 2026, de 29,1k à 86,1k sur MathArena Apex 2025. La précision ne baisse sur aucun benchmark : +40,3 points sur MathArena Apex 2025 (25,3 → 65,6 %), 100 % sur AIME 2026. Dans les scaffolds de code, en revanche, la longueur augmente toujours avec l'effort, mais le Pass@1 ne suit que de loin, avec des plateaux et des creux.

• Raisonnement : GPQA Diamond, Humanity's Last Exam (HLE), Codeforces (benchmark interne), MathArena Apex.
• Agents de code : Terminal-Bench 2.1 / 3.0 / 4.0, DeepSWE v1.1, ProgramBench, NL2Repo-Bench. Évalués avec le mode Minimal de DeepSeek Harness, 1M tokens de contexte, température 1,0, top-p 0,95 (mini-SWE pour DeepSWE).
• Cybersécurité : SEC-Bench Pro, CyberGym, ExploitGym.
• Agents généralistes : AutomationBench, Agents' Last Exam.
• Agents visuels : Chartography, BabyVision, ZeroBench (avec le harnais Claude Code, contexte de 512k).

Pour limiter la triche dans les évaluations de code, l'accès à internet est coupé, les historiques Git sont supprimés et les caches de compilation ou de paquets sont purgés. Des comportements de recherche d'exploit ont pourtant été observés, par exemple la décompilation de paquets Ubuntu pour y trouver des vulnérabilités dans CyberGym. Les auteurs appellent la communauté à en tenir compte dans les prochains benchmarks.

Un modèle est rarement déployé dans un seul harnais. Les auteurs gardent le même checkpoint, la même configuration de décodage et les mêmes tâches, et ne changent que le scaffold (prompt système, outils, logique des tours) : huit configurations issues de six familles.

Les capacités se transfèrent bien entre familles de scaffolds, ce qui est cohérent avec la diversité des environnements et formats d'outils des données synthétisées. Sur Claude Code, quatre versions testées donnent en moyenne 68,9 % sur DeepSWE et 87,8 % sur Terminal-Bench 2.1 (annexe, tableau 5).

Expérience préliminaire : le mode Agent Team de DeepSeek Harness. Un agent chef crée de manière asynchrone des coéquipiers nommés et persistants (spawn_teammate). Chacun démarre soit « à neuf », soit avec une copie de l'historique du chef (fork). Tous partagent le même checkout du dépôt. Ils communiquent par une boîte aux lettres durable (send_message). Le chef surveille l'état de l'équipe (list_agents, wait_agent), peut interrompre un coéquipier (interrupt_agent) et tient un tableau de tâches partagé. À la fin, il relit, teste et livre.

L'entraînement RL combine trois termes : la performance sur la tâche, un bonus de collaboration (déléguer, communiquer) et une pénalité de latence dérivée. Cette latence est la longueur du chemin critique d'un graphe acyclique des événements : les coûts en tokens y sont convertis à des vitesses de prefill/decode fixes, plus le temps mesuré des outils. On encourage ainsi le parallélisme utile et on pénalise l'attente inutile.

Les prochaines priorités annoncées :

• étendre les tests de stress, surtout la recherche parcimonieuse sur très longs contextes et la reconstruction SWA aux frontières de reprise du cache ;
• surveiller les charges réelles pour caractériser les modes de défaillance ;
• continuer de faire évoluer les protocoles d'évaluation, car les benchmarks saturent. Des scores proches ne signifient pas des capacités égales aux meilleurs systèmes fermés sur les problèmes les plus durs. Le papier cite Fable-5 et GPT-6 Astra comme références de pointe ;
• faire croître ensemble données, capacité du modèle et RL, et co-concevoir le modèle avec son harnais d'agent (model–harness co-design).

L'ambition affichée : baisser les coûts et augmenter les capacités en même temps, pour rendre des agents très capables plus accessibles et plus faciles à déployer.

• Le rapport technique complet : copie locale (PDF, 51 pages) · sur Hugging Face
• Les checkpoints du modèle : huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash
• Les travaux sur lesquels il s'appuie, cités dans le rapport : YoCo (Sun et al., 2024), mHC (Xie et al., 2026), Engram (Cheng et al., 2026), DSpark (Cheng et al., 2026), DeepSeek-V4 (DeepSeek-AI, 2026).