Mistral Small 4 : comment déployer le modèle MoE 119B (benchmark, vLLM, quantification et alternatives)

Mistral AI vient de publier Mistral Small 4, un modèle Mixture-of-Experts (MoE) de 119 milliards de paramètres qui unifie instruction, raisonnement et vision dans un seul poids. Pour les développeurs et les agences qui construisent des produits IA pour leurs clients, ce modèle pose une question très concrète : est-ce le bon choix technique, et comment le mettre en production ?

Ce guide couvre l'architecture en détail, les options de déploiement (vLLM, llama.cpp, NVIDIA NIM), les résultats de benchmark face à GPT-4o-mini, Qwen 3.5-122B et Gemma 3, ainsi que les pièges à éviter.

Architecture MoE de Mistral Small 4 : ce que les développeurs doivent comprendre

128 experts, 4 actifs par token : le profil d'inférence

Mistral Small 4 utilise une architecture MoE sparse avec les caractéristiques suivantes :

• 128 experts dans les couches FFN (feed-forward network)

• 4 experts activés par token lors de l'inférence

• 119B de paramètres totaux, mais seulement ~6,5B actifs par passe avant

• Réduction de calcul d'environ 95 % par rapport à un modèle dense de taille équivalente

Ce design suit la même philosophie que DeepSeek V3 et Mixtral 8x22B : une capacité massive avec un coût d'inférence contenu. La différence clé avec Mixtral 8x22B (qui activait ~39B de paramètres) est que Small 4 est nettement plus efficient par token tout en ayant une capacité totale comparable.

Comparaison architecturale avec les modèles Mistral précédents

Le passage de 24B dense à 119B MoE avec seulement 6,5B actifs est un changement radical. En termes de FLOPS par token, Small 4 est moins cher à inférer que Small 3.2, tout en ayant 5 fois plus de capacité de connaissance.

Raisonnement configurable via reasoning_effort

Le modèle expose un paramètre reasoning_effort qui permet de contrôler le comportement par requête :

from openai import OpenAI client = OpenAI(api_key="EMPTY", base_url="http://localhost:8000/v1") # Mode rapide (pas de chain-of-thought) response = client.chat.completions.create( model="mistralai/Mistral-Small-4-119B-2603", messages=[{"role": "user", "content": "Résume ce document"}], reasoning_effort="none", ) # Mode raisonnement profond response = client.chat.completions.create( model="mistralai/Mistral-Small-4-119B-2603", messages=[{"role": "user", "content": "Analyse ce contrat et identifie les risques"}], reasoning_effort="high", )

Pour une agence, cela signifie pouvoir construire un produit client avec un seul modèle derrière, en routant intelligemment les requêtes simples vers le mode rapide et les tâches complexes vers le mode raisonnement.

Spécifications techniques de Mistral Small 4

Benchmark Mistral Small 4 : résultats face à GPT-4o-mini, Qwen 3.5-122B et Phi-4

Scores sur les benchmarks standards

Sur GPQA Diamond, le modèle affiche un score de 71,2 %, soit +31 points par rapport à GPT-4o-mini. Sur MMLU-Pro, l'écart est de +13 points. Ces benchmarks mesurent le raisonnement scientifique et la compréhension approfondie, deux domaines où l'architecture MoE avec raisonnement configurable fait la différence.

Efficience des sorties : moins de tokens, même qualité

C'est un point souvent négligé dans les comparatifs, mais critique pour les coûts en production :

Des sorties plus courtes à qualité égale signifient moins de tokens facturés, moins de latence, et un débit supérieur. Pour une agence facturant des projets IA, cette efficience se traduit directement en marge.

Tableau comparatif complet

Gains de performance par rapport à Mistral Small 3

Ces gains sont directement liés à l'architecture MoE : 6,5B de paramètres actifs contre 24B pour Small 3, soit environ 3,7 fois moins de calcul par token. Malgré un modèle 5 fois plus lourd en poids totaux, chaque passe avant est plus rapide à calculer une fois le modèle chargé en mémoire.

Mistral fournit aussi un modèle eagle head (Mistral-Small-4-119B-2603-eagle) pour le décodage spéculatif, permettant de réduire encore la latence de génération.

Comment déployer Mistral Small 4 : guide technique étape par étape

Option 1 : vLLM (recommandé pour la production)

Mistral a publié une image Docker dédiée avec des correctifs pour le tool calling et le parsing du raisonnement (ces correctifs seront mergés dans vLLM main sous 1 à 2 semaines) :

# Image Docker Mistral docker pull mistralllm/vllm-ms4:latest docker run -it mistralllm/vllm-ms4:latest

Installation manuelle depuis le fork Mistral :

git clone --branch fix_mistral_parsing https://github.com/juliendenize/vllm.git VLLM_USE_PRECOMPILED=1 pip install --editable . uv pip install git+https://github.com/huggingface/transformers.git # Vérifier mistral_common >= 1.10.0 python -c "import mistral_common; print(mistral_common.__version__)"

Commande de lancement :

vllm serve mistralai/Mistral-Small-4-119B-2603 \ --max-model-len 262144 \ --tensor-parallel-size 2 \ --attention-backend FLASH_ATTN_MLA \ --tool-call-parser mistral \ --enable-auto-tool-choice \ --reasoning-parser mistral \ --max_num_batched_tokens 16384 \ --max_num_seqs 128 \ --gpu_memory_utilization 0.8

Le serveur vLLM expose ensuite une API compatible OpenAI sur localhost:8000.

Option 2 : NVIDIA NIM (cloud ou on-prem)

Disponible dès le lancement sur build.nvidia.com, avec prototypage gratuit. Pour la production, les conteneurs NIM s'intègrent dans votre infrastructure existante. Le checkpoint NVFP4 est optimisé pour les GPU NVIDIA H100/H200/B200 et offre le meilleur ratio performance/mémoire.

Option 3 : llama.cpp et Ollama (en cours)

Au moment du lancement, le support llama.cpp est en développement via le PR #20649 dans le dépôt officiel. Une fois mergé, des quantifications GGUF communautaires (bartowski, unsloth) suivront.

# Une fois le support GGUF disponible : ./llama-cli -hf mistralai/Mistral-Small-4-119B-2603-GGUF:Q4_K_M --jinja

Le support Ollama dépend de la stabilité du support llama.cpp. Pour le moment, mistral-small sur Ollama pointe vers les versions 3.x.

Option 4 : SGLang

SGLang a annoncé un support day-0 via @lmsysorg. C'est une alternative crédible à vLLM pour les charges de travail à haute concurrence.

Option 5 : HuggingFace Transformers

Pour le prototypage uniquement. Les poids FP8 nécessitent une conversion manuelle en BF16. Le code de référence utilise Mistral3ForConditionalGeneration.

from transformers import AutoProcessor, Mistral3ForConditionalGeneration # Voir le snippet complet sur le model card HuggingFace

Quantification : options disponibles et impact mémoire

Le checkpoint NVFP4 est la voie recommandée pour les déploiements NVIDIA. Pour les setups Apple Silicon (M3 Max 128 Go de RAM unifiée), les quantifications GGUF Q4_K_M seront l'option de choix une fois disponibles.

Infrastructure requise pour l'auto-hébergement

Tensor parallelism : la configuration de référence vLLM utilise --tensor-parallel-size 2 pour les setups à 2 GPU. Les tailles TP plus grandes sont supportées pour les configurations multi-GPU.

Cas Apple Silicon : en full BF16, le modèle nécessite ~238 Go de RAM. Avec une quantification 4-bit, cela descend à ~60 à 75 Go, ce qui rend le modèle exploitable sur un M3 Max avec 128 Go de mémoire unifiée.

Quand choisir Mistral Small 4 plutôt que GPT-4o-mini ou Qwen 3.5

Choisir Mistral Small 4 si :

• Vous avez besoin de raisonnement configurable : GPT-4o-mini n'offre pas de mode raisonnement. Avec Small 4, vous pouvez alterner entre mode rapide et mode profond sans changer de modèle.

• Vous voulez un modèle auto-hébergeable sous Apache 2.0 : GPT-4o-mini est propriétaire et uniquement accessible via API. Small 4 peut tourner sur votre infrastructure sans aucune donnée envoyée à l'extérieur.

• Vous construisez des agents multi-outils : le function calling natif hérité de Devstral, combiné au raisonnement et à la vision, en fait un choix solide pour les workflows agentiques complexes.

• Le contexte long est critique : 256K tokens, soit le double de GPT-4o-mini (128K). Idéal pour l'analyse de bases de code, de documents juridiques, ou de rapports techniques.

Préférer GPT-4o-mini si :

• Vous n'avez pas besoin d'auto-hébergement et la simplicité de l'API OpenAI est prioritaire

• Votre volume de requêtes est faible et le coût d'infrastructure d'un déploiement multi-GPU n'est pas justifié

• Vous avez besoin de modèles stables et documentés avec un écosystème d'outils tiers mature

Préférer Qwen 3.5-122B si :

• Vous avez besoin d'un contexte très long (262K) comparable à Mistral Small 4 avec un écosystème MoE alternatif

• Vos cas d'usage ciblent principalement l'Asie (Qwen excelle sur les benchmarks chinois et asiatiques)

• Attention : Qwen génère des sorties significativement plus longues, ce qui augmente les coûts en production

Limites techniques à anticiper

1. Infrastructure lourde : 119B de paramètres totaux nécessitent au minimum 4x H100. Ce n'est pas déployable sur un RTX 4090 (24 Go de VRAM), même avec quantification. La communauté r/LocalLLaMA a souligné ce point comme la principale frustration.

1. Support llama.cpp incomplet au lancement : le PR #20649 est ouvert mais non mergé. Pas de GGUF officiel, pas de support Ollama fonctionnel pour le moment.

1. vLLM : correctifs non mergés dans main : il faut utiliser l'image Docker Mistral ou le fork dédié pour le tool calling et le reasoning parser. Les correctifs devraient être intégrés dans les 1 à 2 semaines suivant le lancement.

1. Transformers : workaround FP8 nécessaire : les poids FP8 (F8_E4M3) ne sont pas nativement supportés par HuggingFace Transformers. Une conversion manuelle en BF16 est requise.

1. Pas de variante légère : contrairement à la famille Small 3 (Ministral 3B/8B/14B), il n'y a pas de modèle compagnon léger pour le déploiement sur GPU unique ou edge.

1. Tarification API non publiée : les prix sur l'API Mistral ne sont pas encore disponibles. Anticipez une fourchette entre Small 3.1 (~0,10 $/1M tokens input) et Medium 3.1 (~0,40 $/1M tokens input).

1. Données d'entraînement non documentées : aucune information sur le dataset d'entraînement n'a été divulguée.

Pour une agence : intégrer Mistral Small 4 dans vos projets clients

Mistral Small 4 est un modèle particulièrement adapté aux agences et studios de développement IA pour plusieurs raisons :

• Un seul modèle à maîtriser et maintenir au lieu de trois spécialisés, ce qui simplifie la formation de vos équipes et la maintenance des projets

• Licence Apache 2.0 : vous pouvez le déployer chez vos clients sans frais de licence et créer des produits dérivés

• Raisonnement configurable par requête : vous pouvez concevoir des workflows où la complexité de l'IA s'adapte automatiquement à la difficulté de la tâche, optimisant les coûts pour vos clients

• Fine-tuning possible via Axolotl : vous pouvez créer des versions spécialisées pour les verticales de vos clients (juridique, santé, finance)

Le modèle est disponible dès maintenant sur Hugging Face, via l'API Mistral et sur NVIDIA NIM.