SkyRL a fait gagner onze points au score AIME de Mistral Large 4 sur huit nœuds : ce que le RL Day-0 sur un MoE 1T prouve

Mistral Large 4 a été annoncé en tant qu’aperçu API le 6 octobre 2026, et ses poids n’ont été rendus téléchargeables qu’à 14 h 51 UTC le 29 octobre — ce qui rend le rapport sur l’apprentissage par renforcement publié le même jour remarquable pour une raison sur laquelle ses auteurs ne s’étendent pas : avant cet après-midi-là, personne en dehors de Mistral n’avait de résultat de fine-tuning à publier. La note provient de l’équipe SkyRL de NovaSky. Huit nœuds NVIDIA GB200, apprentissage par renforcement LoRA sur le checkpoint NVFP4, vLLM assurant le service des rollouts, et AIME 2024 average@8 passant d’environ 64 % à environ 75 % sur 75 étapes d’entraînement. Onze points sur un benchmark habituellement départagé au dixième près constituent soit le résultat jour zéro le plus utile du trimestre, soit le moins reproductible, et la note telle qu’elle est rédigée ne vous dit pas lequel.

Ce qu’elle vous apprend est réel, et il vaut la peine de le distinguer de ce qu’elle ne vous apprend pas. Le matériel est nommé. Le checkpoint est nommé. Le moteur de rollout est nommé. Le framework d’entraînement est nommé comme l’un des deux. Ce qui manque, c’est la fonction de récompense, le rang de l’adaptateur, le harnais d’évaluation et toute courbe d’apprentissage — les quatre éléments dont une autre équipe aurait besoin pour tenter la même exécution. Il s’agit donc d’une annonce de recette accompagnée d’un chiffre phare, et non d’un kit de reproduction. Lisez-la comme la première et elle est vraiment instructive sur ce que coûte le post-entraînement d’un mélange d’experts à un billion de paramètres à la fin de 2026. Lisez-la comme la seconde et vous surestimerez un seul benchmark sur une seule tâche.

Ce que la note SkyRL dit réellement

L’affirmation entière tient en cinq lignes, la voici donc sans mise en contexte :

• Matériel — 8 nœuds NVIDIA GB200, loués plutôt que possédés, ce qui, à raison de quatre GPU par nœud, représente 32 puces Blackwell et environ 6,1 To de mémoire HBM agrégée, à 192 Go par GPU.

• Checkpoint — l'homologue quantifié NVFP4 de la version ouverte, 610,1 Go répartis sur 32 fragments, et non le parent FP8 de 1 060,6 Go. Ce choix est déterminant : c'est ce qui permet à un modèle 1T de tenir sur huit nœuds en gardant de la place pour les activations, le cache KV et deux copies des poids du moteur de rollout.

• Méthode — LoRA plutôt que l’RL à paramètres complets. Seuls les adaptateurs reçoivent des gradients, donc l’état de l’optimiseur reste petit et la base gelée peut rester sous sa forme quantifiée.

• Boucle — vLLM génère les rollouts ; FSDP2 ou Megatron gère la partie entraînement. La note propose l'un ou l'autre, ce qui indique que le backend d'entraînement était encore en cours de remplacement au moment de la rédaction du résultat.

• Résultat — AIME 2024 average@8 passe d’environ 64 % à environ 75 % en 75 étapes d’entraînement.

Rien dans cette liste ne constitue une spécification de l’exécution. Il n’y a ni taille de lot, ni longueur de séquence, ni taux d’apprentissage, ni taille de groupe pour le gradient de politique, ni indication de ce qu’était la récompense au-delà de l’implicite « les réponses AIME sont vérifiables ». Le chiffre de 75 étapes est précis ; presque tout ce qui serait nécessaire pour l’interpréter ne l’est pas.

Pourquoi le nombre de nœuds fait les gros titres, et non le score AIME

Un billion de paramètres est un nombre qui sert surtout de dissuasif. Le checkpoint FP8 fait 1,06 To : parfait si vous disposez d'un datacenter, problématique si vous n'avez qu'une baie. Le checkpoint NVFP4 divise ce chiffre par deux, à 610 Go, et 610 Go est une quantité que l'on peut répartir sur huit nœuds sans recourir à des astuces de sharding qui coûtent plus en communication qu'elles n'économisent de mémoire.

C’est pourquoi la phrase intéressante de la note n’est pas celle qui contient le pourcentage. Hugging Face avait déjà publié une recette de fine-tuning supervisé pour ce modèle — LoRA via l’entraîneur SFT de TRL, sur un seul nœud de huit GPU B300, sur la base des poids FP8. Le SFT sur un seul nœud était donc documenté avant même que les poids n’aient un jour d’existence. Ce qui n’était pas documenté, c’était l’apprentissage par renforcement, et la raison est structurelle : RL a besoin d’un moteur d’inférence tournant aux côtés de l’entraîneur, générant des rollouts assez rapidement pour que le temps GPU consacré à l’entraînement ne soit pas éclipsé par le temps GPU consacré à l’échantillonnage. Le SFT lit un jeu de données fixe. RL doit produire le sien.

Donc l’écart entre les deux recettes publiées n’est pas de huit nœuds contre un. Il est de huit nœuds plus une pile de service contre un seul nœud sans pile de service, pour une tâche où le modèle doit tenter trente problèmes huit fois chacun avant d’apprendre quoi que ce soit. Le moteur de rollout est le nouveau centre de coûts, et le fait de nommer vLLM comme générateur est la partie de la note sur laquelle les autres équipes peuvent agir dès aujourd’hui.

La comparaison que tout le monde fera, et pourquoi elle est injuste dans les deux sens

Mistral a mené son propre RL sur ce modèle avant de livrer les poids, et l’entreprise a précisé ses contours : environ trois semaines de plus après la preview du 6 octobre, mené sur des capacités de calcul françaises que l’entreprise décrit en mégawatts plutôt qu’en GPU — environ 10 MW — d’autres reportages situant l’infrastructure RL dans son ensemble à l’échelle des 3 000 GPU. Les résultats qu’elle a publiés de cette exécution :

• Terminal-Bench 4.0 — 28,3 % avant le RL supplémentaire, 41 % après.

• BrowseComp — 75 % avant, 84,5 % après.

• Suite de sécurité des agents B3 — 93,3 % avant, 97,1 % après.

• Longueur de sortie — environ 30 % de jetons en moins par tâche après le RL, ce qui compte davantage pour un acheteur que n’importe laquelle des lignes de précision.

Mettez cela en regard de 64 à 75 sur AIME, et la tentation est de calculer un ratio d’heures GPU par point. Résistez-y, car les deux exécutions ne partagent presque aucune variable. Le gain de Mistral porte sur le travail agentique en terminal et la navigation, mesuré par un fournisseur ayant conçu la récompense en interne et avec trois semaines de temps réel. Le gain de SkyRL porte sur les mathématiques de compétition, mesuré par un partenaire disposant d’un cluster loué et d’une récompense qu’un script peut vérifier. Un écart de 13 points sur Terminal-Bench et un écart de 11 points sur AIME ne sont pas le même exploit exprimé dans des unités différentes ; ce sont des exploits différents qui se trouvent avoir une ampleur similaire.

La lecture équitable est plus étroite et plus utile : trois semaines de RL à l’échelle d’un datacentre ont fait varier de treize points le score terminal de Mistral, et quelques heures de RL LoRA à l’échelle de huit nœuds ont fait varier de onze points le score de maths d’un partenaire. Les deux chiffres disent la même chose — ce checkpoint répond volontiers à l’apprentissage par renforcement — et ni l’un ni l’autre ne dit quoi que ce soit sur l’autre.

Ce que 64 à 75 à l’AIME 2024 prouve et ne prouve pas

Commençons par l’arithmétique, car c’est la seule partie de tout cela qui peut être vérifiée sans GPU. AIME 2024 compte trente problèmes. Average@8 signifie huit tentatives échantillonnées par problème, donc le chiffre rapporté repose sur 240 complétions. L’erreur d’échantillonnage sur une proportion proche de 70 % pour cette taille d’échantillon est de quelques points de pourcentage, ce qui place un écart de onze points confortablement hors du bruit. Si les deux chiffres proviennent du même dispositif d’évaluation, l’amélioration est réelle sur cette tâche.

C’est la chose la plus forte qu’on puisse dire, et il vaut la peine de le dire clairement, car la plupart des affirmations du jour zéro ne sont même pas à ce niveau. Maintenant, les limites :

• Aucun score AIME publié par Mistral n’existe pour ce modèle. La référence de 64 % est la mesure effectuée par SkyRL lui-même sur le checkpoint de base avec son propre banc d’essai ; l’écart est donc cohérent en interne mais non ancré en externe — vous ne pouvez pas le comparer à un chiffre fournisseur, car aucun chiffre fournisseur n’existe.

• Average@8 n’est pas pass@1. Huit tentatives par problème avantagent tout modèle dont la distribution d’échantillonnage est large, et l’écart entre les deux métriques est couramment de cinq à quinze points sur les mathématiques de compétition. Le chiffre qui décide si vous déploieriez le modèle est l’unique tentative que vous lui accordez en production.

• AIME 2024 a deux ans et demi et figure parmi les ensembles de mathématiques les plus fortement représentés dans les données de post-entraînement. Un modèle de 2026 qui obtient de bons résultats sur cet ensemble est la preuve d'un point de contrôle entraînable, non un verdict sur le raisonnement. Rien dans la note ne fait état d'une évaluation sur un ensemble mis de côté ou plus récente.

• Une tâche, une exécution, une récompense. Le RL sur des mathématiques vérifiables est le cas le plus simple qui soit : la récompense n’a besoin ni de juge, ni de grille d’évaluation, ni d’humain. Le résultat indique jusqu’où ce modèle progresse sous le signal de RL le moins coûteux possible, ce qui est véritablement la bonne première expérience et aussi la moins transférable.

Ce qu’il vous faudrait pour le reproduire, et ce que la licence autorise

La liste de courses pratique, reconstruite à partir de la note plutôt que publiée par celle-ci :

• Le checkpoint NVFP4 — 610 Go, 32 fragments, sans restriction, téléchargeable dès aujourd'hui sans passer par l'autorisation d'un compte Hugging Face.

Environ 32 GPU de classe Blackwell répartis sur huit nœuds, plus l’interconnexion pour éviter que la synchronisation des adaptateurs ne consomme le temps de l’étape.

• Une compilation de vLLM dotée d’un chemin NVFP4 fonctionnel pour cette architecture. La fiche du modèle recommande vLLM avec un conteneur officiel et une taille de parallélisme tensoriel de huit, et signale une tête de décodage spéculatif intégrée dont le fournisseur affirme qu’elle vaut jusqu’à 1,9× le débit — cette tête n’est pas ce dont une boucle RL a besoin, mais le conteneur, si.

• Un rang d'adaptateur et une récompense, vous devrez les choisir vous-même, car la note ne le précise pas.

La question de la licence se règle plus proprement que celle de la technique. Mistral a publié ce modèle sous la Mistral Ecosystem Open-Weight License, un texte MIT modifié qui autorise l’usage commercial, le fine-tuning et les dérivés, et n’exige une licence commerciale séparée que pour exploiter par-dessus une activité de modèle en tant que service. Le fine-tuning interne, un adaptateur privé, une exécution d’évaluation sur des nœuds loués — tout cela relève de l’autorisation. Mettre en place une API à facturation par token et vendre l’accès à votre fine-tuning, non. Si votre projet relève du premier cas, la licence n’est pas votre problème. S’il relève du second, elle est tout le problème, et aucune amélioration du score AIME, aussi grande soit-elle, n’y changera rien.

La moitié de la boucle qui devient coûteuse plus tard

AIME est le cas bon marché pour une raison qui vaut la peine d’être explicitée. La récompense est une chaîne de réponse qu’un script compare. Il n’y a pas de juge, pas de grille d’évaluation, pas de second modèle dans la boucle, donc le coût marginal d’un rollout est l’inférence et rien d’autre. Transposez la même recette à des tâches agentiques, à l’écriture ouverte ou à tout ce qui est évalué par préférence, et la récompense devient un appel à un modèle — émis à l’échelle du rollout, des milliers de fois par étape, pendant toute l’exécution. C’est un problème d’approvisionnement différent de celui du calcul d’entraînement, et c’est celui que la plupart des équipes découvrent après avoir réservé les GPU.

Mistral Large 4 lui-même n'est pas un modèle que nous servons, donc cet article n'est pas une route vers lui — l'héberger soi-même renvoie au dépôt Hugging Face et à l'API propre de l'éditeur. Ce qui est routable, c'est l'autre moitié de la boucle. Si votre vérificateur est un modèle juge plutôt qu'un script, il doit survivre à des appels à l'échelle des rollouts : un seul endpoint pour plus de 200 modèles, le prix catalogue du fournisseur répercuté sans marge supplémentaire, et le basculement en cas de défaillance lorsqu'un endpoint de juge unique atteint sa limite de débit au milieu d'une étape d'entraînement. Les modèles que vous utiliseriez réellement comme juges sont listés, avec leur contexte et leur prix, dans le catalogue de modèles OrcaRouter. L'idée n'est pas que le routage rende le RL bon marché. C'est que le signal de récompense est la partie d'un run de RL autour de laquelle vous ne pouvez pas vous organiser, c'est donc la partie qui mérite d'être placée derrière une interface stable.

Que regarder ensuite

Trois choses transformeraient cette note prometteuse en résultat. Que l’équipe SkyRL publie le rang de l’adaptateur, la définition de la récompense et une courbe d’apprentissage, ce qui permettrait à un autre groupe de tenter la même exécution plutôt que de l’admirer. Une deuxième tâche, idéalement dont la récompense n’est pas une comparaison de chaînes, qui montrerait si l’effet survit au contact d’un juge. Et une évaluation indépendante sur AIME ou sur des mathématiques plus difficiles du checkpoint publié, car le plancher de 64 % est actuellement la mesure du partenaire lui-même et le seul moyen de lever cette réserve est que quelqu’un d’autre le mesure.

D'ici là, le résumé honnête est court. Les poids ont un jour, un partenaire a fait gagner onze points à un benchmark de mathématiques sur huit nœuds loués avec un adaptateur LoRA, et personne ne l'a encore reproduit. C'est plus que ce que la plupart des publications de modèles à poids ouverts offrent lors de leur première semaine, et moins que ce que le titre laisse entendre.