HOPE e i modelli MoE: tagliare gli esperti senza perdere quelli che collaborano

Un modello Mixture-of-Experts può attivare pochi esperti per ciascun token e, nello stesso tempo, richiedere memoria per conservarne moltissimi. È uno dei compromessi meno intuitivi dei grandi modelli sparsi: il calcolo è selettivo, l’occupazione dei pesi molto meno. Quando si prova a eseguire questi sistemi su hardware limitato, la differenza tra parametri attivi e parametri residenti diventa un problema operativo, non una curiosità architetturale.

Il 9 novembre 2026 Amazon ha presentato HOPE, Higher-Order Pruning of Experts, un metodo per eliminare permanentemente una parte degli esperti considerando anche le loro interazioni. Il punto interessante non è la promessa di comprimere un modello: è il cambio di criterio con cui si decide che cosa si può togliere.

Il paradosso dei modelli sparsi: pochi esperti lavorano, molti occupano memoria

Nel caso di Qwen3.5-122B citato dai ricercatori, ogni livello MoE dispone di 256 esperti e ne utilizza otto per token. Gli autori attribuiscono agli MLP degli esperti circa il 95% dell’impronta dei parametri, stimata intorno a 250 GB nella configurazione discussa. Sono numeri riferiti a quel modello e a quella rappresentazione dei pesi: non vanno estesi automaticamente a qualsiasi MoE o hardware.

Scaricare e ricaricare esperti dalla memoria più lenta può introdurre latenza, soprattutto quando le richieste e le sequenze di token cambiano gli esperti richiesti. Il pruning prende una strada diversa: elimina alcuni esperti dal checkpoint. Il risultato è un modello più piccolo, ma la perdita è strutturale e non si recupera semplicemente cambiando un’impostazione a runtime.

Perché scegliere gli esperti uno alla volta non basta

Un approccio classico assegna a ogni esperto un punteggio di importanza, ordina la lista e rimuove quelli in fondo. È intuitivo, ma presuppone implicitamente che il contributo di ciascuno sia indipendente dagli altri. Nei MoE questa ipotesi può essere debole: il router può attivare ripetutamente certe combinazioni e il risultato dipende dalla collaborazione tra i componenti conservati.

HOPE usa dati di calibrazione per costruire una rappresentazione delle interazioni a coppie e scegliere il sottoinsieme da mantenere attraverso un problema di ottimizzazione quadratica, risolto in modo approssimato. I termini sulla diagonale rappresentano l’importanza individuale; quelli fuori diagonale introducono le relazioni tra esperti. Non significa che il metodo capisca semanticamente il ruolo di ogni esperto: misura segnali statistici e funzionali su un campione di lavoro.

La distinzione è importante. Due esperti mediocri se valutati isolatamente possono essere utili insieme; due esperti forti potrebbero coprire funzioni in parte ridondanti. Tagliare sulla sola graduatoria individuale può quindi danneggiare combinazioni che il modello utilizza davvero.

I benchmark: risultati interessanti, ma non un assegno in bianco

Nel paper degli autori, HOPE viene confrontato con quattro metodi di pruning su tre modelli, due insiemi di calibrazione e benchmark generali e di coding agentico. Al 50% di pruning gli autori riportano un rango medio di 1,58 tra cinque metodi, contro 2,42 di REAP. In una configurazione Qwen3.5-35B-A3B su SWE-Bench Pro indicano 42,3 per HOPE, 41,8 per il modello originale e 36,2 per REAP.

Questi sono risultati sperimentali riportati dal gruppo che propone il metodo, non una validazione indipendente di ogni combinazione di modello, dataset e infrastruttura. Non dimostrano neppure che dimezzare gli esperti dimezzi il costo totale di servizio: memoria dei pesi, cache KV, throughput, batching e tempo di risposta sono grandezze differenti.

È significativo anche dove il vantaggio si riduce. Gli stessi autori riconoscono che con pruning meno aggressivo, nell’intervallo 10-20%, metodi più semplici possono restare competitivi. HOPE opera inoltre per livello: le interazioni tra livelli non sono ancora coperte da una validazione altrettanto matura. Le relazioni considerate sono a coppie, non gruppi arbitrariamente grandi.

Pruning, quantizzazione e deployment non sono la stessa decisione

Il pruning riduce il numero di esperti conservati. La quantizzazione riduce invece la precisione con cui i pesi vengono rappresentati. Le due tecniche possono essere combinate, ma i loro errori possono sommarsi e vanno misurati insieme. Anche un checkpoint più piccolo non garantisce che il serving sia più rapido: la velocità dipende dal motore, dal layout dei pesi, dalla concorrenza e dal tipo di richieste.

Per chi deve progettare un’infrastruttura AI locale, la domanda pratica non è soltanto quanti gigabyte si risparmiano. È se il modello compresso conserva le capacità richieste dal gestionale, dai documenti, dalle interrogazioni SQL e dai flussi con strumenti. Una prova fatta su domande generiche non sostituisce una prova su sessioni reali, lunghe e multi-step.

La ricerca parallela conferma che non esiste una sola strada per comprimere gli esperti: REAM studia la fusione degli esperti anziché la semplice eliminazione, mentre OptEP esplora selezione e ricostruzione. I risultati non sono direttamente intercambiabili: setup e metriche cambiano. Il confronto utile resta quello riproducibile sul proprio carico.

Come valuterei HOPE prima di metterlo in produzione

Partirei da un insieme di richieste rappresentative e separato dai dati usati per la calibrazione: conversazioni brevi e lunghe, ricerca documentale, codice o query, chiamate a strumenti e casi in cui il modello deve ammettere di non sapere. Misurerei la qualità prima e dopo il pruning, includendo errori silenziosi e regressioni sulle attività meno frequenti.

Poi confronterei memoria residente, tempo al primo token, token al secondo, latenza di coda, throughput con più utenti e stabilità su contesti estesi. Ripeterei le prove con lo stesso motore di inferenza, la stessa quantizzazione e parametri di serving equivalenti. Se cambia tutto contemporaneamente, non si capisce più quale scelta abbia prodotto il miglioramento.

Infine terrei il checkpoint originale e il dataset di valutazione come parte del rilascio. Il pruning è una trasformazione del modello: richiede versionamento, criteri di accettazione e possibilità di rollback esattamente come una modifica software importante.

Il vero valore è scegliere cosa non perdere

HOPE rende esplicita una cosa che le classifiche individuali nascondono: in un sistema complesso il valore di un componente può dipendere da quelli che gli restano accanto. È un principio utile anche oltre i MoE, ma qui ha una conseguenza misurabile: il taglio aggressivo degli esperti può preservare meglio certi carichi se si considerano le interazioni.

Il metodo merita attenzione per chi lavora con modelli grandi e vincoli di memoria. Non merita ancora una scorciatoia commerciale del tipo “stessa AI a metà costo”. Prima si verifica il lavoro che deve svolgere; poi si decide quanto si può comprimere.