DSpark dans llama.cpp : +31,5 % de génération sur Qwen3‑8B

Un test local sous llama.cpp montre une hausse de débit de génération de 95,0 à 124,9 tokens/s avec DSpark sur Qwen3‑8B, à paramètres identiques. La technique de DeepSeek reste simple à activer mais son support de modèles est encore limité et son intégration dans llama.cpp est récente.

Le support DSpark reste limité et encore jeune dans llama.cpp

La prise en charge des modèles compatibles avec un brouillon DSpark est restreinte, ce qui limite l'expérimentation à un nombre réduit de configurations. L'intégration dans llama.cpp est récente et peut exposer à des bugs ou des instabilités selon le modèle et la version utilisés. Lors des mesures, la vitesse de traitement des prompts est plus faible avec DSpark qu'en exécution classique. Pour des sorties longues, l'intérêt principal réside dans le débit de génération de tokens, qui peut avoir un impact plus important sur le temps d'inférence global.

DSpark combine brouillon parallèle et séquentiel avec filtrage par confiance

DSpark associe une production de brouillons en parallèle à un composant séquentiel léger. Cette organisation permet aux positions de brouillon ultérieures de tenir compte des prédictions précédentes tout en conservant la rapidité d'une génération parallèle. Les approches strictement parallèles voient souvent la précision diminuer sur les tokens ultérieurs du bloc ; DSpark vise à y remédier. Le système peut estimer la probabilité de conservation des tokens lors de la vérification et supprimer les segments jugés à faible confiance. Dans llama.cpp, un seuil de confiance optionnel permet d'exposer ce comportement.

Protocole de test constant pour isoler l’effet de DSpark

Le banc d'essai s'appuie sur Qwen3‑8B sous llama.cpp en exécutant d'abord une référence sans décodage spéculatif, puis la même configuration avec DSpark. Le prompt reste identique, demandant une implémentation Python complète du tri fusion avec explications et complexités. Le décodage est déterministe avec une température de 0 et un top‑k fixé à 1. Les options de déchargement vers le GPU sont activées, avec -ngl all pour le modèle principal et l'activation de Flash Attention.

Résultats : de 95,0 à 124,9 tokens/s, soit environ 1,31×

Sans DSpark, le résumé de benchmark de llama.cpp affiche une génération à 95,0 tokens/s, valeur retenue comme référence. Avec DSpark, le modèle de brouillon est chargé via -md, le mode --spec-type draft-dspark est activé et --spec-draft-n-max est fixé à 3, avec déchargement du brouillon vers le GPU. Le résumé de benchmark indique alors une génération à 124,9 tokens/s. La comparaison donne un passage de 95,0 à 124,9 tokens/s, pour un gain d'environ 1,31×, soit environ 31,5 % plus rapide, tandis que la phase de prompt est mesurée plus lente avec DSpark.

Mise en place : compilation CUDA et modèles Qwen3‑8B en GGUF

La configuration passe par la construction de la dernière version de llama.cpp avec l'accélération CUDA, après installation de git, cmake et build-essential. Le dépôt officiel ggml-org/llama.cpp est cloné et les cibles binaires dont llama-cli sont construites. Les fichiers GGUF sont stockés dans /workspace/models et téléchargés via la CLI Hugging Face, avec authentification possible par variable HF_TOKEN. Le modèle principal Qwen3‑8B Q4_K_M est récupéré depuis Qwen/Qwen3‑8B‑GGUF, et le brouillon DSpark correspondant dspark‑Qwen3‑8B‑Q8_0.gguf depuis ggml‑org/Qwen3‑8B‑GGUF. Les tailles observées sont de l'ordre de 4,7G pour le modèle cible et 1,2G pour le brouillon.

Contexte : MTP plus répandue, DSpark promet de meilleurs brouillons

Plusieurs leviers d'optimisation existent au‑delà de l'ajout de GPU, dont la quantification, des kernels optimisés et des moteurs d'inférence améliorés. Côté décodage spéculatif, les approches traditionnelles recourent à un plus petit modèle de brouillon, la MTP anticipe plusieurs tokens et des variantes comme Medusa, EAGLE ou DFlash modulent la manière de générer des blocs candidats. La MTP est souvent présentée comme l'option la plus pratique pour l'inférence locale car plus simple et disponible sur davantage de modèles. DSpark peut cependant prendre l'avantage lorsque la qualité du brouillon accroît la part de tokens spéculatifs acceptés. DeepSeek rapporte des gains de 60 à 85 % par rapport à sa base MTP‑1 avec DeepSeek‑V4, des chiffres qui ne sont pas posés comme une attente pour un petit modèle local.