Il paradosso delle risorse libere
Immaginiamo un assistente che legge molti documenti tecnici insieme. Il suo modello contiene diversi moduli specializzati e, per ogni frammento di testo, ne usa soltanto uno. Sembra una soluzione naturale per risparmiare calcolo. Eppure una parte del sistema si riempie mentre altre restano quasi vuote. Aumentare il numero complessivo delle risorse non spiega il problema: occorre capire dove arrivano le richieste. La domanda di questo articolo è come un modello poco attivo nel complesso possa essere troppo carico in un punto preciso.
Abstract. Studiamo un livello Mixture of Experts, o MoE, con selezione di un esperto per token. Un esempio sintetico di sedici token permette di derivare capacità, richieste non elaborate e spazio inutilizzato. Separiamo probabilità del router, assegnazioni discrete, bilanciamento nel tempo e distribuzione fisica sugli acceleratori. Confrontiamo l’impostazione storica Switch con sviluppi documentati in DeepSeek-V3 e nel preprint LLEP del 2026, senza trasferirne i benchmark al nostro esempio. I risultati propri sono conteggi Python eseguiti: nessuna rete addestrata, nessuna GPU misurata.
Un esperto non è una persona, un token non è una richiesta
Un token è una delle unità in cui il testo viene segmentato: può essere una parola, un frammento o un segno. Nel livello che studiamo, un esperto è una rete feed-forward, cioè un blocco di trasformazioni numeriche applicato alla rappresentazione del token. Gli esperti hanno parametri differenti; non sono agenti che discutono tra loro e non corrispondono necessariamente a professioni come medico o ingegnere. Chiamarli esperti descrive una possibile specializzazione appresa, non una competenza certificata.
Il router assegna punteggi ai moduli e decide quali usare. Nel caso top-1 prende il punteggio più alto; in top-k ne seleziona k. La sparsità riguarda l’attivazione degli esperti per token, non significa che tutto il modello sia spento. Attenzione, router e altri componenti continuano a lavorare. Inoltre sedici token di un batch possono appartenere a una sola conversazione o a più documenti: contare i token instradati non equivale a contare gli utenti serviti.
Costruiamo una situazione che possiamo controllare
Consideriamo T=16 token ed E=4 esperti. Per dodici token il router preferisce l’esperto 1, per due il 2, per uno il 3 e per uno il 4. Otteniamo quindi n=[12,2,1,1], dove n_i conta le assegnazioni all’esperto i. La somma è sedici perché ogni token viene assegnato una volta. È un batch inventato per rendere evidente il meccanismo, non una traccia estratta da un modello commerciale. Il carico medio è quattro; il massimo è dodici, tre volte la media.
Per capire se tutti possano essere elaborati, dobbiamo specificare una capacità locale C. Assumiamo per ora buffer rigidi di uguale dimensione: ogni esperto può accogliere al massimo C assegnazioni nel passaggio corrente. Se ne arrivano di più, non si trasferiscono automaticamente a un esperto diverso. L’analogia con quattro sportelli aiuta a vedere la coda, ma ha un limite: gli esperti hanno pesi diversi, quindi spostare un token a un altro modulo può cambiare la funzione calcolata.
Perché sedici posti non bastano per sedici token
Definiamo c come fattore di capacità, un moltiplicatore adimensionale del carico medio. Nel nostro simulatore arrotondiamo all’intero superiore: C=ceil(cT/E). Con c=1 otteniamo C=4 e una capacità complessiva EC=16. La capacità totale coincide con la domanda, ma la distribuzione non coincide: il primo esperto può prendere soltanto quattro dei dodici token assegnati. Gli altri accolgono 2, 1 e 1. In totale vengono elaborate otto assegnazioni e altre otto superano il limite.
A è il numero di assegnazioni elaborate, D quello delle assegnazioni eccedenti e U quello degli slot inutilizzati. Tutte queste quantità sono conteggi; non misurano secondi, watt o byte. La seconda formula somma ciò che ogni esperto riesce ad accogliere, non ciò che il sistema potrebbe accogliere se i posti fossero intercambiabili. Nel caso c=1, A=8, D=8 e U=8: domanda non soddisfatta e spazio libero convivono. Questa è la risposta quantitativa al paradosso iniziale.
| c | C per esperto | D eccedenti | Slot totali | U liberi |
|---|---|---|---|---|
| 1 | 4 | 8 | 16 | 8 |
| 1.25 | 5 | 7 | 20 | 11 |
| 1.5 | 6 | 6 | 24 | 14 |
| 2 | 8 | 4 | 32 | 20 |
| 2.5 | 10 | 2 | 40 | 26 |
| 3 | 12 | 0 | 48 | 32 |
La tabella esegue una sensibilità al fattore c mantenendo identico il routing. Raddoppiare la capacità porta a C=8, ma lascia quattro assegnazioni eccedenti. Per azzerarle in questo batch serve C=12, ottenuto con c=3: riserviamo quarantotto slot per sedici assegnazioni. Non ne segue che un software reale consumi esattamente tre volte memoria o tempo: dipende dalla rappresentazione dei buffer e dai kernel. Il conto mostra il costo dell’allocazione rigida, non una misura di un acceleratore.
Scartare un token non significa cancellare una parola
Nel contesto di un livello MoE, token dropping può significare saltare il contributo dell’esperto quando la capacità è esaurita. Nell’impostazione Switch letta, la rappresentazione prosegue attraverso la connessione residua. Non viene cancellata una parola dal documento. Questo dettaglio cambia l’interpretazione: il modello può ancora produrre una risposta, ma quel token non ha ricevuto la trasformazione prevista in quel livello. Nel nostro esperimento contiamo i contributi mancanti; non calcoliamo l’effetto sulla qualità del linguaggio.
Altre implementazioni elaborano tutte le assegnazioni, usando forme dinamiche, raggruppamenti o pianificazioni differenti. In quel caso D non descrive ciò che il runtime fa davvero: è il numero che supererebbe il limite ipotetico C. Il problema può riapparire come più memoria, attesa o lavoro sul dispositivo più carico. Prima di leggere una percentuale di token scartati bisogna quindi chiedere quale politica venga applicata. La stessa distribuzione dei carichi può avere conseguenze diverse in sistemi diversi.
Probabilità quasi uniformi, decisioni molto sbilanciate
Per ogni token assegniamo probabilità 0,28 all’esperto vincente e 0,24 a ciascuno degli altri tre. La somma vale uno. La preferenza è debole, ma top-1 sceglie comunque un vincitore: non suddivide il token in quattro frazioni. Indichiamo con f_i=n_i/T la quota effettiva di assegnazioni e con P_i la probabilità media dell’esperto i nel batch. Nel nostro esempio f=[0,75;0,125;0,0625;0,0625], mentre P=[0,27;0,245;0,2425;0,2425]. Confondere queste due distribuzioni nasconde il sovraccarico.
B è il termine di bilanciamento di tipo Switch prima del coefficiente che lo pesa nell’obiettivo di addestramento. Per assegnazioni e probabilità uniformi vale uno. Sostituendo i nostri numeri otteniamo B=1,05375, pur avendo metà delle assegnazioni oltre la capacità C=4. Il punto non è che il termine sia inutile: è che il suo valore non è una misura del numero di token mancanti e non impone un vincolo rigido per ciascun batch. Non affermiamo neppure che uno sia un limite inferiore globale per ogni coppia ammissibile di f e P.
Il router apprende modificando punteggi continui, mentre la scelta del massimo cambia in modo discreto. Per questo una regolarizzazione statistica e una garanzia di capacità rispondono a domande diverse. La prima orienta l’apprendimento, la seconda deve specificare cosa accade a ogni assegnazione. Aumentare arbitrariamente il peso del bilanciamento può inoltre spostare l’obiettivo dalla qualità del compito verso l’uniformità. Per valutarlo servirebbero addestramenti controllati, che qui non abbiamo eseguito.
La media del giorno può nascondere ogni singolo picco
Cambiamo esperimento. Osserviamo quattro finestre successive da otto token: nella prima tutti vanno all’esperto 1, nella seconda al 2, poi al 3 e al 4. Sull’intero intervallo ogni esperto riceve otto token: un istogramma aggregato appare perfettamente bilanciato. Ma in ogni finestra, con c=1, la capacità è C=8/4=2. Sei token superano il limite ogni volta, per un totale di ventiquattro su trentadue assegnazioni. Il rapporto aggregato non rivela il picco che interessa il buffer.
Non abbiamo dimostrato che finestre corte siano sempre peggiori, né che bisogna forzare ogni documento a usare tutti gli esperti. Abbiamo dimostrato una perdita di informazione dovuta all’aggregazione. Per un sistema reale occorre registrare carichi per livello, batch e dispositivo, con una scala temporale coerente con il limite da verificare. Se la memoria viene allocata per micro-batch, una media sull’intera giornata risponde a una domanda diversa da quella che determina un esaurimento istantaneo.
Bilanciare gli esperti e bilanciare le macchine sono cose diverse
Un esperto è un modulo logico; una GPU è un dispositivo fisico e può ospitarne diversi. Nel secondo conteggio abbiamo otto esperti con carichi [8,8,0,0,4,4,4,4] e quattro dispositivi, due esperti ciascuno. Raggruppando gli esperti consecutivi otteniamo carichi fisici [16,0,8,8]. Cambiando soltanto la collocazione in coppie (1,3), (2,4), (5,6), (7,8), otteniamo [8,8,8,8]. Nessun token ha cambiato esperto: è cambiato il luogo in cui quell’esperto viene eseguito.
È una possibilità geometrica, non un’accelerazione misurata. Spostare o replicare pesi costa memoria e comunicazione; i risultati devono tornare al punto di origine e, nell’addestramento, anche i gradienti devono essere raccolti correttamente. Inoltre il carico del batch successivo può essere diverso. Il bilanciamento fisico conserva la scelta semantica del router, ma introduce un problema di pianificazione. Perciò il numero di parametri attivi da solo non determina latenza, picco di memoria o costo di un servizio.
Che cosa aggiunge la ricerca, e che cosa non abbiamo riprodotto
Switch Transformers di Fedus, Zoph e Shazeer è un lavoro JMLR del 2022, non una novità del 2026. Abbiamo letto routing, capacità, obiettivo e confronto sperimentale: la tabella 1 usa pretraining C4 e 32 core TPUv3. È una base per capire il meccanismo; i suoi tempi non descrivono il nostro conteggio né un’infrastruttura EL-AI.
Il report DeepSeek-V3, v2 del 18 febbraio 2025, separa bias di selezione e pesi di combinazione; mantiene anche un piccolo termine ausiliario per sequenza. Le ablation lette confrontano due scale mantenendo dati e architettura comparabili. È una fonte tecnica degli autori, non una nostra verifica indipendente: non ne riproduciamo addestramento o benchmark e non equipariamo “loss-free” ad assenza assoluta di ogni loss ausiliaria.
Per aggiornare il quadro abbiamo letto metodi ed esperimenti di Least-Loaded Expert Parallelism, Nguyen e colleghi, preprint arXiv v1 del 23 gennaio 2026. Ridistribuisce lavoro e pesi tra dispositivi; i test controllati usano otto H200 e separano livelli singoli da modelli completi. Non riportiamo accelerazioni trasferibili: comunicazione, dimensione del batch e soglie condizionano il vantaggio. Questa selezione di fonti non pretende di essere una rassegna esaustiva della frontiera.
Dal conto riproducibile alla decisione progettuale
Il frammento Python sotto ripete la tabella iniziale. ceil definisce la regola di arrotondamento; min limita le assegnazioni elaborate da ciascun esperto; le sottrazioni ricavano eccessi e slot liberi. Il pacchetto completo aggiunge probabilità, loss, finestre temporali e collocazioni. Usa dati deterministici, senza seed; non genera token con un modello. Il conteggio delle probabilità costa O(TE) e conserva una matrice T×E, mentre il conteggio delle sole capacità è O(E) per configurazione. Questi costi descrivono lo script didattico, non un kernel MoE.
Per valutare un’implementazione reale occorrerebbe fissare checkpoint, livello, top-k, precisione, hardware, runtime, batch e distribuzione dei documenti. Si dovrebbero misurare separatamente carichi per esperto e dispositivo, memoria di picco, comunicazione e latenza; poi verificare qualità delle risposte e comportamento sui domini meno frequenti. Un protocollo di confronto dovrebbe usare gli stessi input e includere il costo del bilanciamento. Sono verifiche proposte, non eseguite qui. Il nostro esperimento serve a scegliere le domande giuste prima di una misura costosa.
La risposta iniziale è dunque concreta: usare pochi esperti per token limita una parte del lavoro, ma non garantisce che quel lavoro sia distribuito dove esiste capacità. Nel nostro batch sedici slot lasciano otto assegnazioni senza contributo esperto; probabilità quasi uniformi e medie globali non bastano a rilevarlo. Capacità, apprendimento del routing e collocazione fisica sono leve diverse, con costi e limiti distinti. Per un’impresa che valuta un assistente, la domanda utile non è soltanto quanti parametri si attivano, ma quale carico il sistema sostiene sui propri documenti, con quale qualità e sotto quali vincoli.
Bibliografia e materiale riproducibile
Fedus, Zoph, Shazeer — Switch Transformers, JMLR 23, 2022, sections 2.1–2.4.
from math import ceil
loads = [12, 2, 1, 1]
tokens, experts = sum(loads), len(loads)
for factor in (1, 1.25, 1.5, 2, 2.5, 3):
capacity = ceil(factor * tokens / experts)
accepted = sum(min(n, capacity) for n in loads)
print(factor, capacity, tokens-accepted, experts*capacity-accepted)
Codice, dati e istruzioni · JSON. Calcoli didattici eseguiti con Python 3.14.0; figure con Matplotlib 3.11.2. Analisi con assistenza AI, senza dichiarare peer review o revisione umana. Copertina originale ImageGen, illustrativa: non documenta persone, sedi o installazioni EL-AI. Fonti consultate il 4 ottobre 2026.