Mistral Large 4 face à GPT-6 Astra : le duel des GPU et du prix du jeton

Deux logos croisent le fer, mais les armes ne sont pas de même taille. Mistral annonce un modèle entraîné sur 3 800 GPU ; OpenAI évoque un entraînement dépassant 100 000 GPU pour Astra. Ce face-à-face raconte deux façons de construire l’IA. Il révèle aussi ce que les centres de données devront vendre demain : du calcul disponible, une maîtrise de l’exploitation et un coût d’usage soutenable.

La tentation est forte d’y voir un David européen face à un Goliath américain. La comparaison mérite mieux. Le nombre de puces renseigne sur l’échelle industrielle ; il ne mesure, à lui seul, ni la qualité d’un modèle ni la rentabilité d’un service. Et le prix du jeton, cette unité de texte traitée par l’IA, peut compter davantage que le classement général pour un utilisateur professionnel.

Ce qu’il faut retenir

• Les chiffres publiés décrivent des grappes d’entraînement. Leur rapport dépasse 26, mais ce n’est pas un rapport de consommation électrique, de coût ou de performance.
• Mistral promet les poids du modèle fin octobre. L’accès par API est déjà proposé ; les conditions de licence restent à examiner lors de la publication des poids.
• L’écart tarifaire est substantiel. La fiche de Mistral affiche aussi une promotion, à distinguer du tarif de référence.
• Pour les datacenters européens, l’opportunité se joue autant dans l’inférence, lorsque le modèle répond aux utilisateurs, que dans les grands entraînements.

3 800 contre 100 000 : ce que les chiffres disent vraiment

Dans son annonce du 6 octobre, Mistral situe l’entraînement de ML4 dans ses propres centres de données européens, sur 3 800 GPU NVIDIA Grace Blackwell. Sa documentation technique précise 1 050 milliards de paramètres au total, dont 52 milliards actifs.

De son côté, Greg Brockman décrit dans son entretien à Stratechery le premier entraînement d’OpenAI mobilisant plus de 100 000 GPU. L’architecture d’Astra n’y est pas détaillée. Le rapprochement porte donc sur le nombre d’accélérateurs mobilisés, pas sur une quantité totale de calcul publiée pour les deux modèles.

Pourquoi la prudence ? Le calcul total dépend de la durée du run, de l’utilisation effective des puces et des opérations exécutées. Deux grappes de tailles différentes peuvent tourner pendant des périodes différentes. Sans ces données, écrire « 26 fois moins d’énergie » ou « 26 fois plus efficace » transformerait un rapport arithmétique en promesse non démontrée.

Un classement ne départage pas tous les usages

Mistral publie notamment 61,7 % sur DeepSWE et 28,3 % sur Terminal-Bench 4. L’éditeur rapporte aussi un léger avantage de ML4 sur Astra pour l’ancrage visuel Dense200 : 42 % contre 41 %. Ces résultats figurent dans son billet de lancement. Ils portent sur un aperçu dont le post-entraînement continue.

Un point d’écart ne suffit pas à annoncer une supériorité générale. Les outils disponibles, les budgets de raisonnement et les protocoles influencent les résultats. Un modèle utile pour lire des plans techniques peut rester moins adapté à une mission autonome longue. Les évaluations des éditeurs donnent des pistes ; un test sur les documents et les tâches du client doit décider.

L’indicateur économique pertinent devient alors le coût d’une tâche correctement terminée. Un modèle moins cher perd son avantage s’il exige trois reprises et une vérification lourde. Un modèle plus coûteux peut le justifier s’il évite ces reprises. Cette logique favorise des systèmes qui choisissent le modèle selon la difficulté, plutôt qu’un abonnement systématique au plus puissant.

Des GPU aux mégawatts : une différence d’échelle, pas un relevé de compteur

Une baie n’est pas un GPU. NVIDIA décrit le GB200 NVL72 comme un système réunissant 72 GPU et 36 CPU Grace, refroidi par liquide. Son document de conception pour l’Open Compute Project évoque une capacité de refroidissement de 120 kW par baie.

Prenons ce chiffre comme hypothèse illustrative de dimensionnement thermique, et non comme une mesure des installations des deux entreprises. À 72 GPU par baie, 3 800 accélérateurs correspondent à environ 53 baies ; 100 000 à environ 1 389. En appliquant 120 kW, on obtient quelque 6,4 MW et 166,7 MW de charge thermique théorique à évacuer.

Ce calcul ne reconstitue ni les équipements effectivement installés ni leur fonctionnement. Il exclut notamment les infrastructures auxiliaires et ne fournit pas la puissance totale du site. Il rend seulement visible le changement d’échelle : les besoins de raccordement, les circuits de refroidissement et la coordination du réseau informatique ne se traitent pas de la même manière.

Pour un exploitant, la question pratique est précise : combien de baies à haute densité peut-il accueillir réellement ? Une réserve de puissance sur le papier n’assure pas des distributions électriques adaptées, des boucles liquides utilisables et une capacité d’évacuation de chaleur disponible au même moment.

L’inférence ouvre une autre carte pour l’Europe

Entraîner un modèle et le faire fonctionner sont deux activités distinctes. L’entraînement rassemble de nombreux accélérateurs pour produire les poids ; l’inférence utilise ces poids pour répondre aux requêtes. Cette seconde activité peut rapprocher le calcul des utilisateurs, selon leurs exigences de latence, de confidentialité et de disponibilité.

Des poids accessibles peuvent permettre à une entreprise d’exploiter le modèle sur une infrastructure choisie. Cela ouvre une possibilité pour les clouds privés et la colocation européenne. Ce n’est pas encore une demande locative signée. Il faut attendre les conditions de licence, mesurer les besoins matériels et vérifier qu’un volume de requêtes justifie l’investissement.

L’auto-hébergement ne supprime pas la facture. Il déplace les postes de coût : machines, énergie, personnel, maintenance et renouvellement. Une capacité peu utilisée peut coûter davantage qu’une API. À l’inverse, des traitements réguliers, avec des contraintes fortes sur les données, peuvent rendre une exploitation propre intéressante.

Notre lecture pour les investisseurs est donc sélective. Un site capable de livrer rapidement une salle à forte densité peut trouver sa place sans reproduire un campus géant. Sa valeur dépendra des usages contractés et des caractéristiques livrables, pas du seul récit de la souveraineté. Le dossier du Guide consacré à cette notion détaille les contrôles à distinguer.

La cybersécurité montre que le service compte autant que le modèle

Mistral défend la possibilité d’exécuter des travaux de sécurité sous les politiques de l’organisation. OpenAI classe Astra au seuil « critique » de son cadre de préparation en cybersécurité et prévoit un accès encadré aux capacités les plus avancées. Cette catégorie qualifie des capacités et les protections qu’elles nécessitent ; elle ne signifie pas qu’Astra serait un produit défaillant.

Deux modèles capables peuvent ainsi répondre différemment à une même demande parce que leurs règles d’accès diffèrent. Un refus n’est pas toujours une incapacité technique. Pour une direction informatique, le contrat, la continuité d’accès et les conditions d’exploitation font donc partie de la comparaison. Les poids ouverts donnent davantage de latitude, avec davantage de responsabilités opérationnelles.

Le prix du jeton change déjà la comparaison

La fiche Mistral consultée le 8 octobre affiche 1,36 dollar en entrée et 4,18 dollars en sortie par million de jetons, barrés au profit de prix promotionnels de 0,68 et 2,09 dollars. La grille officielle OpenAI donne 10 et 50 dollars pour Astra en traitement Standard et contexte court. Cache, contexte long et modes de traitement peuvent modifier la facture.

Au tarif de référence, l’écart de cette simulation atteint environ neuf fois. Mais personne ne doit en déduire qu’un abonnement de 20 dollars remplace un budget API de 200 dollars : les produits, les quotas et les services inclus diffèrent.

L’abonnement se rapproche de l’usage, sans devenir une API

Dans son annonce d’Astra, OpenAI prévoit l’usage dans les quotas existants des abonnements et l’achat de crédits supplémentaires. Cette combinaison explique la convergence : un prix mensuel ouvre l’accès au produit, tandis que les usages intensifs peuvent faire apparaître une consommation facturée en supplément.

La convergence reste partielle. Une interface prête à l’emploi apporte des outils et du confort ; une API permet d’intégrer le modèle à un processus et de suivre la dépense. Pour des agents qui relisent des documents, utilisent des outils et poursuivent une tâche pendant longtemps, le nombre de messages devient un repère médiocre. Le budget doit porter sur le travail réalisé.

Le duel entre Mistral et OpenAI ne se termine donc pas sur un score. Il se poursuit dans les salles techniques et dans les comptes d’exploitation. Quel modèle termine la tâche, à quel coût, sur quelle infrastructure et avec quel contrôle ? Les utilisateurs doivent répondre à ces questions. Les datacenters qui sauront fournir une réponse vérifiable auront une proposition commerciale plus solide qu’une simple promesse de mégawatts.