Il problema dei modelli sparse Mixture-of-Experts non è soltanto l'instradamento irregolare. Quando si addestrano modelli MoE su nodi con memoria GPU limitata, le copie aggiuntive degli esperti — introdotte per ridistribuire il carico di calcolo — entrano in competizione con i buffer associati ai token. LRMoE, un sistema di training memory-aware, affronta la questione dall'altro lato: invece di aumentare la capacità disponibile, ricalibra la domanda generata dal passaggio all'indietro e bilancia il lavoro che viene effettivamente mantenuto.

Il sistema distingue due fasi. Nella forward execution, pianifica quote di retention e collocamento degli esperti sotto vincoli di risorse, senza eliminare alcun calcolo instradato. Nella retropropagazione, una metrica di load recalibration stima il contributo di ciascuna coppia token-esperto all'aggiornamento dell'esperto e seleziona le coppie all'interno delle quote. Un algoritmo di instradamento capacity-aware distribuisce poi le coppie trattenute tra le istanze eleggibili degli esperti originali. Infine una compattazione fisica riduce le dimensioni dei payload di comunicazione e trasforma le operazioni GEMM in gruppi a dimensione variabile: meno traffico all'indietro, meno calcolo e meno pressione sui buffer di esecuzione.

L'impatto misurato è netto: su Qwen3-30B-A3B e GLM4.5-106B-A12B, LRMoE riduce il tempo cumulativo di addestramento degli strati MoE per raggiungere obiettivi di loss prefissati dal 21,2% al 44,8% rispetto a SYMI. Il dato non riguarda un micro-benchmark di laboratorio, ma la durata complessiva necessaria per arrivare a un determinato risultato di loss.

La tesi di fondo è che la memoria diventa la variabile di progetto, non un limite esterno. Molti sistemi di training per MoE trattano la memoria come un vincolo quando replica gli esperti, ma la lasciano invariata nella fase di aggiornamento. LRMoE sposta la contabilità al livello delle coppie token-esperto: non tutte contribuiscono in modo uguale all'aggiornamento, quindi trattenere solo quelle più utili entro le quote riduce il fabbisogno di buffer senza richiedere più VRAM. Questo è un cambio di prospettiva: se il costo marginale di un token nel passaggio all'indietro dipende dalla sua utilità per l'esperto, allora si può fare training di modelli MoE più grandi su nodi che prima sarebbero stati scartati.

Le implicazioni di secondo ordine toccano chi gestisce infrastrutture private. I nodi con memoria limitata sono spesso quelli già presenti nei data center aziendali, non i cluster GPU di ultima generazione. Un sistema che riduce il tempo di training senza imporre nuovo hardware rende più credibile la strada on-premise per i modelli MoE, perché abbassa il costo incrementale di usare GPU con meno memoria. Non è un argomento solo di TCO: è anche una questione di controllo. Meno dipendenza da cloud con GPU ad alta capacità significa poter addestrare senza spostare i dati.

C'è poi un terzo ordine: l'ottimizzazione si sposta dai FLOPs alla gestione della memoria e della comunicazione. I GEMM raggruppati a dimensione variabile e la compattazione fisica segnalano che il prossimo collo di bottiglia non è il calcolo, ma il movimento dei dati e l'occupazione dei buffer. Per i progettisti di infrastrutture AI, questo sposta l'attenzione su interconnessioni, memoria e scheduling, più che sulla potenza di calcolo pura.

Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per leggere questi trade-off.