Il dato più utile dello studio non è che un modello Mixture-of-Experts possa essere potato, ma che la sua tolleranza al taglio cambia radicalmente con la profondità. Su Qwen3.6-35B-A3B, un'architettura MoE per LLM da 40 layer, 256 esperti per layer e routing top-8, i ricercatori hanno applicato un mascheramento basato sulla magnitudo degli esperti e misurato gli effetti sul benchmark XLCoST di traduzione cross-linguale di codice, eseguendo valutazioni su 100, 300 e 500 prompt distribuite su tre server H100.

I numeri chiave raccontano una geografia netta. Il mascheramento piatto del 30% su tutti i layer conserva appena 150 output Good+Similar su 300. Le politiche focalizzate sugli ultimi layer, invece, ne mantengono tra 249 e 255 su 300, mascherando da 640 a 1.145 esperti. In una validazione separata da 500 prompt, la politica più selettiva, applicata ai layer 35-39 al 50%, conserva 419 output Good+Similar su 500 e maschera soltanto 640 dei 10.240 esperti totali.

La lettura tecnica è che la fragilità dei primi layer (0-9) e di quelli intermedi (10-29) impone cautela: lì gli esperti a bassa magnitudo contribuiscono ancora in modo critico. Negli strati molto tardivi (35-39), invece, molti esperti sono ridondanti rispetto al compito. Questo sposta l'unità di intervento dal modello intero al singolo layer: una compressione efficace sui MoE non può essere piatta, perché penalizza inutilmente la qualità nelle aree sensibili e lascia capacità inutilizzata nelle aree tolleranti.

Anche la riduzione del routing top-k da 8 a 6 esperti attivi per token offre un segnale interessante: su una prova da 100 prompt i ricercatori osservano una riduzione marcata del wall-clock senza perdita di output Good+Similar. Tuttavia questo intervento non si compone ancora in modo pulito con il mascheramento aggressivo degli esperti. È un dettaglio importante: suggerisce che la latenza e la qualità non si ottimizzano con un unico interruttore, ma vanno calibrate congiuntamente.

Per chi gestisce server H100 in locale, il risultato sposta l'attenzione: prima di moltiplicare i nodi o passare a modelli più piccoli, la mappatura della sensibilità dei layer diventa un passaggio analitico rilevante. Il lavoro traccia tre direzioni: physical weight surgery, scoring degli esperti basato sulle attivazioni e recovery basata su training. Sono le leve che in un contesto self-hosted possono ridurre l'occupazione di memoria e migliorare il TCO mantenendo il controllo sui dati. Il paper non misura direttamente i consumi o l'occupazione di VRAM, ma rende esplicito che il margine non è uniforme lungo la profondità. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per confrontare i trade-off tra compressione, hardware e TCO.

La posta in gioco non è solo tecnica. I fornitori di tecniche di compressione uniforme rischiano di lasciare sul tavolo il guadagno più accessibile, quello concentrato negli strati finali. Allo stesso tempo, chi costruisce pipeline di inference per modelli MoE può ottenere margini di efficienza senza cambiare hardware, spostando il vantaggio competitivo verso chi controlla il deployment e può eseguire valutazioni su benchmark reali come XLCoST. Il passaggio dalla mascheratura alla rimozione fisica dei pesi resta il nodo da sciogliere: non basta sapere che gli ultimi layer tollerano il mascheramento, serve capire se il risparmio si materializza davvero in VRAM e latenza quando gli esperti vengono eliminati, non solo esclusi dal calcolo. È qui che lo studio si ferma, ma è anche il punto in cui la compressione dei MoE smette di essere una questione di qualità e diventa una questione di infrastruttura.