Tutoriel Multi-Token Prediction : comment accélérer les LLM

Qu’est-ce que la Multi-Token Prediction ?

La plupart des LLM génèrent le texte un token après l’autre. Le modèle prédit le token suivant, l’ajoute au contexte, puis recommence. C’est fiable, mais potentiellement lent, car chaque nouveau token implique généralement une étape de décodage supplémentaire.

La Multi-Token Prediction change la donne en permettant au modèle d’anticiper et de proposer plusieurs tokens futurs au lieu d’un seul. Ces tokens proposés sont ensuite validés par le processus principal de décodage. Si les prédictions sont correctes, le modèle peut accepter plusieurs tokens d’un coup. Si un token est erroné, il revient au chemin normal à partir de ce point.

En pratique, MTP fonctionne comme un mécanisme de brouillon intégré. Le modèle esquisse quelques tokens probables, les vérifie et conserve ceux qui sont valides. Plus il y a de tokens de brouillon acceptés, moins il faut d’étapes complètes de décodage, ce qui peut augmenter les tokens par seconde sans dégrader la qualité finale.

En résumé :

• Sans MTP : Générer le token 1 → générer le token 2 → générer le token 3
• Avec MTP : Rédiger plusieurs tokens → les vérifier → accepter les tokens valides en lot

C’est pourquoi MTP peut rendre l’inférence locale des LLM nettement plus fluide. Au lieu d’avancer à pas minuscules, le modèle peut sauter prudemment plusieurs étapes lorsque ses prédictions de brouillon sont correctes. 

Dans des outils comme llama.cpp et les implémentations proches du style vLLM, cela s’apparente étroitement au decoding spéculatif, où les tokens de brouillon ne sont acceptés que s’ils correspondent à la sortie du vérificateur. 

1. Configurer une machine RunPod RTX 3090

Pour ce guide, j’ai utilisé une instance GPU RunPod avec une RTX 3090. Vous pouvez employer un autre GPU compatible CUDA, mais les résultats du tutoriel se basent sur une configuration RTX 3090.

Commencez par créer un nouveau pod RunPod et sélectionnez un GPU RTX 3090.

Avant de déployer le pod, modifiez les paramètres du template :

• Augmentez la taille du disque à 100 Go

• Ajoutez un port HTTP supplémentaire : 8910

• Ajoutez une variable d’environnement nommée HF_TOKEN et renseignez votre jeton d’accès Hugging Face. 

Le port HTTP supplémentaire vous permettra d’accéder au serveur et à l’interface web de llama.cpp depuis votre navigateur. Le jeton Hugging Face facilite l’authentification et peut accélérer le téléchargement, notamment pour les gros fichiers GGUF.

Après la mise à jour du template, déployez le pod. Une fois démarré, attendez l’accès à l’instance JupyterLab fournie par RunPod. Ouvrez JupyterLab, puis lancez un nouveau terminal.

Dans le terminal, installez les paquets système requis :

apt update
apt install -y git cmake build-essential curl wget python3-pip

2. Cloner et basculer sur la branche MTP

Ensuite, placez-vous dans le répertoire de travail où nous allons installer et compiler llama.cpp :

cd /workspace

Clonez le dépôt llama.cpp :

git clone --depth 1 https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

Les changements MTP sont encore testés via une pull request dédiée de llama.cpp. Nous allons donc récupérer et utiliser cette branche pour bénéficier de la dernière implémentation MTP avant son intégration au tronc principal.

Récupérez la branche MTP en local :

git fetch origin pull/22673/head:mtp-pr
git checkout mtp-pr

Votre build local de llama.cpp bascule ainsi vers la version compatible MTP, que nous utiliserons pour la suite.

3. Compiler llama.cpp avec le support CUDA

Maintenant que vous êtes sur la branche MTP, compilez llama.cpp avec le support CUDA. Le modèle pourra ainsi utiliser la RTX 3090 plutôt que d’exécuter l’inférence sur le CPU.

Lancez la configuration CMake :

cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release

Puis compilez les deux cibles nécessaires à ce guide :

cmake --build build --target llama-cli llama-server -j

Cette compilation produit :

• llama-cli pour des tests rapides en ligne de commande

• llama-server pour lancer un serveur compatible OpenAI accessible via le navigateur

Une fois la compilation terminée, copiez le binaire llama-server dans le répertoire racine de llama.cpp :

cp ./build/bin/llama-server ./llama-server

Cela facilitera le lancement du serveur à la racine du projet lors des prochaines étapes.

4. Télécharger le modèle Qwen3.6-27B-MTP

Téléchargez maintenant le modèle Qwen3.6 27B MTP au format GGUF que nous allons utiliser pour les tests. Nous l’exécuterons d’abord sans MTP, puis avec MTP activé pour comparer les performances.

Commencez par installer les outils de téléchargement Hugging Face :

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer

Activez ensuite les téléchargements accélérés :

export HF_HUB_ENABLE_HF_TRANSFER=1

Cela aide à accélérer les gros téléchargements de modèles, notamment les fichiers GGUF.

Créez maintenant un répertoire dédié au modèle :

mkdir -p /workspace/models/qwen3.6-mtp

Téléchargez le modèle Qwen3.6 27B MTP (GGUF) :

hf download froggeric/Qwen3.6-27B-MTP-GGUF \
 Qwen3.6-27B-Q4_K_M-mtp.gguf \
 --local-dir /workspace/models/qwen3.6-mtp

Si l’affinage des LLM vous intéresse, consultez mon tutoriel sur l’affinage de Qwen3.6 sur un jeu de questions-réponses médical.

5. Exécuter Qwen3.6-27B sans MTP

Nous arrivons au cœur du guide : mesurer la vitesse du modèle avant et après l’activation de MTP.

Nous allons d’abord exécuter le modèle sans MTP. Cela nous donne une base de comparaison. Même modèle, même GPU, même taille de contexte et mêmes paramètres serveur. La seule différence majeure ensuite sera l’activation de MTP.

Revenez dans le répertoire llama.cpp :

cd /workspace/llama.cpp

Démarrez le serveur sans MTP :

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-no-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Cela lance un serveur llama.cpp compatible OpenAI sur le port 8910.

Le chargement peut prendre un peu de temps, le serveur devant transférer les poids du modèle en mémoire GPU. Une fois prêt, le terminal indiquera que le serveur est disponible sur le port 8910.

Comme nous avons exposé ce port lors de la configuration du template RunPod, aucune autre configuration n’est nécessaire. Revenez au tableau de bord RunPod et cliquez sur le lien associé au port 8910. L’interface web de llama.cpp s’ouvre alors dans votre navigateur avec le modèle local déjà chargé.

Vous pouvez ensuite tester des prompts directement dans le navigateur, comme dans une interface de chat.

Dans mon test de référence, le modèle a généré des réponses autour de 38,86 tokens/s sans MTP. Même avec un prompt plus complexe, la vitesse est restée dans le même ordre de grandeur. 

Pour un modèle 27B sur une RTX 3090, c’est déjà exploitable, surtout compte tenu de la vitesse et de la VRAM plus limitées par rapport aux cartes data center récentes. 

6. Exécuter Qwen3.6-27B avec MTP

Nous allons maintenant relancer le même modèle, cette fois avec MTP activé.

Revenez sur le terminal où tourne le serveur et arrêtez-le avec :

CTRL + C

Point important : nous ne changeons ni le modèle, ni le GPU, ni la quantification, ni la plupart des paramètres d’exécution. Nous ajoutons seulement deux options liées à MTP :

--spec-type mtp
--spec-draft-n-max 3

La première indique à llama.cpp d’utiliser le decoding spéculatif en mode MTP. La seconde fixe à 3 le nombre maximal de tokens de brouillon. Le modèle peut donc préparer jusqu’à trois tokens avant vérification.

Relancez maintenant le serveur avec MTP activé :

./llama-server \
-m "/workspace/models/qwen3.6-mtp/Qwen3.6-27B-Q4_K_M-mtp.gguf" \
--alias qwen3.6-27b-mtp \
--host 0.0.0.0 \
--port 8910 \
-ngl 99 \
-c 100000 \
--spec-type mtp \
--spec-draft-n-max 3 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-b 2048 \
-ub 512 \
-t 8 \
-fa on \
--temp 0.7 \
--top-k 20 \
--top-p 0.95 \
--repeat-penalty 1.1 \
--metrics

Une fois le serveur prêt, rafraîchissez la page du navigateur. S’il ne se reconnecte pas automatiquement, fermez-la et rouvrez le lien du port 8910 depuis votre tableau de bord RunPod. 

Testez à nouveau le modèle avec le même type de prompts.

Avec MTP activé, la vitesse a nettement augmenté. Pour un simple prompt de salutation, le modèle a atteint environ 65–67 tokens/s. Comparé à la base de 38,86 tokens/s, c’est un gain majeur obtenu avec seulement deux options en ligne de commande. 

Avec un prompt plus complexe (par exemple demander la création d’un petit jeu en Python), la vitesse a légèrement baissé mais est restée bien supérieure à la référence sans MTP. Dans ce test, le modèle a généré autour de 56–61 tokens/s, ce qui reste excellent pour un 27B sur RTX 3090. 

Au global, l’activation de MTP a fait passer Qwen3.6 27B d’environ 38 tokens/s à 65 tokens/s sur la configuration RunPod RTX 3090. Soit une accélération de 1,71×, environ 71 % de débit en plus, sans changer de matériel ni réduire la taille du modèle. 

7. Recommandation : aller plus loin avec TurboQuant

Le benchmark de ce guide utilise la configuration MTP d’origine de llama.cpp, sans TurboQuant, ni patchs personnalisés, ni autres optimisations d’exécution. Cela rend le test simple, reproductible et focalisé sur le gain lié à MTP seul.

Pour aller plus loin, l’étape suivante consiste à combiner MTP et TurboQuant. MTP accroît le débit en acceptant plusieurs tokens prédits, tandis que TurboQuant réduit la pression mémoire de la KV-cache pendant l’inférence. 

C’est particulièrement utile pour les modèles volumineux, les prompts à long contexte et des GPU comme la RTX 3090, où la bande passante mémoire et la VRAM peuvent devenir limitantes.

C’est aussi la raison pour laquelle certains résultats partagés sur r/LocalLLaMA affichent des tokens/s plus élevés que ceux de ce guide : ces configurations combinent souvent MTP, TurboQuant, des builds patchés, des réglages de KV-cache différents ou des GPU plus rapides. Ce tutoriel se concentre sur un benchmark propre « MTP seul » ; considérez donc TurboQuant comme la prochaine expérimentation recommandée, plutôt qu’une partie de la configuration actuelle.

Conclusion

Ces derniers temps, je suis de près les publications de la communauté LocalLLaMA sur Reddit, et les progrès de l’inférence locale sont impressionnants. Des modèles comme Qwen3.6 27B tournent désormais comme agents de code en local, y compris sur d’anciens GPU à VRAM limitée. Certains obtiennent aussi d’excellents résultats sur Mac.

Après avoir testé MTP moi-même, je comprends l’enthousiasme. Avec le même modèle et la même RTX 3090, activer la Multi-Token Prediction a fait passer la vitesse de génération d’environ 38 tokens/s à 65 tokens/s. C’est presque un doublement des performances sans changer de GPU ni réduire la taille du modèle.

Ce guide s’est volontairement limité à une configuration MTP simple et reproductible avec llama.cpp, mais ce n’est qu’un début. La prochaine étape consiste à expérimenter de meilleures quantifications GGUF, MTP, TurboQuant et des paramètres runtime plus affinés, pour voir jusqu’où on peut pousser la vitesse en local.

Le plus enthousiasmant, à mes yeux, c’est l’impact sur les agents de code locaux : vous exécutez des modèles puissants sur votre propre matériel, réduisez le coût par requête, gardez votre code privé et disposez d’un assistant IA sans dépendre entièrement d’API en ligne. Les LLM locaux deviennent plus rapides, plus pratiques et nettement plus utiles qu’il y a encore peu.