Colibrì: il mini motore che fa girare un modello da 744B su hardware consumer

Ogni settimana la comunità open source dell'intelligenza artificiale locale sembra cercare il suo argomento di conversazione preferito, e quella appena passata sembra aver eletto un repository su GitHub con un nome curioso e una promessa quasi assurda: far girare GLM-5.2, un modello Mixture-of-Experts da 744 miliardi di parametri, su un computer con appena 25 GB di RAM. Il progetto si chiama Colibrì ed è opera di un solo sviluppatore, JustVugg, che nella sezione dei ringraziamenti del proprio README ammette con onestà disarmante di aver scritto e testato tutto su un portatile a dodici core. Nessun laboratorio, nessun cluster, nessuna sponsorizzazione hardware. Solo un'ossessione tecnica portata fino in fondo.

Va detto subito, con la stessa onestà che l'autore riserva al proprio lavoro: Colibrì non è pensato per un pubblico di massa, non è un prodotto e non aspira a diventarlo. È un esperimento, nel senso più classico del termine, quello di chi vuole scoprire dove si trova realmente il limite fisico di una macchina consumer quando le si chiede di sostenere un modello che, in condizioni normali, richiederebbe centinaia di gigabyte di memoria dedicata. Ed è proprio questa cornice sperimentale, più che le prestazioni in sé, a renderlo interessante da raccontare.

Cosa c'è dentro il motore

Il cuore di Colibrì sta in un singolo file C di circa 2.400 righe, glm.c, accompagnato da qualche header minimale. Zero dipendenze esterne, zero librerie di algebra lineare come BLAS, zero runtime Python durante l'inferenza vera e propria (Python entra in gioco solo nella fase di conversione offline del modello, un compito che svolge una volta sola e poi esce di scena). È un'impostazione che ricorda la filosofia di certi progetti storici dell'informatica, quelli in cui la scelta di scrivere meno codice, ma scriverlo bene, diventa essa stessa una dichiarazione d'intenti.

C'è qualcosa, in questa ostinazione minimalista, che fa pensare a certe produzioni musicali della scena IDM britannica degli anni Novanta: strumenti pochi, regole rigide, eppure risultati sorprendentemente complessi che emergono da un sistema volutamente povero di elementi. Colibrì funziona più o meno così: un motore piccolissimo che orchestra un modello colossale, senza fronzoli, senza livelli di astrazione superflui, con l'obiettivo dichiarato di far girare esattamente un'architettura, GLM-5.2, e di farlo con fedeltà verificabile rispetto all'implementazione originale in transformers.

GLM-5.2, il modello mostruoso

Per capire perché questa impresa abbia senso tecnico, bisogna prima capire cosa significhi davvero "744 miliardi di parametri". GLM-5.2 è un modello Mixture-of-Experts, un'architettura in cui la rete non elabora ogni token con l'intera sua capacità, ma la smista fra migliaia di sotto-reti specializzate, chiamate esperti, attivandone solo una piccola parte per ciascun token generato. Nel caso di GLM-5.2 gli esperti instradabili sono 21.504, distribuiti su 75 layer MoE da 256 esperti ciascuno più una testa aggiuntiva per la decodifica speculativa, per un totale complessivo di 19.456 esperti secondo il conteggio che il progetto stesso utilizza nella propria dashboard. Di tutti questi, solo circa 40 miliardi di parametri vengono effettivamente attivati per ogni singolo token, e di questi appena 11 GB cambiano realmente da un token all'altro, quelli instradati dal router.

È una distinzione cruciale, perché significa che il problema non è più "come tengo 744 miliardi di parametri in memoria", ma "come faccio arrivare al processore, in tempo utile, solo gli 11 GB che servono davvero in questo istante". È lo stesso principio, applicato con radicalità estrema, che governa altri motori di inferenza MoE nati in queste settimane, e che vale la pena tenere a mente quando più avanti confronteremo Colibrì con un cugino concettuale nato dalle parti di Redis. La web dashboard di colibrì, immagine tratta dal repository github

La gerarchia di memoria a tre livelli

L'idea tecnica che sostiene tutto il progetto è, in fondo, semplice da spiegare con un'analogia. Immaginate una biblioteca sterminata in cui la parte del catalogo che consultate ogni giorno sta sulla vostra scrivania, quella che vi serve ogni tanto sta in uno scaffale in un'altra stanza, e quella che aprite raramente sta in un magazzino esterno da cui va richiesta apposta. Colibrì tratta VRAM, RAM e disco esattamente come tre livelli di questa stessa biblioteca, gestiti come un'unica gerarchia di memoria.

La parte densa del modello, attenzione, esperti condivisi, embedding, circa 17 miliardi di parametri, resta sempre residente in RAM in formato int4, occupando circa 9,9 GB. Gli oltre 21.000 esperti instradati, invece, vivono su disco in un contenitore int4 che pesa complessivamente circa 370 GB, e vengono caricati dinamicamente solo quando il router del modello decide di attivarli, grazie a una cache LRU per ogni layer, uno "store caldo" opzionale per gli esperti più usati e la cache di pagina del sistema operativo che funge da livello intermedio gratuito. È a questo punto che il collo di bottiglia si sposta, in modo quasi filosofico, dal calcolo alla lettura: non è più la CPU a decidere quanto siete veloci, è il disco.

Hardware minimo, aspettative realistiche

Colibrì gira su Linux, WSL2, macOS e, dalla sua evoluzione più recente, anche su Windows 11 nativo grazie a un livello di compatibilità scritto appositamente. Serve un processore con supporto AVX2, almeno 16 GB di RAM, e circa 370 GB liberi su un'unità NVMe locale, mai su una condivisione di rete. Non è un requisito banale, ma è comunque ordini di grandezza più abbordabile del cluster di GPU che servirebbe per caricare lo stesso modello nella sua interezza a piena precisione.

La distinzione più importante, tuttavia, non riguarda l'hardware minimo ma la differenza fra "funziona" e "è praticabile". Colibrì funziona anche sulla configurazione più modesta testata dall'autore, dodici core e 25 GB di RAM dietro una macchina virtuale WSL2 con un disco che legge a circa 1 GB al secondo. Ma a quella velocità il modello produce risposte a un ritmo compreso fra 0,05 e 0,1 token al secondo da cache fredda, un valore che rende l'esperienza più simile a un telegramma che a una conversazione. È un progetto pensato per essere spinto oltre, non per essere usato così com'è sulla configurazione di partenza.

I numeri onesti delle prestazioni

Il README del progetto dedica una sezione intera, intitolata senza ironia "numeri onesti", proprio a chiarire questa distanza fra teoria e pratica. Sulla macchina di sviluppo, un cold start costa circa 11 GB di letture da disco per ogni token generato, il che significa che la velocità dipende quasi interamente dal throughput del disco stesso: con un limite fisico di circa 1 GB al secondo su quella configurazione, il risultato è appunto lo 0,05-0,1 token al secondo di cui sopra.

Le cose cambiano sensibilmente quando la comunità ha iniziato a testare Colibrì su hardware più capace, e qui i dati raccolti nelle issue del repository diventano il vero laboratorio del progetto. Su un Ryzen AI Max con 128 GB di RAM la velocità sale a circa 0,37-0,40 token al secondo una volta che la cache si è scaldata. Su un Mac con chip M5 Max e 128 GB di memoria unificata si arriva a circa 1 token al secondo con la configurazione base, e a oltre 2 token al secondo abilitando il backend sperimentale Metal. Il datapoint più estremo arriva da un banco di sei schede RTX 5090 collegate insieme, dove tenendo l'intero parco esperti residente fra VRAM e RAM si toccano i 6 token al secondo in decodifica su singola richiesta, una cifra che comincia ad avvicinarsi a un utilizzo realmente conversazionale, sebbene ottenuta con un investimento hardware che nulla ha più di consumer.

Un dettaglio tecnico interessante riguarda la decodifica speculativa nativa di GLM-5.2, la cosiddetta MTP, in cui una piccola testa aggiuntiva del modello prova a indovinare in anticipo i token successivi, che il motore principale poi verifica in un unico passaggio. Funziona solo se quella testa viene quantizzata a 8 bit anziché a 4: con la precisione sbagliata l'accettazione dei token proposti crolla a zero, mentre con quella corretta sale fra il 39 e il 59 per cento, portando fino a 2,8 token generati per ogni passaggio del modello. È il genere di dettaglio apparentemente minuscolo che, su un sistema così tirato al limite, fa la differenza fra un progetto utilizzabile e uno che si blocca senza una ragione apparente.

La cache che impara

Uno degli aspetti più affascinanti di Colibrì, dal punto di vista puramente concettuale, è che il motore osserva se stesso mentre lavora e impara dai propri pattern d'uso. Ogni sessione di chat aggiorna un file che registra quali esperti sono stati effettivamente attivati, e al riavvio successivo il motore usa quella cronologia per decidere quali esperti tenere pre-caricati nella RAM disponibile. Più lo si usa, più la macchina diventa, in un senso molto letterale, abituata alle proprie conversazioni.

A questo si aggiunge un meccanismo di prefetch predittivo, ancora sperimentale, che sfrutta una regolarità interessante scoperta nel comportamento del router: lo stato di un layer dopo l'attenzione permette di anticipare correttamente il 71,6 per cento degli esperti che verranno attivati dal layer successivo, un valore misurato dagli stessi contributor del progetto. Un thread di I/O dedicato può quindi iniziare a leggere dal disco gli esperti del prossimo layer mentre quello corrente sta ancora calcolando, sovrapponendo tempo di lettura e tempo di calcolo invece di sommarli in sequenza. La brain page di colibrì, immagine tratta dal repository github

Un posto a sé nel panorama locale

Colibrì non nasce nel vuoto. Nelle stesse settimane, un altro progetto ha catalizzato l'attenzione della comunità dell'inferenza locale con una filosofia sorprendentemente simile: DwarfStar (in codice DS4), il motore scritto da Salvatore Sanfilippo, alias antirez, il creatore di Redis, di cui ho parlato su Codemotion. Anche DwarfStar è un motore in C scritto da zero, ottimizzato in modo maniacale per un singolo modello, e anche lì la strategia per aggirare i limiti della memoria consumer passa da una combinazione di quantizzazione aggressiva e streaming degli esperti dal disco su Mac con architettura Metal.

Le differenze, però, sono altrettanto istruttive quanto le somiglianze. DwarfStar punta su DeepSeek V4 Flash, un modello MoE più contenuto con 284 miliardi di parametri totali e 13 miliardi attivi, e lo comprime fino a un file GGUF di circa 81 GB grazie a una quantizzazione asimmetrica calibrata empiricamente sui pesi che contano davvero. Colibrì, al contrario, sceglie la strada opposta e più radicale: non comprime il modello per farlo stare nella RAM disponibile, lo lascia enorme, circa 370 GB su disco, e costruisce invece un intero sistema di caching e streaming per gestirne l'immensità senza comprometterne la precisione dichiarata. Dove DwarfStar dice "rendo il modello più piccolo perché la RAM è quella che è", Colibrì dice "lascio il modello grande com'è e reinvento il modo in cui la memoria lo tocca". Sono due risposte diverse alla stessa domanda, e messe a confronto raccontano meglio di qualunque benchmark quanto sia vivo, in questo momento, il fermento attorno all'inferenza locale di modelli di frontiera.

C'è poi una differenza di scala che vale la pena sottolineare: DwarfStar lavora su un modello da 284 miliardi di parametri pensato per hardware Apple di fascia alta, con benchmark che raggiungono i 25-36 token al secondo in generazione su Mac Studio. Colibrì affronta un modello quasi tre volte più grande, 744 miliardi di parametri, e lo fa nella condizione più ostile possibile, un PC generico con RAM limitata e un disco qualunque, ottenendo di conseguenza numeri molto più modesti. Non è un paragone alla pari, ed è giusto dirlo con chiarezza, ma è proprio la distanza fra i due approcci a rendere evidente quanto lo spazio di manovra fra "compressione del modello" e "streaming intelligente della memoria" sia ancora tutto da esplorare.

Perché conta, oltre la demo

Al di là del fascino tecnico immediato, Colibrì tocca un tema che negli ultimi mesi è tornato centrale nel dibattito sull'intelligenza artificiale: la sovranità tecnologica, ovvero la possibilità concreta di eseguire modelli capaci senza dipendere da un'infrastruttura cloud di terzi. Un modello che gira interamente sul proprio hardware, per quanto lentamente, non manda un solo byte di conversazione a un server esterno, e questo per certi contesti, ricerca, sviluppo di strumenti proprietari, sperimentazione su dati sensibili, ha un valore che va oltre la semplice curiosità tecnica.

Colibrì suggerisce inoltre qualcosa di più ampio sul futuro dei modelli MoE su hardware consumer: che la strada per democratizzare l'accesso ai modelli di frontiera non passa necessariamente, o soltanto, dal renderli più piccoli. Passa anche dal ripensare radicalmente come la memoria viene gestita, trattando RAM, VRAM e disco come un'unica risorsa fluida invece che come compartimenti stagni. È un'intuizione che, se dovesse maturare oltre lo stadio sperimentale, potrebbe influenzare il modo in cui vengono progettati i prossimi runtime di inferenza, ben oltre il perimetro di un singolo progetto personale.

I nodi ancora aperti

Sarebbe disonesto, verso i lettori e verso lo stesso spirito del progetto, chiudere senza elencare le criticità che Colibrì porta ancora con sé. La velocità in condizioni di cache fredda resta bassissima, al limite dell'inutilizzabile per qualunque compito che richieda risposte rapide. La dipendenza dalle prestazioni dello storage è totale: chi non dispone di un NVMe realmente veloce vedrà numeri difficilmente distinguibili da un timeout. C'è poi la questione, ancora aperta, dell'accuratezza: un primo benchmark di qualità condotto dalla comunità ha misurato un punteggio del 62,5 per cento su una batteria di test standard, sensibilmente più basso rispetto al 85-95 per cento pubblicato per la versione originale del modello a piena precisione, sebbene lo stesso autore inviti alla cautela, segnalando che il metodo di valutazione usato penalizza strutturalmente un modello pensato per ragionare passo dopo passo, e che serve ancora un confronto diretto e controllato fra le due precisioni per isolare davvero il costo della quantizzazione dal rumore della misura.

Va aggiunta, infine, una constatazione più prosaica: l'usabilità per un pubblico non tecnico è, allo stato attuale, pressoché nulla. Configurare Colibrì significa scaricare centinaia di gigabyte, convertire pesi, leggere variabili d'ambiente e interpretare log di diagnostica. È uno strumento per chi sa già cosa sta facendo, non un'applicazione pronta all'uso, e servono benchmark indipendenti su hardware più vario prima di poter dire con certezza quanto i numeri pubblicati siano rappresentativi al di fuori del laboratorio artigianale in cui il progetto è nato.

Conclusioni

Colibrì non dimostra che i modelli enormi siano diventati comodi da usare su un computer qualunque, e sarebbe fuorviante raccontarlo così. Dimostra, piuttosto, che i confini dell'inferenza locale possono essere spinti molto più in là di quanto la maggior parte degli addetti ai lavori avrebbe scommesso fino a poche settimane fa, trattando la scarsità di memoria non come un ostacolo insormontabile ma come un vincolo di progettazione da aggirare con creatività ingegneristica. È un progetto importante da raccontare proprio perché, insieme a esperimenti paralleli come DwarfStar, mostra dove sta andando davvero l'ecosistema dell'AI open source in questo momento: non verso un'unica soluzione definitiva, ma verso una pluralità di strategie, chi comprime il modello, chi reinventa la memoria, che si confrontano apertamente sullo stesso terreno.

Colibrì non è il futuro dell'AI locale per tutti, ma è un segnale chiarissimo di quanto i runtime stanno diventando più creativi nel superare i limiti fisici dell'hardware.