Markdown-Ausgabe

AI-translated from English; not yet reviewed by a fluent editor.

# Olmo-core 3 öffnet Ai2s MoE-Trainingsstack mit begrenzten GPU-Ergebnissen

> Ai2s Veröffentlichung von Olmo-core 3 am 1. Oktober bietet offenen MoE-Trainingscode und B300-Benchmarks. Die Skalierungstests messen Systemdurchsatz, nicht die Qualität eines trainierten Modells.

By BIG CHANGE Editorial

Published: 2026-10-13T02:08:18.598Z
Updated: 2026-10-13T02:08:18.598Z
Canonical: https://bigchange.ai/blog/ai2-olmo-core-3-moe-training-stack-benchmarks

![Conceptual charcoal illustration of an unbranded accelerator circuit board beside its separate finned heat sink.](https://bigchange.ai/api/media/file/olmocore3-gpu-board-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE. Generic accelerator components; no specific B300 design, Ai2 installation, completed training run or BIG CHANGE hardware test is depicted.

Ai2 veröffentlichte Olmo-core 3 am 1. Oktober als offenes Trainingsframework für Mixture-of-Experts-Sprachmodelle (MoE). Das nützlichste Ergebnis für Systemingenieure ist enger gefasst als die Schlagzeile mit einer Billion Parametern: Ai2 hat Code, Referenzkonfigurationen und begrenzte GPU-Messungen veröffentlicht, mit denen Teams entscheiden können, ob sich ein Test dieses Stacks auf einem bestimmten Cluster lohnt.

Ein MoE leitet jedes Token an eine Teilmenge seiner Expertennetzwerke weiter. Das begrenzt den Rechenaufwand pro Token, doch der vollständige Expertenpool und sein Optimiererzustand müssen weiterhin auf GPUs Platz finden. Auch das Verschieben von Tokens zu den Experten kostet Zeit. Olmo-core 3 ändert Ai2s Umgang mit diesen beiden Einschränkungen: Das DDP-basierte System lässt Experten auf GPUs resident und leitet Daten zu ihnen; die frühere FSDP-Implementierung sammelte Gewichte für Microbatches wiederholt ein und teilte sie neu auf. Der neue Stack kombiniert Experten- und Pipeline-Parallelisierung, verteilten Optimiererzustand, GPU-residentes Routing und gruppierte Expertenberechnung. Ai2 unterstützt MXFP8 außerdem für ausgewählte Operationen. Das sind überprüfbare und konfigurierbare Designentscheidungen, keine Zusage gleicher Geschwindigkeit auf einem anderen Cluster.

## Die große Änderung

Olmo-core 3 stellt Ai2s umfangreiche MoE-Trainingswerkzeuge als Apache-2.0-Code und Referenzskripte bereit. Ai2s Tests zeigen in einem bestimmten Vergleich mit acht B300 einen höheren Durchsatz als der frühere Stack und zeigen, dass eine zufällig geroutete Konfiguration mit 1,2 Billionen Parametern auf 512 B300 ausgeführt werden kann. Sie belegen weder die Qualität eines trainierten Billionen-Parameter-Modells noch die Geschwindigkeit im Workload der Leserschaft. Der praktische Nutzen ist ein nachvollziehbarer Ausgangspunkt, um Konfigurationen nachzustellen, lokale Engpässe zu messen und zu entscheiden, welche Parallelisierungs- und Präzisionseinstellungen einen kostspieligen Trainingslauf rechtfertigen.

## Drei Zahlen, drei Bezugsgrößen

Ai2s vorläufiger Vergleich eines MoE mit 47 Milliarden Parametern lief auf acht Nvidia-B300-GPUs. Der neue Stack verarbeitete 52.000 Tokens pro Sekunde **pro GPU**, gegenüber 19.400 mit der früheren FSDP-basierten Implementierung. Das Verhältnis beträgt 52.000 ÷ 19.400 = 2,68, gerundet 2,7-mal. Dies ist ein interner Vergleich zwischen altem und neuem *Stack* , keine Messung gegenüber Megatron-Core und keine saubere reine DDP-Ablation. Der nächste Vergleich der getaggten Beispiele zwischen DDP plus Expertenparallelisierung und FSDP/HSDP hält Modellform und Messfenster konstant, ändert aber ebenfalls Router, Sparse-Kernels, Optimierer und weitere Implementierungsdetails.

Das Ergebnis „weniger als 5 %“ beantwortet eine andere Frage. Ai2 vergrößerte den Pool von 8 auf 128 Experten und wählte vier pro Token. Die Gesamtkapazität stieg von 4,6 auf 47 Milliarden Parameter, während die aktiven Parameter pro Token bei etwa 3,2 Milliarden blieben. Der Durchsatz sank zwischen diesen Expertenpool-Konfigurationen um weniger als 5 % **zwischen diesen Expertenpool-Konfigurationen**. Das bedeutet weder, dass der neue Stack nur 5 % langsamer als der alte ist, noch dass 16-mal mehr Experten in jeder Konfiguration kostenlos wären. Die Veröffentlichung enthält nicht genügend Angaben, um den Prozentsatz in die Kosten eines Lesers in Dollar umzurechnen.

Das Skalierungsergebnis hat einen dritten Nenner: Ai2 meldet für eine Konfiguration mit insgesamt 1,2 Billionen Parametern und 58,36 Milliarden aktiven Parametern pro Token auf 512 B300 einen Spitzenwert von 858 TFLOP/s **pro GPU** . Die Referenztabelle von v3.0.0 kennzeichnet diese Ultra-128E-Zeile als zufällig geroutet, MXFP8 und Rekombination pro Schicht. Zufälliges Routing misst den Systempfad, ohne zu prüfen, ob ein gelernter Router ein gutes Modell hervorbringt. Eine Konfiguration mit 2,38 Billionen Parametern nutzte DeepEP v2 in einem kurzen Kapazitätstest. Ai2 beschreibt dies als Skalierungsprüfung, nicht als anhaltendes Training. Keine der Zahlen belegt Modellgenauigkeit, nützliche Ausgabequalität oder eine stabile Wirtschaftlichkeit eines vollständigen Trainingslaufs.

Ai2 meldet außerdem einen kontrollierten Vergleich mit vier B300: MXFP8 erhöhte den End-to-End-Trainingsdurchsatz gegenüber BF16 um rund 21 % und senkte den aktiven Spitzenspeicher von 103 GiB auf 95 GiB; die Arbeit war gleichmäßig auf Experten verteilt. Das Ergebnis gilt für die getesteten Präzisionsoptionen und den Workload. Es lässt sich nicht zur 2,7-fachen Zahl addieren, als hätten beide Messungen dieselbe Basis.

## Was Ingenieure tatsächlich ausprobieren können

Die Veröffentlichung des Repositorys vom 1. Oktober `v3.0.0` ist unter Apache 2.0 öffentlich. Laut README soll zuerst PyTorch für das Zielbetriebssystem und die Zielhardware installiert und danach `ai2-olmo-core` von PyPI oder das geklonte Repository für die Entwicklung installiert werden. Die getaggte `src/examples/olmo_ddp/README.md` ordnet die gemeldeten Betriebspunkte den Skripten zu und dokumentiert `torchrun` als allgemeinen Startweg. Die Produktionsskripte setzen acht GPUs pro Knoten voraus und geben die Knotenzahl in `REF_NUM_NODES` an. Dies sind Beispiele für Teams mit einer verteilten GPU-Umgebung, kein Ein-Befehl-Weg zur Reproduktion der Ai2-B300-Ergebnisse.

Die Berichtsskripte haben wichtige Zugangsvoraussetzungen. Ihr README nennt das `beaker`-Extra, FlashAttention 4, ein beschreibbares `/workspace` und Lesezugriff auf Ai2s `s3://ai2-llm`-Datenmix; der DeepEP-v2-Pfad benötigt zusätzlich einen DeepEP-Checkout. Ai2s Haupt-README sagt, dass die veröffentlichten Docker-Images Abhängigkeiten, aber nicht das Olmo-core-Paket enthalten, und warnt, dass andere Hardware oder Treiber-/CUDA-Versionen ein angepasstes Image erfordern können. Die Version v3.0.0 hebt die minimale PyTorch-Version auf 2.10.0 an. Wir haben diese Dokumente und die getaggte Referenztabelle geprüft; BIG CHANGE hat das Paket nicht installiert, keinen Zugriff auf den Datenmix erhalten, keine GPUs reserviert und keinen Trainingslauf ausgeführt.

Für eine lokale Evaluation beginnen Sie mit der getaggten Referenzzeile, die Modellgröße und verfügbarer Hardware am nächsten kommt, und berücksichtigen Sie jede Abhängigkeit sowie unzugängliche Datenpfade, bevor Sie Rechenzeit reservieren. Vergleichen Sie Tokens pro Sekunde und GPU bei gleicher Sequenzlänge, Batchgröße, Routing, Präzision und gleichem Messfenster; überwachen Sie Spitzenspeicher und Checkpoint-Verhalten separat. Die veröffentlichten Produktionszeilen nutzen Sequenzlänge 8.192, Top-Four-Routing und einen gemeinsamen Experten. Für Tiny und Small gibt es ergänzende Skripte mit gelerntem Routing, während die größeren Schlagzeilenzeilen zufällig routen. Die Verteilung der Trainingsdaten kann Kommunikationsbalance und Durchsatz ändern; ein repräsentativer Pilot bleibt daher nötig, bevor ein vollständiger Lauf hochgerechnet wird.

Die Kostengrenze ist physisch ebenso wie softwarebedingt. Der hervorgehobene Vergleich mit acht GPUs benötigt acht B300; das höchste Durchsatzergebnis nutzte 512. Ai2 nennt in der Veröffentlichung weder einen allgemeinen Stundenmietpreis noch ein vollständiges Trainingsbudget. Apache 2.0 beseitigt eine Softwarelizenzgebühr für diesen Code, stellt aber keine GPUs, kompatiblen Treiber, den genannten Datenzugriff oder Arbeitszeit für den Betrieb bereit. Das Referenz-README sagt außerdem, dass die Messung mit überlappenden Zweier-Batches im Bericht einen Branch vor dem Merge verwendete und sich mit den getaggten Skripten nicht reproduzieren lässt.

Das offene System ist nützlich, weil sich seine Aussagen anhand tatsächlicher Konfigurationen prüfen lassen. Ai2s Veröffentlichung fasst Fälle zusammen, in denen ein scheinbar besserer Routing-Balance-Wert unausgeglichenere Arbeit verdeckte und überlappende Kommunikation mit Berechnung das Training verlangsamte. Dadurch wird ein lokaler Messplan wichtiger: Ein schneller Kernel oder eine günstige Einzelmetrik ist kein End-to-End-Trainingsergebnis. Ai2 sagt, dass die nächste Olmo-Generation eine MoE-Architektur nutzen wird; diese Veröffentlichung liefert Trainingsstack und Systemmessungen, bevor die Qualität dieses künftigen Modells bewertet werden kann.

## Quellen und weiterführende Informationen

- [Ai2s Veröffentlichung vom 1. Oktober](https://allenai.org/blog/olmocore3) erläutert die Architektur und nennt begrenzte Durchsatz-, Speicher- und Skalierungswerte. Die Zahlen stammen aus Ai2-Messungen; BIG CHANGE hat sie nicht reproduziert.
- [Olmo-core-v3.0.0-Veröffentlichung](https://github.com/allenai/Olmo-core/releases/tag/v3.0.0) belegt die getaggte Version, das Veröffentlichungsdatum 1. Oktober, das PyTorch-Minimum und Codeänderungen.[ Repository-README](https://github.com/allenai/Olmo-core) dokumentiert Installation, optionale Abhängigkeiten und Docker-Image-Hinweise.
- [Leitfaden zum getaggten MoE-Referenzskript](https://raw.githubusercontent.com/allenai/Olmo-core/v3.0.0/src/examples/olmo_ddp/README.md) ordnet Berichtskonfigurationen GPU-Zahl, Routing und Präzision zu und erklärt Grenzen des Vergleichs zwischen altem und neuem Stack.[ Technischer Bericht](https://allenai.org/papers/olmocore3) ist der Hauptbericht zu den Systemexperimenten; das PDF ließ sich in unserer Rechercheumgebung nicht abrufen, daher beruhen detaillierte Aussagen hier auf Ai2s zugänglicher Veröffentlichung und den getaggten Skripten.

## Sources

- [Ai2, Introducing Olmo-core 3](https://allenai.org/blog/olmocore3) — Hauptankündigung zu Architektur und Messwerten; von Ai2 gemeldete Zahlen.
- [Olmo-core-v3.0.0-Veröffentlichung](https://github.com/allenai/Olmo-core/releases/tag/v3.0.0) — Getaggte Veröffentlichung, Version, Veröffentlichungsdatum 1. Oktober, PyTorch-Minimum und Codeänderungen.
- [README der Olmo-core-v3.0.0-MoE-Referenzskripte](https://raw.githubusercontent.com/allenai/Olmo-core/v3.0.0/src/examples/olmo_ddp/README.md) — Betriebspunkte, zufälliges Routing, GPU-Zahlen, Voraussetzungen und Vergleichsgrenzen.
- [Olmo-core-Repository-README und Lizenz](https://github.com/allenai/Olmo-core) — Installation, optionale Abhängigkeiten, Docker-Hinweise und Apache-2.0-Lizenz.
- [Technischer Bericht von Ai2](https://allenai.org/papers/olmocore3) — Verlinkter Hauptbericht; vollständiges PDF konnte nicht abgerufen werden; dem ungelesenen PDF werden keine einzigartigen technischen Details zugeschrieben.