La tête MTP de Mellum2.1 : 1,11x plus rapide sur une requête, 1,45x sur huit, et le modèle tourne en 8 bits sur une RTX 5080 de 16 GB

Crédits

• JetBrains : le modèle, entraîné avec sa tête MTP, sous Apache-2.0 ; le dépôt MTP avec la tête dans model-mtp.safetensors, la version Thinking de base, le dépôt GGUF avec les fichiers de proposition MTP, les recettes de service, le prompt du Quickstart que nous avons lancé et le tableau de benchmarks.
• Le projet vLLM : le décodage spéculatif MTP (--speculative-config '{"method": "mtp", ...}'), les métriques de spec-decode dont nous avons tiré l'acceptation, la quantification FP8 en ligne, et le backend de modélisation Transformers qui sert Mellum et sa tête de proposition dans la 0.33.0 (TransformersMoEForCausalLM, TransformersMoEForMTP).
• Hugging Face Transformers : le code de modélisation que le backend exécute ; la 5.20 est la première version qui charge la tête au lieu de l'ignorer.
• pmttyji sur r/LocalLLaMA : là où nous l'avons repéré (post du 2026-11-02).
• Notre part : le déploiement via la plateforme, les essais sans tête contre MTP sur le même GPU, le balayage à 1/2/3 tokens et en concurrence, le bilan mémoire de la tête, l'échelle de VRAM sur deux vrais GPU plus des limites émulées, l'exemple du SDK et la vidéo de démo.

Modèle et fichiers

• JetBrains/Mellum2.1-12B-A2.5B-Thinking-MTP : sha d55846102dd1c047e95d4841070f88290227c3b7, créé le 2026-10-30T17:20:32Z, modifié pour la dernière fois le 2026-10-30T18:12:02Z, sans accès restreint, Apache-2.0, 17 likes et 1 302 téléchargements au 2026-11-13. Cinq shards BF16 de 24,30 GB plus model-mtp.safetensors de 856 767 160 octets, 25,17 GB en tout.
• Base JetBrains/Mellum2.1-12B-A2.5B-Thinking : sha 92ddae9f, créé le 2026-09-20, modifié pour la dernière fois le 2026-10-07. Sa fiche annonçait les builds GGUF et la tête MTP comme "coming soon".
• Dépôt GGUF : sha 4159d684, modifié pour la dernière fois le 2026-10-22, BF16, MXFP4_MOE, Q4_K_M, Q6_K et Q8_0 plus des GGUF de proposition mtp/ dans les mêmes quantifications. Non testé.
• Architecture : 12B au total, 2,5B actifs, 28 couches (21 en fenêtre glissante de 1 024 et 7 en attention complète), hidden 2304, 64 experts dont 8 actifs, GQA 32 têtes Q / 4 têtes KV, head_dim 128, vocabulaire de 98 304, contexte de 131 072 (YaRN facteur 16 sur les couches d'attention complète), num_nextn_predict_layers: 1. Modèle de base JetBrains/Mellum2-12B-A2.5B-Base.
• Prérequis de la fiche : vLLM 0.33 ou plus récent avec transformers 5.20 ou plus récent. "vLLM releases up to 0.32 refuse the checkpoint" ; transformers avant la 5.20 ignore les tenseurs de la tête avec un avertissement. Autres voies sur la fiche, non testées : use_mtp=True dans generate de transformers, et llama.cpp avec --spec-type draft-mtp --spec-draft-n-max 1.
• Échantillonnage du Quickstart de la fiche : temperature 0.6, top_p 0.95, top_k 20, max_tokens 81920.
• La fiche n'indique ni le GPU, ni la taille de batch, ni la précision derrière sa fourchette de 1,4 à 1,8x.

Benchmarks des auteurs (non reproduits)

Aussi sur la fiche pour Mellum2.1 : HumanEval+ 91,5, MBPP+ 79,4, IFEval 90,6, HarmBench 8,5 (plus bas, c'est mieux). Les essais agentiques ont utilisé le harnais Pi v0.73.1.

Configuration

• GPU sur InferenceKey Cloud : RTX A6000 48 GB (46 068 MiB, compute capability 8.6, driver 595.91.07) pour les essais principaux, sans tête et MTP, en BF16 ; RTX 5080 16 GB (16 303 MiB, compute capability 12.0, driver 580.178.04) pour l'échelon réel de petite carte, en FP8. Aucune RTX A4000 (Ampere, 16 GB) n'était disponible, donc le FP8 sur une vraie carte Ampere de 16 GB n'est pas testé.
• Backend : le backend intégré vllm avec vllm_version="0.33.0" dans la spec du workload, qui installe torch 2.14.0 et transformers 5.20.x. vLLM 0.33.0 associe MellumForCausalLM au backend de modélisation Transformers ; il n'existe pas encore d'implémentation native de Mellum dans vLLM. Pourquoi vLLM : c'est la recette principale de la fiche.
• Un manager InferenceKey local, que les workers joignent par des tunnels. La production n'a jamais été touchée. Poids pré-téléchargés sur le disque du conteneur de chaque worker (36 s sur l'A6000).
• Mesures : un balayage par réglage, sans répétition ; cinq prompts x 2 via l'endpoint (greedy, en streaming) ; balayages de concurrence et de profondeur de proposition en direct sur vLLM sur le worker après préchauffage ; acceptation tirée des compteurs vllm:spec_decode_* ; VRAM d'après nvidia-smi échantillonné chaque seconde.

Pas à pas avec l'exemple du SDK

1. Clonez inferencekey-sdk et ouvrez examples/mellum21-12b-a2-5b-mtp-vllm-private-nvidia (commit 0a5188e70d0c32c95c9e36a17dcb75078102e48f).
2. cp .env.example .env et renseignez le token SDK (ik_sdk_, lecture et écriture des workloads), une clé d'API ik_live_ qui autorise le workload, le projet et IK_WORKER_ID : un worker NVIDIA privé avec un driver CUDA 13 (580 ou plus récent), 32 GB pour le BF16 ou 16 GB avec le FP8.
3. pip install -r requirements.txt plus le build local du SDK avec maturin (le SDK n'est pas sur PyPI).
4. python main.py. Il fait un ensure() d'un workload vllm fixe (slug mellum21-thinking, vllm_version="0.33.0") sur votre worker, attend jusqu'à 2 400 s, pose la question du Quickstart de la fiche avec generate_text(), diffuse en streaming une tâche merge_intervals avec le délai jusqu'au premier token et les tokens par seconde, lance une boucle d'agent get_weather de 4 tours au plus, écrit outputs/answers-<mtp|plain>.json, et appelle delete() sauf si IK_KEEP_ALIVE=1.
5. Variantes : MELLUM_MTP=0 python main.py pour le modèle sans tête ; MELLUM_FP8=1 MELLUM_CONTEXT=16384 MELLUM_SPEC_TOKENS=2 python main.py pour une carte de 16 GB. Autres réglages : MELLUM_SPEC_TOKENS (1 par défaut, celui de la fiche), MELLUM_CONTEXT (131072), MELLUM_GPU_UTIL (0.90).

La commande que le backend exécute (MTP activé, réglage de la fiche) :

vllm serve JetBrains/Mellum2.1-12B-A2.5B-Thinking-MTP \
  --max-model-len 131072 --gpu-memory-utilization 0.90 --max-num-seqs 16 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser hermes \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'

Pour le modèle sans tête, retirez --speculative-config. Pour l'échelon RTX 5080, ajoutez --quantization fp8, réglez --max-model-len 16384 et num_speculative_tokens à 1 ou 2. L'exemple n'envoie que temperature et top_p ; un commentaire du code dit que le top_k=20 de la fiche ne peut pas passer par l'endpoint (non vérifié dans le code du manager).

Durées

Délai jusqu'au premier token via l'endpoint : 0,23 à 0,29 s dans tous les cas.

Vitesse via l'endpoint (A6000, BF16, greedy, streaming)

Acceptation pendant ce banc d'essai sur le workload MTP : 3365/3767 = 89,3 %.

Vitesse en direct sur vLLM (à chaud)

Via l'endpoint sur la RTX 5080 avec MTP 2 : 298 à 344 tok/s.

À huit à la fois, trois propositions sont arrivées en tête avec le décodage greedy, et deux avec l'échantillonnage de la fiche ; un seul essai pour chacun.

Ce que la tête MTP coûte en mémoire

Le pic est fixé par --gpu-memory-utilization : le coût de la tête se voit donc en KV perdu, pas en pic plus élevé sur l'A6000. L'échantillon le plus haut sur l'A6000 a été de 41 280 MiB, pendant le workload MTP. vLLM a aussi averti Add 6 padding layers, may waste at most 27.27% KV cache memory.

Échelle de VRAM

Non essayé : 12 GB (les poids FP8 seuls font 12,18 GiB), la voie GGUF et llama.cpp, le FP8 sur une vraie carte de 24 GB (3090/4090), le BF16 sur une vraie carte de 32 GB, plus de 16K de contexte sur 16 GB, un long prompt qui remplit toute la fenêtre de 131 072, use_mtp=True de transformers, et les benchmarks des auteurs. La qualité en FP8 n'a été vérifiée que sur nos cinq prompts.

Vérifications de qualité

• Quickstart de la fiche (def mean(xs): return sum(xs) / len(xs) - 1) : bug trouvé à chaque essai et à chaque échelon.
• merge_intervals : 13 sorties vérifiées sur 13 ont passé les 4 asserts.
• Maths (n^2+1 divisible par 5, n <= 1000) : 400 à chaque essai.
• Outils : appels valides au format hermes à chaque essai.
• Essais de l'exemple du SDK : A6000 avec MTP, tâche de code de 510 tokens en 4,36 s, 126,1 tok/s, TTFT 0,32 s ; A6000 sans tête, 474 tokens, 109,4 tok/s ; RTX 5080 FP8 MTP 2, 700 tokens en 2,47 s, 303,3 tok/s.

Problèmes restants

1. Accélération sur une seule requête en dessous de la fourchette de la fiche, sur l'A6000 en BF16. 1,11x avec un token proposé, alors que 87,2 % sont acceptés. Hypothèse, non prouvée : le backend de modélisation générique Transformers, plus le Using default MoE config. Performance might be sub-optimal! de vLLM, et une étape de vérification qui coûte presque autant qu'elle fait gagner sur un MoE à 2,5B de paramètres actifs. Deux tokens proposés donnent 1,31x. Ouvert en amont : pas encore d'implémentation native de Mellum dans vLLM.
2. Un seul job à la fois par workload sur le worker (max_in_flight slots=1). Les requêtes parallèles via l'endpoint font la queue, donc les chiffres de concurrence ont été mesurés en direct sur vLLM. Ouvert de notre côté.
3. Sorties greedy non identiques octet pour octet d'un essai à l'autre, avec et sans MTP (MTP : maths 369 contre 810 tokens, table de hachage 940 contre 718 ; sans tête : 380 contre 829, 792 contre 881). Les réponses sont restées justes. Attendu d'après la documentation de vLLM : le décodage spéculatif est sans perte "up to the precision limits of hardware numerics", et la taille de batch peut déplacer les logprobs et les probabilités de sortie.
4. Les appels d'outils ont varié d'un essai à l'autre. Sur l'A6000 en BF16 avec MTP, le modèle a appelé les outils une ville par tour (Lisbonne, puis Oslo) ; sans MTP, il a fait deux appels get_weather en parallèle, tout comme l'essai 3 sur la RTX 5080 (FP8, MTP 2). Les clients ont besoin d'une boucle d'agent. La première version de notre exemple n'autorisait qu'un tour et renvoyait une réponse finale vide. Corrigé : l'exemple boucle jusqu'à 4 tours.
5. La première requête échantillonnée après un redémarrage est lente : Triton compile à la volée _gumbel_sample_kernel et d'autres, 52,4 tok/s puis 105,8. Préchauffez avant de mesurer.
6. Le FP8 en ligne sur Ampere passe par un pic au chargement : 21 917 MiB pendant environ 3 s sous la limite de 16 GB. Une vraie carte Ampere de 16 GB peut échouer au chargement. La RTX 5080 (FP8 natif) ne l'a pas montré.
7. Avertissements de vLLM : padding du KV (may waste at most 27.27% KV cache memory), config MoE par défaut, et max_num_scheduled_tokens is set to 2048 based on the speculative decoding settings.
8. Téléchargements de paquets lents sur la machine de la RTX 5080 : environ 14 de ses 20 minutes jusqu'à prêt.

Vidéo de démo

La démo commentée de 165 secondes : ce qu'est Mellum2.1 (la fiche du modèle, le paragraphe sur le MTP, les benchmarks des auteurs, et une comparaison sur Terminal-Bench 2.1 avec GPT-5.6 Sol et Claude Mythos 5, tirée de la copie que BenchLM fait du classement de Vals (récupérée le 2026-11-08, non revérifiée), avec un harnais différent de celui des auteurs), le déploiement dans le panneau sur la RTX A6000 avec la tête activée (une tâche de code à 128 tokens par seconde, 640 tokens en 5,1 s, et la boucle d'outils, Lisbonne puis Oslo, en 4,9 s), la comparaison clé, sans tête contre MTP, et l'échelle de GPU. Sous-titres en anglais inclus.

Sources

• JetBrains/Mellum2.1-12B-A2.5B-Thinking-MTP (fiche du modèle, config, tête MTP).
• JetBrains/Mellum2.1-12B-A2.5B-Thinking (version de base).
• JetBrains/Mellum2.1-12B-A2.5B-Thinking-GGUF (non testé).
• Documentation de vLLM sur le décodage spéculatif, consultée le 2026-11-13 (redirige vers les pages sur le décodage spéculatif et le MTP).
• Post de pmttyji sur r/LocalLLaMA, 2026-11-02 (là où nous l'avons repéré).
• Exemple du SDK, commit 0a5188e70d0c32c95c9e36a17dcb75078102e48f.