DSpark est une méthode de décodage spéculatif publiée par Novita. Nous avons entraîné et publié des spéculateurs DSpark orientés production pour Kimi-K2.6 et Kimi-K2.7-Code, les avons intégrés à vLLM, et avons évalué comment leur approche de rédaction de blocs parallèles s’adapte à mesure que la fenêtre spéculative s’agrandit.
Les points de contrôle sont conçus pour accélérer le service de Kimi sans modifier le modèle cible. Un modèle de brouillon léger propose un bloc de tokens candidats, et le modèle Kimi complet vérifie ces candidats avant qu’ils ne soient acceptés.
Dans nos évaluations nocturnes de vLLM avec une taille de lot de 1, DSpark avec num_speculative_tokens=7 a atteint une accélération moyenne du débit de 2,55x pour Kimi-K2.6 et de 2,36x pour Kimi-K2.7-Code. À mesure que la fenêtre spéculative passait de n=3 à n=7, DSpark a converti les tokens de brouillon supplémentaires en débit de manière plus cohérente que les références Eagle3-MLA disponibles.
Les points de contrôle publiés sont :
- novita/kimi-k2.6-dspark pour Kimi-K2.6
- novita/kimi-k2.7-code-dspark pour Kimi-K2.7-Code
Résultats de référence DSpark pour Kimi-K2.6 et Kimi-K2.7-Code
Avec une taille de lot de 1, passer num_speculative_tokens de 3 à 7 a augmenté l’accélération moyenne de DSpark de 2,17x à 2,55x pour Kimi-K2.6 et de 2,12x à 2,36x pour Kimi-K2.7-Code. Les références Eagle3-MLA listées sont restées quasiment plates en moyenne.
| Modèle cible | Modèle de brouillon | Accélération moyenne n=3 | Accélération moyenne n=7 | Variation par rapport à n=3 | |—|—:|—:|—:| | Kimi-K2.6 | DSpark | 2.17x | 2.55x | +17.8% | | Kimi-K2.6 | Eagle3-MLA | 2.01x | 2.01x | +0.2% | | Kimi-K2.7-Code | DSpark | 2.12x | 2.36x | +11.7% | | Kimi-K2.7-Code | Eagle3-MLA | 2.04x | 2.05x | +0.3% |
Ces valeurs sont des moyennes simples et non pondérées des accélérations au niveau des benchmarks sur GSM8K, MATH500, AIME, HumanEval, LiveCodeBench et SPEED-Bench Coding ; elles ne sont pas pondérées par le nombre de prompts. Une fenêtre de brouillon plus grande n’améliore pas automatiquement le débit : les propositions supplémentaires doivent être acceptées suffisamment souvent pour compenser le surcoût de la rédaction et de la vérification.
LiveCodeBench illustre concrètement la différence. Pour Kimi-K2.6, DSpark est passé de 1,86x à n=3 à 1,87x à n=7, tandis qu’Eagle3-MLA est tombé de 1,67x à 1,48x. Pour Kimi-K2.7-Code, DSpark a augmenté de 1,75x à 1,78x, tandis qu’Eagle3-MLA est tombé de 1,69x à 1,52x. Sur SPEED-Bench Coding, DSpark a augmenté de 2,19x à 2,41x pour Kimi-K2.6 et de 2,15x à 2,31x pour Kimi-K2.7-Code.
Configuration d’évaluation : taille de lot 1, décodage spéculatif nocturne en ligne vLLM, décodage glouton, TP=8, max_model_len=20000, graphiques CUDA activés, et fuse_allreduce_rms=false. Un nombre plus élevé de tokens/s et une accélération plus élevée sont meilleurs. La taille de lot 1 isole le comportement de décodage d’une seule requête ; les résultats peuvent différer sous batching continu ou des charges de travail de production à plus forte concurrence. Les résultats complets sont disponibles sur les pages Hugging Face de Kimi-K2.6 DSpark et Kimi-K2.7-Code DSpark.
Pourquoi DSpark améliore le décodage spéculatif de Kimi
Nos points de contrôle appliquent DSpark à Kimi-K2.6 et Kimi-K2.7-Code en tant que modèles de brouillon pour le service vLLM.
Par rapport au backbone de rédaction parallèle DFlash, DSpark ajoute deux têtes légères : une tête de biais logit de Markov pour la dépendance intra-bloc de bas rang des tokens, et une tête de confiance par position pour la prédiction d’acceptation. DSpark propose le bloc de brouillon complet en parallèle, puis utilise ces têtes pour améliorer la qualité du brouillon au niveau du bloc et estimer les positions que le vérificateur est susceptible d’accepter.
Nous avons entraîné les modèles de brouillon avec un fork vendu du framework Speculators de vLLM. Pendant l’entraînement, le brouillon consomme les états cachés diffusés en continu par un vérificateur Kimi en direct fonctionnant dans vLLM, alignant le spéculateur sur le comportement du vérificateur qu’il rencontrera au moment du service.
Nos tableaux publiés utilisent les points de contrôle open-source disponibles d’Eagle3-MLA comme références de modèles de brouillon avec la même configuration de vérificateur et de service. Le résultat central est la façon dont les méthodes évoluent avec une fenêtre spéculative plus grande : de n=3 à n=7, l’accélération moyenne de DSpark a augmenté de 17,8 % pour Kimi-K2.6 et de 11,7 % pour Kimi-K2.7-Code, tandis que les références Eagle3-MLA listées sont restées quasiment plates en moyenne et ont ralenti sur les deux évaluations LiveCodeBench. Cela suggère que DSpark préserve plus efficacement la qualité utile du brouillon à mesure que la fenêtre s’agrandit. La comparaison est spécifique aux points de contrôle, à la charge de travail de taille de lot 1 et à la configuration de service testées ici.
Comment servir Kimi-K2.7-Code avec DSpark dans vLLM
Le support de DSpark nécessite actuellement une version nocturne de vLLM. Pour Kimi-K2.7-Code, utilisez la configuration de décodage spéculatif suivante :
uv pip install vllm --extra-index-url https://wheels.vllm.ai/nightly
vllm serve moonshotai/Kimi-K2.7-Code \
--tensor-parallel-size 8 \
--max-model-len 20000 \
--trust-remote-code \
--compilation-config='{"pass_config": {"fuse_allreduce_rms": false}}' \
--speculative-config '{
"model": "novita/kimi-k2.7-code-dspark",
"num_speculative_tokens": 7,
"method": "dspark"
}'
Pour Kimi-K2.6, utilisez la même configuration et pointez speculative_config.model vers novita/kimi-k2.6-dspark.
Mises en garde connues pour les versions nocturnes : la planification AOT de FA3 côté brouillon peut nécessiter de passer fast_build=True lors de la construction des métadonnées d’attention du brouillon, et la capture de graphiques CUDA peut rencontrer une erreur de taille d’espace de travail all-reduce FlashInfer. La configuration testée désactive fuse_allreduce_rms ; consultez les pages Hugging Face liées pour les solutions de contournement actuelles.
DSpark modifie le chemin de décodage sans changer le modèle Kimi cible. Nous recommandons de commencer avec num_speculative_tokens=7, puis de valider le débit, la longueur acceptée, la latence inter-token et la latence de bout en bout par rapport au trafic de production représentatif. La meilleure configuration dépendra de la forme de la charge de travail, du batching et du matériel de service.
