Single-Pass mHC, Engram et DSpark¶
Trois extensions complètent l'architecture. Aucune n'est propre à V4.1-Flash : toutes viennent de travaux antérieurs de DeepSeek, reprises ici avec des modifications. Elles n'ont rien à voir avec le cache clé-valeur — elles visent respectivement la bande passante mémoire, la mémorisation et la vitesse de décodage.
Single-Pass mHC¶
Le point de départ¶
DeepSeek-V4 avait introduit mHC (multi-stream Hyper-Connections) : au lieu d'un seul flux résiduel entre blocs Transformer, on en maintient \(n\). Pour chaque jeton, ces flux forment une matrice \(X_l \in \mathbb{R}^{n \times d}\) où \(l\) est l'indice du bloc et \(d\) la dimension cachée. Dans V4.1-Flash, \(n = 4\).
La mise à jour s'écrit :
| Symbole | Dimensions | Rôle |
|---|---|---|
| \(A_l\) | \(1 \times n\) | mélange les \(n\) flux en une entrée pour le bloc |
| \(B_l\) | \(n \times n\) | recombine les flux entre eux |
| \(C_l\) | \(n \times 1\) | redistribue la sortie du bloc vers les flux |
| \(\mathcal{H}\) | — | le prédicteur de coefficients (normalisation + projection) |
| \(\mathcal{F}_l\) | — | le bloc Transformer lui-même |
Les coefficients sont donc prédits à partir des flux eux-mêmes, jeton par jeton.
Le problème : le trafic mémoire¶
La transformation idéale entre deux blocs demande \((n+1)d\) lectures et \((n+1)d\) écritures, soit une borne inférieure de \((2n+2)d\) en trafic d'activations.
L'implémentation de V4 utilise trois noyaux séquentiels, à cause de leurs dépendances de données :
Total : \((4n+4)d\), soit deux fois la borne inférieure.
Deux de ces trois étapes peuvent partager une même traversée du résiduel. La troisième — le mélange d'entrée — ne le peut pas : \(A_l\) n'est disponible qu'après la réduction complète sur la dimension cachée. Il faut donc une seconde lecture de \(X_l\), d'où \((3n+2)d\) au mieux.
La solution : décaler d'un bloc¶
Single-Pass mHC décale les coefficients de mélange d'entrée d'un bloc : chaque bloc consomme les coefficients produits par le précédent.
Le mélange utilise \(A_{l-1}\) au lieu de \(A_l\). La dépendance disparaît : chaque tuile de \(X_l\) peut servir immédiatement au mélange et à la prédiction des coefficients, sans attendre la réduction.
Le noyau fusionné qui en résulte, Mega-mHC, atteint \((2n+2)d\) — la borne idéale — et divise donc par deux le trafic d'activations de l'implémentation d'origine. Il intègre au passage la pré-normalisation et la conversion FP8.
Un détail révélateur
Le pré-entraînement conserve l'implémentation multi-noyau. Seul le déploiement utilise Mega-mHC. Le décalage ne change que les coefficients appliqués par chaque bloc — les deux formulations sont entraînables de façon équivalente, mais une seule est fusionnable efficacement.
DeepSeek indique que le décalage « entraîne une dégradation négligeable des performances ». Aucune mesure n'accompagne cette affirmation.
Engram — la mémoire conditionnelle¶
L'idée¶
Engram, introduit par DeepSeek dans un travail antérieur, sépare la mémorisation du calcul. Plutôt que de forcer les paramètres du réseau à stocker des faits, on ajoute d'énormes tables de correspondance consultées par recherche — donc à coût de calcul quasi nul.
L'adressage se fait par hachage de n-grammes : la séquence de jetons courante détermine directement quelles lignes des tables sont lues.
La configuration dans V4.1-Flash¶
| Paramètre | Valeur |
|---|---|
| Paramètres totaux | 196 G |
| Modules | 2, aux couches 1 et 14 |
| Ordres de n-grammes | 2, 3 et 4 |
| Têtes de hachage | 8 par ordre |
| Dimension totale par ordre | 2 048 (soit 256 par tête) |
| Entrées par table | ≈ 16 M, tailles choisies comme des nombres premiers distincts |
| Précision | FP8, tables et projections |
Le recalcul donne :
à 0,3 % de l'annonce.
Deux modifications par rapport à l'Engram d'origine¶
- la convolution causale courte est supprimée — ses gains ne justifiaient pas la complexité ajoutée dans la pile d'inférence ;
- les tables sont optimisées par mise à jour à momentum suivie d'un équilibrage de Sinkhorn plutôt que par Adam — voir Optimiseurs.
À l'inférence¶
L'adressage étant déterministe — il ne dépend que des jetons d'entrée — les plongements peuvent être préextraits depuis la mémoire hôte par transferts RDMA en arrière-plan. La préextraction du premier module recouvre le calcul du premier bloc Transformer.
196 G de paramètres qui doivent bien être quelque part
Engram n'est pas gratuit en mémoire : 196 G de paramètres en FP8, ce sont environ 196 Go à héberger, au minimum en mémoire hôte. Ils sont exclus du compte des « 552 G du squelette » et des « 16 G activés », ce qui est défendable — ce ne sont ni des matrices multipliées ni un chemin de calcul — mais fausse la comparaison si on l'oublie.
DSpark — le décodage spéculatif¶
Le principe du décodage spéculatif¶
Générer un jeton coûte une passe complète du modèle. L'idée du décodage spéculatif est de faire produire plusieurs jetons candidats par un modèle brouillon rapide, puis de les vérifier tous en une seule passe du grand modèle. Si les candidats sont acceptés, on a gagné plusieurs jetons pour le prix d'un.
Pour aller plus loin
Cette bibliothèque contient une recherche dédiée à ce mécanisme : Le décodage spéculatif, de 2018 à DSpark, qui retrace son histoire et détaille DSpark en particulier.
Ce que fait DSpark¶
| Composant | Description |
|---|---|
| Brouillonneur | 3 blocs Transformer, fenêtre d'attention de 128 jetons |
| Génération | semi-autorégressive — une seule passe produit les logits de base pour 5 positions en parallèle |
| Tête de Markov | modélise les dépendances entre les jetons du brouillon |
| Tête de confiance | prédit la probabilité d'acceptation conditionnelle par position |
| Ordonnanceur | choisit dynamiquement la longueur de vérification par requête |
L'ordonnanceur combine les probabilités de survie de préfixe estimées par la tête de confiance avec des courbes de débit du moteur mesurées au préalable, pour maximiser le débit système attendu sous la charge courante. C'est un choix d'ingénierie plus que d'architecture : la longueur de spéculation optimale dépend du taux d'occupation du serveur, pas seulement du modèle.
Un entraînement séparé¶
Contrairement au module MTP de DeepSeek-V3, entraîné conjointement avec le squelette dès le pré-entraînement, DSpark est introduit dans une étape dédiée après le pré-entraînement, avec le squelette gelé.
Pendant le post-entraînement, il continue d'être entraîné aux côtés du squelette, mais sans propager de gradients de son objectif vers celui-ci. DSpark reste ainsi aligné sur la politique en évolution, ce qui lui permet d'accélérer non seulement le service en ligne mais aussi la génération de trajectoires pour l'apprentissage par renforcement.
À retenir
Ces trois extensions n'améliorent pas le cache clé-valeur. Elles réduisent le trafic mémoire (mHC), ajoutent de la connaissance à coût de calcul nul (Engram) et accélèrent le décodage (DSpark). Elles expliquent une partie de l'écart entre un modèle de 16 G activés et ses performances mesurées.
Chapitre suivant : La voie visuelle