Un modèle d’IA peut économiser des calculs sur le papier et perdre cet avantage lorsqu’il faut déplacer ses données entre des centaines de processeurs. Avec Olmo-core 3, Ai2 s’attaque à cette mécanique discrète qui décide de la vitesse réelle d’un entraînement.
L’institut a annoncé le 1er octobre 2026 une nouvelle version de son infrastructure ouverte pour les modèles Mixture of Experts, ou MoE. Olmo-core 3 prépare la prochaine génération d’Olmo ; cette annonce porte sur l’outil d’entraînement, pas sur la sortie d’un nouveau chatbot. Le billet officiel d’Ai2 présente les premiers résultats et leur périmètre.
Pourquoi les modèles à experts ont besoin d’une organisation particulière
Un modèle MoE comporte plusieurs ensembles de paramètres appelés « experts ». Un mécanisme de routage sélectionne ceux qui traiteront chaque token, une petite unité de texte. Le mot expert désigne ici un composant mathématique : il ne faut pas imaginer une équipe de spécialistes humains, chacun affecté à un métier.
L’intérêt est de disposer d’une capacité totale importante tout en n’activant qu’une partie de ces composants pour une entrée donnée. Mais les experts doivent rester stockés quelque part. Lorsqu’ils sont répartis entre plusieurs GPU, les représentations des tokens voyagent vers les processeurs qui possèdent les composants nécessaires, puis les résultats reviennent.
La présentation pédagogique d’Ai2 sur l’entraînement distribué explique ce compromis entre mémoire disponible, calcul et communication. Répartir les experts libère de la place sur chaque GPU ; cela introduit aussi des échanges qui prennent du temps.
Une analogie aide à comprendre le problème : dans un atelier, mobiliser seulement les machines utiles ne garantit pas une fabrication rapide si les pièces passent leur temps en transit. Pour un modèle MoE, réduire le nombre de calculs n’est donc qu’une partie du travail.
Faire circuler les données plutôt que rassembler sans cesse les poids
Ai2 explique que son ancienne approche rassemblait puis redistribuait les poids pour les petits lots d’entraînement. La nouvelle conserve les experts sur les GPU et leur envoie les données pertinentes. Le changement vise à éviter ces rassemblements répétés.
Cela ne supprime pas les échanges entre machines. Leur organisation devient centrale : regrouper le travail destiné au même expert, éviter des attentes inutiles et maintenir les différents processeurs occupés.
Le dépôt documente notamment une pile MoE distribuée, des opérations matricielles groupées et des fonctions de communication entre GPU. Son journal des modifications situe la version 3.0.0 au 30 septembre, avant l’annonce publique du lendemain. Plusieurs composants MoE figuraient déjà dans les versions précédentes : la publication présente une évolution de l’infrastructure, plutôt qu’une fonctionnalité apparue d’un seul bloc.
Trois formes de partage à distinguer
Le parallélisme des données fait travailler plusieurs copies sur des lots différents. Le parallélisme des experts distribue les experts entre GPU. Le parallélisme par étapes répartit les couches du modèle entre groupes de processeurs.
Ces méthodes répondent à des contraintes différentes. Une configuration peut tenir en mémoire tout en étant lente parce que certains GPU attendent les autres. La bonne répartition doit donc être jugée sur le temps d’exécution complet, et pas seulement sur la quantité de mémoire économisée.
Le gain de 2,7 fois concerne un test précis
Voici le résultat le plus immédiatement lisible de l’annonce :
| Élément du test préliminaire | Résultat rapporté par Ai2 |
|---|---|
| Modèle MoE | 47 milliards de paramètres au total |
| Matériel | Huit GPU NVIDIA B300 |
| Ancienne implémentation | 19 400 tokens par seconde et par GPU |
| Nouvelle implémentation | 52 000 tokens par seconde et par GPU |
| Rapport entre les débits | Environ 2,7 fois |
Ces chiffres comparent la nouvelle pile à l’ancienne implémentation d’Ai2. Ils ne constituent ni un classement de toutes les infrastructures concurrentes ni une garantie de gain sur un autre cluster.
La distinction compte pour une équipe qui prépare un budget. Un débit supérieur signifie que davantage de tokens sont traités par seconde dans les conditions mesurées. Il ne suffit pas à déduire le coût total : il faudrait aussi connaître les interruptions, les sauvegardes, les évaluations et le nombre d’étapes nécessaires pour atteindre la qualité recherchée.
Même le raisonnement énergétique demande de la prudence. Une exécution plus courte pourrait réduire la consommation à travail comparable, mais le débit ne fournit pas à lui seul une mesure de l’énergie utilisée. L’annonce ne permet donc pas de chiffrer une économie électrique globale.
Un essai à 1 200 milliards de paramètres n’est pas un modèle validé
Ai2 rapporte aussi un test à 1 200 milliards de paramètres sur 512 GPU B300, avec routage aléatoire pour mesurer les performances du système. Il s’agit d’éprouver l’infrastructure, pas de démontrer les capacités d’un modèle entraîné.
Le nombre total de paramètres décrit une échelle. Pour apprécier un modèle destiné à des utilisateurs, il faudrait ensuite des évaluations de ses réponses, de sa fiabilité et de ses usages. Confondre ces deux étapes ferait passer une réussite d’ingénierie pour une percée déjà démontrée en qualité.
Ce que l’ouverture du code apporte aux laboratoires
Le dépôt public Olmo-core est sous licence Apache 2.0. Il fournit des briques de modélisation et d’entraînement fondées sur PyTorch, ainsi que des scripts officiels pour des modèles Olmo déjà publiés. L’ouverture permet d’examiner les choix, d’adapter le code et de comparer des configurations.
Pour la recherche, cette possibilité d’inspection est précieuse. Une équipe peut tenter de reproduire un résultat, modifier la répartition des experts ou identifier l’origine d’un ralentissement. Le bénéfice ne se limite donc pas à récupérer des poids prêts à l’emploi : il concerne aussi les moyens d’étudier comment un modèle se construit.
Cette accessibilité logicielle ne rend toutefois pas le matériel gratuit. Le dépôt avertit que ses images d’environnement peuvent ne pas convenir à un cluster doté d’autres GPU, pilotes ou versions de CUDA. Les performances sur B300 ne doivent pas être extrapolées sans essais locaux.
Une démarche utile consisterait à commencer par une configuration représentative du matériel disponible, puis à suivre le débit, les attentes entre processeurs et la stabilité de l’apprentissage. Ce sont des critères d’évaluation proposés ici, pas des résultats supplémentaires publiés par Ai2.
L’enjeu : rendre les choix d’entraînement vérifiables
Olmo-core 3 attire l’attention sur une question souvent éclipsée par les annonces de modèles : comment utilise-t-on réellement les processeurs achetés ou loués pour entraîner une IA ? Le code ouvert donne aux équipes une prise sur cette question, sans effacer les contraintes de matériel et de données.
La prochaine étape à suivre sera double : la reproduction des gains dans d’autres configurations et les résultats des modèles entraînés avec cette infrastructure. Une pile plus rapide peut faciliter les expériences. La qualité de l’IA qui en sort devra, elle, être démontrée séparément.
Références
- Ai2 — annonce d’Olmo-core 3, 1er octobre 2026.
- Ai2 — explication interactive de l’entraînement distribué.
- Ai2 — code, licence et documentation d’Olmo-core.
- Ai2 — historique officiel des versions.
