🤖 machine learning

Compute-Optimal Is Not Cluster-Optimal: Systems-Aware Scaling for Sparse Mixture-of-Experts

Dieses Paper stellt MOSAIC vor, ein systembewusstes Co-Design-Framework, das zeigt, dass die optimale Sparsity für Sparse Mixture-of-Experts-Modelle erst dann entsteht, wenn die Modellarchitektur gemeinsam mit Hardware-Beschränkungen optimiert wird, anstatt lediglich durch traditionelle compute-optimale Skalierungsgesetze.

Ursprüngliche Autoren: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Veröffentlicht 2026-08-12

📖 7 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, das ultimative, leistungsfähigste Robotergehirn zu bauen. In der Welt der Künstlichen Intelligenz ist dieses „Gehirn“ ein massives Computerprogramm, ein sogenanntes Large Language Model (LLM). Um diese Gehirne intelligenter zu machen, haben Wissenschaftler eine einfache Regel entdeckt: Wenn man sie mit mehr Daten füttert und größer macht, werden sie besser darin, die Welt zu verstehen. Diese Regel wird als „Scaling Law“ (Skalierungsgesetz) bezeichnet. Lange Zeit war das Rezept für den Bau dieser Gehirne in zwei separate Schritte aufgeteilt. Zuerst berechnete ein Mathematiker die perfekte Größe des Gehirns basierend auf der verfügbaren Rechenleistung (genannt „Compute“). Dann versuchte ein anderer Ingenieur, dieses Gehirn auf einen spezifischen Satz von Computerchips zu pressen, um es so schnell wie möglich laufen zu lassen.

Stellen Sie sich das wie die Planung eines Roadtrips vor. Der erste Schritt besteht darin, zu entscheiden, wie weit man fahren möchte, basierend auf seinem Benzinbudget. Der zweite Schritt ist die Wahl des Autos. Aber was, wenn das Auto, das Sie gewählt haben, so schwer und klobig ist, dass es Benzin in einem schrecklichen Tempo verschlingt, sodass Sie eigentlich gar nicht so weit fahren können, wie Sie geplant hatten? Das ist das Problem, das dieses Paper angeht. Es argumentiert, dass man nicht einfach erst eine Gehirngröße wählen und sich dann darum kümmern kann, wie das Auto aussieht. Man muss das Gehirn und das Auto gemeinsam entwerfen, denn die Form des Gehirns verändert, wie effizient das Auto fährt. Wenn man den Motor des Autos ignoriert, landet man vielleicht bei einem „perfekten“ Gehirn, das zu schwer ist, um sich zu bewegen, und bleibt so am Startpunkt stehen.

Das Problem: Das „perfekte“ Gehirn, das nicht passt

Das Paper stellt eine neue Denkweise namens MOSAIC (Model Optimization via Systems-Aware TraIning Co-design) vor. Die Autoren, die bei Amazon AGI Foundations arbeiten, bemerkten, dass die alte Arbeitsweise Geld auf dem Tisch liegen ließ. Traditionell berechneten Forscher das „Compute-Optimale“ Modell. Dies ist die Modellgröße, die die besten Ergebnisse für eine feste Menge an Rechenleistung erzielt, unter der Annahme, dass jeder Bit an Leistung perfekt genutzt wird.

Die Autoren fanden jedoch eine versteckte Falle. Sie konzentrierten sich auf eine spezielle Art von KI-Architektur namens Mixture-of-Experts (MoE). Stellen Sie sich eine riesige Bibliothek vor, in der, anstatt eines einzigen riesigen Bibliothekars, der jedes Buch liest, tausende kleiner, spezialisierter Experten existieren. Wenn eine Frage eingeht, leitet ein intelligenter Router sie an nur wenige dieser Experten (sagen wir 2 von 100) weiter, um sie zu beantworten. Dies macht das Modell sehr schnell und effizient, da nicht die ganze Bibliothek für jede Frage geweckt werden muss.

Die alte Mathematik legte nahe, dass man die Bibliothek so groß wie möglich machen und so wenige Experten wecken sollte, um die besten Ergebnisse zu erzielen. Mit anderen Worten: Das „perfekte“ Modell sollte extrem spärlich (sparse) sein (also hauptsächlich leer). Das Paper zeigt, dass, wenn man nur der reinen Mathematik von „Wie viele Berechnungen benötigen wir?“ folgt, die Antwort immer lautet: „Mache es so spärlich wie nur möglich.“ Die Mathematik besagt, dass die beste Sparsity (Spärlichkeit) genau an der Grenze dessen liegt, was überhaupt möglich ist.

Der Twist: Der Automotor spielt eine Rolle

Hier ändert sich die Geschichte. Die Autoren erkannten, dass während die Mathematik sagt „mache es super spärlich“, die physische Realität der Computerchips sagt „auf keinen Fall“.

Wenn man ein Modell mit tausenden winzigen Experten hat, muss der Computer viel zusätzliche Arbeit leisten, nur um zu entscheiden, welche Experten geweckt werden sollen und wie die Informationen zwischen ihnen ausgetauscht werden. Es ist, als hätte man ein riesiges Bürogebäude, in dem der Manager den ganzen Tag damit verbringt, zwischen den Cubicles hin und her zu laufen, um Memos zu liefern, wodurch kaum Zeit für die eigentliche Arbeit bleibt. Je spärlicher das Modell wird, desto mehr Zeit verschwendet der Computer mit diesen „Herumlauf-Aufgaben“ (Kommunikationskosten) und desto weniger Zeit verbringt er mit dem eigentlichen Denken (Berechnungen).

Das Paper argumentiert, dass die alte „Compute-Optimale“ Mathematik fehlerhaft war, weil sie davon ausging, dass der Computer 100 % seiner Leistung für den Denkprozess nutzen kann. In der Realität nutzt ein super-spärliches Modell vielleicht nur 8 % der Rechenleistung für das eigentliche Denken, während ein etwas dichteres Modell vielleicht 15 % erreicht.

Die Lösung: MOSAIC

Um dies zu beheben, baute das Team MOSAIC. Anstatt zu fragen: „Was ist das beste Modell für eine feste Menge an Mathematik?“, fragten sie: „Was ist das beste Modell, das wir tatsächlich auf unserem spezifischen Cluster von Computern in einer festen Zeitspanne ausführen können?“

Sie kombinierten zwei Dinge:

Ein Scaling Law (Skalierungsgesetz): Eine Vorhersage darüber, wie intelligent das Modell basierend auf seiner Größe und Form sein wird.
Ein Leistungsmodell (Performance Model): Ein Simulator, der vorhersagt, wie schnell das Modell auf echter Hardware tatsächlich laufen wird, wobei die „Herumlauf-Kosten“ berücksichtigt werden.

Als sie MOSAIC ausführten, waren die Ergebnisse überraschend. Das „perfekte“ Modell war nicht dasjenige am extremen Rand der Sparsity. Stattdessen war das beste Modell eine interne Lösung – ein glückliches Mittelmaß. Es war spärlich genug, um effizient zu sein, aber nicht so spärlich, dass der Computer durch die Verwaltung all dieser winzigen Experten überfordert wurde.

Was sie herausfanden

Das Team testete dies auf echter Hardware unter Verwendung von NVIDIA B200 GPUs. Sie trainierten Modelle mit einer Spanne von 700 Millionen bis 18 Milliarden aktiven Parametern (und bis zu 79 Milliarden Gesamtparametern).

Der alte Weg: Wenn man einfach der alten Mathematik gefolgt wäre, hätte man ein Modell mit einer Sparsity von etwa 0,985 gewählt (was bedeutet, dass 98,5 % der Experten schlafen). Aber auf ihrem spezifischen Cluster wäre dieses Modell so langsam gewesen, dass das Training ewig gedauert hätte, und es wäre tatsächlich weniger intelligent gewesen als ein etwas dichteres Modell.
Der MOSAIC-Weg: Das System fand heraus, dass der „Sweet Spot“ bei einer Sparsity von etwa 0,96 lag. Dieses Modell war nicht das „theoretisch“ Beste, aber es war das praktisch Beste. Es lief schneller, nutzte die Leistung des Computers effizienter und erreichte eine geringere Fehlerrate (was bedeutet, dass es intelligenter war) als das „theoretisch“ beste Modell.

Tatsächlich zeigten sie, dass das Modell, das auf dem Papier am besten aussah (dasjenige mit den meisten „Model FLOPs“), in der Realität am langsamsten zu trainieren war. Das Modell, das gewann, war dasjenige, das die Mathematik mit der Realität der Hardware in Einklang brachte.

Warum das wichtig ist

Dieses Paper legt nahe, dass wir aufhören müssen, das Design von KI-Modellen und das Design der Computer, auf denen sie laufen, als separate Schritte zu behandeln. Man kann nicht einfach eine Modellgröße wählen und hoffen, dass die Computer damit klarkommen. Die Form des Modells verändert, wie der Computer reagiert.

Die Autoren merken vorsichtig an, dass ihre Erkenntnisse spezifisch für die Art der Computerchips sind (NVIDIA B200s), die sie verwendet haben, sowie für die Software, die sie gebaut haben. Sie haben kein universelles Gesetz gefunden, das für jeden Computer im Universum gilt. Sie haben jedoch bewiesen, dass es bei der Entwicklung der KI-Frontier zu suboptimalen Ergebnissen führt, wenn man die „Systeme“ (die Hardware und wie sie Daten bewegt) ignoriert.

Durch die Verwendung von MOSAIC zeigten sie, dass das „beste“ Modell kein fester Punkt auf einem Graphen ist, sondern ein bewegliches Ziel, das von Ihrem spezifischen Hardware-Budget abhängt. Das effizienteste Modell ist dasjenere, das wie ein Handschuh auf Ihren Cluster passt, und nicht dasjenige, das auf einem Blatt Papier am besten aussieht. Dies ist ein Wechsel von „Compute-Optimal“ (was die Mathematik sagt) zu „Cluster-Optimal“ (was die Hardware tatsächlich liefern kann).

Kurz gesagt: Wenn Sie das intelligentste KI-System der Welt bauen wollen, brauchen Sie nicht nur ein größeres Gehirn; Sie brauchen ein Gehirn, das in den Körper passt, in dem es lebt.

Technisches Resümee: Compute-Optimal ist nicht Cluster-Optimal

Problemstellung
Konventionelle Workflows für das groß angelegte Pretraining trennen üblicherweise algorithmische Skalierungsentscheidungen von der Systemimplementierung. Eine „Scaling Law“-Phase wählt eine Modellarchitektur und ein Datenbudget aus, um den Verlust unter einer festen Rechenleistung (FLOPs) zu minimieren, gefolgt von einer getrennten „Systems“-Phase, die die Implementierung für die Hardwareeffizienz optimiert. Die Autoren argumentieren, dass diese Trennung für dünnbesetzte (sparse) Mixture-of-Experts (MoE)-Modelle fehlerhaft ist. Während traditionelle Skalierungsgesetze auf die Modell-FLOPs ( $C_{model}$ ) optimieren, ignorieren sie die Systemeffizienz der vorgeschriebenen Architektur. Zwei Architekturen mit identischen vorhergesagten Verlusten und identischen $C_{model}$ können aufgrund von Variationen in der Model FLOPs Utilization (MFU), Kommunikationskosten und Speicher-Footprints drastisch unterschiedliche Trainingsdurchsatzraten liefern. Folglich kann die „compute-optimale“ Konfiguration, die aus einem FLOPs-Budget abgeleitet wurde, auf einem spezifischen Hardware-Cluster unpraktikabel oder suboptimal sein, da sie die „lieferbare“ Rechenleistung (deliverable compute), die ein Cluster über ein festes Zeitfenster tatsächlich aufrechterhalten kann, nicht berücksichtigt.

Methodik: MOSAIC
Die Autoren führen MOSAIC (Model Optimization via Systems-Aware Training Co-design) ein, ein Framework, das die Modellarchitektur- und System-Co-Design als ein einziges Optimierungsproblem formuliert. MOSAIC wählt gemeinsam die Modellarchitektur, das Trainings-Token-Budget und das verteilte Ausführungslayout (Parallelisierungsstrategie) aus, um den vorhergesagten Verlust unter einem hardwarebeschränkten Budget zu minimieren.

Das Framework integriert drei Kernkomponenten:

Ein vierdimensionales gemeinsames Skalierungsgesetz: Die Autoren passen ein neues Skalierungsgesetz für sparse MoE-Modelle an, das die Gesamtzahl der Parameter ( $N_{tot}$ ), die Trainings-Tokens ( $D$ ), die Sparsity ( $S$ ) und einen Expert-Split-Faktor ( $G$ ) umfasst. $G$ ist definiert als das Verhältnis der dichten Feed-Forward-Breite zur Breite eines einzelnen Experten ( $G = d_{ff}/d_{expert}$ ) und erfasst die Granularität der Experten. Das Gesetz ist wie folgt formuliert:
$L(N_{tot}, S, D, G) = \frac{a}{N_{tot}^\alpha} + \frac{b}{D^\beta} + \frac{c}{(1-S)^\lambda} + \frac{j}{(1-S)^\delta N_{tot}^\gamma G^\eta} + e$
Diese Formulierung ermöglicht es, den Verlust basierend auf diskreten geometrischen Entscheidungen statt auf abstrakten Parameterzahlen vorherzusagen.
Ein Operator-basiertes Leistungsmodell: Um die Systemeffizienz zu schätzen, haben die Autoren ein analytisches Leistungsmodell entwickelt, das die MFU und den Speicher-Footprint für eine gegebene Architektur und ein Parallelisierungs-Layout vorhersagt. Dieses Modell berücksichtigt:
- Rechenkosten (dichte und gruppierte GEMMs, Attention).
- Kommunikationsoverhead (All-to-All für Experten-Parallelität, Pipeline-Bubbles, Data-Parallel-Kollektive).
- CPU-Dispatch-Latenz (kritisch für kleine Micro-Batches).
- Hardware-spezifische Kalibrierungsfaktoren für Intra-Node-Stragglers und Intra-Node-Overlap.
  Das Modell wird gegen Trainingsläufe mit bis zu 18 Milliarden aktiven Parametern validiert und erreicht einen mittleren absoluten prozentualen Fehler (MAPE) von unter 15 % bei der MFU-Vorhersage.
Gemeinsame Optimierung (MINLP): MOSAIC löst ein gemischt-ganzzahliges nichtlineares Programm (MINLP), das den vorhergesagten Verlust unter der Nebenbedingung minimiert, dass die erforderlichen Modell-FLOPs ( $C_{model}$ ) die lieferbaren Modell-FLOPs ( $C_{deliverable}$ ) nicht überschreiten.
$C_{deliverable} = C_{peak} \times \text{MFU}(Z, P_\ell, B) \times \eta_{good}$
Hierbei ist $C_{peak}$ das rohe Hardware-Maximum und MFU ist architekturabhängig. Die Optimierung durchsucht ein diskretes Gitter aus realisierbaren Geometrien ( $Z$ ) und Ausführungsplänen ( $P_\ell$ ), um die Konfiguration zu finden, die den Verlust innerhalb der tatsächlichen Kapazitäten des Clusters minimiert.

Wesentliche Beiträge

Reformulierung des Rechenbudgets: Die Arbeit zeigt, dass die Optimierung unter einem festen $C_{model}$ -Budget bei sparse MoE-Modellen zu einem „Boundary-Seeking“-Verhalten führt, bei dem die optimale Sparsity am oberen Limit der Datenunterstützung liegt (d. h. beim sparsamsten möglichen Modell). Dies liegt daran, dass das Skalierungsgesetz bei festen FLOPs einen geringeren Verlust für sparsere Modelle vorhersagt, dabei aber die Systemkosten ignoriert.
Systems-Aware Co-Design: Durch die Kopplung des Skalierungsgesetzes mit einem Leistungsmodell verschiebt MOSAIC das Budget von $C_{model}$ zu $C_{deliverable}$ . Dies zeigt, dass die optimale Sparsity ein innerer Punkt ist, der durch die spezifischen Einschränkungen des Clusters (Speicher, Bandbreite, Parallelisierungs-Overhead) bestimmt wird, anstatt an der Grenze zu liegen.
Validierung des Leistungsmodells: Die Autoren stellen ein validiertes, Operator-basiertes Leistungsmodell bereit, das die MFU präzise vorhersagt und das optimale Parallel-Layout (Tensor, Expert, Pipeline, Data Parallelism) für sparse MoEs identifiziert. Es zeigt, dass das „beste“ Layout hochgradig von der spezifischen Geometrie und der Clustergröße abhängt.
Empirische Validierung: Das Framework wurde auf AWS p6-Nodes (NVIDIA B200 GPUs) mit Läufen bis zu 250B Gesamtparametern getestet. Die Ergebnisse bestätigten, dass die auf Modell-FLOPs basierende Rangfolge der Konfigurationen signifikant von der auf Hardware-Recheneffizienz (Wandzeit) basierenden Rangfolge abweicht.

Ergebnisse

Boundary vs. Interior Optima: Unter einem festen $C_{model}$ -Budget sinkt der gefittete Verlust monoton mit steigender Sparsity und drängt das Optimum an die Grenze ( $S_{max}$ ). Unter einem festen Hardware-Budget ( $C_{deliverable}$ ) weist die Verlustkurve jedoch ein lokales Minimum im Inneren auf. Die Systemkosten (Kommunikation, Speicher) extrem sparser Modelle überwiegen schließlich deren theoretische Verlustvorteile.
Loss vs. Throughput Trade-off: In Experimenten mit einem 32-Node, 20-Tage-Budget war die Konfiguration, die die meisten Modell-FLOPs realisierte (eine dichtere, gröbere Experten-Geometrie), nicht diejenelbe, die den geringsten Verlust erzielte. Umgekehrt war die verlustoptimale Konfiguration (eine sparsere, feinere Experten-Geometrie) zwar in der Lage, eine niedrigere MFU aufrechtzuerhalten, erreichte aber einen geringeren Endverlust, weil sie die einzige Konfiguration war, die innerhalb der lieferbaren FLOPs-Beschränkung lag und gleichzeitig eine günstige Verlust-Trajektorie beibehielt.
Validierung unter Realbedingungen: Gestufte Pretraining-Läufe auf 8-Node-Clustern validierten das Framework. Die gemessene MFU-Rangfolge entsprach der vorhergesagten Ordnung. Zudem zeigte sich beim Plotten des Verlusts gegen die „Peak-Äquivalente Hardware-Rechenleistung“ (unter Berücksichtigung der MFU), dass sich die Rangfolge der Konfigurationen im Vergleich zur Rangfolge gegen die rohen Modell-FLOPs umkehrte, was bestätigt, dass das „compute-optimale“ Modell nicht das „cluster-optimale“ Modell ist.

Bedeutung
Die Arbeit plädiert für einen grundlegenden Wandel in der Art und Weise, wie Frontier-Sprachmodelle trainiert werden: weg von getrennten Phasen der „Skalierungsgesetz-Auswahl“ und „System-Tuning“ hin zu einem einheitlichen Architektur-System-Co-Design. Die Autoren behaupten, dass die alleinige Nutzung von Modell-FLOPs-Budgets für sparse MoE-Modelle unzureichend ist, da sie die Systemeffizienz der Architektur nicht einzupreisen vermag. Durch die Einführung von MOSAIC demonstrieren sie, dass die optimale Modellgeometrie keine universelle Konstante ist, sondern von der spezifischen Hardware-Cluster, dem Trainingszeitfenster und den Parallelisierungsbeschränkungen abhängt. Dieser Ansatz stellt sicher, dass die gewählte Architektur nicht nur theoretisch verlustoptimal, sondern auch praktisch machbar und effizient auf der Zielhardware ist.

Mehr davon