Radar · 23/07/2026 · fatto del 21/07/2026

Due paper convergono: la memoria dell'ottimizzatore è il collo di bottiglia nei MoE a scala di trilioni

Due paper usciti su Hugging Face Daily Papers (22-23 luglio 2026) affrontano lo stesso collo di bottiglia da due angoli. SLAI T-Rex documenta il post-training completo di DeepSeek-V4, un MoE da trilioni di parametri, su un cluster Ascend NPU SuperPOD: pressione di memoria severa, comunicazione non sovrapposta, kernel inefficienti. “Where Should Optimizer State Live?” quantifica il problema alla radice: in un MoE da 6,78 miliardi di parametri, AdamW accumula 50,6 GB di stato dell’ottimizzatore per aggiornare 12,6 GB di pesi. Lo stato dell’ottimizzatore è la voce più grande nel budget di memoria.

Perché ti riguarda: come raccontavamo il 22 luglio, AMD ha messo 5 miliardi e 2 GW di GPU dietro Anthropic. Questo è il lato tecnico di quell’investimento. Addestrare modelli a scala di trilioni richiede più che comprare chip: la memoria che serve all’algoritmo di training per tenere traccia dei gradienti cresce più velocemente dei parametri stessi. SkewAdam, l’ottimizzatore del secondo paper, assegna precisioni diverse alle tre componenti di un MoE (backbone denso, esperti, router) in base alle loro statistiche di gradiente. Taglia il 97,4% dello stato dell’ottimizzatore: da 50,6 GB a 1,29 GB. La memoria di picco scende da 81,4 GB a 31,3 GB, portando il training di MoE da miliardi di parametri entro il budget di una GPU da 40 GB. Per chi costruisce modelli o valuta i vincoli infrastrutturali, è il dettaglio che separa un cluster che gira da uno che sta fermo.

Nel dettaglio

Il problema dello stato dell’ottimizzatore spiega perché addestrare modelli grandi costa tanto. Quando alleni un modello con AdamW (l’ottimizzatore standard per i LLM), l’algoritmo non conserva solo i pesi: tiene anche una copia dei gradienti passati (primo momento) e una stima della loro varianza (secondo momento). Per ogni parametro servono due valori aggiuntivi in memoria, più il parametro stesso. Su un modello denso questo raddoppia o triplica la memoria necessaria. Su un MoE il problema è più sottile.

Un MoE ha tre popolazioni di parametri con caratteristiche molto diverse: il backbone denso (piccolo ma aggiornato a ogni passo), gli esperti (grandi ma attivati raramente) e il router (minuscolo ma critico per il routing). AdamW li tratta tutti allo stesso modo, assegnando a ciascuno la stessa quantità di stato. Il paper “Where Should Optimizer State Live?” parte da un’osservazione: le statistiche dei gradienti di queste tre popolazioni sono così diverse che trattarle uniformemente è uno spreco.

SkewAdam assegna precisioni diverse alle tre componenti. Il backbone denso riceve stato a piena precisione, gli esperti ricevono stato a precisione ridotta, il router riceve un trattamento intermedio. Il risultato, misurato su un MoE da 6,78 miliardi di parametri: lo stato dell’ottimizzatore passa da 50,6 GB a 1,29 GB, un taglio del 97,4%. La memoria di picco totale scende da 81,4 GB a 31,3 GB, portando il training entro il budget di una GPU da 40 GB senza perdita misurabile nella perplexity di validazione.

Il paper di SLAI T-Rex affronta il problema dall’altro lato: non l’ottimizzatore, ma l’infrastruttura. Il post-training completo di DeepSeek-V4 su un cluster Ascend NPU SuperPOD richiede di gestire pressione di memoria, overhead di comunicazione e kernel inefficienti. Il paper documenta l’ottimizzazione end-to-end su hardware non-NVIDIA, un dettaglio che conta perché il mercato del compute si sta allargando oltre CUDA.

I due paper convergono su un punto: a scala di trilioni di parametri, la memoria è il collo di bottiglia principale, più della potenza di calcolo grezza. Lo stato dell’ottimizzatore è la voce più grande nel budget, e distribuirlo bene (con precisione differenziata o con architetture di sistema ridisegnate) è ciò che fa funzionare un cluster invece di fermarlo.

Cosa resta aperto. SkewAdam è testato su un MoE da 6,78 miliardi di parametri, non su trilioni. La scalabilità della precisione ridotta a scala reale è una questione aperta. Il paper di SLAI T-Rex è una pratica di ingegneria documentata su hardware specifico (Ascend), non un risultato generalizzabile a qualsiasi cluster. Entrambi i paper sono preprint su Hugging Face, senza revisione paritaria al 23 luglio 2026.

Scrivi per cercare fra corso, playbook, skill, paper…