DeepSeek DSpark : accélération des LLM de 400% dévoilée

DeepSeek DSpark : Accélération des LLM de 400% Dévoilée

Qu'est-ce que le Décodage Spéculatif ?

La génération de LLM est lente car chaque token nécessite un passage complet à travers le modèle. Le décodage spéculatif accélère ce processus grâce à un modèle de brouillon plus petit qui prédit plusieurs tokens futurs à la fois, que le modèle cible vérifie ensuite en un seul passage.

Si le modèle de brouillon fait de bonnes prédictions, plusieurs tokens peuvent être produits à partir d'un seul passage à travers le modèle cible. En revanche, s'il fait de mauvaises prédictions, il revient à son rythme normal. La qualité de sortie est maintenue car le modèle cible vérifie les prédictions par rapport à sa propre distribution de probabilité.

Le principal défi consiste à développer un modèle de brouillon approprié :

• Lorsqu'il est séquentiel et précis sur de longues prédictions, il ne peut pas suivre le modèle cible et échoue à produire plusieurs tokens avant que le modèle cible ne termine.
• Dans ce cas, la latence augmente en fonction du nombre de blocs traités.

En rendant le modèle de brouillon plus rapide et parallèle plutôt que séquentiel, les prédictions deviennent moins précises dans la dernière partie du bloc. DSpark démontre une solution qui aborde ces deux facteurs simultanément.

L'idée Principale : Rédaction Semi-Autoregressive

Voici un modèle de prédiction : dans un contexte autoregressif (c'est-à-dire, Eagle3), chaque token généré est conditionné par tous les tokens précédemment générés. Bien que cela soit représentatif de l'entraînement traditionnel en apprentissage automatique, c'est inefficace, car le modèle connaît une augmentation linéaire de la latence au fur et à mesure que le nombre de tokens générés augmente.

Dans un contexte parallèle (c'est-à-dire, DFlash), le modèle génère un bloc entier de tokens en un seul passage. Cela produit une sortie très rapide. Cependant, chaque token est estimé de manière isolée des autres tokens du bloc, ce qui peut créer un mélange incohérent de mots.

DSpark combine une structure largement parallèle pour la vitesse (de nombreux chemins de traitement indépendants) avec une petite structure séquentielle qui ajoute des dépendances locales entre les tokens. Ensemble, c'est une approche principalement parallèle avec une fine couche d'autoregression pour corriger l'incohérence à travers la séquence.

Le document présente deux structures de séquençage :

• Une tête Markov utilise uniquement le token précédent plus une matrice de faible rang, atteignant presque aucun surcoût.
• Une tête RNN maintient un état récurrent minimal à travers le bloc, lui donnant plus de contexte que la tête Markov.

DeepSeek a constaté que la tête Markov offre essentiellement tous les avantages à une complexité beaucoup plus faible, c'est donc celle qu'ils ont mise en production.

Commencer avec DeepSpec

DeepSeek a open-sourcé le code d'entraînement et d'évaluation pour leurs modèles de brouillon sous le nom de DeepSpec. Il s'agit d'un dépôt complet pour entraîner tout type de modèles de brouillon, et pas seulement pour DSpark, mais aussi pour DFlash et Eagle3. Vous pouvez reproduire leurs comparaisons de ces modèles en utilisant ce dépôt.

Pour installer les dépendances et cloner ce dépôt, consultez les fichiers README inclus dans le dépôt.

git clone https://github.com/deepseek-ai/DeepSpec.git
python -m pip install -r requirements.txt

Cela couvre l'installation pour l'entraînement et l'évaluation des modèles avec DeepSpec. Cependant, vous devrez préparer vos données séparément en utilisant un mécanisme pour inférer les sorties du modèle cible. Pour plus d'informations à ce sujet, consultez le fichier scripts/data/README.md dans ce dépôt.

Pratique : Entraînement et Évaluation d'un Modèle de Brouillon

Il y a trois étapes dans un flux de travail DeepSpec : préparation des données, entraînement de votre modèle à partir du brouillon, et évaluation. La sortie d'une étape devient l'entrée de la suivante.

Étape 1 : Choisir une Configuration

Vous pouvez trouver des configurations dans le dossier config/ (il y a un fichier pour chaque paire d'algorithmes et de modèles cibles).

ls config/dspark/
# dspark_qwen3_4b.py  dspark_qwen3_8b.py  dspark_gemma4_12b.py

Chaque fichier de configuration spécifie le modèle cible, la taille du bloc, et quelle tête séquentielle doit être utilisée. Si vous souhaitez que votre configuration soit la même que la plus petite référence décrite dans l'article, vous voudrez utiliser le fichier de configuration dspark_qwen3_4b.py.

Étape 2 : Entraîner le Modèle

Pour commencer l'entraînement, vous utiliserez la commande suivante :

bash scripts/train/train.sh --opts config_path=config/dspark/dspark_qwen3_4b.py

Le script peut créer un travailleur pour chaque GPU de votre système. Les fichiers de point de contrôle seront sauvegardés dans ~/checkpoints///step_*. Si vous utilisez un seul nœud pour l'entraînement, vous devrez définir la variable CUDA_VISIBLE_DEVICES pour correspondre au nombre de GPU que vous avez.

Au cours du processus d'entraînement, nous optimisons trois types de pertes simultanément :

• un terme de cross-entropy (pour prédire correctement le prochain token),
• un terme de correspondance de distribution (qui se rapporte directement au « taux d'acceptation » du contenu généré),
• une « perte de confiance ».

Cette dernière est importante, car elle nous permet d'implémenter le truc de planification décrit dans la section suivante.

Étape 3 : Évaluation

bash scripts/eval/eval.sh \
--target_name_or_path Qwen/Qwen3-4B \
--draft_name_or_path ~/checkpoints/deepspec/dspark_block8_qwen3_4b/step_latest

La vérification se fait en un seul passage, il faut donc mesurer combien de tokens sont acceptés à travers trois types de tâches : mathématiques, code, et chat. Plus de tokens acceptés signifie moins de passages inutiles vers le modèle cible.

Résultats Expérimentaux

Les chiffres présentés par DeepSeek étaient en effet remarquables. DSpark a dépassé la longueur acceptée d'Eagle3 d'environ 27-31%. La sortie de DSpark a dépassé celle de DFlash de 16-18%. Ces améliorations sont restées constantes pour tous les modèles cibles Qwen3-4B, 8B, et 14B. De plus, ils ont également obtenu des résultats similaires sur le modèle Gemma4-12B, indiquant qu'il y a également quelque chose avec les résultats de Gemma et pas seulement une particularité de Qwen.

Le résultat inter-famille aide à clarifier pourquoi le post de DeepSeek avait les titres de Gemma et Qwen listés. Cela doit être considéré comme une meilleure indication que de comparer uniquement à un seul modèle. Les astuces spécifiques à l'architecture ont généralement des limites lorsqu'elles sont testées sur une autre division de modèles.

Points à Surveiller et Écueils

Voici quelques informations très importantes, peu importe la forme sous laquelle elles sont présentées :

• La discussion vérifie différemment du code : La discussion a plus de tokens suivants valides (ce qui signifie qu'elle a un taux de confiance plus bas) que le code, donc la confiance diminue plus rapidement et la planification sera plus agressive.

• Les seuils statiques ne sont pas une planification dynamique : Un seuil statique est une technologie de l'année dernière, et le seuil ne prend pas en compte à quel point votre système est occupé, DSpark recalculera un seuil dynamique à chaque lot.

• La causalité est non négociable : Parce que vous ne pouvez pas voir dans le futur, le planificateur ne peut pas vérifier un token avant de s'assurer que le token a été validé. Cela est souvent géré hors ligne en utilisant le processus de prédiction de confiance en deux étapes qui était en cours à la fin de V2.

• Les extrêmes des pourcentages nominaux sont très trompeurs : Par exemple, le multiplicateur de 661% pour MTP-1@V4-Flash est sous des conditions artificielles, la métrique ne reflète pas la production réelle d'un fabricant, donc ne pas utiliser cette multiplication comme valeur attendue, mais plutôt utiliser le 60-85% de débit correspondant.

• Vous ne pouvez pas récupérer les coûts de rédaction : Même si votre requête n'est pas acceptée, vous payez toujours des frais de rédaction complets au moment de la requête, même si le système élimine la vérification après la planification.

DSpark est un solide rappel que les accélérations d'inférence peuvent provenir de nombreux endroits. Tous les gains ne nécessitent pas un modèle plus grand ou un meilleur matériel ; parfois, cela vient du fait d'admettre que les brouillons peuvent être inexacts et de laisser le planificateur travailler intelligemment autour de cette admission.

Si vous exécutez un décodage spéculatif sous des charges de requêtes variables, l'idée s'applique même si votre architecture n'est pas de type DeepSeek. Le principe est simple : ne vérifiez que ce qui a une valeur attendue positive.

Et si vous vous demandez comment la tête Markov se compare à l'attention complète pour le bloc de brouillon, c'est le prochain sujet à explorer. Vous pouvez le tester vous-même, puisque le...