3 · DSpark¶
DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation, Cheng, Yu, Shao et al. (DeepSeek), arXiv 2607.05147, déposé le 6 juillet 2026.
L'article s'ouvre sur le dilemme du chapitre précédent, formulé par ses auteurs ainsi : les drafters parallèles proposent efficacement de longues séquences en une passe, mais souffrent d'une « décroissance rapide de l'acceptation, faute de dépendances entre jetons ».
DSpark répond sur deux plans distincts, qu'il faut bien séparer :
- La qualité du brouillon — un drafter semi-autorégressif ;
- L'efficacité système — une vérification à longueur variable par requête, pilotée par une prédiction de confiance.
Le second point est le plus original, et le moins présent dans la littérature antérieure.
3.1 Le drafter semi-autorégressif¶
Le tronc parallèle¶
DSpark part d'un modèle DFlash modifié : cinq couches de transformeur qui produisent en une seule passe avant les logits des \(\gamma\) positions du bloc, avec attention bidirectionnelle entre positions, et conditionnement sur le modèle cible par injection KV (états cachés du modèle cible concaténés dans le cache du drafter).
C'est la partie rapide, et c'est aussi la partie qui ignore les dépendances internes au bloc.
La tête de Markov¶
L'ajout central de DSpark est une tête séquentielle minuscule intercalée après le tronc, qui réintroduit la dépendance manquante.
Elle applique un biais dépendant du jeton précédent, via une matrice de transition de rang faible \(B = W_1 W_2\) (rang \(r = 256\) dans l'article). Au pas \(k\), le jeton échantillonné \(x_{k-1}\) sélectionne une ligne, qui devient un biais ajouté aux logits de la position \(k\) :
Deux propriétés font tout l'intérêt du procédé :
- le surcoût mesuré est de 0,2 à 1,3 % de latence par rapport à DFlash seul, parce qu'on ne repasse pas dans le tronc — on ne fait qu'ajouter un vecteur ;
- le softmax reste exact, donc la règle d'acceptation-rejet du chapitre 1 reste valide, et la sortie reste sans perte.
Pourquoi « semi-autorégressif »
Le bloc est produit en parallèle (comme DFlash), mais chaque position voit le jeton effectivement tiré à la position précédente (comme EAGLE). D'où le « semi » : la dépendance est d'ordre 1, pas d'ordre complet.
Une variante à tête récurrente (RNN), qui accumule tout le préfixe au lieu du seul jeton précédent, est évaluée dans l'article : elle n'apporte de gain marginal qu'aux blocs longs.
Entraînement¶
Les trois composants — tronc, tête de Markov, tête de confiance — sont entraînés sur les réponses du modèle cible lui-même, afin d'en imiter la distribution. Le jeu utilisé est Open-PerfectBlend, 1,3 million d'échantillons répartis en 17,6 % de conversation, 39,4 % de mathématiques, 38,9 % de code.
3.2 La tête de confiance¶
La seconde tête est une simple projection linéaire produisant, pour chaque position \(k\) du bloc, un scalaire \(c_k \in (0,1)\) : la probabilité estimée que le préfixe survive jusqu'à cette position, c'est-à-dire que toutes les positions précédentes aient été acceptées.
La cible d'entraînement est analytique : c'est le taux d'acceptation exact, donné par la distance en variation totale entre brouillon et modèle cible,
Une prédiction de probabilité n'a de valeur que si elle est calibrée — c'est sur ce nombre qu'on va décider de dépenser du calcul. DSpark applique un Sequential Temperature Scaling : une recherche de température position par position, minimisant l'erreur de calibration attendue du produit cumulé \(\prod_{i \le k} c_i\) sur un jeu de validation. L'erreur de calibration résiduelle rapportée est d'environ 1 %.
3.3 La vérification programmée¶
C'est ici que DSpark quitte le terrain habituel.
Toutes les méthodes antérieures fixent une longueur de brouillon \(\gamma\) identique pour tout le lot. Or les requêtes ne se ressemblent pas : la suite d'un fichier de code répétitif est presque certaine, la suite d'un raisonnement mathématique difficile ne l'est pas. Vérifier douze jetons pour les deux, c'est gaspiller sur la seconde.
L'algorithme d'ordonnancement de DSpark procède ainsi, à chaque pas :
- pour chaque requête \(r\), calculer les probabilités de survie de chaque préfixe, \(a_{r,j} = \prod_{i \le j} c_{r,i}\) ;
- trier globalement, toutes requêtes confondues, les extensions de préfixe candidates \((r, j)\) par \(a_{r,j}\) décroissant ;
- les admettre gloutonnement tant que cela augmente le débit utile
où \(B\) est le nombre total de jetons à vérifier dans le lot, \(\tau^{*}\) l'espérance de jetons acceptés, et \(\mathrm{SPS}(B)\) la courbe de débit mesurée du moteur — profilée une fois puis stockée en table de correspondance.
| Symbole | Signification |
|---|---|
| \(c_{r,i}\) | Confiance prédite, requête \(r\), position \(i\) |
| \(a_{r,j}\) | Probabilité que le préfixe de longueur \(j\) survive |
| \(B\) | Taille du lot de vérification, en jetons |
| \(\mathrm{SPS}(B)\) | Pas par seconde du moteur pour un lot de \(B\) jetons |
| \(\Theta\) | Débit utile en jetons acceptés par seconde |
L'idée en une phrase
Un jeton spéculé n'est pas gratuit : il occupe une place dans le lot de vérification. DSpark n'accorde cette place qu'aux jetons dont il estime, de manière calibrée, qu'ils la rentabiliseront — et le budget se resserre tout seul quand le serveur se remplit.
En production, une contrainte de causalité s'ajoute : le planificateur ne peut pas attendre la confiance du pas courant sans créer une bulle dans le pipeline GPU. DSpark utilise donc les estimations de deux pas plus tôt, ce qui permet un ordonnancement asynchrone à surcoût nul.
3.4 Les résultats publiés¶
Longueur acceptée (modèles ouverts)¶
Sur Qwen3 en 4B, 8B et 14B, à conditions de brouillon comparables :
| Comparaison | Qwen3-4B | Qwen3-8B | Qwen3-14B |
|---|---|---|---|
| DSpark vs EAGLE-3 | +30,9 % | +26,7 % | +30,0 % |
| DSpark vs DFlash | +16,3 % | +18,4 % | +18,3 % |
Bancs d'essai : GSM8K, MATH, AIME25 (mathématiques), MBPP, HumanEval, Live-CodeBench (code), MT-Bench, Alpaca, Arena-Hard (conversation). Gemma4-12B est également évalué.
En production¶
Sur le système de service de DeepSeek-V4, à débit total équivalent, la vitesse perçue par utilisateur augmente de :
- 60 à 85 % sur DeepSeek-V4-Flash ;
- 57 à 78 % sur DeepSeek-V4-Pro ;
par rapport au baseline MTP-1, tout en tenant les engagements de service (120 jetons/s sur Flash, 50 sur Pro).
L'intégration SGLang rapporte 383,7 jetons/s à lot de taille 1 sur DeepSeek-V4-Pro, pour une longueur acceptée d'environ 5 jetons, et une supériorité sur MTP à toutes les tailles de lot testées de 1 à 256 (GPU H200).
La preuve que l'ordonnancement sert à quelque chose¶
Deux mesures valent mieux qu'un discours :
- selon la prévisibilité de la charge, le budget de vérification moyen s'établit à 5,24 / 3,78 / 2,91 jetons sur trois types de trafic — la différenciation se fait bien par requête, pas par moyenne de lot ;
- il passe de 4–6 jetons à faible charge à environ 2 jetons quand la concurrence sature la machine.
Ablations¶
- Un DSpark à 2 couches dépasse un DFlash à 5 couches : la dépendance d'ordre 1 vaut plus que de la profondeur.
- L'écart avec DFlash se creuse quand le bloc s'allonge : à \(\gamma = 15\), +30 % en mathématiques, +26 % en code, +22 % en conversation par rapport à \(\gamma = 7\). C'est cohérent avec le diagnostic initial — c'est bien la décroissance d'acceptation le long du bloc qui est corrigée.
- Retirer la tête de Markov ou la tête de confiance dégrade le résultat : les deux contributions sont indépendantes.
3.5 Ce qui est publié¶
Les points de contrôle DeepSeek-V4-Pro-DSpark et DeepSeek-V4-Flash-DSpark sont diffusés sous licence MIT, donc utilisables commercialement. Le dépôt d'entraînement DeepSpec couvre également EAGLE-3 et DFlash, ce qui rend les comparaisons de l'article reproductibles dans leur principe.
Chapitre précédent : Avant DSpark · Chapitre suivant : Comparaison et limites