In che modo il routing Mixture-of-Experts modifica il calcolo dei modelli locali?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Il routing Mixture-of-Experts cambia il calcolo dei modelli locali inviando ogni token attraverso solo un piccolo sottoinsieme di reti feed-forward esperte, invece di attivare ogni esperto.

Questo rende insolito un modello MoE di grandi dimensioni su un server domestico: il suo checkpoint complessivo può essere enorme, mentre il calcolo degli esperti eseguito per un singolo token può essere paragonabile a quello di un modello attivo molto più piccolo. Il vantaggio è nell’aritmetica sparsa, non nella memoria gratuita. I pesi degli esperti devono comunque essere archiviati e il routing tra più dispositivi può trasformare parte del calcolo risparmiato in comunicazione.

Un Transformer denso attiva gli stessi parametri feed-forward per ogni token

In un normale livello di Transformer denso, ogni token passa attraverso la stessa rete feed-forward. Aumentare il numero di parametri feed-forward aumenta quindi sia le dimensioni del modello sia la quantità di calcoli eseguiti per ogni token.

Switch Transformer mette a confronto questo approccio con i livelli Mixture-of-Experts ad attivazione sparsa, nei quali token diversi possono selezionare sottoinsiemi diversi di parametri.

Per l’inferenza locale, questa è la prima distinzione degli MoE: i parametri totali determinano la quantità di stato del modello da archiviare, mentre i parametri attivati determinano gran parte del calcolo degli esperti per ogni token.

Un router assegna un punteggio a ogni token rispetto agli esperti disponibili

In un livello MoE, un piccolo router analizza la rappresentazione del token e produce punteggi o probabilità per gli esperti candidati. Il runtime ne seleziona quindi un numero limitato, generalmente top-1 o top-k a seconda dell’architettura.

Megatron Core di NVIDIA espone un router che determina a quali esperti viene inviato ciascun token. La decisione di routing modifica quali matrici degli esperti elaboreranno quel token.

Due token dello stesso prompt possono quindi attivare pesi degli esperti diversi, anche se condividono l’attenzione e le altre parti dense del modello.

L’attivazione sparsa riduce il calcolo degli esperti, ma non l’archiviazione complessiva dei pesi

Se un livello contiene otto esperti ma instrada ogni token verso due di essi, per quel token vengono eseguiti solo i calcoli degli esperti selezionati. Le matrici degli altri esperti rimangono inattive in quel passaggio.

La ricerca Expert Choice descrive gli MoE come un approccio che aumenta il numero di parametri mantenendo relativamente limitato il calcolo per token. Per questo un checkpoint MoE può dichiarare un numero totale di parametri molto elevato, ma una quantità di parametri attivi molto più ridotta.

Un server domestico deve comunque avere l’intero insieme di pesi degli esperti disponibile da qualche parte, a meno che il runtime non li trasferisca in streaming o non li scarichi su altri supporti. Il calcolo sparso non equivale a un’archiviazione sparsa.

La distribuzione degli esperti può trasformare il routing in comunicazione tra dispositivi

Su una singola GPU, la selezione di un esperto modifica principalmente quali blocchi di pesi locali vengono letti. Su più GPU, gli esperti possono essere distribuiti in modo tale che la rappresentazione di un token debba raggiungere il dispositivo che ospita l’esperto selezionato, per poi tornare al flusso principale del livello.

Il design di inferenza MoE di DeepSpeed assegna gruppi di esperti utilizzando il parallelismo tra esperti su più GPU. Il routing include quindi sia la comunicazione sia la moltiplicazione di matrici.

Un piccolo server domestico con più GPU può quindi diventare limitato dall’interconnessione anche quando il calcolo per ogni token è sparso. La topologia PCIe e il supporto peer-to-peer sono più importanti di quanto suggerisca il solo numero di parametri attivi.

Un routing sbilanciato crea esperti sovraccarichi e capacità inutilizzata

I prompt reali non distribuiscono necessariamente i token in modo uniforme. Se molti token scelgono lo stesso esperto, quel dispositivo o kernel diventa un punto critico mentre gli altri esperti rimangono in attesa.

MoETuner identifica il routing sbilanciato dei token e l’attivazione degli esperti come colli di bottiglia pratici per l’erogazione, perché alcuni dispositivi possono accumulare più lavoro instradato e più comunicazioni rispetto ad altri.

Nell’inferenza locale, un routing non uniforme può manifestarsi come una latenza variabile dei token tra prompt diversi, anche quando la lunghezza del contesto e le dimensioni del modello sono simili. Il modello sceglie dinamicamente un percorso di calcolo diverso.

Pianifica la capacità locale per gli MoE separando i pesi totali dal percorso attivo

Una stima hardware utile registra le dimensioni complessive dei pesi del modello, il numero di esperti attivi per token, il costo dei livelli densi, la cache KV, la quantizzazione e il fatto che gli esperti risiedano su un singolo acceleratore, su più GPU, nella RAM della CPU o nello spazio di archiviazione.

La guida di ZimaSpace sulla memoria per l’IA locale e alla pianificazione degli acceleratori offre il contesto più ampio sulla capacità dei server domestici. Gli MoE aggiungono un’ulteriore distinzione tra capacità residente e calcolo attivo.

Esegui benchmark con prompt relativi ad attività diverse, perché i modelli di routing possono variare. Misura token al secondo, utilizzo per dispositivo, carico degli esperti, traffico di comunicazione e permanenza in memoria, invece di presumere che il numero dichiarato di parametri attivi predica il comportamento dell’intero sistema.

Per i checkpoint locali particolarmente grandi, l’analisi della distribuzione dei modelli di grandi dimensioni di ZimaSpace affronta la questione complementare della capacità. Il routing modifica il calcolo attivo, ma la permanenza complessiva dei pesi e la loro distribuzione tra i dispositivi determinano comunque la praticità del modello.

Hub Tecnologico e AI

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.