L’ANALISI
Kolibri-1 in llama.cpp: cosa cambia con il supporto nativo b11709
Aggiornamento operativo su Kolibri-1: supporto nativo in llama.cpp b11709, conversione GGUF BF16 e Q4_K_M, requisiti di memoria, limiti e protocollo di prova locale.
In breve: Il supporto b11709 rimuove un ostacolo software: Kolibri-1 può ora essere convertito e avviato direttamente con llama.cpp invece di dipendere soltanto dallo stack Aleph Alpha e dal plugin vLLM. Non rimuove però il vincolo principale, cioè la dimensione dei pesi: il GGUF Q4_K_M documentato è circa 45 GiB e va ancora provato su una macchina autorizzata con memoria e disco sufficienti.
Aggiornamento del 17 ottobre
La build llama.cpp b11709 include il commit che aggiunge l’architettura Kolibri-1, il mapping dei tensori, il modello GGUF e il relativo template di chat. La release distribuisce binari precompilati per numerosi backend, quindi il delta è disponibile in un pacchetto pubblico e non soltanto nel ramo principale.
Conversione e formati GGUF
La pull request documenta una conversione BF16 da circa 156 GiB e una quantizzazione Q4_K_M da circa 45 GiB. Questi numeri descrivono i file prodotti dal contributore, non la memoria di picco completa: runtime, buffer, cache KV, contesto e offload aggiungono ulteriore consumo.
Che cosa resta invariato nel modello
Kolibri-1 resta un MoE bilingue inglese-tedesco da 78,1 miliardi di parametri totali e circa 3,46 miliardi attivi per token, con licenza Apache 2.0. Il model card raccomanda fino a 262.144 token per efficienza e dichiara una validazione fino a 1.048.576 token, ma il contesto lungo aumenta memoria e latenza.
Il test pubblicato non è un benchmark consumer
Il contributore ha verificato l’esecuzione su quattro GPU NVIDIA A800. Questo conferma il percorso software usato nella pull request, ma non permette di dedurre che il modello funzioni bene su una singola GPU, su CPU o sull’hardware disponibile a Francesco. Servono misure separate per caricamento, prompt processing e generazione.
Quando il supporto diventa utile
Il nuovo backend rende sensato un test di fattibilità locale e un confronto tra BF16, Q4_K_M ed eventuali quantizzazioni successive. Il risultato editoriale utile non è un semplice avvio: deve mostrare memoria residente, velocità, stabilità, qualità bilingue, uso del contesto e comportamento su un task RAG controllato.
Condizioni e limitazioni
Il supporto architetturale non certifica tutte le combinazioni di backend, offload e quantizzazione. Le prestazioni dipendono da hardware, build, driver e parametri. Prima di scaricare decine di gigabyte vanno verificati spazio, memoria e autorizzazione della macchina; i benchmark del produttore e il test A800 restano evidenza del progetto, non una prova indipendente sul sistema finale.
Checklist pratica
- Verificare una macchina autorizzata con almeno 60 GiB liberi per file, cache e margine operativo.
- Bloccare la build b11709 o un commit successivo esplicito e registrare backend, driver e flag di compilazione.
- Scaricare o produrre una sola quantizzazione iniziale e verificarne checksum, dimensione e metadati GGUF.
- Tentare il caricamento con contesto breve prima di aumentare la finestra e registrare memoria di picco ed errori.
- Eseguire almeno tre run identici su un task tecnico bilingue e tre su un piccolo corpus RAG.
- Separare prompt processing e generazione, misurando token al secondo, tempo totale e qualità della risposta.
- Documentare ogni offload CPU o GPU e non confrontare configurazioni diverse come se fossero equivalenti.
- Interrompere il test prima di acquisti o noleggi non autorizzati; un esito negativo resta un risultato utile.