Auto-héberger Mistral Large 4 : les leçons à la dure

Quand Mistral a publié les poids de Mistral Large 4, un modèle d'environ 1 000 milliards de paramètres dont environ 52 milliards actifs, ma boîte mail s'est remplie de la même question : peut-on le faire tourner nous-mêmes ? L'auto-hébergement de poids ouverts n'est plus un fantasme de bidouilleur, c'est une vraie option d'architecture, et ça veut dire que beaucoup d'équipes vont bientôt faire de coûteuses erreurs. J'en ai déjà vu plusieurs. Ce article fait le bilan de ces leçons : les façons précises dont les praticiens se trompent, et ce que serait la bonne solution à chaque fois.

Erreur n° 1 : lire « poids ouverts » comme « utilisable librement, comme bon vous semble »

La première erreur survient avant même de toucher à un GPU. Mistral Large 4 est distribué sous une licence de type MIT modifiée, avec une exception notable : si vous ou vos affiliés exploitez une activité de modèle en tant que service, vous devez obtenir une licence commerciale distincte auprès de Mistral avant de l'utiliser commercialement. Pour une entreprise qui fait tourner l'inférence en interne, par exemple pour résumer des documents ou alimenter un assistant de code pour ses salariés, c'est probablement acceptable. Pour une startup qui compte revendre de l'inférence, c'est un arrêt net tant qu'elle n'a pas écrit à Mistral.

Les praticiens se trompent dans les deux sens. Certaines équipes voient le mot « ouvert » dans un communiqué de presse, construisent un produit commercial sur les poids, et découvrent la restriction pendant un audit de due diligence pour une levée de fonds, le pire moment possible. D'autres font l'excès inverse et supposent que la licence interdit tout usage commercial, alors qu'elle vise en réalité les fournisseurs d'inférence concurrents. La solution est ennuyeuse mais indispensable : faites lire le texte réel de la licence par vos juristes, pas l'annonce. Que l'on parle de « poids ouverts » ou de « poids disponibles », une distinction sur laquelle la communauté s'écharpe bruyamment, et pas à tort, la décision d'ingénierie doit reposer sur ce que les conditions permettent réellement à votre activité de faire.

Autre subtilité : ce type de licence est désormais la norme pour les grandes publications de poids, et non plus l'exception. Si votre architecture repose sur l'alternance entre Mistral, Qwen et d'autres modèles à poids ouverts de pointe, il vous faut une matrice de licences, pas une relecture ponctuelle. Créez ce tableur avant de monter le cluster.

Erreur n° 2 : dimensionner le matériel d'après la page marketing plutôt que d'après le calcul

Voici l'erreur qui coûte le plus cher. Un ingénieur lit « 1T paramètres », jette un œil aux quatre H200 dans la salle serveur de l'entreprise, et se dit que 540 Go de VRAM, ça doit suffire. Ce n'est pas le cas, et la raison tient à un calcul qui prend quatre-vingt-dix secondes et qui vous évite un trimestre de honte.

En précision BF16, un trillion de paramètres nécessite environ 2 To de mémoire rien que pour les poids. Quantifiez en 8 bits et vous tombez près de 1 To. En 4 bits, on arrive autour de 500 à 560 Go, avant d'ajouter le KV cache, les activations et le surcoût de service. Ce serveur de 540 Go ne peut accueillir un modèle en 4 bits que si vous acceptez une fenêtre de contexte courte et quelques utilisateurs simultanés. L'architecture mixture-of-experts (52 milliards de paramètres actifs par token) réduit le calcul par token, mais ne change rien à la mémoire : les mille milliards de paramètres doivent toujours résider quelque part et être adressables. Dans un MoE, les poids des experts sont sollicités de façon imprévisible, donc les déporter en RAM CPU détruit la latence, ce qui n'est pas le cas pour les modèles denses.

La solution consiste à partir de vos besoins de service et à remonter vers le matériel, et non l'inverse. Définissez d'abord la longueur de contexte cible, la concurrence et le nombre de tokens par seconde, puis déduisez le niveau de quantification que vous pouvez vous permettre, et enfin le matériel. Si le résultat est huit H200 ou une paire de nœuds de classe NVL72, et que ce chiffre vous fait grimacer, tant mieux : la grimace prouve que le modèle fait son travail. Nous avons déjà abordé le problème voisin dans ce qu'il faut faire quand votre GPU manque de VRAM, et les options présentées (déport, quantifications plus légères, modèles plus petits) s'appliquent ici aussi, à l'échelle du datacenter.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Remarquez que la version honnête de ce tableau inclut le KV cache et le surcoût. La version malhonnête, qui ne compte que les poids, est celle qui aboutit à un modèle qui se charge sans problème mais ne peut servir plus de trois utilisateurs.

Erreur n° 3 : considérer la quantification comme un repas gratuit

Une fois que les équipes acceptent de devoir quantifier, l'erreur suivante consiste à croire que le 4 bits est « fondamentalement le même modèle ». Parfois, c'est vrai. Souvent, non, et les modes de défaillance sont justement ceux qui vous importent le plus.

Le schéma que j'ai vu se répéter : une équipe évalue son déploiement 4 bits sur un QCM de type MMLU, constate une baisse de 1 %, et met en production. Puis les utilisateurs signalent que les longs refactorings multi-fichiers partent en vrille, ou que les JSON des appels d'outils sont légèrement malformés, avec une probabilité faible mais une fréquence élevée. Une quantification agressive dégrade de façon disproportionnée les tâches à long horizon, structurées ou à basse température, précisément celles des workloads agentiques et de code qui justifient un modèle de pointe. La moyenne bouge à peine ; c'est la queue de distribution qui s'effondre.

La solution est de quantifier jusqu'à la limite que tolère votre évaluation sur tâche, et non jusqu'à celle que vous impose votre VRAM. Passez les prompts de votre propre workload sur des builds FP8, 4 bits et 3 bits, puis comparez. Si le 3 bits passe vos évaluations, bravo, votre facture matérielle vient de diviser par deux. S'il échoue, aucune moyenne de benchmark ne vous sauvera. Et privilégiez les versions quantifiées natives lorsque le laboratoire les publie : Mistral a livré une variante NVFP4 à côté des poids BF16, et une quantification de première main avec des écarts de qualité mesurés vaut mieux qu'une conversion GPTQ communautaire validée en un après-midi.

Un niveau de quantification est un budget de qualité, pas un réglage de compression. Dépensez-le là où votre workload peut encaisser la perte.

Erreur n° 4 : comparer le prix de l'API au prix du GPU et appeler ça une analyse de TCO

Le tableur classique : « l'API coûte 2,10 $ par million de tokens de sortie, un nœud GPU réservé coûte X $ par heure, donc l'auto-hébergement se rentabilise à partir de Y tokens par mois. » Ce tableur est presque toujours faux, et il se trompe dans le sens coûteux.

Ce qu'il oublie : le taux d'utilisation. Une API vous offre 100 % de l'utilisation de la capacité de quelqu'un d'autre, facturée au token. Votre cluster auto-hébergé vous offre le taux d'utilisation que votre trafic permet, et la plupart des workloads internes sont irréguliers : chargés en journée, inactifs la nuit, en pics autour des mises en production. Un cluster dimensionné pour le pic reste à moitié vide la plupart du temps. Ajoutez ensuite les coûts qui n'apparaissent jamais dans le tableur : une astreinte pour une stack de service qui inclut désormais les mises à jour de vLLM, les incompatibilités de pilotes CUDA et l'alerte de 2 h du matin quand le KV cache se fragmente ; la rotation permanente liée aux nouvelles versions de poids (faut-il revalider chaque publication ? votre suite d'évaluation répond oui) ; et le coût d'opportunité de l'ingénieur ML qui devient gardien de GPU au lieu de construire le produit.

Il existe aussi un problème de cible mouvante que personne ne chiffre. Mistral a baissé le prix de l'API de ce modèle de près de moitié entre la préversion et la version finale : les tokens en entrée sont passés de 1,36 $ à 0,70 $ par million. Tous les calculs de ROI d'auto-hébergement faits sur l'ancien prix sont désormais de la fiction. L'inférence de pointe devient moins chère à un rythme trimestriel, alors que votre matériel s'amortit sur plusieurs années. Cette asymétrie est le tueur silencieux des business cases d'auto-hébergement.

La solution : n'auto-hébergez que pour des raisons que l'API ne peut structurellement pas offrir. Ces raisons existent et sont réelles, mais « moins cher à grande échelle » en fait rarement partie, du moins aux échelles où opère la plupart des entreprises.

Quand l'auto-hébergement gagne vraiment

Alors, quand faire tourner des poids de classe Mistral en local bat-il l'API ? Après avoir vu des équipes réussir et échouer, les cas gagnants se regroupent en quatre catégories :

• Résidence et souveraineté des données. Secteurs réglementés, travaux liés à la défense et organisations européennes soumises à des exigences juridictionnelles strictes. Une contrainte vue sur le terrain : une entreprise interdite d'utiliser des modèles d'origine chinoise pour des raisons de conformité. Des poids ouverts issus d'un laboratoire européen, à la provenance auditable, ont résolu un problème qu'aucun contrat d'API ne pouvait régler.
• Environnements isolés ou à connectivité intermittente. Si le réseau ne peut pas être considéré comme fiable, les poids locaux constituent toute l'architecture. Nous avons exploré ce schéma dans la construction d'un LLM qui fonctionne hors ligne.
• Charges de travail soutenues, prévisibles et à fort volume. Le traitement par lots de documents, 24 h sur 24 à débit constant, peut réellement battre la tarification au token, car il règle le problème du taux d'utilisation par construction.
• Fine-tuning et modification. Vous ne pouvez pas affiner le modèle d'une API au-delà de ce que son endpoint de fine-tuning autorise. Posséder les poids, c'est posséder la boucle d'entraînement : pré-entraînement continu sur des corpus métier, alignement sur mesure, distillation vers des déploiements plus petits.

Remarquez ce qui ne figure pas dans la liste : la latence. Auto-héberger un MoE d'un trillion de paramètres ne vous donne pas une latence plus basse qu'une API bien dimensionnée, sauf si vous êtes prêts à investir lourdement dans le décodage spéculatif et un service optimisé pour le batch de taille 1. Et remarquez aussi ce qui manque : « éviter la dépendance à un fournisseur ». Les poids que vous téléchargez aujourd'hui seront deux générations en retard dans un an, et vous reviendrez au même point de décision. C'est d'ailleurs un bon argument en faveur de l'instinct d'archivage de certains praticiens, qui gardent des copies locales des grandes versions de poids. Le stockage est bon marché ; les options, elles, ont de la valeur.

La façon honnête de voir les choses : poids ouverts et API sont complémentaires, pas concurrents. Plusieurs équipes que je connais font de l'hybride : l'API pour le trafic interactif irrégulier, les poids locaux pour la tranche réglementée ou orientée batch. Les compétences se transfèrent : votre configuration vLLM, votre harnais d'évaluation et vos modèles de prompts fonctionnent dans les deux mondes. Si vous voulez les fondamentaux opérationnels avant de vous engager à l'échelle de la pointe, notre guide sur l'exécution de grands modèles de langage sur votre propre matériel couvre toute la stack de service, de bout en bout.

Erreur n° 5 : évaluer avec des benchmarks plutôt qu'avec votre workload

La dernière erreur est celle qui annule toutes les autres. Une équipe fait tout correctement : licence relue, matériel dimensionné, quantification testée sur des benchmarks publics. Puis elle livre un modèle que les utilisateurs détestent, parce que les évaluations n'ont jamais mesuré ce que les utilisateurs font réellement.

Les benchmarks publics répondent à la question « ce modèle est-il globalement capable ? ». Ils ne répondent pas à « ce modèle classe-t-il nos tickets support avec le ton et le format qu'il nous faut, en 4 bits, sous notre charge de concurrence ? ». Nous avons déjà expliqué pourquoi les benchmarks d'IA passent à côté de 90 % du travail réel, et l'auto-hébergement rend l'écart plus net, pas moins : vous devenez responsable de toutes les variables que le fournisseur d'API gérait pour vous. La stack de déploiement, les réglages du sampler, les conventions de prompt système avec lesquelles le modèle a été entraîné, tout cela devient votre responsabilité, et tout cela peut mal tourner.

La solution consiste à construire une évaluation en trois couches avant de vous engager sur le matériel :

1. Un jeu de référence issu de la production. Quelques centaines de vrais prompts avec des sorties idéales relues, couvrant la distribution réelle de vos tâches, y compris les cas longs, désordonnés et multi-tours.
2. Un harnais de non-régression. Chaque candidat (API ou local, FP8 ou 4 bits, anciens ou nouveaux poids) passe automatiquement le jeu de référence. Notez avec un modèle juge solide, complété par une relecture humaine ponctuelle ; ne faites pas confiance aveuglément au juge sur les sorties structurées.
3. Une période d'ombre. Faites tourner le déploiement local en parallèle de l'API sur du trafic réel pendant deux semaines, en comparant les sorties et en mesurant la latence réelle sous charge réelle. C'est là que ressortent les erreurs de dimensionnement du KV cache et les échecs de la queue de distribution liés à la quantification.

Ce harnais se rentabilise dès la première sortie d'une nouvelle version de poids, car vous pouvez répondre à « faut-il mettre à jour ? » avec des données en un après-midi, au lieu de sentiments en réunion.

La vraie leçon : les poids ouverts ont changé la question, pas la réponse

Il y a un an, « faut-il auto-héberger un modèle de pointe ? » était une question hypothétique : la pointe n'était pas téléchargeable. Mistral Large 4, avec la vague des autres publications à un trillion de paramètres, en a fait une décision réelle, avec de l'argent réel à la clé. Mais le cadre de décision n'a pas changé ; il est simplement devenu incontournable.

Auto-hébergez quand la souveraineté, la connectivité, le volume soutenu ou le besoin de modifier le modèle l'exigent. Payez l'API quand votre trafic est irrégulier, que votre équipe est petite et que votre avantage concurrentiel est le produit plutôt que la stack d'inférence. Et quel que soit votre choix, faites le calcul mémoire de quatre-vingt-dix secondes, lisez la licence et construisez le harnais d'évaluation avant de signer quoi que ce soit. Les poids sont ouverts désormais. Les erreurs, malheureusement, aussi.