Colibrì fa girare un modello AI da 744 miliardi di parametri con 25 GB di RAM
Pubblicato il: July 28, 2026
La prima cosa da capire di Colibrì è che non promette miracoli: non trasforma un normale computer in un cluster di GPU, non cancella il costo computazionale dell'intelligenza artificiale e non permette di eseguire un modello da 744 miliardi di parametri alla stessa velocità con la quale interroghiamo un servizio cloud. Fa una cosa diversa e, secondo me, più interessante, perché sposta il confine tra ciò che consideriamo impossibile e ciò che consideriamo soltanto lento.
Colibrì è un motore di inferenza open source sviluppato da Vincenzo Fornaro. Il suo primo obiettivo è stato eseguire GLM-5.2, un modello Mixture of Experts da 744 miliardi di parametri, anche su una macchina consumer con circa 25 GB di RAM disponibili, lasciando sul disco la maggior parte dei pesi e caricando nella memoria più veloce soltanto ciò che serve in quel momento. Il motore tratta VRAM, RAM e storage come livelli differenti di una stessa gerarchia: avere poca memoria veloce riduce le prestazioni, ma non obbliga necessariamente a modificare la precisione dei pesi o il comportamento del router.
Il 27 luglio ho avuto la fortuna di partecipare, come uno degli intervistatori, alla prima intervista pubblica di Vincenzo Fornaro, ospitata dagli amici della Brigata dei Geek Estinti. È stata una conversazione lunga e molto tecnica, dalla quale è emerso però con chiarezza un elemento che rischia di perdersi dietro ai 744 miliardi di parametri, alle quantizzazioni e ai benchmark: Colibrì non nasce da un esercizio teorico sull'ottimizzazione dell'inferenza, ma da un limite estremamente concreto. Vincenzo voleva provare un modello molto grande e non aveva il computer necessario per farlo.
Il progetto nato dal computer sbagliato
Il computer sul quale è iniziato lo sviluppo di Colibrì non assomiglia alla macchina che normalmente assoceremmo all'esecuzione di un modello di frontiera. Fornaro ha raccontato di aver lavorato su un normale PC Windows, usando WSL, con 32 GB di RAM, una GPU integrata e un SSD NVMe consumer: non una workstation costruita per l'AI, quindi, ma sostanzialmente la macchina che aveva già a disposizione.
L'esperimento iniziale era quasi un gioco, nato dal desiderio di capire fino a dove sarebbe riuscito a spingersi prima di far collassare il computer, e il primo prototipo non era nemmeno destinato alla pubblicazione. Era rimasto per qualche tempo sul disco del suo autore, come spesso accade ai progetti sviluppati per curiosità, fino alla decisione di caricarlo su GitHub e mostrarlo su Reddit e Hacker News.
A quel punto la reazione ha sorpreso prima di tutto lui e, durante l'intervista, a circa tre settimane dalla nascita del progetto, Fornaro parlava già di centinaia di pull request, tra aperte e chiuse, e di una comunità che aveva iniziato a proporre, implementare e verificare quantizzazioni differenti, backend per nuovo hardware e strategie più efficaci per gestire gli esperti del modello.
L'origine del progetto non è soltanto un dettaglio narrativo, perché il computer insufficiente è la ragione per cui Colibrì ha assunto questa forma. Se Vincenzo avesse avuto immediatamente accesso a centinaia di gigabyte di RAM o a un sistema multi-GPU, probabilmente avrebbe affrontato il problema nel modo abituale, cercando di collocare la maggior parte possibile del modello nella memoria più veloce; non potendolo fare, ha dovuto cambiare la domanda, passando da "come faccio a far entrare il modello in memoria?" a "è davvero necessario che il modello entri interamente in memoria?".
Un modello da 744 miliardi di parametri non ne usa 744 miliardi per ogni token
La risposta dipende dall'architettura Mixture of Experts, normalmente abbreviata in MoE. In un modello denso, tutti o quasi tutti i parametri partecipano alla generazione di ogni token; in un modello MoE esistono invece numerosi gruppi specializzati, chiamati esperti, e un router decide quali debbano essere attivati per elaborare uno specifico input.
GLM-5.2 possiede complessivamente 744 miliardi di parametri, ma ne attiva circa 40 miliardi per token e, secondo la documentazione di Colibrì, soltanto circa 11 GB di esperti instradati cambiano tra un token e quello successivo. Colibrì sfrutta questa caratteristica separando la componente densa del modello dagli esperti selezionati dinamicamente: la parte densa, che comprende attenzione, embedding ed esperti condivisi, contiene circa 17 miliardi di parametri e, nella quantizzazione int4 usata dal progetto, occupa poco meno di 10 GB, mentre i 19.456 esperti instradati, che occupano complessivamente circa 370 GB, restano sul disco e vengono caricati quando il router stabilisce che sono necessari.
I parametri smettono quindi di essere considerati esclusivamente come uno stato che deve risiedere in memoria e diventano dati da collocare dinamicamente. Il repository paragona l'idea al comportamento di un compilatore JIT: un compilatore just-in-time non compila preventivamente ogni possibile percorso del programma, ma osserva quali percorsi vengono realmente eseguiti e dedica le proprie risorse a quelli più caldi.
Colibrì applica sostanzialmente la stessa intuizione ai pesi del modello.
Gli esperti utilizzati più frequentemente possono essere mantenuti nella RAM o nella VRAM, mentre quelli meno usati rimangono sul disco. Il runtime registra il comportamento del workload e aggiorna un file di utilizzo, così da individuare progressivamente quali esperti convenga mantenere residenti, mentre il router può lavorare in anticipo rispetto all'esecuzione, tentando di precaricare gli esperti che probabilmente serviranno al layer successivo. Non esiste più, quindi, un singolo requisito di memoria che la macchina deve soddisfare, ma una gerarchia nella quale la posizione dei pesi determina la velocità e non dovrebbe determinare il risultato del calcolo. Questa è la tesi tecnica centrale del progetto.
È lento, e non è un dettaglio da nascondere
Sulla configurazione minima Colibrì è lento. Il repository riporta, per la macchina da circa 25 GB dalla quale è iniziato il progetto, una velocità compresa tra 0,05 e 0,1 token al secondo a freddo, quindi una risposta può richiedere minuti; su un sistema CPU con 128 GB di RAM, a cache calda, è stata misurata una velocità nell'ordine di 1,8 token al secondo, mentre su una macchina con sei RTX 5090 e tutti gli esperti residenti nella memoria veloce il progetto dichiara valori tra 5,8 e 6,8 token al secondo.
Sono misurazioni prodotte dagli autori e dalla comunità di Colibrì, non benchmark indipendenti, e le configurazioni sono profondamente diverse, quindi non vanno trasformate in una classifica tra macchine; mostrano però con una certa efficacia il comportamento della gerarchia, perché più pesi possono essere mantenuti vicino all'unità di calcolo, più il sistema è veloce, mentre quando gli esperti devono essere continuamente caricati da un SSD il collo di bottiglia diventa inevitabilmente l'I/O.
Questo significa che Colibrì, sull'hardware minimo, non è oggi lo strumento giusto per chi vuole una conversazione interattiva fluida, e fingere il contrario servirebbe soltanto a trasformare un'idea interessante nell'ennesima promessa facilmente smentibile sull'intelligenza artificiale. Ma lento non significa necessariamente inutile: durante l'intervista ho osservato che l'impiego asincrono disaccoppia la velocità di generazione dal valore del risultato, perché posso porre una domanda la sera e leggere la risposta la mattina.
Fornaro ha confermato che non si tratta soltanto di un caso ipotetico, visto che alcuni utenti stavano già utilizzando Colibrì in batch, lasciando il sistema lavorare ciclicamente e controllandone i risultati in seguito.
La Local AI, insomma, non deve necessariamente essere una chat. Può diventare infrastruttura.
Portare il modello verso i dati
Una parte consistente del discorso sulla Local AI continua a utilizzare la chat come unità di misura: un modello locale viene giudicato in base a quanto rapidamente risponde, quanto è fluida la generazione e quanto l'esperienza assomiglia a quella offerta da un servizio remoto. È una metrica comprensibile, ma rischia di essere limitante, perché gran parte del software aziendale non lavora in modo interattivo e molti processi vengono eseguiti in background, attraverso code, job pianificati o lavorazioni notturne.
Una fattura non deve necessariamente essere classificata in mezzo secondo, un archivio documentale non deve essere indicizzato mentre una persona osserva una barra di avanzamento e un agente che controlla migliaia di file può impiegare ore, purché il risultato sia disponibile quando serve. Il valore dell'elaborazione, quindi, non è sempre direttamente proporzionale al numero di token generati al secondo.
Questo rende Colibrì interessante nei casi nei quali sia preferibile portare il modello verso i dati, invece di portare i dati verso un modello remoto. Per una volta la vecchia battuta funziona persino meglio del previsto: la montagna è il modello, ed è davvero lei ad andare da Maometto, cioè verso i dati, invece di obbligare i dati ad abbandonare il luogo nel quale si trovano per raggiungere un servizio remoto.
Privacy e controllo non sono gli unici motivi. Esistono ambienti isolati, vincoli contrattuali, quantità di dati che sarebbe costoso trasferire e workload che possono essere eseguiti nelle ore nelle quali l'infrastruttura è meno utilizzata; questo non significa che Colibrì sia già pronto per essere inserito in produzione in ognuno di questi scenari, ma significa che il paradigma merita di essere studiato senza pretendere che la prima applicazione debba necessariamente essere l'ennesima finestra nella quale scrivere "ciao".
La fisica non sparisce
L'intelligenza artificiale generativa viene normalmente raccontata come un problema di potenza di calcolo. Lo è, naturalmente, ma è anche un problema di memoria e di movimento dei dati: una GPU può eseguire molto rapidamente le moltiplicazioni necessarie, ma deve ricevere i pesi sui quali operare e, nei grandi modelli, la quantità e la larghezza di banda della memoria diventano quindi determinanti, mentre la memoria ad alte prestazioni resta una delle componenti più costose dell'infrastruttura.
Colibrì non elimina questo costo, ma propone di negoziarlo.
Una parte dei pesi può stare nella VRAM, una parte nella RAM e una parte nello storage; chi possiede più memoria ottiene prestazioni migliori, mentre chi ne possiede meno può comunque eseguire il modello, accettando un costo in termini di tempo. Il disco è più lento della RAM - in termini di latenza, tipicamente di circa tre ordini di grandezza, e in fisica gli ordini di grandezza non sono gratis - mentre la RAM di sistema, a sua volta, offre normalmente molta meno banda della memoria locale di una GPU.
Nessuna quantità di software può cancellare questa gerarchia fisica, ma propone di negoziarlo. Una parte dei pesi può stare nella VRAM, una parte nella RAM e una parte nello storage; chi possiede più memoria ottiene prestazioni migliori, mentre chi ne possiede meno può comunque eseguire il modello, accettando un costo in termini di tempo. Il disco è più lento della RAM - in termini di latenza, tipicamente di circa tre ordini di grandezza, e in fisica gli ordini di grandezza non sono gratis - mentre la RAM di sistema, a sua volta, offre normalmente molta meno banda della memoria locale di una GPU.
Nessuna quantità di software può cancellare questa gerarchia fisica, ma il software può decidere meglio quali dati debbano trovarsi in ciascun livello, quali possano essere spostati, quando convenga farlo e quanta parte del costo del trasferimento possa essere nascosta sovrapponendo lettura e calcolo. È esattamente qui che Colibrì concentra buona parte delle proprie ottimizzazioni: ogni esperto viene letto con una singola operazione, i caricamenti possono avvenire in parallelo al calcolo degli esperti già residenti, le posizioni elaborate in batch condividono le letture e il router tenta di anticipare gli esperti necessari al layer successivo.
Il progetto supporta anche una seconda copia del modello collocata su un altro SSD, distribuendo gli esperti tra i due dischi per sommarne la banda disponibile. Non è striping a livello di filesystem: il runtime decide deterministicamente da quale copia leggere ogni esperto e continua a funzionare anche nel caso in cui il secondo disco non contenga tutti gli shard o diventi indisponibile. È un compromesso, non una scorciatoia.
E l'SSD, quanto lo massacriamo?
A questo punto una domanda viene quasi da sola: se Colibrì continua a recuperare dal disco gli esperti necessari, quanto impatta sulla durata dell'SSD? Produce una sorta di thrashing capace di consumarlo rapidamente, oppure il problema è diverso?
Il percorso pesante di Colibrì è sostanzialmente in lettura: gli esperti vengono recuperati dal disco, utilizzati e poi eventualmente mantenuti nei livelli di memoria più veloci. Questo conta perché l'endurance degli SSD, normalmente espressa attraverso i TBW, riguarda soprattutto la quantità di dati scritti sulle celle e non la quantità di dati letti; un workload di lettura intenso può produrre calore, saturare la banda disponibile, innescare throttling termico e mettere in evidenza i limiti di un disco consumer, ma non consuma le celle nello stesso modo di una riscrittura continua dei pesi.
Colibrì effettua comunque alcune scritture, per esempio aggiornando file laterali come .coli_usage, che registra gli esperti utilizzati, e .coli_kv, che conserva lo stato compresso della KV cache tra un'esecuzione e quella successiva, ma il volume di queste operazioni non è paragonabile alla riscrittura continuativa dei circa 370 GB del modello. Il rischio da osservare sembra quindi riguardare soprattutto la qualità dell'SSD, la capacità di sostenere letture prolungate, la temperatura e l'eventuale throttling, più che un'improvvisa distruzione delle celle NAND; resta comunque un tema sul quale servono misurazioni di lungo periodo, perché Colibrì ha poche settimane di vita e qualunque affermazione assoluta sul comportamento dopo mesi o anni sarebbe prematura.
Guardare dentro il routing
C'è un'altra caratteristica di Colibrì che non riguarda direttamente la velocità: il progetto prova a rendere osservabile una parte del comportamento del modello durante l'inferenza. La dashboard mostra quali esperti si trovano nella VRAM, nella RAM o sul disco e permette di seguirne l'attivazione durante la generazione, mentre la vista chiamata Brain rappresenta i 19.456 esperti come una sorta di corteccia dinamica, nella quale il colore indica il livello di memoria, la luminosità il calore di routing e gli esperti selezionati durante il turno vengono evidenziati.
Atlas prova invece a organizzare gli esperti sulla base di affinità tematiche misurate osservando il routing prodotto da insiemi di prompt differenti. Qui bisogna essere molto precisi: dire che un esperto si attiva più frequentemente con prompt riguardanti SQL, il diritto o la poesia non significa che quell'esperto "contenga" SQL, il diritto o la poesia, ma soltanto che, nel corpus e nei test utilizzati dal progetto, ha mostrato una maggiore affinità di routing con determinati argomenti, lingue o formati.
La differenza non è cosmetica, perché il risultato dipende dai probe scelti, dalla loro distribuzione e dal metodo statistico usato per confrontare le attivazioni, e gli stessi partecipanti al lavoro su Atlas stanno discutendo come distinguere le affinità dipendenti dal corpus dalle strutture di co-attivazione più stabili. Siamo quindi davanti a uno strumento sperimentale, non a una tomografia definitiva della conoscenza del modello, ma resta un lavoro interessante perché trasforma il routing da un meccanismo interno e sostanzialmente invisibile in qualcosa che può essere misurato, confrontato e forse utilizzato per migliorare il caching, il prefetch e la disposizione fisica degli esperti.
Un motore, ma soprattutto una comunità di macchine
Il motore di inferenza di Colibrì è scritto in C; il repository comprende poi strumenti Python per la conversione dei modelli, il launcher e il gateway API, oltre a backend opzionali per CUDA e Metal. Non insisterei però troppo sulla quantità di file, sulle dipendenze o sulla presunta purezza dell'implementazione, perché il repository sta cambiando rapidamente e una descrizione corretta oggi potrebbe essere superata tra pochi giorni: la caratteristica più interessante non è la forma attuale del codice, ma il modo nel quale viene sviluppato.
Fornaro, ovviamente, non possiede tutto l'hardware sul quale Colibrì deve essere provato e non può verificare personalmente ogni processore, configurazione multi-GPU, Mac con memoria unificata o sistema NUMA. La comunità diventa quindi parte dell'architettura del progetto: le persone eseguono test sulle proprie macchine, riportano regressioni, confrontano quantizzazioni e propongono modifiche accompagnate da misurazioni, così il maintainer non riceve soltanto idee, ma risultati sperimentali prodotti su hardware al quale non avrebbe avuto accesso.
Durante l'intervista gli sono brillati gli occhi quando ha raccontato che un membro della community aveva potuto provare Colibrì su Intel Optane, semplicemente perché ne aveva ancora uno a disposizione. Era abbastanza evidente che Vincenzo avrebbe voluto essere lui quello con l'Optane.
È uno dei meccanismi più interessanti dell'open source: il limite economico del singolo sviluppatore viene parzialmente compensato dalla diversità delle macchine possedute dalla comunità, quindi il laboratorio non è un luogo, ma la rete di persone che esegue gli esperimenti. Questo comporta anche dei rischi, perché una crescita così rapida può rendere difficile verificare ogni contributo, conservare una direzione architetturale coerente e distinguere un miglioramento generale da un risultato valido soltanto su una configurazione specifica; la cautela dimostrata da Vincenzo durante l'intervista è quindi sensata, perché prima di introdurre una nuova ottimizzazione o dichiarare il supporto per un altro modello vuole essere ragionevolmente certo di non compromettere ciò che già funziona. Non è perfezionismo: è il lavoro di un maintainer.
La qualità non è una conseguenza automatica della compressione
Caricare soltanto una parte del modello non è l'unica ottimizzazione necessaria, perché un modello da centinaia di miliardi di parametri occuperebbe comunque una quantità ingestibile di spazio se i pesi fossero conservati nella precisione originale. Colibrì usa quindi versioni quantizzate, riducendo il numero di bit necessari a rappresentarli, e il container consigliato per GLM-5.2 occupa circa 372 GB, utilizza una quantizzazione int4 group-scaled gs64 e mantiene la testa MTP in int8.
La specificità non è un dettaglio. La documentazione avverte esplicitamente che alcune versioni precedenti della quantizzazione int4 hanno prodotto una riduzione misurabile della qualità, loop nella modalità di ragionamento e generazioni che non terminavano, mentre anche la testa utilizzata per la predizione speculativa deve mantenere una precisione sufficiente, visto che la variante int4 aveva sostanzialmente annullato il tasso di accettazione dei token proposti.
È un aspetto sano del progetto, perché Colibrì non tratta la quantizzazione come una compressione gratuita: la qualità viene misurata e, quando una configurazione si dimostra inadeguata, la documentazione lo dichiara. La stessa cautela deve valere quando raccontiamo il runtime, quindi è corretto dire che un modello da 744 miliardi di parametri può essere eseguito con circa 25 GB di RAM, ma non sarebbe corretto sostenere che quell'esperienza sia equivalente a utilizzare il modello su una grande infrastruttura.
È ancora troppo presto
Colibrì ha poche settimane di vita, quindi è troppo presto per sapere se diventerà un runtime di riferimento, se le sue idee verranno incorporate in progetti più maturi oppure se l'evoluzione dei modelli e dell'hardware renderà meno rilevante il problema che sta cercando di risolvere. Al momento in cui scrivo, il progetto dichiara il supporto per GLM-5.2 e OLMoE, mentre altre famiglie MoE sono indicate nella roadmap e anche gli algoritmi di placement, scheduling e sovrapposizione tra CPU e GPU sono ancora oggetto di ricerca.
Il progetto richiede inoltre centinaia di gigabyte di storage, preferibilmente veloce. Sulla mia macchina, seguendo il README e scaricando la versione di GLM indicata dal repository, il modello ha richiesto circa 400 GB: non è esattamente la quantità di spazio libero che la maggior parte delle persone tiene a disposizione per fare una prova nel fine settimana. Sulla configurazione minima le prestazioni sono inoltre basse e la compatibilità con un modello non equivale automaticamente alla robustezza necessaria per usarlo come componente di un sistema aziendale.
Sono limiti reali, ma nessuno di questi annulla la tesi dimostrata dal progetto: un grande modello MoE non deve necessariamente risiedere per intero nella memoria più veloce disponibile, perché può essere distribuito su livelli differenti, può imparare quali esperti convenga mantenere residenti, può anticipare le letture e può adattare le prestazioni alle risorse presenti, invece di rifiutarsi semplicemente di partire quando una singola soglia di memoria non viene raggiunta.
Dal "non si può fare" al "quanto possiamo aspettare"
La tecnologia progredisce anche quando qualcuno decide di non accettare il requisito che tutti gli altri considerano inevitabile. Nel caso di Colibrì, quel requisito era che un modello dovesse entrare nella memoria della macchina prima di poter essere eseguito; Vincenzo Fornaro non disponeva di quella memoria e, invece di rinunciare, ha trattato il modello come una quantità di dati da collocare e spostare dinamicamente.
Il risultato, oggi, è ancora lento sull'hardware più piccolo, giovane come progetto e lontano dall'essere la soluzione universale per l'inferenza locale, ma funziona abbastanza da cambiare la domanda. Non dobbiamo più chiederci soltanto se una macchina possieda memoria sufficiente per eseguire un modello: possiamo chiederci quali parti debbano restare residenti, quali possano essere caricate dal disco, quanto sia prevedibile il routing e quanto tempo siamo disposti ad aspettare in funzione del valore dell'elaborazione.
Sembra una differenza sottile. È la differenza tra impossibile e possibile.
Fonti e nota metodologica
Questo articolo è basato sulla documentazione e sul codice pubblicati nel repository ufficiale di Colibrì e sulla conversazione con Vincenzo Fornaro trasmessa il 27 luglio 2026 durante la puntata 114 della Brigata dei Geek Estinti, alla quale l'autore ha partecipato come intervistatore.
Le caratteristiche tecniche e i dati prestazionali riportati provengono dal progetto e dalla sua comunità. Non costituiscono benchmark indipendenti e possono cambiare rapidamente, considerata la fase iniziale dello sviluppo.
Repository ufficiale di Colibrì:
https://github.com/JustVugg/colibri
