Miscela di Esperti Spiegata

La Miscela degli Esperti Spiegata in Dettaglio

Con il rilascio di Mixtral 8x7B (annuncio, scheda del modello), una classe di trasformatore è diventata il tema più caldo nella comunità dell’open AI: il Mixture of Experts, o MoE per breve. In questo post del blog, esamineremo i mattoni di base del MoE, come vengono addestrati e i compromessi da considerare quando li si utilizza per l’inferezione.

Andiamo a scoprirlo!

Indice

TL;DR

MoE:

  • Viene pre-trainato molto più velocemente rispetto ai modelli densi
  • Ha inferezione più veloce rispetto a un modello con lo stesso numero di parametri
  • Richiede alta VRAM poiché tutti gli esperti vengono caricati in memoria
  • Affronta molte sfide nell’affinamento, ma lavori recenti con l’istruzione MoE-tuning sono promettenti

Andiamo avanti!

Cosa è un Mixture of Experts (MoE)?

La scalabilità di un modello è uno degli assi più importanti per una migliore qualità del modello. Dato un budget di calcolo fisso, addestrare un modello più grande per meno passaggi è migliore che addestrare un modello più piccolo per più passaggi.

Mixture of Experts consente ai modelli di essere preaddestrati con molto meno calcolo, il che significa che è possibile aumentare notevolmente la dimensione del modello o del dataset con lo stesso budget di calcolo di un modello denso. In particolare, un modello MoE dovrebbe raggiungere la stessa qualità del suo equivalente denso molto più velocemente durante il preaddestramento.

Allora, cosa esattamente è un MoE? Nel contesto dei modelli di trasformatori, un MoE è composto da due elementi principali:

  • Strati MoE sparsi vengono utilizzati invece di strati densi di feed-forward network (FFN). Gli strati MoE hanno un certo numero di “esperti” (ad esempio, 8), dove ogni esperto è una rete neurale. Nella pratica, gli esperti sono FFN, ma possono anche essere reti più complesse o anche un MoE stesso, portando a MoE gerarchici!
  • Una rete gate o router determina quali token vengono inviati a quali esperti. Ad esempio, nell’immagine sottostante, il token “More” viene inviato al secondo esperto e il token “Parameters” viene inviato alla prima rete. Come esploreremo in seguito, possiamo inviare un token a più di un esperto. Come indirizzare un token a un esperto è una delle decisioni più importanti quando si lavora con MoE: il router è composto da parametri appresi ed è preaddestrato allo stesso tempo del resto della rete.
Strato MoE dal [Switch Transformers paper](https://arxiv.org/abs/2101.03961)

Quindi, per riassumere, negli MoE sostituiamo ogni strato FFN del modello di trasformatori con uno strato MoE, che è composto da una rete gate e un certo numero di esperti.

Sebbene gli MoE offrano vantaggi come un preaddestramento efficiente e una inferenza più veloce rispetto ai modelli densi, presentano anche delle sfide:

  • Addestramento: Gli MoE consentono un preaddestramento significativamente più efficiente in termini di calcolo, ma hanno avuto difficoltà storicamente nella generalizzazione durante il fine-tuning, portando all’overfitting.
  • Inferenza: Sebbene una MoE possa avere molti parametri, solo alcuni di essi vengono utilizzati durante l’inferenza. Ciò porta a un’infrenza molto più veloce rispetto a un modello denso con lo stesso numero di parametri. Tuttavia, tutti i parametri devono essere caricati in RAM, quindi i requisiti di memoria sono elevati. Ad esempio, data una MoE come Mixtral 8x7B, avremo bisogno di una VRAM sufficiente per contenere un modello denso con 47B di parametri. Perché 47B di parametri e non 8 x 7B = 56B? Questo perché nei modelli MoE, solo gli strati FFN vengono considerati come esperti individuali e il resto dei parametri del modello sono condivisi. Allo stesso tempo, presumendo che vengano utilizzati solo due esperti per token, la velocità di inferenza (FLOPs) è simile all’utilizzo di un modello da 12B (rispetto a un modello da 14B), perché calcola moltiplicazioni di matrici 2x7B, ma con alcuni strati condivisi (ne parleremo più avanti).

Ora che abbiamo un’idea generale di cosa sia un MoE, diamo un’occhiata agli sviluppi della ricerca che hanno portato alla loro invenzione.

Una breve storia del MoE

  • Esperti come componenti: Nell’organizzazione tradizionale MoE, l’intero sistema comprende una rete di gating e diversi esperti. MoE come modello completo sono stati esplorati in SVM, Gaussian Processes e altri metodi. Il lavoro di Eigen, Ranzato e Ilya ha esplorato MoE come componenti di reti più profonde. Ciò consente di avere MoE come strati in una rete multistrato, rendendo possibile che il modello sia contemporaneamente grande e efficiente.
  • Calcolo condizionale: Le reti tradizionali elaborano tutti i dati di input attraverso ogni strato. In questo periodo, Yoshua Bengio ha studiato approcci per attivare o disattivare dinamicamente i componenti in base al token di input.

Questi lavori hanno portato a esplorare una combinazione di esperti nel contesto dell’NLP. In particolare, Shazeer et al. (2017, con “et al.” che include Geoffery Hinton e Jeff Dean, Chuck Norris di Google) hanno esteso questa idea a un LSTM da 137B (l’architettura NLP di fatto allora, creata da Schmidhuber) introducendo la sparsità, consentendo di mantenere un’inferenza molto veloce anche a una scala elevata. Questo lavoro si è concentrato sulla traduzione ma ha affrontato molte sfide, come elevati costi di comunicazione e instabilità di addestramento.

Strato MoE dal paper Outrageously Large Neural Network

Le MoE hanno permesso di addestrare modelli con trilioni di parametri, come i Switch Transformers con 1,6T di parametri open source, tra gli altri. Le MoE sono state esplorate anche nella Visione Artificiale, ma questo post si concentrerà sul dominio dell’NLP.

Cos’è la Sparsità?

La sparsità utilizza l’idea di calcolo condizionale. Mentre nei modelli densi tutti i parametri vengono utilizzati per tutti gli input, la sparsità ci consente di eseguire solo alcune parti dell’intero sistema.

Approfondiamo ulteriormente l’esplorazione di Shazeer delle MoE per la traduzione. L’idea di calcolo condizionale (parti della rete attive caso per caso) consente di aumentare la dimensione del modello senza aumentare il calcolo, e quindi ciò ha portato all’utilizzo di migliaia di esperti in ogni strato MoE.

Questo setup introduce alcune sfide. Ad esempio, sebbene dimensioni di batch grandi siano generalmente migliori per le prestazioni, le dimensioni di batch nelle MOE vengono effettivamente ridotte man mano che i dati passano attraverso gli esperti attivi. Ad esempio, se il nostro input raggruppato consiste di 10 token, cinque token possono finire in un esperto e gli altri cinque token possono finire in cinque esperti diversi, portando a dimensioni di batch irregolari e sottoutilizzazione. La sezione Making MoE go brrr di seguito discuterà altre sfide e soluzioni.

Come possiamo risolvere questo? Una rete di gating appresa (G) decide a quali esperti (E) inviare una parte dell’input:

y=∑i=1nG(x)iEi(x)y = \sum_{i=1}^{n} G(x)_i E_i(x)y=i=1∑n​G(x)i​Ei​(x)

In questo setup, tutti gli esperti vengono eseguiti per tutti gli input – è una moltiplicazione ponderata. Ma cosa succede se G è 0? In tal caso, non è necessario calcolare le operazioni dell’esperto corrispondente e quindi si risparmiano calcoli. Qual è una tipica funzione di gating? Nella configurazione più tradizionale, utilizziamo una semplice rete con una funzione softmax. La rete imparerà a quale esperto inviare l’input.

Gσ(x)=Softmax(x⋅Wg)G_\sigma(x) = \text{Softmax}(x \cdot W_g)Gσ​(x)=Softmax(x⋅Wg​)

Il lavoro di Shazeer ha anche esplorato altri meccanismi di gating, come la gating Noisy Top-K. Questo approccio di gating introduce un po’ di rumore (regolabile) e quindi conserva i primi k valori. Questo significa:

  1. Aggiungiamo un po’ di rumore

H(x)i=(x⋅Wg)i+StandardNormal()⋅Softplus((x⋅Wnoise)i)H(x)_i = (x \cdot W_{\text{g}})_i + \text{StandardNormal()} \cdot \text{Softplus}((x \cdot W_{\text{noise}})_i)H(x)i​=(x⋅Wg​)i​+StandardNormal()⋅Softplus((x⋅Wnoise​)i​)

  1. Selezioniamo solo i primi k

KeepTopK(v,k)i={viif vi è tra i primi k elementi di v,−∞altrimenti.\text{KeepTopK}(v, k)_i = \begin{cases}v_i & \text{se } v_i \text{ è tra i primi } k \text{ elementi di } v, \\-\infty & \text{altrimenti.}\end{cases}KeepTopK(v,k)i​={vi​−∞​se vi​ è tra i primi k elementi di v,altrimenti.​

  1. Applichiamo la softmax.

G(x)=Softmax(KeepTopK(H(x),k))G(x) = \text{Softmax}(\text{KeepTopK}(H(x), k))G(x)=Softmax(KeepTopK(H(x),k))

Questa sparagnrezza introduce alcune proprietà interessanti. Utilizzando un valore k sufficientemente basso (ad esempio uno o due), possiamo allenarci e eseguire l’inferenza molto più velocemente rispetto a quando molti esperti vengono attivati. Perché non selezionare semplicemente l’esperto migliore? La congettura iniziale era che fosse necessario fare riferimento a più di un esperto per consentire al gate di imparare come inviare dati a esperti diversi, quindi dovevano essere scelti almeno due esperti. La sezione Switch Transformers riconsidera questa decisione.

Perché aggiungiamo il rumore? Per il bilanciamento del carico!

Token per il bilanciamento del carico per MoEs

Come discusso in precedenza, se tutti i nostri token vengono inviati solo a pochi esperti popolari, ciò renderà inefficiente l’allenamento. In un normale allenamento di MoE, la rete di instradamento tende a attivare principalmente pochi esperti. Questo si auto-rinforza poiché gli esperti preferiti vengono addestrati più velocemente e quindi selezionati più volte. Per mitigare questo problema, viene aggiunta una loss ausiliaria per favorire l’attribuzione di uguale importanza a tutti gli esperti. Questa loss garantisce che tutti gli esperti ricevano un numero approssimativamente uguale di esempi di allenamento. Le sezioni seguenti esploreranno anche il concetto di capacità degli esperti, che introduce una soglia di quanti token possono essere elaborati da un esperto. In transformers, la loss ausiliaria è esposta tramite il parametro aux_loss.

MoEs e Transformers

I Transformers sono un caso molto chiaro in cui l’aumento del numero di parametri migliora le prestazioni, quindi non sorprende che Google abbia esplorato questo concetto con GShard, che esplora un aumento dei transformers oltre i 600 miliardi di parametri.

GShard sostituisce ogni altro livello FFN con un livello MoE utilizzando un instradamento al top 2 sia nell’encoder che nel decoder. La figura successiva mostra come appare questa configurazione per la parte dell’encoder. Questa configurazione è molto vantaggiosa per il calcolo su larga scala: quando passiamo a più dispositivi, il livello MoE viene condiviso tra i dispositivi mentre tutti gli altri livelli vengono replicati. Questo è ulteriormente discusso nella sezione “Making MoEs go brrr”.

MoE Transformer Encoder from the GShard Paper

Per mantenere un carico bilanciato ed essere efficienti a scala, gli autori di GShard hanno introdotto un paio di modifiche oltre a una loss ausiliaria simile a quella discussa nella sezione precedente:

  • Instradamento casuale: in una configurazione top-2, viene sempre selezionato il primo esperto, ma il secondo esperto viene selezionato con probabilità proporzionale al suo peso.
  • Capacità dell’esperto: è possibile impostare una soglia di quanti token può elaborare un esperto. Se entrambi gli esperti sono al massimo delle loro capacità, il token viene considerato superfluo e viene inviato alla pagina successiva tramite connessioni residue (o eliminato del tutto in altri progetti). Questo concetto diventerà uno dei più importanti concetti per MoEs. Perché è necessaria una capacità esperto? Poiché tutte le forme di tensori sono staticamente determinate al momento della compilazione, ma non possiamo sapere in anticipo quanti token andranno a ogni esperto, è necessario fissare il fattore di capacità.

Il paper GShard ha contributi che esprimono modelli di calcolo parallelo che funzionano bene per MoEs, ma discuterne esula dallo scopo di questo post del blog.

Nota: quando eseguiamo l’inferenza, solo alcuni esperti verranno attivati. Allo stesso tempo, ci sono calcoli condivisi, come l’attenzione su se stessi, che viene applicata a tutti i token. Ecco perché quando parliamo di un modello di 47B con 8 esperti, possiamo eseguire il calcolo con un modello denso da 12B. Se usiamo i primi 2, verranno utilizzati 14B di parametri. Ma dato che le operazioni di attenzione sono condivise (tra le altre), il numero effettivo di parametri utilizzati è di 12B.

Switch Transformers

Anche se MoEs ha mostrato molte promesse, hanno difficoltà con l’addestramento e la messa a punto. Gli Switch Transformers sono un lavoro molto interessante che approfondisce questi argomenti. Gli autori hanno persino rilasciato un MoE da 1,6 trilioni di parametri su Hugging Face con 2048 esperti, che è possibile eseguire con transformers. Switch Transformers ha ottenuto un’accelerazione del pre-addestramento 4 volte superiore a T5-XXL.

Strato del Transformer Switch del paper Switch Transformer

Come in GShard, gli autori hanno sostituito i livelli FFN con un livello MoE. Il paper Switch Transformers propone un livello Switch Transformer che riceve due input (due token diversi) e ha quattro esperti.

A differenza dell’idea iniziale di utilizzare almeno due esperti, Switch Transformers utilizza una strategia semplificata a singolo esperto. Gli effetti di questo approccio sono:

  • La riduzione dei calcoli del router
  • La dimensione del batch di ogni esperto può essere ridotta almeno a metà
  • La riduzione dei costi di comunicazione
  • La qualità viene preservata

Switch Transformers esplora anche il concetto di capacità degli esperti.

Capacità degli esperti = (token per batch / numero di esperti) × fattore di capacità

La capacità suggerita sopra divide in modo uniforme il numero di token nel batch tra il numero di esperti. Se utilizziamo un fattore di capacità superiore a 1, forniamo un buffer per quando i token non sono perfettamente bilanciati. Aumentare la capacità porterà a una comunicazione inter-dispositivo più costosa, quindi è un compromesso da tenere presente. In particolare, gli Switch Transformers funzionano bene con fattori di capacità bassi (1-1,25)

Gli autori degli Switch Transformers riprendono e semplificano anche la perdita di bilanciamento del carico menzionata nelle sezioni. Per ogni livello Switch, la perdita ausiliaria viene aggiunta alla perdita totale del modello durante l’addestramento. Questa perdita incoraggia un routing uniforme e può essere ponderata utilizzando un iperparametro.

Gli autori sperimentano anche con la precisione selettiva, ad esempio addestrando gli esperti con bfloat16 mentre utilizzano la precisione completa per il resto dei calcoli. La precisione inferiore riduce i costi di comunicazione tra i processori, i costi di calcolo e la memoria per memorizzare i tensori. Gli esperimenti iniziali, in cui sia gli esperti che le reti di gateway erano addestrate con bfloat16, hanno prodotto un addestramento più instabile. Ciò è stato dovuto in particolare al calcolo del router: poiché il router ha una funzione di esponenziazione, è importante avere una precisione più alta. Per mitigare le instabilità, è stata utilizzata la precisione totale anche per il routing.

L'utilizzo della precisione selettiva non degrada la qualità e consente modelli più veloci

Questo notebook illustra l’addestramento fine-tuning degli Switch Transformers per la sintesi, ma suggeriamo di prima rivedere la sezione di adattamento.

Switch Transformers utilizza un’architettura di encoder-decoder in cui hanno fatto un controparte MoE di T5. Il paper GLaM esplora l’aumento della scala di questi modelli addestrando un modello che raggiunge la qualità di GPT-3 utilizzando 1/3 dell’energia (sì, grazie alla minore quantità di calcolo necessaria per addestrare un MoE, è possibile ridurre la produzione di carbonio fino a un ordine di grandezza). Gli autori si sono concentrati su modelli solo con decoder e su valutazioni a pochi o un solo esempio invece che sul fine-tuning. Hanno utilizzato il routing Top-2 e fattori di capacità molto più grandi. Inoltre, hanno esplorato il fattore di capacità come metrica che può essere modificata durante l’addestramento e la valutazione a seconda di quanto calcolo si desidera utilizzare.

Stabilizzazione dell’addestramento con router Z-loss

L’errore di bilanciamento precedentemente discusso può causare problemi di instabilità. Si possono utilizzare vari metodi per stabilizzare i modelli sparsi a scapito della qualità. Ad esempio, l’introduzione del dropout migliora la stabilità ma porta alla perdita di qualità del modello. D’altra parte, l’aggiunta di componenti moltiplicative aumenta la qualità ma diminuisce la stabilità.

Il router z-loss, introdotto in ST-MoE, migliora significativamente la stabilità dell’addestramento senza degradare la qualità penalizzando i grandi logit che entrano nella rete di gating. Poiché questa perdita incoraggia una magnitudine assoluta dei valori più piccola, gli errori di arrotondamento vengono ridotti, il che può avere un impatto significativo per funzioni esponenziali come il gating. Consigliamo di consultare il paper per i dettagli.

Cosa impara uno specialista?

Gli autori di ST-MoE hanno osservato che gli specialisti dell’encoder si specializzano in un gruppo di token o concetti superficiali. Ad esempio, potremmo avere uno specialista in punteggiatura, un esperto in nomi propri, ecc. D’altra parte, gli specialisti del decoder hanno una specializzazione inferiore. Gli autori hanno anche addestrato in un ambiente multilingue. Anche se si potrebbe immaginare che ogni esperto si specializzi in una lingua, accade il contrario: a causa del routing dei token e dell’equilibrio del carico, non c’è un solo esperto specializzato in una determinata lingua.

Tabella tratta dal paper ST-MoE che mostra a quali gruppi di token sono stati inviati gli specialisti.

Qual è l’impatto dell’aumento del numero di specialisti sull’addestramento?

Più specialisti portano a una maggiore efficienza del campione e a una velocità di accelerazione più rapida, ma questi sono guadagni marginali (soprattutto dopo 256 o 512), e sarà necessaria più VRAM per l’infrazione. Le proprietà studiate nei Switch Transformers a grande scala sono state coerenti a piccola scala, anche con 2, 4 o 8 specialisti per strato.

Fine-tuning dei MoEs

Mixtral è supportato dalla versione 4.36.0 di transformers. Puoi installarlo con pip install "transformers==4.36.0 --upgrade

Le dinamiche dell’overfitting sono molto diverse tra modelli densi e sparsi. I modelli sparsi sono più inclini all’overfitting, quindi possiamo esplorare una maggiore regolarizzazione (ad esempio, dropout) all’interno degli stessi specialisti (ad esempio, possiamo avere un tasso di dropout per i livelli densi e un altro tasso più alto di dropout per i livelli sparsi).

Una questione decisionale è se utilizzare o meno la perdita ausiliaria per il fine-tuning. Gli autori di ST-MoE hanno sperimentato spegnendo la perdita ausiliaria e la qualità non è stata significativamente influenzata, anche quando è stato fatto cadere fino al 11% dei token. Il dropout dei token potrebbe essere una forma di regolarizzazione che aiuta a prevenire l’overfitting.

Switch Transformers ha osservato che, a una perplessità di pretrain fissa, il modello sparso va peggio rispetto al corrispettivo denso nelle attività di downstream, soprattutto nelle attività che richiedono ragionamento come SuperGLUE. D’altra parte, per attività che richiedono molte conoscenze come TriviaQA, il modello sparso si comporta in modo sproporzionatamente bene. Gli autori hanno anche osservato che un minor numero di specialisti ha aiutato nel fine-tuning. Un’altra osservazione che ha confermato il problema della generalizzazione è che il modello ha ottenuto risultati peggiori nelle attività più piccole ma ha avuto successo nelle attività più grandi.

Nell'attività più piccola (sinistra), si può osservare chiaramente l'overfitting poiché il modello sparso ottiene risultati molto peggiori nel set di validazione. Nell'attività più grande (destra), il MoE si comporta bene. Questa immagine proviene dal paper ST-MoE.

Si potrebbe sperimentare con il congelamento di tutti i pesi non esperti. Ciò ha portato a un’enorme diminuzione delle prestazioni, come era previsto poiché gli strati MoE corrispondono alla maggior parte della rete. Potremmo provare l’opposto: congelare solo i parametri negli strati MoE, che si è scoperto funzionare quasi altrettanto bene dell’aggiornamento di tutti i parametri. Ciò può aiutare a velocizzare e ridurre la memoria per il fintuning.

Congelando solo gli strati MoE, possiamo accelerare l'allenamento preservando la qualità. Questa immagine proviene dal documento ST-MoE.

Ultima parte da considerare quando si fa il fine-tuning di MoE sparsi è che hanno diverse impostazioni di iperparametri per il fine-tuning, ad esempio, i modelli sparsi tendono a beneficiare di dimensioni di batch più piccole e learning rate più alti.

Il miglioramento della qualità dei modelli sparsi fine-tuned migliora con learning rate più bassi e dimensioni di batch più grandi. Questa immagine proviene dal documento ST-MoE.

A questo punto, potresti essere un po’ triste perché le persone hanno faticato a fare il fine-tuning di MoE. In modo eccitante, un recente articolo, MoEs Meets Instruction Tuning (luglio 2023), ha condotto degli esperimenti che comprendono:

  • Fine-tuning di singola attività
  • Fine-tuning di istruzioni multi-tasking
  • Fine-tuning di istruzioni multi-tasking seguita da fine-tuning di singola attività

Quando gli autori hanno fatto il fine-tuning di MoE e del corrispondente equivalente T5, il T5 equivalente era migliore. Quando gli autori hanno fatto il fine-tuning del Flan T5 (il corrispettivo T5 istruzionale) di MoE, il MoE è risultato significativamente migliore. Non solo questo, il miglioramento di Flan-MoE rispetto a MoE era maggiore rispetto a Flan T5 rispetto a T5, indicando che i MoE potrebbero beneficiare molto di più dal fine-tuning delle istruzioni rispetto ai modelli densi. I MoE beneficiano di un numero maggiore di attività. A differenza della precedente discussione che suggeriva di disattivare la funzione di perdita ausiliaria, la perdita effettivamente previene l’overfitting.

I modelli sparsi beneficiano di più dall'addestramento delle istruzioni rispetto ai modelli densi. Questa immagine proviene dal documento MoEs Meets Instruction Tuning.

Quando usare MoE sparsi rispetto ai modelli densi?

Gli esperti sono utili per scenari ad alta velocità con molti dispositivi. Data un budget di calcolo fisso per la preallenamento, un modello sparso sarà più ottimale. Per scenari a bassa velocità con poca VRAM, un modello denso sarà migliore.

Nota: non è possibile confrontare direttamente il numero di parametri tra modelli sparsi e densi, in quanto rappresentano cose significativamente diverse.

Rendere i MoE veloci

Il lavoro iniziale su MoE ha presentato gli strati MoE come un setup di branching, portando a una lenta computazione in quanto le GPU non sono progettate per questo e la larghezza di banda di rete diventa un collo di bottiglia poiché i dispositivi devono inviare informazioni agli altri. Questa sezione discuterà alcuni lavori esistenti per rendere il preallenamento e l’inferenza con questi modelli più pratici. I MoE vanno veloci.

Parallelismo

Effettuiamo una breve revisione del parallelismo:

  • Parallelismo dei dati: gli stessi pesi vengono replicati su tutti i core e i dati vengono frammentati tra i core.
  • Parallelismo del modello: il modello viene frammentato tra i core e i dati vengono replicati su tutti i core.
  • Parallelismo del modello e dei dati: possiamo frammentare il modello e i dati tra i core. Si noti che i diversi core elaborano diversi batch di dati.
  • Parallelismo esperto: gli esperti vengono posizionati su diversi dispositivi. Se combinato con il parallelismo dei dati, ogni core ha un esperto diverso e i dati vengono frammentati tra tutti i core.

Con competenze di parallelismo esperto, gli esperti vengono posizionati su diversi lavoratori e ogni lavoratore prende un diverso gruppo di campioni di addestramento. Per i livelli non-MoE, il parallelismo esperto si comporta allo stesso modo del parallelismo dei dati. Per i livelli MoE, i token nella sequenza vengono inviati ai lavoratori dove risiedono gli esperti desiderati.

Illustrazione dal documento Switch Transformers che mostra come i dati e i modelli vengono suddivisi su core con diverse tecniche di parallelismo.

Fattore di capacità e costi di comunicazione

Aumentando il fattore di capacità (CF) si aumenta la qualità ma si aumentano i costi di comunicazione e la memoria delle attivazioni. Se le comunicazioni di tipo “tutti-tutti” sono lente, è meglio utilizzare un fattore di capacità più piccolo. Un buon punto di partenza è utilizzare il routing di top-2 con un fattore di capacità di 1,25 e avere un esperto per core. Durante la valutazione, il fattore di capacità può essere modificato per ridurre il calcolo.

Tecniche di servizio

Puoi implementare mistralai/Mixtral-8x7B-Instruct-v0.1 su Endpoint di Inferenza.

Un grande svantaggio dei MoE è il grande numero di parametri. Per casi d’uso locali, potrebbe essere preferibile utilizzare un modello più piccolo. Discutiamo rapidamente alcune tecniche che possono aiutare nel servizio:

  • Gli autori di Switch Transformers hanno effettuato esperimenti preliminari di distillazione. Distillando un MoE in un suo equivalente denso, hanno potuto mantenere il 30-40% dei guadagni di sparità. La distillazione, quindi, fornisce i vantaggi di un preaddestramento più rapido e l’utilizzo di un modello più piccolo in produzione.
  • Approcci recenti modificano il routing per instradare frasi complete o attività verso un esperto, consentendo l’estrazione di sottoreti per il servizio.
  • Aggregazione di esperti (MoE): questa tecnica unisce i pesi degli esperti, riducendo così il numero di parametri al momento dell’inferenza.

Ulteriori informazioni sull’addestramento efficiente

FasterMoE (marzo 2022) analizza le prestazioni dei MoE in sistemi distribuiti altamente efficienti e analizza il limite teorico delle diverse strategie di parallelismo, nonché le tecniche per sbilanciare la popolarità degli esperti, le comunicazioni pianificate in modo più dettagliato che riducono la latenza e una porta consapevole della topologia regolata che seleziona gli esperti in base alla latenza più bassa, ottenendo un aumento della velocità del 17x.

Megablocks (novembre 2022) esplora un preaddestramento sparso efficiente fornendo nuovi kernel GPU che possono gestire il dinamismo presente nei MoE. La loro proposta non elimina mai i token e si adatta in modo efficiente all’hardware moderno, ottenendo significativi aumenti di velocità. Qual è il trucco? I MoE tradizionali utilizzano la moltiplicazione di matrici raggruppate, che assume che tutti gli esperti abbiano la stessa forma e lo stesso numero di token. Al contrario, Megablocks esprime i livelli MoE come operazioni a matrice sparso a blocchi che possono ospitare assegnazioni sbilanciate.

Moltiplicazione di matrici sparse a blocchi per esperti di dimensioni e numero di token diversi (da [MegaBlocks](https://arxiv.org/abs/2211.15841)).

MoEs open source

Oggi ci sono diversi progetti open source per addestrare i MoE:

Nel campo dei MoE open access rilasciati, puoi controllare:

  • Switch Transformers (Google): Collezione di MoE basate su T5 che vanno da 8 a 2048 esperti. Il modello più grande ha 1,6 trilioni di parametri.
  • NLLB MoE (Meta): Una variante MoE del modello di traduzione NLLB.
  • OpenMoE: Un’opera di comunità che ha rilasciato MoE basate su Llama.
  • Mixtral 8x7B (Mistral): Un MoE di alta qualità che supera Llama 2 70B e ha un’infrazione molto più veloce. È stato rilasciato anche un modello con istruzioni ottimizzate. Leggi di più al riguardo nel post del blog di annuncio.

Eccitanti direzioni di lavoro

Ulteriori esperimenti sulla distillazione di un MoE sparso in un modello denso con meno parametri ma un numero simile di parametri.

Un’altra area sarà la quantizzazione di MoE. QMoE (ottobre 2023) è un buon passo in questa direzione, quantizzando i MoE a meno di 1 bit per parametro, quindi comprimendo il Switch Transformer da 1,6T che utilizza un acceleratore da 3,2TB a soli 160GB.

Quindi, TL;DR, alcune aree interessanti da esplorare:

  • Distillare Mixtral in un modello denso
  • Esplorare tecniche di fusione dei modelli degli esperti e il loro impatto sul tempo di esecuzione dell’interpretazione
  • Eseguire tecniche di quantizzazione estreme di Mixtral

Alcune risorse

Citazione

@misc {sanseviero2023moe,    author       = { Omar Sanseviero and                     Lewis Tunstall and                     Philipp Schmid and                     Sourab Mangrulkar and                     Younes Belkada and                     Pedro Cuenca                   },    title        = { Spiegazione del Mixture of Experts },    year         = 2023,    url          = { https://huggingface.co/blog/moe },    publisher    = { Hugging Face Blog }}

Sanseviero, et al., "Spiegazione del Mixture of Experts", Hugging Face Blog, 2023.