💬 NLP

MoE-Prism: Disentangling Monolithic Experts for Elastic MoE Services via Model-System Co-Designs

MoE-Prism è un framework di co-design modello-sistema che abilita l'elasticità computazionale a livello di richiesta nel serving di Mixture-of-Experts (MoE) decomponendo gli esperti monolitici in sub-esperti a grana fine e implementando un runtime $k$ -aware, migliorando così significativamente il throughput e riducendo la latenza per carichi di lavoro eterogenei.

Autori originali: Xinfeng Xia, Xiaofeng Hou, Jiacheng Liu, Wenfeng Wang, Mingxuan Zhang, Peng Tang, Chao Li, Minyi Guo

Pubblicato 2026-08-11

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Xinfeng Xia, Xiaofeng Hou, Jiacheng Liu, Wenfeng Wang, Mingxuan Zhang, Peng Tang, Chao Li, Minyi Guo

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 gestire una biblioteca enorme e super intelligente dove i libri non sono scritti da esseri umani, ma da un cervello digitale gigante chiamato Large Language Model (LLM). Questi cervelli diventano sempre più grandi e intelligenti ogni giorno, ma sono anche incredibilmente affamati di elettricità e potenza di calcolo. Per renderli più veloci ed economici da gestire, gli scienziati hanno inventato un trucco astuto chiamato "Mixture-of-Experts" (MoE). Pensa a un modello MoE non come a un unico cervello gigante, ma come a un team di molti specialisti più piccoli (esperti) che lavorano insieme. Quando poni una domanda, il sistema non risveglia l'intero team; chiama solo alcuni esperti specifici che sono i migliori su quell'argomento. È come chiedere a un bibliotecario di andare a prendere solo i libri dalla sezione "Fantascienza" invece di trascinare l'intera biblioteca sulla tua scrivania.

C'è però un problema. Attualmente, questi sistemi sono un po' rigidi. Indipendentemente dal fatto che tu stia ponendo una domanda semplice come "Che tempo fa?" o una complessa come "Analizza questo contratto legale di 50 pagine", il sistema spesso risveglia lo stesso identico numero di esperti. È come assumere un'intera squadra di costruzione per appendere un singolo quadro, o inviare un singolo stagista per costruire un grattacielo. Questo spreca energia per i compiti facili o non fornisce abbastanza potenza per quelli difficili. La grande domanda che i ricercatori si pongono è: Possiamo rendere questi team di IA più flessibili, permettendo di aumentare o diminuire il numero di esperti in base a quanto è difficile il lavoro, il tutto mantenendo il sistema veloce ed efficiente?

È esattamente questo che i ricercatori dietro a MOE-PRISM si sono posti l'obiettivo di risolvere. Si sono resi conto che, sebbene l'idea di "aumentare o diminuire" gli esperti suoni ottima, la tecnologia attuale è troppo goffa per farlo in modo fluido. Hanno scoperto che il sistema esistente tratta ogni esperto come un mattone gigante e indivisibile — non puoi usare mezzo mattone. Se hai bisogno di un po' meno potenza, devi rimuovere un intero esperto, il che rappresenta un salto enorme che spesso rovina la qualità della risposta. Inoltre, quando il sistema cerca di gestire molte richieste contemporaneamente (come una biblioteca affollata), tende a raggrupparle tutte insieme e a usare l'impostazione "massima" per tutti, sprecando energia per le richieste facili solo per mantenere grande la dimensione del batch.

Per risolvere questo problema, il team ha costruito un nuovo framework chiamato MOE-PRISM. Hanno affrontato il problema da due angolazioni: il "modello" (il cervello stesso) e il "sistema" (il gestore della biblioteca).

Per prima cosa, sul lato del modello, hanno inventato un modo per rompere quei giganteschi "mattoni esperti" in pezzi più piccoli e raffinati. Immagina di prendere un grande blocco di formaggio pesante e di tagliarlo in molti cubetti più piccoli. Lo hanno fatto osservando come si illuminano i neuroni interni dell'IA (le minuscole unità di elaborazione all'interno di un esperto) quando lavorano. Hanno notato che, per qualsiasi compito, solo un sottoinsieme specifico di questi neuroni è davvero importante. Così, hanno tagliato gli esperti in "sub-esperti" più piccoli che raggruppano questi neuroni importanti. Ciò consente al sistema di scegliere, ad esempio, 12,5 sub-esperti invece di essere costretto a scegliere tra 12 o 13 esperti interi. Questo fornisce un "pomello" molto più fluido per controllare quanta potenza di calcolo viene utilizzata, senza dover riaddestrare l'intera IA da zero.

In secondo luogo, sul lato del sistema, hanno creato un "manager" più intelligente per la biblioteca. Inveve di lanciare semplicemente tutte le richieste in un unico grande mucchio e usare l'impostazione più alta per tutti, questo nuovo manager raggruppa le richieste che necessitano di quantità simili di potenza. Se arrivano un sacco di domande facili, vengono elaborate insieme con un'impostazione a bassa potenza. Se arrivano un sacco di domande difficili, queste avranno il loro gruppo ad alta potenza. Ciò evita che il sistema sprechi energia sovra-servendo i compiti facili solo per mantenere pieno il batch. Hanno anche costruito un particolare "controllore del traffico" che gestisce in modo efficiente i grafici CUDA, assicurando che, anche con tutte queste diverse impostazioni, il sistema non si intasi a causa di problemi di memoria.

Quando hanno testato MOE-PRISM su tre diversi modelli di IA popolari, i risultati sono stati promettenti. Hanno scoperto che, utilizzando questi esperti più granulari e la gestione più intelligente, potevano aumentare il numero di "impostazioni di potenza" disponibili di 4 volte. Nei loro test, questo ha portato a un miglioramento del 33,9% nel modo in cui il sistema può gestire le richieste contemporaneamente (throughput) per i compiti offline. Per i compiti online, dove la velocità è critica, ha ridotto il tempo necessario per ottenere la prima parola di una risposta (Time-to-First-Token) quando si gestiscono carichi di lavoro misti.

Il documento suggerisce che questo approccio non serve solo a risparmiare denaro sull'elettricità; rende l'IA più adattabile. Dimostra che si può avere un singolo modello di IA che può essere "elastico", estendendo la sua potenza di calcolo per i compiti difficili e restringendola per quelli facili, il tutto senza svuotare il portafoglio o rallentare. Sebbene gli attuali test siano stati eseguiti su configurazioni specifiche con due schede grafiche, i risultati indicano che questo "refactoring" della struttura interna dell'IA e il "ripensamento" di come programmare il lavoro potrebbe essere un grande passo verso un'IA più efficiente e flessibile nel mondo reale.

Riepilogo Tecnico: MOE-PRISM

1. Definizione del Problema

Le architetture Mixture-of-Experts (MoE) sono diventate centrali per i grandi modelli linguistici (LLM) per scalare la capacità senza aumenti proporzionali della computazione. Tuttavia, i sistemi di serving MoE esistenti eseguono tipicamente tutte le richieste sotto una configurazione di routing fissa (un top- $k$ statico), fallendo nel sfruttare i requisiti computazionali eterogenei tra le diverse richieste. Sebbene alcuni approcci ottengano un'"elasticità computazionale a livello di richiesta" tramite il cascading di più modelli o l'uso di meccanismi di early-exit, questi metodi introducono costi significativi di memoria/deployment o richiedono cambiamenti specializzati nell'architettura o nell'addestramento.

Il documento identifica due lacune primarie che impediscono un'efficace elasticità a livello di richiesta all'interno di un singolo istanza MoE:

Unità di Routing Grossolane: Il routing nativo MoE tratta interi esperti come unità indivisibili. Ridurre il budget di routing $k$ di una unità rimuove un intero esperto, causando un calo netto e discreto della qualità del modello e limitando i punti operativi disponibili nello spazio di compromesso tra computazione e qualità.
Batching Eterogeneo Inefficiente: I sistemi di serving come vLLM utilizzano il continuous batching. Quando vengono miscelate richieste con diversi budget di routing, il sistema tipicamente esegue il batch al valore massimo di $k$ richiesto per garantire la qualità, portando a un "over-serving" (sovra-servizio) e a uno spreco di computazione. Al contrario, dividere i batch per preservare i budget frammenta l'esecuzione, riducendo il throughput.

2. Metodologia: MOE-PRISM

MOE-PRISM è un framework di supporto modello-sistema progettato per abilitare l'elasticità computazionale a livello di richiesta all'interno di una singola istanza di serving MoE. Affronta il problema attraverso due componenti co-progettati:

A. Motore di Refactoring del Modello (Lato Modello)

Questa componente trasforma il modello per esporre uno spettro più denso di punti operativi di routing senza richiedere un riaddestramento end-to-end.

Decomposizione degli Esperti: Il motore profila le attivazioni dei neuroni intermedi su dati di calibrazione. Osserva che la massa di attivazione all'interno di un esperto è concentrata in sottoinsiemi di neuroni dipendenti dai token.
Partizionamento dei Sub-Esperti: Utilizzando un risolutore di partizionamento delle ottimizzazioni (inizializzazione greedy seguita da simulated annealing), ogni esperto monolitico viene suddiviso in $N$ sub-esperti più fini e disgiunti. Il partizionamento mira a raggruppare i neuroni che si co-attivano attraverso i token, garantendo che saltare un sub-esperto minimizzi la perdita di qualità.
Ricostruzione del Gating: Il sistema ricostruisce l'interfaccia di routing per i nuovi sub-esperti tramite due percorsi:
1. Proxy Senza Addestramento: Un meccanismo di selezione gerarchica che utilizza le statistiche di co-attivazione per punteggiare i sub-esperti, permettendo un deployment immediato.
2. Fine-Tuning Solo del Gate: Un adattamento a basso costo in cui vengono raffinati solo i pesi del router (con il resto del modello congelato) per allinearsi con lo spazio espanso dei sub-esperti, massimizzando la fedeltà.

B. Runtime di Serving k-Aware (Lato Sistema)

Questa componente gestisce efficientemente l'esecuzione di budget di routing eterogenei.

Scheduler di Serving k-Aware:
- Offline (Orientato al Throughput): Utilizza la separazione temporale tramite batching stratificato per qualità. Le richieste sono ordinate per il loro budget di routing ( $k$ ) e raggruppate in tier. Lo scheduler decide se inviare immediatamente un batch residuo o unirlo al tier successivo in base a un'euristica locale del throughput, minimizzando l'over-serving pur mantenendo la pienezza del batch.
- Online (Sensibile alla Latenza): Utilizza la separazione spaziale tramite routing a corsie (lane-based). I rank di data-parallel (DP) sono partizionati in corsie "low- $k$ " e "high- $k$ " con un confine morbido e adattivo. Ciò evita di miscelare budget molto diversi nello stesso stream di esecuzione evitando al contempo una partizione rigida che potrebbe causare accumuli di code.
Esecutore di Grafi Segmentato: Per gestire l'aumento degli stati di routing senza far esplodere l'uso della memoria di CUDA Graph, l'esecutore divide il blocco Transformer all'interfaccia Attention-MoE.
- Segmenti di Attention: Condivisi tra diversi valori di $k$ (insensibili al routing).
- Segmenti MoE: Specializzati per il budget di routing $k$ (sensibili al routing).
- Questo design permette al sistema di mantenere l'efficienza di CUDA Graph pur supportando l'esecuzione dinamica di $k$ .

3. Contributi Chiave

Metodo di Refactoring del Modello: Una tecnica per scomporre gli esperti monolitici in sub-esperti e ricostruire la rete di gating, consentendo a un singolo modello di esporre punti operativi di routing più densi. Supporta il deployment senza addestramento e il fine-tuning opzionale solo del gate.
Runtime di Serving k-Aware: Un'estensione di vLLM che combina lo scheduling consapevole del budget (separazione temporale e spaziale) con l'esecuzione efficiente di dinamica- $k$ tramite un esecutore di grafi segmentato.
Integrazione di Sistema e Valutazione: Piena integrazione in vLLM e valutazione su tre modelli MoE rappresentativi (OLMoE, DeepSeek-V2-Lite, Qwen3), dimostrando un'elasticità pratica.

4. Risultati Sperimentali

Gli autori hanno valutato MOE-PRISM su tre modelli utilizzando il framework vLLM su GPU A100, RTX A6000 e H800.

Throughput (Offline): MOE-PRISM ha migliorato il throughput dell'inferenza offline fino al 33,9% rispetto ai baseline. I guadagni derivano sia dalla capacità di eseguire un $k$ inferiore (tramite refactoring) sia dalla capacità dello scheduler di raggruppare richieste simili per evitare l'over-serving.
Latenza (Online): Sotto carichi di lavoro eterogenei, MOE-PRISM ha ridotto il Time-to-First-Token (TTFT), particolarmente nei carichi elevati dove i baseline soffrono di ritardi di accodamento e latenza di coda.
Accuratezza: Il refactoring del modello ha preservato ampiamente l'accuratezza dei modelli originali. In alcuni casi (ad esempio, OLMoE e Qwen3 a budget inferiori), i modelli rifattorizzati hanno ottenuto una perplexity o un'accuratezza sui task downstream leggermente migliori, suggerendo che la nuova struttura supporta una selezione efficace degli esperti sotto computazione limitata.
Studi di Ablazione:
- Refactoring: Ha confermato che la decomposizione fine-grained riduce significativamente l'overshoot del budget di routing rispetto all'arrotondamento coarse-grained.
- Grafico Segmentato: Ha mostrato che l'esecutore riduce l'uso della memoria del grafo di circa l'84% (rispetto a un approccio standard k-aware) con una penalità di throughput trascurabile (<0,2%).
- Scheduling: Ha dimostrato che l'esecuzione dinamica di $k$ da sola è insufficiente; è richiesto uno scheduling esplicito per prevenire l'interferenza cross- $k$ e realizzare i guadagni di prestazione end-to-end.

5. Significato e Rivendicazioni

Il documento afferma che MOE-PRISM dimostra la fattibilità pratica dell'elasticità computazionale a livello di richiesta nel serving MoE. Trattando il top- $k$ di routing come un controllo a runtime piuttosto che come un'impostazione architettonica fissa, il sistema può:

Servire richieste con diversi requisiti di qualità/computazione all'interno di un'unica istanza di modello distribuita.
Tradurre budget di routing eterogenei in miglioramenti tangibili di latenza e throughput end-to-end.
Evitare l'overhead di memoria e deployment associato al cascading di più modelli.

Gli autori notano un limite: la valutazione è attualmente limitata a testbed a due GPU, che rappresenta l'ambiente minimo non banale per validare il meccanismo centrale. Non rivendicano una scalabilità immediata a cluster massivi senza ulteriore ingegneria, ma i risultati stabiliscono i principi fondamentali di co-design modello-sistema per il serving MoE elastico.