Olmo-core 3 muscle l’entraînement des modèles MoE ouverts

Allen Institute for AI, via Ai2, a présenté le 1er octobre 2026 Olmo-core 3, une refonte de son infrastructure de formation pour grands modèles de langage. Le système cible les modèles mixture-of-experts, ou MoE, qui n’activent qu’une partie de leurs paramètres à chaque requête. L’enjeu est simple : faire monter la taille sans faire exploser le coût, ni la facture électrique, ni les migraines de coordination GPU.

Un socle ouvert pour des MoE bien plus grands

Olmo-core 3 est conçu pour porter l’entraînement de MoE jusqu’à l’échelle du trillion de paramètres, tout en gardant une efficacité de calcul élevée. Ai2 le décrit comme l’un des systèmes centraux de la prochaine génération d’Olmo, avec code ouvert, rapport technique et démonstration interactive à l’appui.

Le point de départ est connu : les MoE permettent d’augmenter fortement le nombre total de paramètres sans mobiliser tous les experts à chaque token, c’est-à-dire chaque petite unité de texte traitée par le modèle. Mais cette architecture déplace le problème ailleurs, vers le stockage des poids, le routage des données et les échanges entre GPU. Olmo-core 3 a été bâti pour réduire ce goulot d’étranglement.

Pourquoi changer de stack maintenant ?

La version précédente d’Olmo-core reposait sur du fully sharded data parallelism, ou FSDP, qui rassemble et redistribue fréquemment les poids du modèle pendant l’entraînement. Olmo-core 3 passe à une approche fondée sur le distributed data parallelism, ou DDP, en gardant les experts résidents sur les GPU et en envoyant les données vers eux. Ce choix évite des opérations répétées de collecte de poids.

Dans un test préliminaire sur huit GPU NVIDIA B300, Ai2 dit qu’un MoE de 47 milliards de paramètres a traité 52 000 tokens par seconde et par GPU avec la nouvelle pile, contre 19 400 avec l’ancienne. Cela représente environ 2,7 fois plus de débit. La mesure reste interne et technique, mais elle montre le type de gain recherché.

Les briques qui font tenir l’ensemble

Trois mécanismes structurent la montée en charge : le parallelisme d’experts répartit les experts entre GPU ; le parallelisme de pipeline découpe les couches du modèle entre groupes de GPU ; enfin, un optimiseur distribué répartit aussi l’état d’optimisation, c’est-à-dire les données nécessaires pour appliquer les mises à jour d’entraînement.

À cela s’ajoutent plusieurs optimisations de routage. Le rowwise expert parallelism place les données directement dans les tampons d’entrée des experts. Le GPU-resident routing conserve les métadonnées de routage côté GPU. Et grouped GEMM regroupe plusieurs petites opérations matricielles pour mieux utiliser les processeurs graphiques. Ces détails sont moins glamour qu’un grand lancement, mais c’est souvent là que les performances se gagnent.

MXFP8, mémoire et vitesse : le compromis classique

Olmo-core 3 prend aussi en charge MXFP8, un format numérique de précision réduite qui utilise moins de bits pour certaines valeurs. Dans un benchmark contrôlé sur quatre GPU NVIDIA B300, Ai2 rapporte un gain d’environ 21% de débit par rapport à BF16, avec une mémoire active maximale passant de 103 à 95 GiB. Le bénéfice vient surtout du calcul feed-forward et des échanges entre experts.

Le système inclut aussi des checkpoints indépendants de la topologie, afin de reprendre un entraînement sur une configuration matérielle différente. Le rapport technique indique enfin que la recomputation des activations réduit fortement la mémoire utilisée, mais au prix d’une baisse de débit d’environ 20% dans le test comparatif présenté.

Jusqu’où peut-on pousser la machine ?

Ai2 dit avoir benchmarké Olmo-core 3 jusqu’à un modèle MoE de 1,2 trillion de paramètres, avec 58,36 milliards de paramètres actifs par token sur 512 GPU NVIDIA B300. Le pic observé atteint 858 TFLOP/s par GPU, une mesure du calcul utile par seconde. Ces tests utilisent un routage aléatoire pour évaluer le système, pas la qualité d’un modèle entraîné.

L’organisation a aussi expérimenté DeepEP v2, un autre backend de communication entre experts, et dit avoir atteint 2,38 trillions de paramètres totaux dans un test de capacité court. La nuance compte : il s’agit d’une démonstration d’échelle, pas d’un entraînement soutenu de bout en bout.

Ce que le rapport dit aussi sur les limites

Le rapport technique, intitulé Supercharging Olmo-core for Efficient and Scalable MoE Training, documente plusieurs effets moins intuitifs. Ai2 parle par exemple de token gerrymandering, un cas où une métrique de répartition s’améliore alors que la charge réelle devient plus déséquilibrée. Le papier note aussi que baisser le taux d’apprentissage des experts parce qu’ils voient moins de tokens n’a pas amélioré les résultats dans le modèle testé.

Autre surprise : superposer communication et calcul sur des flux GPU séparés n’a pas toujours accéléré l’entraînement. Dans certains cas, cela l’a même ralenti. Le message est assez net : dans les gros MoE, empiler les optimisations ne suffit pas, il faut surtout éviter qu’elles se marchent dessus.

Pourquoi ce lancement compte pour le reste du marché

Avec Olmo-core 3, Ai2 met à disposition une base ouverte pour entraîner ses propres MoE, adapter le système à d’autres matériels et tester différentes stratégies de routage ou de parallélisme. Le prochain Olmo doit d’ailleurs utiliser une architecture MoE, avec l’objectif d’être le plus capable de la famille à ce jour, entraîné sur le plus grand jeu de données et avec la plus longue fenêtre de contexte.

Pour les laboratoires académiques et les équipes plus modestes, la publication compte autant que le modèle final. Ouvrir les poids ne suffit pas toujours ; ouvrir l’infrastructure d’entraînement change aussi qui peut réellement construire la suite. C’est là que se joue une partie de la concurrence dans l’IA de pointe, bien avant le produit fini.

Le dépôt GitHub associé est distribué sous licence Apache-2.0 et peut être installé depuis les sources ou via PyPI sous le nom ai2-olmo-core.