Mixture of experts: cosa cambia tra parametri attivi e totali

Un modello mixture of experts può richiedere meno calcoli per token e restare enorme da ospitare. Il modello linguistico Kimi K3.1 Pro di Moonshot AI ha 2.8T parametri totali, ma ne attiva 104B per token, secondo il post ufficiale di lancio. Il valore più basso aiuta a capire il carico di calcolo; quello più alto resta decisivo quando bisogna tenere in memoria i pesi.

Conteggi dei parametri e dichiarazioni delle fonti verificati il 24 ottobre 2026. Le percentuali di parametri attivi riportate di seguito sono calcoli nostri: non misurano incrementi di velocità, risparmi di memoria o qualità dei risultati.

Che cos’è un modello mixture of experts?

Mixture of experts, o MoE, è un’architettura che mette a disposizione del modello numerose reti interne di elaborazione, selezionandone solo alcune per ogni input. Un parametro è un valore numerico appreso dal modello. I parametri memorizzati vengono comunemente chiamati pesi. Un token è una piccola unità di input o output, spesso un frammento di parola.

Immaginiamo un edificio dedicato alle consulenze, con molte stanze. Una persona alla reception indirizza ogni visitatore nelle stanze necessarie per il suo appuntamento. Solo alcune lavorano per quel visitatore, ma nell’edificio continuano a esserci tutte. In uno strato MoE, il router svolge il ruolo della reception e gli esperti corrispondono alle stanze.

L’analogia ha però un limite: parliamo di reti numeriche addestrate, non di professionisti con un mestiere. Non si può presumere che ci siano un esperto legale, uno di programmazione e uno di contabilità pronti a essere selezionati.

Come funziona il mixture of experts?

Il router seleziona i percorsi interni al modello, poi ne combina i risultati. Un transformer elabora le relazioni di contesto tra i token. Nei transformer MoE più comuni, diverse reti di esperti sostituiscono un blocco feed-forward. Quest’ultimo trasforma la rappresentazione numerica interna di un token; l’attenzione è invece il meccanismo separato che gli consente di usare il contesto circostante.

Il processo si articola così:

1. La rappresentazione corrente di un token raggiunge uno strato MoE.
2. Un router addestrato, chiamato anche gate, assegna un punteggio agli esperti.
3. Ne seleziona un sottoinsieme, spesso scegliendo quelli con il punteggio più alto. È il routing top-k, dove k indica il numero di esperti selezionati.
4. Gli esperti scelti elaborano quella rappresentazione. I loro output vengono pesati e combinati prima che l’elaborazione prosegua.

Questo avviene negli strati MoE del modello: token diversi e strati diversi possono quindi selezionare esperti diversi. La spiegazione dell’architettura di PyTorch descrive la combinazione pesata; il paper di Mistral mostra come le scelte variano tra gli strati.

Che cosa significa MoE sparso?

Sparso significa che, per un dato token, viene eseguito solo un sottoinsieme degli esperti. È questa la variante a cui si riferisce la distinzione tra parametri totali e attivi nelle schede dei modelli moderni. Gli altri esperti possono essere eseguiti per altri token, anche all’interno dello stesso batch.

Un blocco feed-forward denso applica l’intera rete a ogni token. Gli strati di esperti sparsi offrono una maggiore capacità memorizzata senza obbligare ogni token ad attraversare tutti gli esperti. Le componenti condivise, tra cui l’attenzione negli esempi di questo articolo, continuano comunque a lavorare.

Un modello MoE resta un unico modello

Il routing MoE è diverso dalla scelta tra modelli via API o dal far votare più chatbot. Router ed esperti vengono addestrati come componenti di un’unica rete. Di norma, l’applicazione invia una richiesta a quella rete; non seleziona un esperto come si sceglierebbe un prodotto da un menu.

Per chi sviluppa, questa distinzione evita un presupposto progettuale fuorviante: scegliere un modello MoE non significa dotare l’applicazione di una squadra controllabile di agenti specializzati.

Modelli mixture of experts: leggere insieme parametri totali e attivi

I parametri totali indicano la dimensione del modello memorizzato; quelli attivi descrivono il percorso di calcolo per token dichiarato dal produttore. Nessuno dei due valori è una specifica hardware completa. B indica i miliardi; T indica le migliaia di miliardi.

L’ultima colonna riporta il rapporto tra parametri attivi e totali, arrotondato. Descrive i conteggi pubblicati dai singoli produttori, non una classifica di efficienza tra modelli. Architetture e convenzioni di conteggio dei parametri possono essere diverse.

Kimi K3.1 Pro: una piccola parte di un modello molto grande

Kimi K3.1 Pro mostra perché il numero dei parametri «attivi» non può essere usato come dimensione del modello da ospitare. Convertendo il totale dichiarato da Moonshot nella stessa unità di misura, si ottiene 2,800B. Quindi 104 ÷ 2,800 × 100 = 3.7%, arrotondando.

Il conteggio attivo dichiarato rappresenta dunque una piccola parte del totale. Questo non significa che un’infrastruttura di inferenza possa scartare gli altri pesi, né che la latenza dell’API si riduca a quella stessa frazione rispetto a un modello denso. Il percorso cambia al variare dei token e degli strati.

Il post di lancio sul blog di Moonshot descrive Pro come un K3 sottoposto a post-training e usa l’etichetta arrotondata «classe 3T». Il post ufficiale di lancio riporta invece la coppia esatta 2.8T / 104B. Per interpretare le dimensioni del modello, occorre usare questa specifica esplicita.

Per chi sviluppa tramite API, il modello è un candidato da valutare. Per chi lo vuole ospitare, la disponibilità va verificata separatamente: alla data della verifica, Moonshot prometteva i pesi completi entro il 4 novembre 2026. Un rilascio promesso non è ancora un pacchetto disponibile per il deployment. L’approfondimento su Kimi K3.1 Pro esamina le decisioni legate a questa specifica uscita.

Qwen3-235B-A22B: i parametri attivi non sostituiscono il totale

Qwen3-235B-A22B rende visibile la distinzione già nel nome. La scheda originale del modello di Qwen dichiara 235B parametri totali e 22B attivati, con 128 esperti, di cui 8 attivati.

Il calcolo sui parametri è 22 ÷ 235 × 100 = 9.4%, arrotondando. Per un assistente documentale privato, è un’indicazione di come il modello limiti il calcolo per token. Il piano di memoria deve comunque prevedere l’intero checkpoint scelto e lo stato delle richieste servite.

«22B attivi» non va interpretato come «occupa la memoria di un modello denso da 22B». I numeri devono inoltre restare associati al checkpoint preciso: il solo nome della famiglia non basta per scegliere i file dei pesi, la precisione e la configurazione di inferenza.

Mixtral 8x7B: perché moltiplicare i numeri del nome porta fuori strada

Mixtral 8x7B contiene componenti condivise: il suo nome non è un’istruzione di moltiplicazione. Il post di lancio di Mistral dichiara 46.7B parametri totali e 12.9B usati per token. Moltiplicare i numeri del nome significa trattare le componenti condivise come se appartenessero a modelli completi separati.

Il paper di Mistral descrive reti feed-forward di esperti affiancate da un meccanismo di attenzione condiviso. A ogni strato, il router sceglie 2 esperti su 8. Non si tratta di otto modelli completi e indipendenti.

Usando la coppia di conteggi pubblicata si ottiene 12.9 ÷ 46.7 × 100 = 27.6%, arrotondando. Selezionare 2 esperti su 8 equivale al 25% degli esperti: il denominatore è diverso. Le parti condivise sono uno dei motivi per cui la percentuale di esperti e quella di parametri non coincidono.

Per pianificare il deployment, bisogna usare il totale riportato nella scheda e i file effettivi del checkpoint. Né il nome del prodotto né il numero di esperti selezionati indicano l’ingombro complessivo dei pesi.

Perché meno calcoli non garantiscono una latenza più bassa

Il routing sparso riduce il calcolo degli esperti rispetto all’esecuzione di una rete densa di dimensioni analoghe; non promette i tempi di risposta di un modello denso più piccolo. È così che l’architettura MoE può rendere meno costosa l’inferenza per token di modelli ad alta capacità, lasciando però un carico rilevante in termini di memoria e comunicazione.

Le operazioni aritmetiche sono solo una parte dell’inferenza, cioè dell’esecuzione di un modello già addestrato. Il server deve anche leggere i pesi, eseguire le componenti condivise, instradare le rappresentazioni dei token e, a volte, trasferirle tra dispositivi. Un conteggio attivo più basso non elimina queste operazioni. Shazeer e colleghi individuano nei batch piccoli per esperto e nella banda di rete due vincoli prestazionali nel paper originale sul MoE sparso.

Throughput e latenza rispondono a esigenze aziendali diverse. Il throughput misura quanto lavoro il servizio completa nel tempo. La latenza indica quanto attende una singola richiesta. Una coda notturna di elaborazione documentale può trarre vantaggio da una configurazione efficiente con batch grandi; un assistente interattivo per il supporto deve fornire rapidamente una prima risposta utile.

Il batching, cioè l’elaborazione congiunta di più token o richieste, può migliorare l’utilizzo dell’hardware. Token diversi possono però selezionare esperti diversi: un batch può quindi utilizzare una porzione del modello molto più ampia di quella usata da un singolo token. Il conteggio attivo non corrisponde al numero di pesi a cui il server accede nell’intero batch.

Anche l’elaborazione del prompt e la generazione dei token sollecitano il sistema in modo diverso. Il prefill elabora l’input; il decode genera i token successivi. vLLM, un software per servire modelli linguistici, documenta opzioni distinte di comunicazione tra esperti per il prefill ad alto throughput e il decode a bassa latenza. La nostra guida all’inferenza degli LLM spiega queste fasi e le misurazioni da tenere separate.

Per scegliere un’API, bisogna confrontare il comportamento osservato sulle proprie richieste. Una coppia di conteggi dei parametri non dice quanto il fornitore raggruppi il traffico in batch, quanto sia lunga la coda o quanto il suo hardware sia adatto al modello.

I compromessi che incidono sul servizio

MoE sposta parte del carico infrastrutturale dal calcolo ripetuto alla memorizzazione e al coordinamento di un modello più grande. Sul piano operativo, bisogna capire se questo scambio è vantaggioso per il proprio carico di lavoro.

Memoria: ogni esperto deve trovare posto

Inattivo per questo token non significa eliminabile dal deployment. Nella normale inferenza con pesi residenti, tutti i pesi restano caricati nel sistema che serve il modello, anche se ogni token ne usa solo un sottoinsieme. La spiegazione di PyTorch rende esplicito questo requisito di memoria.

Un calcolo utile da cui partire è spazio per i pesi ≈ parametri totali × byte per parametro memorizzato. È soltanto un punto di partenza: la precisione può variare tra i tensori e metadati dei file, padding, repliche e allocazioni del runtime aumentano l’ingombro.

I pesi non esauriscono il fabbisogno di memoria. La KV cache conserva le chiavi e i valori dell’attenzione dei token precedenti, così da poterli riutilizzare. Un assistente documentale con conversazioni più lunghe o più richieste simultanee deve prevedere ulteriore memoria per lo stato delle richieste. L’approfondimento sulla KV cache spiega questo vincolo distinto.

La quantizzazione, che memorizza i pesi con una precisione numerica ridotta, può diminuirne l’ingombro. Non trasforma i parametri totali in parametri attivi e non elimina la necessità di verificare la qualità degli output. La guida alla quantizzazione degli LLM affronta la scelta di formato e precisione; il meccanismo è documentato nella panoramica sulla quantizzazione di Hugging Face.

Throughput: riuscire a caricare il modello è solo il primo requisito

Un modello che si carica correttamente può comunque non raggiungere l’obiettivo di servizio. Il parallelismo degli esperti distribuisce gli esperti su più dispositivi, permettendo di ospitare un modello più grande della memoria di un singolo dispositivo. Richiede però anche di trasferire le rappresentazioni dei token ai dispositivi che ospitano gli esperti scelti e di combinare i risultati.

Questi trasferimenti rendono le interconnessioni, cioè i collegamenti tra dispositivi, parte integrante del progetto dell’infrastruttura di inferenza. La capacità distribuita su macchine collegate male non equivale alla stessa capacità su un sistema ben interconnesso. È una conseguenza diretta dello schema di comunicazione descritto nell’implementazione del parallelismo degli esperti di PyTorch.

Per un assistente interno con poco traffico, il problema pratico è la capacità fissa che rimane sottoutilizzata. Per un servizio batch molto impegnato, può essere invece alimentare gli esperti con lavoro sufficiente. Nessuno dei due esiti dipende dal solo numero di parametri attivi.

Routing: gli esperti più richiesti possono diventare colli di bottiglia

Un router addestrato non garantisce un utilizzo perfettamente uniforme dell’hardware. L’analisi del routing di Mixtral condotta da NVIDIA ha rilevato che un traffico concentrato su un argomento può distribuire il carico in modo disomogeneo tra gli esperti. Alcuni processi di elaborazione finiscono prima, mentre altri restano occupati.

Ecco perché un carico dimostrativo eterogeneo non basta per valutare un servizio che elabora soprattutto contratti o codice. Occorre testare quella concentrazione di richieste, comprese quelle lente, senza affidarsi soltanto a una media.

Il software di inferenza può compensare lo squilibrio, ma anche questa compensazione occupa spazio. vLLM documenta il bilanciamento del carico tramite esperti ridondanti e avverte che le copie aggiuntive consumano memoria GPU altrimenti disponibile per la KV cache. Se i pesi del modello occupano esattamente tutta la memoria, può restare troppo poco margine per una configurazione capace di servirlo bene.

Come scegliere un LLM mixture of experts: API o self-hosting?

Chi sviluppa tramite API deve valutare il servizio erogato; chi ospita il modello deve valutare anche l’intero deployment. Entrambi hanno bisogno di output accettabili, ma solo il secondo gestisce direttamente dove risiedono gli esperti.

Per chi sviluppa usando un’API, l’architettura è un’informazione utile, non un motivo per cambiare modello. Bisogna valutare attività rappresentative, rispetto delle istruzioni, uso degli strumenti quando pertinente, tempo al primo token e tempo di completamento al livello di concorrenza previsto. Vanno registrati anche i tentativi falliti e quelli ripetuti. L’efficienza di inferenza del fornitore non determina la fattura né la quantità di lavoro necessaria per ottenere un risultato accettabile.

Per chi gestisce il modello in self-hosting, il punto di partenza è il checkpoint scaricabile preciso, con la sua licenza e un’implementazione di inferenza supportata. Vanno poi valutati precisione dei pesi, memoria per l’intero modello, margine per la cache, collegamenti tra dispositivi e prestazioni sotto carico. La nostra guida ai modelli open weight distingue l’accesso ai file dai diritti e dalle responsabilità legati al loro utilizzo operativo.

Per chi acquista ed è responsabile degli impegni di servizio, la domanda è se il candidato completi il lavoro conforme ai criteri di accettazione entro i tempi di risposta richiesti, sull’infrastruttura prevista. «Migliaia di miliardi totali, miliardi attivi» descrive un’architettura, non garantisce un livello di servizio.

1. 1

   Definire il carico di lavoro prima di confrontare i modelli

   Usare richieste rappresentative con criteri di accettazione chiari. Separare il lavoro interattivo da quello in coda e includere gli input lunghi e gli argomenti ricorrenti che l’applicazione gestisce davvero.

2. 2

   Valutare la modalità di erogazione che si intende usare

   Per un’API, testare il fornitore e l’endpoint previsti. Per il self-hosting, registrare checkpoint esatto, precisione, runtime e hardware. Una diversa modalità di erogazione produce un diverso risultato operativo.

3. 3

   Testare insieme capacità e qualità

   Aumentare il lavoro simultaneo controllando utilizzo della memoria, attese, qualità degli output ed errori. Una risposta veloce in isolamento non dimostra un throughput utile, così come un throughput elevato non dimostra una latenza accettabile per l’uso interattivo.

4. 4

   Cambiare modello solo quando il carico di lavoro lo giustifica

   Adottare il candidato quando migliorano sia il lavoro che supera i criteri di accettazione sia il rispetto dei requisiti operativi. Se questi vantaggi non emergono, mantenere il modello attuale. Rinviare il self-hosting se i file dei pesi necessari o una modalità di deployment supportata non sono ancora disponibili.

Per chi usa un’API che soddisfa già i requisiti di qualità e di risposta, l’etichetta dell’architettura non cambia la decisione. Chi ha dimensionato un deployment partendo dai parametri attivi deve invece rivedere subito il piano.

Quali promesse sui MoE sono esagerate?

La promessa eccessiva è che la sparsità offra tutti i vantaggi di un modello enorme con tutte le caratteristiche operative di uno piccolo. Offre una separazione utile tra capacità e calcolo, ma a determinate condizioni.

Gli esperti non sono necessariamente specialisti di un dominio. L’analisi di Mixtral di Mistral ha rilevato schemi di routing che non separano nettamente le discipline accademiche. Un esperto addestrato non è uno specialista qualificato e la scelta del router non spiega perché una risposta sia corretta.

Più parametri totali non dimostrano che le risposte siano migliori. E una percentuale attiva più piccola non dimostra che un modello sia superiore. Contano l’addestramento, l’architettura e il compito. La tabella precedente spiega le dimensioni dichiarate: volutamente, non è una classifica di qualità.

Una percentuale attiva più piccola non implica uno sconto o un aumento di velocità proporzionale. Da sola non dice nulla sui costi del fornitore, sulle code, sui trasferimenti di rete o sul numero di token da generare per svolgere il compito.

Il paper che ha definito il meccanismo

Il paper del 2017 di Shazeer e colleghi ha formalizzato uno strato MoE a selezione sparsa di grande influenza, capace di aumentare la capacità del modello senza un aumento proporzionale del calcolo. Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer è il riferimento primario per questo meccanismo. La discussione sul bilanciamento del carico e sulle prestazioni distribuite ricorda anche che i compromessi operativi facevano parte dell’idea fin dall’inizio.

Le domande di chi sviluppa con i modelli MoE

Che cosa significa mixture of experts negli LLM?

È un modo di costruire un modello linguistico di grandi dimensioni con più reti interne di esperti e un router addestrato. Nei MoE sparsi, ogni token usa solo gli esperti selezionati in ciascuno strato MoE. L’applicazione continua a chiamare un unico modello.

GPT-4 è un mixture of experts?

Il report tecnico di GPT-4 non divulga ulteriori dettagli sull’architettura, comprese le dimensioni del modello. Non fornisce una ripartizione dei parametri MoE verificata dal produttore: i conteggi che circolano come indiscrezioni non vanno quindi usati come dati certi per il deployment.

Che cosa comporta il fine-tuning di un modello MoE?

Il fine-tuning adatta il comportamento appreso dal modello; non elimina i requisiti necessari a ospitarne tutti i pesi. Occorre valutare la qualità del modello adattato sul compito e il comportamento del routing con traffico rappresentativo. La guida ai MoE di Hugging Face esamina le diverse criticità di overfitting e bilanciamento coinvolte.

La prossima decisione sul deployment

Lunedì, affiancare a ogni modello in valutazione una scheda operativa per l’inferenza. Annotare i conteggi totali e attivi dichiarati dal produttore, la fonte e il checkpoint esatto o l’endpoint API. Per l’accesso tramite un servizio ospitato, aggiungere i risultati sui propri compiti e le misurazioni di latenza. Per il self-hosting, riportare l’ingombro completo dei pesi, la memoria riservata alla cache e le prestazioni con il traffico previsto. Questa scheda serve più di una classifica basata sul numero più grande pubblicizzato.

Per spiegazioni pratiche sull’infrastruttura dei prodotti AI, iscriviti alla newsletter.