L’arrivo su Hugging Face di GigaChat3.5-432B-A28B non ha nulla del solito lancio di un modello sperimentale. Il repository curato da ai-sage, con tanto di variante base e, soprattutto, una versione in formato GGUF, disegna un percorso pensato per l’adozione locale fin dal primo giorno.

Il nome del modello racchiude già la sua architettura: 432 miliardi di parametri complessivi, ma solo 28 miliardi attivi per ogni token grazie a un design Mixture of Experts. Non è un dettaglio da addetti ai lavori: in un contesto on-premise, dove la VRAM disponibile è spesso il vincolo più duro, poter eseguire un modello enorme con un footprint computazionale effettivo ridotto cambia le carte in tavola. La struttura MoE consente infatti di mantenere una conoscenza molto ampia distribuita tra gli esperti, ma di attivarne solo una frazione per ogni inference, riducendo memoria e latenza rispetto a un dense model di pari parametri totali.

Il vero colpo, però, è la presenza immediata di una versione GGUF. Il formato, ormai colonna portante di llama.cpp e di tutto l’ecosistema di inference locale, permette di eseguire Large Language Models su CPU, GPU consumer e dispositivi edge con quantization variabile e senza dipendenze complesse. Che un modello di questa taglia – progettato da un colosso bancario russo come Sberbank, noto per la forte attenzione alla sovranità dei dati – arrivi con i file GGUF già pronti, mentre la pull request per l’integrazione ufficiale in llama.cpp (la #25342) è ancora aperta, non è un caso. Segnala che la community che gravita attorno al self-hosting ha risposto immediatamente, colmando il divario tra ricerca corporate e operatività da server room.

Chi segue l’ecosistema degli LLM on-premise sa che il collo di bottiglia non è quasi mai il modello in sé, ma la possibilità di integrarlo in pipeline esistenti senza dover stravolgere l’infrastruttura. Avere un punto di partenza GGUF permette di testare il modello su hardware eterogeneo – dai server con GPU datacenter fino a workstation con GPU consumer – senza passare per API cloud. Per i tanti team che valutano deployment on-premise, questo significa poter raccogliere metriche reali di velocità, consumo di VRAM e qualità delle risposte prima di prendere decisioni di investimento.

GigaChat3.5-432B-A28B non è il primo MoE a sbarcare su Hugging Face, ma il tempismo del supporto GGUF lo rende un banco di prova interessante. Se la pull request verrà accettata a breve, chiunque potrà compilare llama.cpp con il nuovo merge e metterlo subito alla prova, magari su una singola GPU con 48 o 80 GB di VRAM, a seconda della quantization scelta. Senza questo passaggio, resterebbe confinato a un pubblico ristretto di laboratori con risorse hardware fuori scala. Invece, già ora si può puntare a una democratizzazione reale della sperimentazione, con tutte le implicazioni che comporta per la verifica indipendente delle performance e la riduzione della dipendenza da fornitori cloud.