Colibrì: 744 miliardi di parametri su 25 GB di RAM, cambia l’economia dell’accesso ai modelli

Un colibrì che solleva un gigante

GLM-5.2 è un modello Mixture-of-Experts da 744 miliardi di parametri rilasciato da Z.ai con pesi in licenza MIT. La versione a piena precisione occupa 756 GB e vive di norma su cluster di GPU datacenter. Colibrì, progetto open source pubblicato su GitHub dall’utente JustVugg con licenza Apache 2.0, lo fa rispondere su una macchina consumer con circa 25 GB di RAM: un motore in C puro, un singolo file da circa 2.400 righe, zero dipendenze a runtime, zero GPU obbligatorie.

L’idea sfrutta la natura del MoE. Su 744 miliardi di parametri, ogni token ne attiva circa 40 miliardi, e solo 11 GB circa di expert instradati cambiano da un token all’altro. Colibrì tiene residente in RAM la parte densa del modello (attenzione, expert condivisi, embedding: circa 9,9 GB quantizzati a int4) e lascia su disco i 21.504 expert instradati, circa 370 GB, letti in streaming su richiesta con una cache LRU per layer, un pin opzionale degli expert più usati e la page cache del sistema operativo come secondo livello gratuito.

Una workstation consumer in uno studio domestico: la classe di macchina su cui Colibrì esegue un modello da 744 miliardi di parametri

Il costo della scelta è dichiarato dal progetto stesso, in una sezione del README intitolata letteralmente «Honest numbers»: sulla macchina di sviluppo, un portatile con 12 core e disco da 1 GB/s, il decode a cache fredda viaggia tra 0,05 e 0,1 token al secondo. L’autore rivendica il punto con una formula efficace: un modello frontier-class «che risponde correttamente su una macchina che costa meno di una ventola di H100».

I numeri misurati dalla comunità

La parte più interessante del progetto, a pochi giorni dal lancio, è la tabella dei benchmark comunitari: ogni riga è tracciabile a una issue pubblica, con configurazione e numeri verificabili. Un Apple M5 Max con 128 GB di memoria unificata e backend Metal arriva a 2,06 token al secondo. Un server EPYC con 430 GB di RAM tocca 1 token al secondo con un hit rate della cache expert del 98 %, eliminando di fatto il disco dal percorso. L’esperimento documentato più spinto, su sei RTX 5090 con tutti i 19.456 expert residenti tra VRAM e RAM, misura 6,0-6,84 token al secondo in decode. In mezzo, datapoint reali su Windows 11 nativo, Mac Mini da 48 GB, APU Strix Halo e perfino un DGX Spark.

Due dinamiche emergono dai dati. La prima: il motore impara dall’uso. Un file di storico registra quali expert vengono instradati davvero e a ogni avvio blocca in RAM i più caldi: sul Framework 13 di un utente la velocità è salita da 0,29 a 0,37 token al secondo per il solo effetto della cache che si scalda. La seconda: il collo di bottiglia migra. Con poca RAM comanda il disco; con RAM abbondante e NVMe veloci il limite diventa il kernel di calcolo sulla CPU. Su una macchina con AVX-512 la CPU ha eguagliato una RTX 5090 sul matmul degli expert, rendendo la GPU quasi irrilevante per quel carico.

La verifica: dove la promessa regge e dove serve ancora misura

La domanda giusta da porsi è se la qualità del modello sopravviva alla quantizzazione int4 e allo streaming. La prima misura comunitaria di qualità (issue #108) dà 62,5 % di accuratezza media su MMLU, ARC e HellaSwag, contro l’85-95 % pubblicato per la versione a piena precisione. Il progetto stesso invita alla cautela nell’interpretare il divario, per due ragioni dichiarate: lo scoring 0-shot a log-likelihood penalizza strutturalmente un modello di reasoning, che risponde al meglio quando può ragionare, e il campione di 40 domande per task porta un margine di ±14 punti percentuali. L’esperimento decisivo, un A/B fp16 contro int4 su un modello piccolo con lo stesso harness, è pronto nel repository e attende chi lo esegua. Fino ad allora, 62,5 % resta un datapoint, il verdetto arriverà con la misura giusta.

Sul fronte velocità, il quadro è onesto: il decode a cache fredda resta materia da batch notturno, e l’interattività vera arriva solo con cache calda, RAM abbondante o GPU dedicate. Anche la riproducibilità richiede attenzione: l’output byte-identico tra configurazioni diverse si ottiene disattivando la decodifica speculativa e i backend GPU, perché i kernel quantizzati arrotondano in modo dipendente dalla forma del calcolo. Ogni token emesso resta comunque l’argmax di un forward valido.

Cosa cambia per lab e contesti chiusi

Per anni l’accesso ai modelli di fascia frontier è passato da due sole porte: API cloud a consumo o cluster GPU da datacenter. Progetti come Colibrì, insieme al filone di lavoro su offloading MoE che attraversa l’intero ecosistema open source, aprono una terza porta: un laboratorio interno, un ambiente air-gapped, un contesto regolato dove il dato deve restare dentro il perimetro può oggi eseguire un modello da 744 miliardi di parametri su hardware che costa quanto una workstation, accettando latenze da batch.

I casi d’uso che reggono questa asimmetria esistono e sono concreti: valutazione e red-teaming di modelli su dati riservati, generazione notturna di dataset sintetici, analisi documentale massiva su archivi che devono restare on-premise, prototipazione a costo marginale prima di impegnare budget cloud. Per chi progetta ambienti dove il modello va dal dato e il dato resta fermo, l’approccio ricalca la logica dell’ambito AI Privacy First. Il conto economico è brutale nella sua semplicità: servire GLM-5.2 a piena precisione richiede un investimento datacenter a sei cifre, mentre una workstation con 128-256 GB di RAM e un NVMe PCIe 5.0 sta sotto i 5.000 euro. Tre ordini di grandezza di differenza, in cambio di pazienza.

C’è anche un dettaglio che parla al lettore italiano: il progetto si chiama colibrì, con l’accento, e la demo nel README risponde «Ciao! Come posso aiutarti oggi?». Su Hacker News l’autore racconta di aver costruito tutto su un portatile consumer, con l’aiuto di agenti AI, per il gusto di vederlo funzionare: «l’importante era il viaggio per arrivarci».

La domanda aperta

La produzione interattiva resterà a lungo su infrastrutture dedicate, e il divario di qualità dell’int4 va chiuso con misure serie prima di fidarsi in scenari critici. Ma la direzione è tracciata, e i datapoint comunitari accumulati in pochi giorni dicono che la domanda di inferenza locale su modelli grandi è reale e trasversale, dal portatile al server dismesso. Se la traiettoria regge, tra kernel migliori, RAM consumer in crescita e NVMe sempre più veloci, quanto del lavoro oggi instradato per default verso le API cloud migrerà su inferenza locale in contesti chiusi? E quante organizzazioni europee stanno già costruendo i processi, le competenze e le policy per governare questa terza porta quando si spalancherà del tutto?

Autore

Pablo Liuzzi

Founder, Synthos Logic