Un petit modèle propose quelques mots, un grand modèle les vérifie d’un coup. C’est tout le principe du décodage spéculatif, une technique capable d’accélérer la génération de texte d’un modèle de langage de 2 à 3 fois, sans changer le modèle ni la qualité de ses réponses.
Le tutoriel complet publié par the-ai.news ne propose pas une idée toute neuve : elle a été formalisée par des chercheurs de Google dans un article de recherche intitulé Fast Inference from Transformers via Speculative Decoding, qui mesurait déjà une accélération de 2 à 3 fois sur un grand modèle, avec des sorties identiques. Voici l’essentiel à retenir, étape par étape.
Étape 1 : pourquoi un LLM est lent à écrire ?
Un modèle de langage génère sa réponse « token par token », c’est-à-dire par petits morceaux de mots, l’un après l’autre. Et plus le modèle grossit, plus l’attente s’allonge.
Le frein principal ne vient pourtant pas de la puissance de calcul. La génération est limitée par la bande passante mémoire : avant chaque token, les milliards de paramètres du modèle doivent être transférés vers le processeur, et pendant ce temps les unités de calcul restent largement inactives. Un GPU très rapide en calcul matriciel, comme le H100 de NVIDIA cité dans le tutoriel, passe pourtant une bonne partie de son temps à attendre ses données.
Étape 2 : un modèle de brouillon et un modèle cible
Le décodage spéculatif répartit le travail entre deux modèles. Un petit modèle « de brouillon » produit rapidement une séquence de quatre à huit tokens candidats, puis le modèle « cible », plus grand et plus fiable, les évalue tous en une seule passe.
Ce n’est pas un détail, parce que les GPU sont conçus pour le calcul parallèle : traiter un lot de tokens ne leur prend guère plus de temps que d’en traiter un seul. Quand tout est accepté, une passe du grand modèle rapporte de 5 à 9 tokens au lieu d’un (le modèle cible ajoute lui-même un token à la fin).
Comment le grand modèle trie-t-il les propositions ?
Pour chaque token proposé, le modèle cible compare sa propre probabilité à celle du brouillon. S’il est au moins aussi confiant, le token passe. Dans le cas contraire, il est accepté avec une probabilité qui baisse à mesure que l’écart grandit. Un token rejeté est remplacé par un autre, tiré d’une distribution corrigée, et la boucle repart.
Selon le tutoriel, le taux d’acceptation tourne autour de 70 à 80 % pour une paire de modèles bien assortie, sur des tâches courantes. C’est à ce niveau qu’on obtient le gain de 2 à 3 fois, et un texte prévisible ou répétitif fait encore mieux.
Étape 3 : plus rapide, mais moins bon ?
La technique ne modifie pas le modèle et ne dégrade pas ses réponses : la procédure de vérification garantit que le texte suit la même distribution de probabilités que si le grand modèle avait tout écrit seul. Le gain vient d’une stratégie de génération plus intelligente, pas d’un changement d’architecture.
Attention, le gain n’est pas garanti pour autant. Dans le pire des cas, le premier candidat est rejeté et le temps passé à rédiger le brouillon est perdu, et une paire de modèles mal assortie peut même ralentir légèrement la génération. Sur un serveur qui traite de gros lots de requêtes en parallèle, les tokens de brouillon consomment aussi de la mémoire et du calcul qui auraient pu servir à d’autres utilisateurs.
Où l’activer, et pour quels usages ?
Plusieurs moteurs d’inférence le proposent déjà, de vLLM à llama.cpp en passant par text-generation-inference de Hugging Face, et l’activer demande en général un simple changement de configuration. Le tutoriel cite aussi des variantes qui se passent d’un second modèle, comme Medusa ou le Prompt Lookup Decoding, qui recycle des passages du prompt.
Les gains les plus nets se voient sur les longues réponses servies une requête à la fois : questions-réponses, résumés de documents ou complétion de code. Autrement dit, ce que vous attendez d’un assistant de programmation ou d’un agent qui doit répondre vite.