4 · Comparaison et limites¶
Tableau récapitulatif¶
| Méthode | Année | Origine du brouillon | Bloc produit en | Statut |
|---|---|---|---|---|
| Blockwise parallel | 2018 | Têtes auxiliaires | 1 passe | Historique, non exact |
| Speculative decoding / sampling | 2022–23 | Modèle séparé plus petit | \(\gamma\) passes | Fondateur, exact |
| SpecInfer | 2023 | Arbre de continuations | \(\gamma\) passes | Vérification en arbre, réutilisée partout |
| Prompt lookup / \(n\)-grammes | 2023 | Le contexte lui-même | 0 passe | Toujours utile en RAG et édition |
| Medusa | 2024 | Têtes parallèles indépendantes | 1 passe | Dépassé par EAGLE |
| EAGLE-1/2/3 | 2024–26 | Autorégression sur caractéristiques | \(\gamma\) passes | Référence de production |
| MTP (DeepSeek-V3) | 2024 | Modules entraînés avec le modèle | \(\gamma\) passes | Baseline de DSpark |
| LayerSkip | 2024 | Le modèle cible, sortie anticipée | \(\gamma\) passes | Zéro paramètre ajouté |
| DFlash | 2026 | Diffusion par blocs + injection KV | 1 passe | Tronc réutilisé par DSpark |
| DSpark | 2026 | DFlash + tête de Markov | 1 passe | Le plus récent |
Les quatre dernières lignes sont les seules encore pertinentes pour un déploiement en 2026 ; les précédentes expliquent pourquoi elles ont cette forme.
Que choisir en pratique¶
- Une charge de type édition, résumé, RAG ou complétion de code : essayer d'abord le prompt lookup. Coût nul, quelques lignes, et sur des tâches à forte recopie il bat parfois des méthodes entraînées.
- Un modèle ouvert servi soi-même : EAGLE-3, disponible dans vLLM, SGLang et TensorRT-LLM, avec des points de contrôle publiés pour les modèles courants. C'est le choix par défaut raisonnable.
- Un service à forte concurrence, avec les moyens d'entraîner un drafter : c'est le terrain de DSpark, à condition que le moteur sache gérer des fenêtres de vérification de longueur variable — SGLang le fait via ses graphes CUDA « ragged ». Sans ce support moteur, l'apport principal de la méthode est perdu.
Les limites, dont celles reconnues par les auteurs¶
Le coût amont du bloc n'est pas récupérable. Le tronc parallèle produit toujours les \(\gamma\) jetons avant qu'on décide combien en vérifier. Sur une requête intrinsèquement peu prévisible, ce calcul est dépensé pour rien. Les auteurs le formulent explicitement.
La longueur de proposition reste statique. En production, \(\gamma\) est fixé à 5 ; seule la longueur vérifiée s'adapte. Une sortie anticipée sensible à la difficulté est laissée aux travaux futurs.
L'ordonnanceur dépend de courbes matérielles régulières. La table \(\mathrm{SPS}(B)\) suppose un débit qui varie de façon lisse avec la taille du lot. Les discontinuités réelles du matériel demandent des adaptations d'ingénierie décrites à part dans l'article.
Les chiffres sont ceux des auteurs. À la date de rédaction, aucune évaluation indépendante de DSpark n'était publiée. Trois nuances de lecture :
- les +27 à +31 % de longueur acceptée face à EAGLE-3 sur Qwen3 sont la mesure la plus solide : métrique bien définie, modèles ouverts, code d'entraînement publié ;
- les +57 à +85 % en production sont mesurés sur l'infrastructure de DeepSeek, face au baseline de DeepSeek, sous les contraintes de service de DeepSeek. Le chiffre est plausible mais non transposable tel quel ;
- les accélérations les plus spectaculaires que l'on croise dans la couverture du sujet correspondent à des régimes particuliers (lot de taille 1, tâches très prévisibles). Une accélération de décodage spéculatif n'a aucun sens hors de son point de fonctionnement : taille de lot, tâche, matériel, et débit total maintenu constant ou non.
Le piège de comparaison le plus courant
Annoncer une accélération « par utilisateur » sans préciser si le débit total du serveur est maintenu constant. Il est facile d'accélérer un utilisateur seul en dépensant le GPU entier pour lui ; la seule mesure qui engage est celle à débit égal — c'est précisément ainsi que DSpark rapporte ses gains de production, et c'est ce qui rend ce chiffre-là intéressant.
Ce qui n'a pas changé depuis 2022¶
Le fond du décodage spéculatif est stable depuis Leviathan et Chen : proposer, vérifier en une passe, accepter selon une règle qui préserve la distribution. Tout ce qui a été inventé depuis porte sur deux questions seulement — d'où vient le brouillon, et combien on en vérifie.
Medusa, EAGLE et DFlash ont travaillé la première. DSpark est le premier à traiter la seconde comme un problème d'ordonnancement à part entière, avec une estimation calibrée et un modèle de coût du matériel. C'est sans doute là que se situe son apport durable, indépendamment des points de contrôle qu'il publie.