DSpark : le pari de DeepSeek sur la vitesse qui ne trahit pas la qualité

DeepSeek n'a pas seulement présenté une nouvelle approche du speculative decoding ; avec DeepSpec, il tente de le transformer en un pipeline industriel reproductible. L'article s'appelle DSpark, le sigle est le énième d'une longue série que le laboratoire chinois sort presque chaque trimestre, et la tentation de le parcourir distraitement est forte. Ce serait une erreur, car derrière l'acronyme se cache une question très concrète : jusqu'à quel point l'inference d'un modèle de langage peut-elle vraiment s'accélérer si le modèle qui génère les brouillons de réponse cesse d'être naïf, et si le système qui les contrôle apprend à ne pas perdre de temps sur ceux destinés à la corbeille.

Pour comprendre pourquoi la question est pertinente, il convient de partir d'un fait inconfortable que quiconque a utilisé un chatbot a expérimenté sans le savoir. Chaque mot qu'un modèle de langage produit naît d'une passe entière de calcul à travers des milliards de paramètres, un par un, en séquence. C'est un peu comme si un romancier devait relire l'intégralité du manuscrit depuis le début avant d'écrire chaque mot suivant. Cela fonctionne, mais c'est lent, et dans un système qui doit répondre à des centaines de requêtes simultanément, cette lenteur se traduit par des files d'attente, des coûts électriques et des utilisateurs fixant un curseur clignotant.

Le goulot d'étranglement de l'inference

Le speculative decoding est l'idée, désormais plus tout à fait nouvelle, qui a tenté de briser ce schéma : au lieu de ne faire travailler que le modèle grand et coûteux, on lui adjoint un petit modèle rapide, appelé draft model, qui risque une séquence de tokens futurs. Le grand modèle, celui que nous appellerons target, les contrôle tous ensemble en une seule passe, acceptant le préfixe le plus long compatible avec ce qu'il aurait lui-même généré et écartant le reste. Si le draft devine juste, le target encaisse plus de mots pour chaque passe de calcul, et la génération s'accélère sans perdre un gramme de qualité, car la règle d'acceptation est construite pour ne pas altérer la distribution statistique du grand modèle.

Le problème est que la conception du draft model détermine un compromis inconfortable. Les premiers drafts étaient autorégressifs, c'est-à-dire qu'ils généraient un token à la fois en conditionnant chacun sur les précédents : efficaces pour maintenir une cohérence interne, mais avec un coût de génération qui croît linéairement avec la taille du bloc de mots proposés, ce qui les oblige à rester petits et à proposer des blocs courts. Les architectures parallèles, je pense à des travaux comme DFlash, ont résolu le problème inverse : elles produisent tous les mots du bloc en une seule passe, rendant le temps de génération presque indépendant de la longueur du bloc, ce qui permet d'oser des blocs beaucoup plus longs. Mais la parallélisation a un prix, car chaque position est prédite isolément des autres, sans savoir ce qu'ont "décidé" les positions voisines.

C'est le même paradoxe que le cadavre exquis surréaliste, ce jeu cher à André Breton où plusieurs personnes écrivent une phrase à tour de rôle en ne voyant que le dernier mot laissé par le compagnon précédent : le résultat peut être surprenant, mais s'effondre souvent en un amas de fragments sensés individuellement et incohérents ensemble. Lorsqu'un draft parallèle doit choisir entre "bien sûr" et "pas de problème" comme réponse à une salutation, il peut tranquillement produire un mélange illisible des deux, car aucun des deux choix ne connaît l'existence de l'autre. Les auteurs de l'article appellent ce phénomène collision multimodale, et c'est la raison pour laquelle les drafts parallèles, bien que partant fort, perdent rapidement de la vitesse à mesure que le bloc s'allonge.

Le second goulot d'étranglement, moins raconté mais tout aussi concret, concerne la vérification. Même en admettant que le draft produise un bloc très long de mots plausibles, les contrôler tous coûte du calcul au modèle target, et ce calcul est la ressource la plus rare dans un système de production avec des centaines de requêtes en attente. Vérifier un token qui a une très haute probabilité d'être rejeté revient à envoyer un candidat manifestement inapte à un entretien qui pourrait être attribué à quelqu'un ayant plus de chances : ce n'est pas gratuit, cela soustrait de la capacité à ceux qui en tireraient un bénéfice réel. L'article note, données à l'appui, que l'acceptation varie énormément selon le domaine : un problème de mathématiques ou un fragment de code ont des structures rigides que le draft devine mieux, une discussion ouverte est beaucoup plus imprévisible. Une longueur de vérification fixe, identique pour chaque requête, ignore cette différence et gaspille systématiquement des ressources.

Un drafter qui apprend à douter de lui-même

La première action de DSpark est architecturale, et le nom donné à l'approche, génération semi-autorégressive, décrit bien l'idée de médiation. Le gros du travail de brouillon reste parallèle : un socle dur, ce que l'article appelle backbone, produit en une seule passe les prévisions de base pour toutes les positions du bloc, conservant l'avantage de vitesse des drafts parallèles. Sur ce socle, cependant, est greffé un module séquentiel très léger, dont la seule tâche est de corriger les prévisions de base en introduisant une dépendance entre un token et le suivant, sans refaire tout le travail lourd.

L'image qui rend le mieux l'idée vient du jazz le plus libre, celui qui circulait dans l'orbite de Sun Ra : toute une section rythmique peut jouer simultanément en lisant la même partition de base, mais c'est le soliste qui, en écoutant en temps réel ce que les autres viennent de jouer, ajuste la phrase suivante pour qu'elle sonne cohérente avec le reste. Le backbone parallèle est la partition commune, le module séquentiel est l'oreille du soliste. Dans l'article, ce module existe en deux variantes : une version minimale, qui ne regarde que le mot immédiatement précédent et utilise une petite table de bas rang pour suggérer quels mots sont cohérents avec lui, et une version plus riche, avec mémoire récurrente, qui accumule l'information sur l'ensemble du préfixe généré jusqu'alors dans le bloc. La première est plus économique, la seconde capture des dépendances plus longues, et les deux conceptions offrent un compromis différent entre coût de calcul et qualité.

Le résultat le plus contre-intuitif de l'article concerne précisément la comparaison entre cette architecture et les drafts purement autorégressifs comme Eagle3. On s'attendrait à ce que générer mot par mot, avec une pleine dépendance séquentielle, produise toujours de meilleurs résultats qu'une approche en partie parallèle. Les auteurs montrent qu'il n'en est rien, en analysant l'acceptation position par position : au tout premier mot du bloc, un draft parallèle peut s'offrir une architecture beaucoup plus profonde précisément parce que son coût ne dépend pas de la longueur du bloc, et cet avantage de capacité initiale se traduit par une marge nette, par exemple presque vingt points de pourcentage d'acceptation en plus sur des tâches de conversation ouverte par rapport à un drafter autorégressif contraint de rester léger. Comme le premier mot du bloc est celui qui a le plus de levier, un refus de sa part invalide tout le reste, cet avantage initial se répercute sur toute la chaîne. Le prix se paie plus loin dans le bloc, où le draft purement parallèle perd rapidement de la vitesse tandis que l'autorégressif tient mieux la barre. DSpark est conçu exactement pour additionner les deux avantages, la puissance initiale du parallèle et la tenue de fin du séquentiel, sans hériter de leurs faiblesses respectives. Image tirée de l'article

Vérifier seulement ce qui compte

La seconde moitié de la proposition est peut-être la plus originale, et concerne non pas la façon dont on génère le draft mais la façon dont on le vérifie. DSpark adjoint au backbone de génération une tête de confiance, un petit module qui, pour chaque position du bloc, estime la probabilité que ce token survive au contrôle du modèle target, conditionnée par le fait que tous les mots précédents dans le même bloc ont été acceptés. C'est une estimation de risque, calculée avant même que le target n'ouvre la bouche.

Ici, cependant, émerge un problème typique de tout système qui s'appuie sur des estimations de confiance produites par un réseau neuronal : elles ont tendance à être trop sûres d'elles-mêmes, un phénomène bien documenté dans la littérature sur la calibration des modèles. Si le scheduler faisait aveuglément confiance aux scores bruts, il finirait par surestimer systématiquement le nombre de mots qui survivront, faussant les calculs. DSpark introduit donc une phase de calibration a posteriori, appelée mise à l'échelle de température séquentielle, qui corrige ces scores un par un en procédant de gauche à droite dans le bloc, utilisant un petit ensemble de validation pour trouver le bon facteur de correction sans altérer l'ordre de mérite entre les tokens, seulement leur magnitude absolue.

Avec des scores fiables en main, le scheduler proprement dit entre en jeu, celui que l'article baptise Hardware-Aware Prefix Scheduler. L'idée est élégante dans sa simplicité : collecter toutes les requêtes actives à un instant donné, ordonner tous les prolongements de vérification possibles de toutes les requêtes en fonction de la probabilité de survie estimée, et les admettre un par un par ordre décroissant tant que le gain de throughput global continue de croître. Au moment où l'ajout d'un autre token dégrade le throughput attendu, on s'arrête. C'est un mécanisme qui rappelle de près la logique des jeux de société de placement d'ouvriers, ceux où à chaque tour on choisit avec soin où investir une ressource rare et où la décision, une fois prise, ne peut être annulée : ici, la ressource rare est la capacité de calcul du modèle target, et chaque token vérifié en plus sur une requête est une part de cette capacité soustraite à une autre.

Il existe une contrainte théorique délicate que les auteurs abordent avec un soin presque maniaque en appendice : la décision du nombre de tokens à vérifier ne peut dépendre du contenu du token lui-même, sous peine d'introduire un biais de sélection qui rompt la garantie fondamentale du speculative decoding, à savoir que le résultat final soit statistiquement identique à celui qu'aurait produit le seul modèle target. Les auteurs démontrent avec un contre-exemple numérique qu'une recherche complètement rétrospective, qui évalue chaque coupe possible du bloc avant de décider, viole cette propriété de causalité et distord silencieusement la distribution de sortie. La solution adoptée dans le scheduler théorique est de s'arrêter dès que le gain attendu commence à baisser, une sorte d'arrêt anticipé qui empêche de "lorgner" des informations qui ne devraient pas encore être disponibles.

En production, cependant, la théorie se heurte au matériel réel. La courbe de capacité d'un moteur d'inference n'est pas une courbe lisse comme dans les modèles mathématiques, elle est pleine de paliers brusques dictés par des contraintes physiques des GPU, et prétendre recalculer le scheduling à chaque étape de manière synchrone ralentirait l'ensemble du pipeline. DeepSeek a résolu le conflit en rendant le scheduler asynchrone : la capacité de référence est estimée en utilisant les prévisions de confiance de deux étapes auparavant, pas celles instantanées, ce qui introduit un léger retard mais préserve la propriété de causalité requise, car la décision ne dépend jamais de la réalisation du token courant. C'est un compromis d'ingénierie pragmatique plus qu'élégant, mais c'est exactement le genre de détail qui sépare un article académique d'un système qui tourne réellement sur des millions de requêtes par jour.

Les chiffres, mis à l'épreuve

Sur le front des benchmarks offline, DSpark est comparé à Eagle3, représentant de l'école autorégressive, et à DFlash, représentant de l'école parallèle, sur quatre modèles target de tailles différentes : la famille Qwen3 dans les versions à 4, 8 et 14 milliards de paramètres, plus Gemma4 à 12 milliards. Sur les quatre, en mesurant combien de mots sont acceptés en moyenne à chaque cycle de vérification, DSpark dépasse systématiquement les deux concurrents. La marge par rapport à Eagle3 oscille entre 27 % et 31 % selon la taille du modèle, celle par rapport à DFlash reste plus contenue mais néanmoins robuste, entre 16 % et 18 %. L'avantage se confirme transversalement sur les mathématiques, la génération de code et la conversation, bien qu'avec des intensités différentes : comme on pouvait s'y attendre, les tâches plus structurées comme le code tolèrent des blocs de vérification plus longs, les tâches conversationnelles beaucoup moins.

Le test le plus intéressant, cependant, n'est pas celui offline, mais la mise en production au sein du moteur de serving de DeepSeek-V4, tant dans la variante Flash que Pro, en comparaison avec l'ancien standard de production interne appelé MTP-1, un drafter à token unique qui était resté en usage précisément parce que des variantes plus agressives à tokens multiples fixes dégradaient le throughput agrégé sous une charge élevée. Ici, DeepSeek introduit le concept de frontière de Pareto du serving : le compromis observable entre la capacité agrégée que le système parvient à servir et la vitesse à laquelle chaque utilisateur individuel voit défiler sa réponse. À niveau de service égal, c'est-à-dire en fixant un seuil minimal de vitesse perçue par l'utilisateur, DSpark apporte un gain de vitesse par utilisateur allant de 60 % à 85 % sur Flash et de 57 % à 78 % sur Pro. Sous des contraintes d'interactivité très strictes, celles où l'ancien système à token unique s'effondrait presque totalement pour rester dans les temps, les gains relatifs deviennent des chiffres énormes, dépassant les 600 % dans un cas : les auteurs eux-mêmes, avec une honnêteté qu'il convient de souligner, avertissent de ne pas lire ces pics comme des multiplicateurs réalistes, mais comme la preuve que DSpark parvient à maintenir un service digne précisément là où auparavant le système cessait pratiquement de fonctionner.

Le mécanisme qui produit ce résultat est visible dans les données de télémétrie live : sous une charge modérée, le scheduler allonge le budget de vérification par requête, passant des deux tokens fixes de MTP-1 à un intervalle dynamique entre quatre et six, tandis que lorsque le nombre de requêtes simultanées augmente et que la capacité du target sature, le budget se réduit automatiquement, protégeant la capacité de calcul résiduelle au lieu de la gaspiller sur des tokens à faible probabilité de survie. C'est exactement le comportement load-aware que la théorie promettait, observé sur un trafic réel et non sur des simulations.

Il faut dire, par exhaustivité et sans triomphalisme, que les auteurs eux-mêmes signalent une limite non négligeable : même lorsque le scheduler évite les gaspillages côté vérification, le coût de génération du bloc initial de brouillon via le backbone parallèle reste fixe et est tout de même payé, même pour les requêtes les plus difficiles où le taux d'acceptation final sera de toute façon bas. C'est un coût qui n'est pas récupéré pour l'instant, et l'article l'indique explicitement comme une direction de travail futur, suggérant des mécanismes de sortie anticipée sensibles à la difficulté de la requête. Image tirée de l'article

Ouvrir les tiroirs : DeepSpec et ses coûts cachés

DeepSeek ne s'est pas contenté de publier un article, il a également ouvert le dépôt DeepSpec, une codebase complète pour entraîner et évaluer des draft models de ce type, contenant à la fois DSpark et les implémentations de référence de DFlash et Eagle3 utilisées pour les comparaisons. Parallèlement au code, des checkpoints prêts à l'emploi pour les versions preview de DeepSeek-V4-Pro avec DSpark ont été publiés sur Hugging Face, un détail qui compte beaucoup pour ceux qui veulent expérimenter sans avoir à tout réentraîner de zéro.

La structure du dépôt suit un flux linéaire et lisible : d'abord la préparation des données, qui inclut le téléchargement des prompts, la régénération des réponses via le modèle target et la construction de ce qu'on appelle la target cache, puis la phase d'entraînement proprement dite lancée avec un script qui distribue le travail sur tous les GPU visibles, enfin l'évaluation sur une suite de benchmarks comprenant, entre autres, GSM8K, MATH500, HumanEval et Arena-Hard-v2. C'est un flux conçu pour ceux qui ont déjà une familiarité avec l'entraînement distribué, pas pour ceux qui veulent essayer DSpark sur un simple ordinateur portable, et la documentation elle-même présuppose un nœud avec huit GPU comme configuration par défaut.

Il y a un avertissement, enfoui dans la documentation de la phase de préparation des données, qui mérite plus d'attention qu'il n'en reçoit habituellement : construire la target cache pour la configuration par défaut basée sur Qwen3-4B peut occuper environ 38 téraoctets de stockage. Ce n'est pas une erreur de frappe, c'est la conséquence directe du fait que l'entraînement nécessite de sauvegarder les états cachés du modèle target pour un nombre énorme de positions, afin d'éviter d'avoir à réexécuter le grand modèle à chaque époque d'entraînement du draft. Pour celui qui lit ce texte en pensant reproduire l'expérience sur du matériel domestique ou même sur un petit cluster d'entreprise, ce seul détail redimensionne considérablement l'accessibilité pratique du projet : le code est ouvert, mais le coût infrastructurel pour l'utiliser jusqu'au bout reste celui d'un laboratoire disposant de ressources importantes.

Sur le front de la licence, DeepSpec est publié sous licence MIT, la plus permissive parmi les licences courantes de l'open source, qui autorise la réutilisation commerciale, la modification et la redistribution avec très peu de conditions. Le fichier NOTICE du dépôt rappelle toutefois que tout le code n'est pas le fruit du travail de DeepSeek : des parties consistantes de l'implémentation, en particulier celle de Eagle3, sont adaptées du framework SpecForge distribué sous licence Apache 2.0, tandis que la conception et la recette d'entraînement de DFlash dérivent d'un dépôt tiers également sous licence MIT. C'est une pratique d'attribution correcte et transparente, de plus en plus rare à voir documentée avec ce soin dans un panorama, celui des sorties open source des grands laboratoires, où l'on se limite souvent à citer les articles académiques sans tracer avec précision la provenance du code.

Qui gagne, qui attend encore

En regardant l'ensemble du travail, les bénéficiaires les plus immédiats sont les opérateurs d'infrastructures de serving qui gèrent un trafic à haute simultanéité : si les chiffres de production déclarés tiennent la route même en dehors des laboratoires DeepSeek, la possibilité d'offrir des niveaux d'interactivité auparavant inaccessibles sans avoir à doubler la flotte de GPU est un argument économique difficile à ignorer, et il ne serait pas surprenant de voir des idées similaires apparaître rapidement dans les moteurs d'inference open source les plus répandus, de SGLang à vLLM. Les utilisateurs finaux d'applications conversationnelles et agentiques en bénéficient également indirectement, pour qui la latence perçue compte autant que la qualité de la réponse.

Ceux qui restent le plus en arrière, du moins à court terme, sont la frange de la communauté qui voudrait expérimenter en autonomie en partant de zéro : entre les prérequis matériels pour l'entraînement et l'espace de stockage nécessaire pour le cache du target, DeepSpec parle surtout un langage de laboratoire industriel, pas de hobbyiste avec une seule carte graphique. Il reste par ailleurs quelques questions ouvertes que l'article lui-même ne referme pas totalement : jusqu'à quel point le scheduler asynchrone est-il robuste quand le trafic réel est encore plus irrégulier que celui observé lors des tests de DeepSeek, et si le coût fixe du backbone parallèle, celui que les auteurs eux-mêmes indiquent comme limite, devient un problème sérieux précisément dans les cas d'usage les plus exigeants, les cas agentiques à très basse tolérance de latence, où chaque milliseconde de génération du brouillon initial pèse proportionnellement plus. Ce sont les questions auxquelles la prochaine itération, presque certainement en route avant que quelqu'un n'ait fini de prononcer correctement l'acronyme actuel, tentera de répondre.