Kolibri di Aleph Alpha: il MoE da 78B che gira (quasi) in locale

Kolibri è il modello open-weight di Aleph Alpha: 78 miliardi di parametri, dei quali per ogni token ne attivano solo 3,46. È un Mixture-of-Experts (MoE) pensato per ambienti mission-critical, rilasciato il 3 ottobre 2026 con licenza Apache 2.0 e pesi in formato FP8. Se i modelli grandi restano un affare da data center, i MoE sono la via più concreta per portarne la qualità su hardware che può stare in un ufficio. In questo articolo lo mettiamo sul banco di prova: cosa serve per girarlo in locale, quanto costa davvero, e cosa manca ancora per usarlo al meglio.

Cos'è Kolibri, in una tabella

I numeri ufficiali dal sito del vendor e dalla model card su Hugging Face:

Specifica	Valore
Architettura	MoE: 50 layer, 384 esperti per layer più 1 condiviso, top-6
Parametri totali	78,1 miliardi (78.103.074.560)
Parametri attivi per token	3,46 miliardi (3.457.573.120)
Lunghezza di contesto	1.048.576 token (consigliati ≤ 262.144)
Precisione	FP8 per pesi e KV cache, BF16 per embedding e router
Lingue di specializzazione	Tedesco e inglese
Licenza	Apache 2.0, open weights
Data di rilascio	3 ottobre 2026
Requisito minimo dichiarato	2× A100 80GB, 2× H100 SXM5, 1× H200, 1× B200 o 1× B300

Il modello è addestrato su 20 trilioni di token di un corpus bilingue (~62,5% inglese, ~23,9% tedesco, ~13,6% codice) su 768 GPU B200 in 21 giorni; la knowledge cutoff è il 18 giugno 2026 per entrambe le lingue. Fonti: pagina ufficiale e model card.

MoE: 78B di qualità, 3,46B di costo

In un modello denso, ogni token fa passare tutti i parametri in calcolo. In un Mixture-of-Experts ogni layer contiene centinaia di "esperti" (sotto-reti più piccole) e un router ne attiva solo alcuni: in Kolibri sono 6 su 384 per layer, più 1 esperto condiviso sempre attivo. Il risultato è la capacità di memoria di un modello da 78B e il costo di calcolo di un modello da ~3,5B.

Perché conta: il costo di generazione scala con i parametri attivi, non con quelli totali. I parametri totali devono stare in VRAM (ci devono stare, altrimenti il modello non parte), ma ogni token viene calcolato da una frazione piccola di loro. È lo stesso principio dei modelli che hai già incontrato — Qwen3 30B-A3B o Gemma 4 26B-A4B — spinto su un'architettura più grande.

Sui benchmark pubblicati dal vendor (misure loro: da leggere con quella lente):

Benchmark	Kolibri	Qwen3.6 35B-A3B	Nemotron 3 Super 120B-A12B
GPQA Diamond (EN)	84,3%	83,4%	78,0%
AIME 2026 (EN)	96,0%	91,0%	90,4%
Tau3-Bench (Banking)	38,1%	10,6%	15,5%
BFCL v4	61,4%	67,2%	61,0%

Due letture: su ragionamento e matematica sta coi modelli molto più grandi in parametri attivi; sul tool calling agentic (Tau3-Bench Banking) è nettamente sopra i MoE della stessa taglia, ma dietro a Qwen3.6 35B-A3B su BFCL. Sul grafico di efficienza del vendor, Kolibri segna 71% di media sui benchmark in tedesco a ~47.000 byte/s per GPU, sulla frontiera della curva.

Il test in locale: cosa ti serve

Qui si fa interessante, e qui si fa complicato.

I pesi ufficiali sono FP8, con un footprint dichiarato di ~78GB di memoria modello: il minimo del vendor sono due GPU da 80GB. La community ha però già prodotto le conversioni GGUF: il repository Hob-forge/Kolibri-1-GGUF (conversione indipendente, non creata né approvata da Aleph Alpha) offre le quantizzazioni dal 2 all'8 bit:

Quantizzazione	Peso	Hardware realistico
Q2_K	28,6 GB	RTX 5090 32GB (~$5.220), Mac con 48GB unificati
Q3_K_M	37,5 GB	2× GPU 32GB, Mac con 64GB unificati
Q4_K_M	47,5 GB	GPU da 96GB, Mac Studio M5 Max 128GB (~$5.099)
Q5_K_M	55,6 GB	2× GPU 32/48GB, Mac con 96GB+ unificati
Q8_0	83,1 GB	2× GPU 80GB (quasi i pesi originali)

Il prezzo da pagare: llama.cpp standard non supporta ancora l'architettura kolibri1. Bisogna applicare il patch incluso nel repository GGUF (sul commit 836d571 di llama.cpp) e compilare, oppure usare le binary precompilate rilasciate dalla stessa community. Ollama e LM Studio non lo caricano finché non aggiungono il supporto.

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
git checkout 836d571
git am /path/to/kolibri1-llama.cpp.patch
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON
cmake --build build -j --target llama-server llama-cli
./build/bin/llama-server -m Kolibri-1-Q4_K_M.gguf -c 32768 --jinja --temp 1.0 --top-p 0.97 --top-k 128

Se va bene: apri http://localhost:8080 nel browser e hai la chat funzionante, con il reasoning mode controllabile per richiesta (nessuno, basso, medio, alto). Se non va: verifica che il patch sia applicato sul commit corretto e che la VRAM copra pesi + KV cache — un contesto da 32K aggiunge diversi gigabyte oltre al peso del modello.

I conti: quanto costa davvero

Due configurazioni, dai list price del dataset che usiamo nel pianificatore (ottobre 2026):

Setup	Prezzo (2× se doppio)	Ammortamento 36 mesi
2× H100 80GB SXM (minimo vendor, FP8)	2 × $27.000 = $54.000	$1.500/mese
Mac Studio M5 Max 128GB (Q4_K_M)	$5.099	$142/mese

La bolletta, per la configurazione da data center, con 10 ore al giorno e 0,30 €/kWh: due H100 a 700W ciascuna fanno 1,4 kW in carico; 1,4 × 10 = 14 kWh al giorno, cioè €4,20 al giorno, ~€1.530 all'anno. La bolletta del Mac Studio è un ordine di grandezza sotto: la macchina unificata assorbe una frazione dei watt di due schede da 700W.

Setup	Ammortamento 36 mesi	Bolletta 36 mesi (10h/die)	Totale 36 mesi
2× H100 80GB	$54.000	~$5.000	~$59.000
Mac Studio M5 Max 128GB (Q4_K_M)	$5.099	molto inferiore	~$5.500

Il rapporto 10:1 sta nelle schede, non nella bolletta. In più: con l'hardware tuo, l'IA è sempre accesa — nessun token a pagamento, nessun limite di utilizzo, i dati restano in casa. Sul cloud il costo scala col tuo utilizzo: se generi 10 ore al giorno, il locale ammortizza in pochi mesi; se lo usi un'ora al giorno, il cloud può costare meno per un anno intero.

E i limiti?

• Lingue: tedesco e inglese, punto. Il corpus è 62,5% inglese e 23,9% tedesco: per lavoro in italiano o francese, Qwen o Gemma danno oggi risultati più affidabili. Kolibri è un modello europeo serio, ma non è un modello multilingua.
• Attrito: un patch da compilare, niente Ollama, niente LM Studio. Per il flusso "funziona in 10 minuti" non è ancora il momento di Kolibri.
• VRAM: anche in Q4_K_M sono 47,5GB. Le schede da 16GB restano fuori dal gioco.
• Benchmark: sono tutti numeri del vendor; le misurazioni indipendenti su hardware locale sono ancora poche.
• Contesto da 1M: validato dal vendor, ma la raccomandazione è ≤ 262K token per efficienza e qualità sui task complessi.

Da dove partire

Se vuoi capire il MoE prima di impegnare l'hardware: quando un modello grande non serve. Se stai dimensionando la RAM: KV cache: perché la RAM conta più del modello. E se ti serve la via multilingua in italiano: Qwen, il modello open con il miglior supporto multilingua.

In sintesi

Kolibri è il MoE open-weight europeo per eccellenza di questo autunno: 78,1B di parametri con 3,46B attivi per token, contesto fino a 1M (consigliati 256K), pesi FP8, licenza Apache 2.0, reasoning mode e tool calling. I benchmark del vendor lo mettono in testa su ragionamento e matematica, vicino alla frontiera di efficienza; il costo reale è in VRAM (~78GB in FP8, 47,5GB in Q4_K_M) e nell'attrito del patch llama.cpp che Ollama e LM Studio non hanno ancora. Per chi lavora in italiano e in francese, aspettano le versioni multilingue: oggi la via è Qwen. Quando l'architettura kolibri1 entrerà in llama.cpp e Ollama, Kolibri sarà il primo modello da mettere alla prova sul tuo hardware.

Articolo generato con IA