Aleph Alpha skaliert Pre-Training eines 30B-A3B-MoE-Modells auf 512 B200-GPUs mit 35,3 % MFU

30. September 2026Quelle: Aleph Alpha

Aleph Alpha hat einen Forschungsbeitrag veröffentlicht, der erklärt, wie das Pre-Training eines 30B-A3B-Mixture-of-Experts-Modells von 16 auf 512 NVIDIA-B200-GPUs skaliert wurde. Laut dem Unternehmen erreicht das Setup auf 512 GPUs eine MFU von 35,3 % und liegt damit nur 6 % unter perfekter linearer Skalierung.

Das Wichtigste in Kürze

Aleph Alpha hat ein 30B-A3B-MoE-Modell von 16 auf 512 NVIDIA-B200-GPUs skaliert.
Das Unternehmen meldet 35,3 % MFU auf 512 GPUs, 6 % unter perfekter linearer Skalierung.
Die Methode verkleinert den Hyperparameter-Suchraum mit Läufen im kleinen Maßstab, bevor GPUs hinzukommen.
Die Abstimmung konzentriert sich auf Parallelisierungsschema, Activation Checkpointing und lokale Batch-Größe.
Das Training nutzt Aleph Alphas Fork von torchtitan auf 64 Knoten mit je 8 GPUs.

Hierarchische Suche statt Brute Force

Der Beitrag von Jordan Sassoon, datiert auf den 30. September 2026, geht von einem einfachen Punkt aus: Mehr GPUs machen das Training nicht automatisch schneller. Aleph Alpha zufolge sinkt die Effizienz rasch, wenn die Software nicht sorgfältig abgestimmt wird. Eine naive Gittersuche über die vielen effizienzrelevanten Hyperparameter ist nach Angaben des Unternehmens im großen Maßstab unerschwinglich teuer.

Die Antwort ist ein hierarchischer Ansatz. Das Team verkleinert den Suchraum mit Experimenten im kleinen Maßstab, bevor es die Zahl der GPUs erhöht. Das Unternehmen weist darauf hin, dass Labore zwar mitunter ihre finalen Trainingskonfigurationen offenlegen, die Überlegungen dahinter aber selten, und will diesen Prozess nun zeigen.

Das Training läuft auf einem eigenen, optimierten Fork von torchtitan. Der Ziel-Cluster besteht aus 64 Knoten, die per InfiniBand verbunden sind, mit je 8 GPUs pro Knoten, die über NVLink gekoppelt sind. Die Optimierungen auf System- und Kernel-Ebene, die 35,3 % MFU erst möglich machen, bleiben laut dem Beitrag größtenteils außen vor, da er sich auf die Skalierungsmethodik selbst konzentriert.

Effizienz messen: TPS und MFU

Aleph Alpha verwendet drei Kennzahlen: Tokens pro Sekunde pro GPU (TPS), Model FLOPS Utilisation (MFU) und GPU-Speichernutzung. TPS ist die Zahl der von einer einzelnen GPU verarbeiteten Tokens geteilt durch die Wandzeit. Das Unternehmen nennt sie ein grobes, aber ehrliches Maß für die Trainingsgeschwindigkeit und die Größe, auf die es optimiert.

MFU drückt dieselbe Messung als Anteil an der theoretischen Spitzenrechenleistung der Hardware aus. Der Beitrag warnt, dass MFU-Vergleiche zwischen Modellen unscharf sein können, etwa weil Training mit gemischter Präzision verändert, wie hoch die Spitzen-FLOPS sind. Aleph Alpha trainiert in BF16, abgesehen von FP32-Gradienten, daher dienen für alle MFU-Werte die BF16-Spitzen-FLOPS als Nenner. MFU wird dennoch angegeben, weil sie der Industriestandard ist.

Die Speichernutzung wird als maximal reservierter Speicher geteilt durch den gesamten Gerätespeicher gemessen. Das Team nutzt den von PyTorch reservierten statt des allokierten Speichers, weil der reservierte Speicher harte Out-of-Memory-Abbrüche bestimmt.

Drei Stellschrauben für Compute-Bound-Betrieb

Ziel ist es, compute-bound zu sein: Die GPUs sollen dadurch begrenzt werden, wie schnell sie mathematische Operationen ausführen können, und nicht dadurch, wie schnell Daten zwischen ihnen wandern. Kommunikation treibt die Berechnung des Modells nicht direkt voran, daher verschwenden GPUs, die auf Daten warten, Kapazität.

Der Beitrag nennt drei Freiheitsgrade, um das Verhältnis von Kommunikation zu Berechnung zu verschieben:

das Parallelisierungsschema
die Technik des Activation Checkpointing
die lokale Batch-Größe

Bei der Parallelisierung stützt sich das Unternehmen auf das Ultra-Scale Playbook von Hugging Face und konzentriert sich auf zwei Dimensionen. Fully Sharded Data Parallelism (FSDP, auch ZeRO-3) verteilt Gewichte, Gradienten und Optimizer-Zustände auf die GPUs einer Gruppe, die zusammen ein vollständiges Modellreplikat bilden. Data Parallelism (DP) bezeichnet die Anzahl der Modellreplikate, die der Zahl unabhängiger FSDP-Gruppen entspricht. Der vorliegende Auszug beschreibt die Operationen all_gather und reduce_scatter, die innerhalb von FSDP verwendet werden, sowie die durch DP hinzukommende Operation all_reduce.

Warum das auch jenseits großer Cluster relevant ist

Aleph Alpha argumentiert, die Erkenntnisse seien nicht auf Labore mit Hunderten Top-GPUs beschränkt, weil viele der Werkzeuge und Ideen skalenunabhängig sind. Höhere Effizienz spart Geld und, wie es im Beitrag heißt, Zeit.

Die übrigen Abschnitte des Beitrags behandeln laut Gliederung, wie sich der Hyperparameter-Raum mit Experimenten auf 16 GPUs eingrenzen lässt, wie Profiling zeigt, welche Operationen das Modell ausführt und ob sie effizient sind, sowie die finale Skalierung von 16 auf 512 GPUs, bei der die Skalierungskosten nach Angaben des Unternehmens nahezu entfallen. Der verfügbare Text endet, bevor diese Ergebnisse im Detail dargestellt werden. Die Kernzahlen von 35,3 % MFU und 6 % unter linearer Skalierung sind daher Angaben des Unternehmens.