🤖 machine learning

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

Questo articolo introduce MOSAIC, un framework di co-design consapevole dei sistemi che dimostra come la sparsità ottimale per i modelli sparse Mixture-of-Experts emerga solo ottimizzando congiuntamente l'architettura del modello con i vincoli hardware, piuttosto che attraverso le sole tradizionali leggi di scalabilità computazionale-ottimali.

Autori originali: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Pubblicato 2026-08-12

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Soumajyoti Sarkar, Yuxin Tang, Sheng Zha

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di cercare di costruire il cervello robotico definitivo e più potente. Nel mondo dell'intelligenza artificiale, questo "cervello" è un enorme programma per computer chiamato Large Language Model (LLM). Per rendere questi cervelli più intelligenti, gli scienziati hanno scoperto una regola semplice: se li nutri con più dati e li rendi più grandi, diventano più bravi a comprendere il mondo. Questa regola è chiamata "legge di scala" (scaling law). Per molto tempo, la ricetta per costruire questi cervelli è stata divisa in due passaggi separati. Prima, un matematico calcolava la dimensione perfetta per il cervello in base alla quantità di potenza di calcolo (chiamata "compute") disponibile. Poi, un ingegnere diverso cercava di far stare quel cervello su un set specifico di chip per computer per farlo girare il più velocemente possibile.

Pensa a come pianificare un viaggio su strada. Il primo passaggio è decidere quanto lontano vuoi guidare in base al tuo budget di benzina. Il secondo passaggio è scegliere l'auto. Ma cosa succederebbe se l'auto che hai scelto fosse così pesante e ingombrante da consumare benzina a un ritmo terribile, rendendoti impossibile guidare per la distanza che avevi pianificato? Questo è il problema che questo articolo affronta. Sostiene che non puoi semplicemente scegliere la dimensione di un cervello e poi preoccuparti dell'auto. Devi progettare il cervello e l'auto insieme, perché la forma del cervello cambia l'efficienza con cui l'auto guida. Se ignori il motore dell'auto, potresti finire con un cervello "perfetto" che è troppo pesante per muoversi, lasciandoti bloccato alla linea di partenza.

Il Problema: Il Cervello "Perfetto" che non ci sta

L'articolo introduce un nuovo modo di pensare chiamato MOSAIC (Model Optimization via Systems-Aware TraIning Co-design). Gli autori, lavorando presso Amazon AGI Foundations, hanno notato che il vecchio modo di fare le cose stava lasciando soldi sul tavolo. Tradizionalmente, i ricercatori calcolavano il modello "Compute-Ottimale". Questo è il modello la cui dimensione garantisce i migliori risultati per una quantità fissa di potenza di calcolo, assumendo che ogni bit di potenza sia usato perfettamente.

Tuttari, gli autori hanno scoperto una trappola nascosta. Si sono concentrati su un tipo speciale di architettura IA chiamato Mixture-of-Experts (MoE). Immagina una biblioteca gigante dove, invece di un unico grande bibliotecario che legge ogni libro, hai migliaia di piccoli esperti specializzati. Quando arriva una domanda, un router intelligente la invia a solo alcuni di questi esperti (ad esempio 2 su 100) per rispondere. Questo rende il modello molto veloce ed efficiente perché non deve svegliare l'intera biblioteca per ogni domanda.

La vecchia matematica suggeriva che, per ottenere i migliori risultati, si dovesse rendere la biblioteca il più grande possibile e svegliare il minor numero di esperti possibile. In altre parole, il modello "perfetto" dovrebbe essere incredibilmente sparso (per lo più vuoto). La matematica dice che la migliore sparsità si trova proprio al limite di ciò che è possibile.

Il Colpo di Scena: Il Motore dell'Auto Conta

È qui che la storia cambia. Gli autori si sono resi conto che, mentre la matematica dice "rendilo super sparso", la realtà fisica dei chip per computer dice "assolutamente no".

Quando hai un modello con migliaia di piccoli esperti, il computer deve fare molto lavoro extra solo per decidere quali esperti svegliare e per passare le informazioni tra di loro. È come avere un grande ufficio dove il manager passa tutto il giorno a correre tra i cubicoli per consegnare memo, lasciando pochissimo tempo per il lavoro vero e proprio. Più il modello diventa sparso, più tempo il computer spreca in questi compiti di "correre avanti e indietro" (costi di comunicazione) e meno tempo passa sul pensiero effettivo (calcoli).

L'articolo sostiene che la vecchia matematica del "Compute-Ottimale" era difettosa perché assumeva che il computer potesse destinare il 100% della sua potenza alla parte del pensiero. In realtà, un modello molto sparso potrebbe ricevere solo l'8% della potenza del computer per il pensiero effettivo, mentre un modello leggermente più denso potrebbe riceverne il 15%.

La Soluzione: MOSAIC

Per risolvere questo problema, il team ha costruito MOSAIC. Invece di chiedere: "Qual è il miglior modello per una quantità fissa di calcoli matematici?", hanno chiesto: "Qual è il miglior modello che possiamo effettivamente far girare sul nostro specifico cluster di computer in un tempo fisso?".

Hanno combinato due cose:

Una Legge di Scala: Una previsione di quanto sarà intelligente il modello in base alla sua dimensione e forma.
Un Modello di Performance: Un simulatore che prevede quanto velocemente girerà il modello su un hardware reale, tenendo conto dei costi di "correre avanti e indietro".

Quando hanno eseguito MOSAIC, i risultati sono stati sorprendenti. Il modello "perfetto" non era quello all'estremo della sparsità. Invece, il miglior modello era una soluzione interiore — un giusto mezzo. Era abbastanza sparso da essere efficiente, ma non così sparso da far affogare il computer nei compiti di gestione di tutti quei piccoli esperti.

Cosa hanno scoperto

Il team ha testato questo su hardware reale utilizzando GPU NVIDIA B200. Hanno addestrato modelli che vanno da 700 milioni a 18 miliardi di parametri attivi (e fino a 79 miliardi di parametri totali).

Il Vecchio Modo: Se avessi semplicemente seguito la vecchia matematica, avresti scelto un modello con una sparsità di circa 0,985 (il che significa che il 98,5% degli esperti è a dormire). Ma sul loro specifico cluster, questo modello sarebbe stato così lento da richiedere un tempo infinito per l'addestramento e finirebbe per essere meno intelligente di un modello leggermente più denso.
Il Modo MOSAIC: Il sistema ha trovato che il punto di equilibrio era una sparsità di circa 0,96. Questo modello non era il "teorico" migliore, ma era il migliore dal punto di vista "pratico". Girava più velocemente, usava la potenza del computer in modo più efficiente e raggiungeva un tasso di errore inferiore (quindi era più intelligente) rispetto al "teoretico" migliore.

In effetti, hanno dimostrato che il modello che sembrava migliore sulla carta (quello con più "Model FLOPs") era in realtà il più lento da addestrare nella realtà. Il modello che ha vinto è stato quello che ha bilanciato la matematica con la realtà dell'hardware.

Perché questo è importante

Questo articolo suggerisce che dobbiamo smettere di trattare la progettazione dei modelli IA e la progettazione dei computer che li eseguono come passaggi separati. Non puoi semplicemente scegliere la dimensione di un modello e sperare che i computer possano gestirlo. La forma del modello cambia il modo in cui il computer si comporta.

Gli autori precisano con cautela che le loro scoperte sono specifiche per il tipo di chip che hanno usato (NVIDIA B200) e per il software specifico che hanno costruito. Non hanno scoperto una legge universale che si applichi a ogni computer nell'universo. Tuttavia, hanno dimostrato che, per la frontiera dell'addestramento dell'IA, ignorare i "sistemi" (l'hardware e come i dati si muovono) porta a risultati subottimali.

Usando MOSAIC, hanno dimostrato che il "miglior" modello non è un punto fisso su un grafico, ma un obiettivo mobile che dipende dal tuo specifico budget hardware. Il modello più efficiente è quello che si adatta al tuo cluster come un guanto, non quello che sembra migliore su un pezzo di carta. È un passaggio dal "Compute-Ottimale" (ciò che dice la matematica) al "Cluster-Ottimale" (ciò che l'hardware può effettivamente fornire).

In breve, se vuoi costruire l'IA più intelligente possibile, non hai solo bisogno di un cervello più grande; hai bisogno di un cervello che si adatti al corpo in cui vive.

Sintesi Tecnica: L'Ottimalità di Calcolo non è l'Ottimalità del Cluster

Definizione del Problema
Gli attuali flussi di lavoro per il pretraining su larga scala separano convenzionalmente le decisioni di scaling algoritmico dall'implementazione dei sistemi. Una fase di "scaling law" seleziona un'architettura di modello e un budget di dati per minimizzare la perdita sotto un vincolo fisso di calcolo (FLOPs), seguita da una fase di "sistemi" disconnessa che ottimizza l'implementazione per l'efficienza dell'hardware. Gli autori sostengono che questa separazione sia fallace per i modelli sparsi Mixture-of-Experts (MoE). Mentre le tradizionali scaling laws ottimizzano per i Model FLOPs ( $C_{model}$ ), esse ignorano l'efficienza di sistema dell'architettura prescritta. Due architetture con identico loss predetto e $C_{model}$ possono generare throughput di addestramento vastamente differenti a causa delle variazioni nel Model FLOPs Utilization (MFU), nei costi di comunicazione e nelle impronte di memoria. Di conseguenza, la configurazione "compute-ottimale" derivata da un budget di FLOPs può risultare inammissibile o subottimale su uno specifico cluster hardware, poiché non tiene conto del calcolo "deliverable" (erogabile) che un cluster può effettivamente sostenere su una finestra temporale fissa.

Metodologia: MOSAIC
Gli autori introducono MOSAIC (Model Optimization via Systems-Aware Training Co-design), un framework che formula la co-progettazione tra architettura del modello e sistemi come un singolo problema di ottimizzazione. MOSAIC seleziona congiuntamente l'architettura del modello, il budget di token di addestramento e il layout di esecuzione distribuita (strategia di parallelismo) per minimizzare la perdita predetta sotto un budget vincolato dall'hardware.

Il framework integra tre componenti principali:

Una Scaling Law Quadrimensionale Congiunta: Gli autori adattano una nuova scaling law per i modelli MoE sparsi che include il numero totale di parametri ( $N_{tot}$ ), i token di addestramento ( $D$ ), la sparsità ( $S$ ) e un fattore di divisione degli esperti (expert split factor, $G$ ). $G$ è definito come il rapporto tra la larghezza del feed-forward denso e la larghezza del singolo esperto ( $G = d_{ff}/d_{expert}$ ), catturando la granularità degli esperti. La legge è formulata come:
$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$
Questa formulazione permette di predire la perdita basandosi su scelte geometriche discrete piuttosto che su astrazioni del conteggio dei parametri.
Un Modello di Performance a Livello di Operatore: Per stimare l'efficienza del sistema, gli autori hanno sviluppato un modello analitico delle performance che predice l'MFU e l'impronta di memoria per una data architettura e un layout di parallelismo. Il modello tiene conto di:
- Costi di calcolo (GEMM densi e raggruppati, attention).
- Overhead di comunicazione (all-to-all per l'expert parallelism, pipeline bubble, collettivi di data-parallelism).
- Latenza di dispatch della CPU (critica per micro-batch piccoli).
- Fattori di calibrazione specifici dell'hardware per stragglers intra-nodo e overlap inter-nodo.
  Il modello è validato rispetto a sessioni di addestramento fino a 18 miliardi di parametri attivi, raggiungendo un errore percentuale assoluto medio (MAPE) inferiore al 15% nella predizione dell'MFU.
Ottimizzazione Congiunta (MINLP): MOSAIC risolve un programma non lineare intero misto (MINLP) che minimizza la perdita predetta soggetto al vincolo che i Model FLFLOPs richiesti ( $C_{model}$ ) non superino i Deliverable Model FLOPs ( $C_{deliverable}$ ).
$C_{deliverable} = C_{peak} \times \text{MFU}(Z, P_\ell, B) \times \eta_{good}$
Qui, $C_{peak}$ è il tetto massimo dell'hardware, e l'MFU dipende dall'architettura. L'ottimizzazione cerca in una griglia discreta di geometrie realizzabili ( $Z$ ) e piani di esecuzione ( $P_\ell$ ) per trovare la configurazione che minimizza la perdita entro le capacità reali del cluster.

Contributi Chiave

Riformulazione del Budget di Calcolo: Il documento dimostra che per i modelli MoE sparsi, l'ottimizzazione sotto un budget fisso di $C_{model}$ porta a un comportamento di "ricerca del confine" (boundary-seeking), dove l'ottimalità della sparsità risiede al limite superiore del supporto dei dati (ovvero, il modello più sparso possibile). Questo accade perché la scaling law predice una perdita inferiore per modelli più sparsi a parità di FLOPs, ignorando il costo sistemistico.
Co-Design Consapevole dei Sistemi: Accoppiando la scaling law con un modello di performance, MOSAIC sposta il budget da $C_{model}$ a $C_{deliverable}$ . Ciò rivela che la sparsità ottimale è un punto interiore determinato dai vincoli specifici del cluster (memoria, banda, overhead di parallelismo), piuttosto che dal confine.
Validazione del Modello di Performance: Gli autori forniscono un modello di performance validato a livello di operatore che predice accuratamente l'MFU e identifica il layout di parallelismo ottimale (Tensor, Expert, Pipeline, Data Parallelism) per i MoE sparsi, mostrando che il "miglior" layout dipende fortemente dalla specifica geometria e dimensione del cluster.
Validazione Empirica: Il framework è stato testato su nodi AWS p6 (GPU NVIDIA B200) con sessioni fino a 250 miliardi di parametri totali. I risultati hanno confermato che la classificazione delle configurazioni basata sui Model FLOPs differisce significamente dalla classifica basata sull'efficienza del calcolo hardware (tempo wall-clock).

Risultati

Ottimi di Confine vs. Ottimi Interiori: Sotto un budget fisso di $C_{model}$ , il loss calcolato diminuisce monotonicamente con l'aumentare della sparsità, spingendo l'ottimo verso il confine ( $S_{max}$ ). Tuttavia, sotto un budget hardware fisso ( $C_{deliverable}$ ), la curva del loss presenta un minimo interiore. I costi di sistema (comunicazione, memoria) di modelli estremamente sparsi finiscono per superare i loro benefici teorici di loss.
Trade-off Loss vs. Throughput: In esperimenti con un budget di 20 giorni su 32 nodi, la configurazione che ha realizzato il maggior numero di Model FLOPs (una geometria di esperti più densa e grossolana) non ha ottenuto il loss più basso. Al contrario, la configurazione ottimale per il loss (una geometria di esperti più sparsa e fine) ha mantenuto un MFU inferiore ma ha ottenuto un loss finale più basso perché era l'unica configurazione in grado di rientrare nel vincolo dei FLOPs deliverable mantenendo una traiettoria di loss favorevole.
Validazione nel Mondo Reale: Sessioni di pretraining a stadi su cluster a 8 nodi hanno validato il framework. L'ordinamento misurato dell'MFU corrispondeva all'ordinamento predetto. Inoltre, tracciando il loss rispetto al "calcolo hardware equivalente al picco" (tenendo conto dell'MFU), la classifica delle configurazioni è cambiata rispetto alla classifica basata sui Model FLOPs grezzi, confermando che il modello "compute-ottimale" non è il modello "cluster-ottimale".

Significatività
Il documento sostiene la necessità di un cambiamento fondamentale nel modo in cui vengono addestrati i modelli linguistici di frontiera: passare da fasi disconnesse di "selezione della scaling law" e "tuning dei sistemi" a una co-progettazione architettura-sistemi unificata. Gli autori affermano che fare affidamento esclusivamente sui budget di Model FLOPs è insufficiente per i modelli MoE sparsi perché non riesce a contabilizzare l'efficienza di sistema dell'architettura. Introducendo MOSAIC, dimostrano che la geometria ottimale del modello non è una costante universale ma è contingente allo specifico cluster hardware, alla finestra temporale di addestramento e ai vincoli di parallelismo. Questo approccio assicura che l'architettura selezionata sia non solo teoricamente ottimale per il loss, ma anche praticamente fattibile ed efficiente sull'hardware di destinazione.

Articoli simili