Quando un progetto pubblica un modello su Hugging Face, il comunicato di solito si concentra sui benchmark. DiffuSpace, con Clover-35B-A3B-Preview, aggiunge però un dettaglio che per chi gestisce carichi on-premise pesa più di una classifica: la separazione netta tra parametri totali e parametri attivi. Il modello combina un backbone mixture-of-experts da 35 miliardi di parametri con circa 3 miliardi di parametri attivi per token, usa una generazione a blocchi per diffusione e apre una finestra di contesto da 128K token. Secondo DiffuSpace, al momento del rilascio Clover offre prestazioni state-of-the-art tra i modelli linguistici a diffusione open source sui benchmark riportati nel blog di lancio. Non è la prima volta che vediamo una MoE, ma è la prima release di DiffuSpace e arriva in open source, con code e backend di inference già indicati nella scheda.

Per un deployment self-hosted, il numero che conta non è il totale dei parametri, ma quanti ne vengono coinvolti per ogni token. In una MoE il modello completo deve comunque essere caricato in memoria o almeno essere accessibile rapidamente, ma il costo computazionale per token si avvicina a quello di un modello molto più piccolo. Questo cambia il calcolo della VRAM, del throughput e del TCO: non basta confrontare la dimensione del checkpoint con la capacità delle GPU, bisogna considerare quanta memoria serve per lo storage degli esperti, quanto traffico si genera fra livelli e quale backend riesce a instradare i token verso gli esperti giusti senza colli di bottiglia. La finestra da 128K token aggiunge un ulteriore fattore: cache di contesto più lunghe possono assorbire rapidamente la memoria disponibile, anche quando il costo di generazione per token resta contenuto.

La scelta di una generazione a blocchi per diffusione ha una conseguenza strutturale. I modelli autoregressivi tradizionali producono un token alla volta e la loro latenza è fortemente condizionata dalla lunghezza della sequenza. Uno schema a blocchi può parallelizzare porzioni della generazione, cambiando il profilo di latenza e, in prospettiva, il tipo di hardware che conviene usare nell'inference. Per i team che valutano server on-premise, il punto non è solo se il modello gira, ma se il backend di serving riesce a sfruttare il parallelismo offerto dalla diffusione. Senza un backend maturo, il vantaggio teorico resta sulla carta.

Ecco perché la pubblicazione del code e dei backend di inference diventa parte integrante della notizia. I vantaggi vanno soprattutto a chi costruisce infrastrutture locali: laboratori, aziende con vincoli di sovranità dei dati, gruppi che non vogliono dipendere da API cloud. Un LLM open source con MoE e un costo per token più basso può spostare l'equilibrio dal cloud verso il self-hosted, a patto che l'ecosistema di serving regga. Chi ci perde, nel breve periodo, sono i vendor che offrono modelli densi di dimensioni simili senza lo stesso profilo di efficienza, o le piattaforme che vendono accesso API senza controllo sul modello. La pressione competitiva non si gioca più solo sulla qualità dei benchmark, ma sul costo di gestione per token e sulla disponibilità di backend adatti.

Per chi valuta deployment on-premise, esistono trade-off da analizzare con attenzione: la MoE riduce il costo per token, ma introduce complessità di orchestrazione e un fabbisogno di memoria per tutti gli esperti; la finestra lunga è utile nei documenti estesi, ma pesa sulla VRAM; il formato diffusion richiede tooling diverso da quello dei modelli autoregressivi. AI-RADAR mette a disposizione framework analitici su /llm-onpremise per valutare questi fattori senza semplificazioni. Il rilascio di Clover-35B-A3B-Preview non risolve di colpo questi problemi, ma li rende più concreti: la direzione, per chi osserva il deployment locale, è un mercato in cui la dimensione del modello conta meno della sua architettura di calcolo.