llama.cpp MTP support landed - Qwen3.6 27B at 2.44× on a Strix Halo, 2.17× on a RTX 3090 rig

## MTP dans llama.cpp : ce que les chiffres signifient vraiment

### Ce qui a atterri

Le PR #22673 (commit 4f13cb7), fusionné le 16 mai, intègre le **Multi-Token Prediction (MTP) speculative decoding** dans le mainline de llama.cpp. Ce n'est pas un fork expérimental ni un patch externe : c'est désormais dans la branche principale, activable via deux flags (`--spec-type draft-mtp --spec-draft-n-max N`). L'output est byte-identical au baseline à seed et température identiques — pas de régression de qualité, pas de compromis.

Avant cette PR, le speculative decoding dans llama.cpp nécessitait un modèle draft séparé (approche classique Medusa/draft-model), ce qui impliquait de charger un second checkpoint, de gérer deux contextes mémoire, et d'accepter une complexité de déploiement significative. MTP exploite les têtes de prédiction multi-token déjà intégrées dans certains modèles (Qwen3 en l'occurrence) — pas de modèle externe requis.

### Les chiffres bruts et leur interprétation

Sur **Qwen3.6 27B** (dense), les gains sont substantiels :

- **Strix Halo / ROCm 7.0.2** : Q4_K_M passe de 11,7 à 21,2 tok/s (×1,81) ; Q8_0 de 7,4 à 18,1 tok/s (×2,44) - **RTX 3090 single @ 450W / CUDA 12.9** : Q4_K_M de 38,7 à 59,5 tok/s (×1,54, n=2) - **Dual RTX 3090 layer-split** : Q8_0 de 25,7 à 55,9 tok/s (×2,17, n=3)

Le gain ×2,44 sur Strix Halo en Q8_0 est particulièrement notable : on passe d'un débit qui rendait l'inférence locale pénible (7,4 tok/s) à quelque chose d'utilisable en temps réel (18,1 tok/s). Le Strix Halo (APU AMD, mémoire unifiée LPDDR5X) bénéficie davantage que le 3090 parce que son goulot d'étranglement est la bande passante mémoire — MTP réduit le nombre de passes forward, donc réduit la pression sur cette bande passante de façon disproportionnée.

Le paramètre optimal `n` varie selon le rig : le 3090 non bridé préfère n=2 en Q4, tandis que le 3090 bridé et le Strix Halo préfèrent n=3. Ce n'est pas un détail — choisir le mauvais n peut annuler une partie du gain.

### Pourquoi les MoE bénéficient moins

Sur **Qwen3.6 35B-A3B** (MoE), les gains sont nettement plus modestes : ×1,40 sur Strix Halo (49,5 → 69,4 tok/s), ×1,24 sur RTX 3090 (120,0 → 148,3 tok/s). L'explication est mécanique : avec seulement ~3B paramètres actifs par token sur 35B totaux, chaque passe forward est déjà bon marché. MTP économise N-1 passes forward — mais si chaque passe ne coûte presque rien, l'économie relative est faible. Les architectures MoE sont intrinsèquement moins compatibles avec le speculative decoding que les modèles denses.

Note importante : le débit de base du MoE est déjà très élevé (120 tok/s sur un seul 3090), donc l'utilité pratique du gain marginal est différente — on est déjà au-delà du seuil de confort pour la plupart des usages.

### Le contexte power limit qui change les références

L'auteur révèle que ses benchmarks 3090 précédents étaient faussés par un cap à 200W non divulgué (problème de disjoncteur avec 4 cartes sur un même circuit). Les re-benchmarks à 350W et 450W montrent des gains de **+70% à +113%** sur les modèles denses 27-32B. Ce point mérite attention : une fraction significative des benchmarks llama.cpp publiés en ligne sont probablement affectés par des power limits implicites non documentés, rendant les comparaisons inter-rigs peu fiables sans cette information.

### Qui perd dans ce tableau

Les solutions de speculative decoding basées sur des modèles draft externes (approche classique) perdent leur principal avantage différenciant pour les modèles qui embarquent des têtes MTP natives. Les fournisseurs d'inférence cloud qui monétisent la latence réduite via des solutions propriétaires voient cet avantage s'éroder pour les utilisateurs locaux. Les frameworks alternatifs (vLLM, llama-cpp-python wrappers) devront intégrer cette PR pour rester compétitifs sur les benchmarks de débit.

### Ce qu'il faut surveiller

La compatibilité MTP est pour l'instant documentée sur Qwen3. L'extension à d'autres architectures (Llama 3.x, Mistral, Gemma) dépend de la présence de têtes MTP dans les checkpoints — ce n'est pas universel. La vraie question pour les prochaines semaines : quels modèles publiés incluent des têtes MTP exploitables, et est-ce que les labs vont systématiser cette pratique dans leurs releases open-weight ?