Kolibri d'Aleph Alpha : le MoE de 78B qui tourne (presque) en local

Kolibri est le modèle open-weights d'Aleph Alpha : 78 milliards de paramètres, dont seuls 3,46B sont activés par token. C'est un Mixture-of-Experts (MoE) pensé pour les environnements critiques, sorti le 3 octobre 2026 sous licence Apache 2.0 avec des poids en FP8. Si les gros modèles restent l'apanage des data center, les MoE sont la voie la plus concrète pour en ramener la qualité sur du matériel qui tient dans un bureau. Dans cet article, on le passe au banc d'essai : ce qu'il faut pour le faire tourner en local, ce que ça coûte vraiment, et ce qui manque encore.

Kolibri, en un tableau

Les chiffres officiels du site du vendor et de la model card sur Hugging Face :

Spécification	Valeur
Architecture	MoE : 50 couches, 384 experts par couche + 1 partagé, top-6
Paramètres totaux	78,1 milliards (78 103 074 560)
Paramètres actifs par token	3,46 milliards (3 457 573 120)
Fenêtre de contexte	1 048 576 tokens (≤ 262 144 recommandés)
Précision	FP8 pour les poids et la cache KV, BF16 pour embeddings et routeur
Langues de spécialisation	Allemand et anglais
Licence	Apache 2.0, open weights
Date de sortie	3 octobre 2026
Minimum déclaré	2× A100 80 Go, 2× H100 SXM5, 1× H200, 1× B200 ou 1× B300

Le modèle a été entraîné sur 20 billions de tokens d'un corpus bilingue (~62,5 % anglais, ~23,9 % allemand, ~13,6 % de code) sur 768 GPU B200 en 21 jours ; la knowledge cutoff est au 18 juin 2026 pour les deux langues. Sources : page officielle et model card.

MoE : 78B de qualité, 3,46B de coût

Dans un modèle dense, chaque token fait transiter tous les paramètres dans le calcul. Dans un Mixture-of-Experts, chaque couche contient des centaines d'« experts » (sous-réseaux plus petits) et un routeur n'en active qu'une partie : dans Kolibri, 6 sur 384 par couche, plus un expert partagé toujours actif. Résultat : la capacité mémoire d'un modèle de 78B, le coût de calcul d'un modèle de ~3,5B.

Pourquoi c'est important : le coût de génération suit les paramètres actifs, pas les totaux. Les totaux doivent tenir en VRAM (sinon le modèle ne démarre pas), mais chaque token est calculé par une petite fraction. C'est le même principe que les modèles que vous avez déjà vus — Qwen3 30B-A3B ou Gemma 4 26B-A4B — poussé sur une architecture plus grande.

Sur les benchmarks publiés par le vendor (mesures maison : à lire avec cette loupe) :

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 %

Deux lectures : en raisonnement et en mathématiques, il tient tête aux modèles bien plus gros en paramètres actifs ; en tool calling agentique (Tau3-Bench Banking), il est nettement au-dessus des MoE de sa taille, mais derrière Qwen3.6 35B-A3B sur BFCL. Sur le graphique d'efficacité du vendor, Kolibri affiche 71 % de moyenne sur les benchmarks en allemand à ~47 000 octets/s par GPU, sur la frontière de la courbe.

Le test en local : ce qu'il vous faut

C'est là que ça devient intéressant — et compliqué.

Les poids officiels sont en FP8, avec un footprint déclaré de ~78 Go de mémoire modèle : le minimum du vendor est deux GPU de 80 Go. La communauté a déjà produit les conversions GGUF : le dépôt Hob-forge/Kolibri-1-GGUF (conversion indépendante, ni créée ni approuvée par Aleph Alpha) propose les quantisations de 2 à 8 bits :

Quantisation	Poids	Matériel réaliste
Q2_K	28,6 Go	RTX 5090 32 Go (~5 220 $), Mac avec 48 Go unifiés
Q3_K_M	37,5 Go	2× GPU 32 Go, Mac avec 64 Go unifiés
Q4_K_M	47,5 Go	GPU 96 Go, Mac Studio M5 Max 128 Go (~5 099 $)
Q5_K_M	55,6 Go	2× GPU 32/48 Go, Mac avec 96 Go+ unifiés
Q8_0	83,1 Go	2× GPU 80 Go (presque les poids d'origine)

Le prix à payer : llama.cpp standard ne supporte pas encore l'architecture kolibri1. Il faut appliquer le patch inclus dans le dépôt GGUF (sur le commit 836d571 de llama.cpp) et compiler, ou utiliser les binaires précompilés sortis par la même communauté. Ollama et LM Studio ne le chargent pas tant qu'ils n'ont pas ajouté le support.

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

Si ça marche : ouvrez http://localhost:8080 dans le navigateur et vous avez la chat qui fonctionne, avec le mode de raisonnement réglable par requête (aucun, bas, moyen, haut). Si ça ne marche pas : vérifiez que le patch est appliqué sur le bon commit et que la VRAM couvre poids + cache KV — un contexte de 32K ajoute plusieurs gigaoctets au-delà du poids du modèle.

Les comptes : ce que ça coûte vraiment

Deux configurations, d'après la base de prix que nous utilisons dans le planificateur (prix catalogue, octobre 2026) :

Configuration	Prix (×2 si double)	Amortissement 36 mois
2× H100 80 Go SXM (minimum vendor, FP8)	2 × 27 000 $ = 54 000 $	1 500 $/mois
Mac Studio M5 Max 128 Go (Q4_K_M)	5 099 $	142 $/mois

La facture d'électricité, pour la configuration data center, à 10 h/jour et 0,30 €/kWh : deux H100 à 700 W chacune font 1,4 kW en charge ; 1,4 × 10 = 14 kWh par jour, soit 4,20 € par jour, ~1 530 € par an. La facture du Mac Studio est d'un ordre de grandeur inférieur : la machine unifiée consomme une fraction des watts de deux cartes à 700 W.

Configuration	Amortissement 36 mois	Électricité 36 mois (10h/j)	Total 36 mois
2× H100 80 Go	54 000 $	~5 000 $	~59 000 $
Mac Studio M5 Max 128 Go (Q4_K_M)	5 099 $	nettement moins	~5 500 $

Le ratio 10:1 est dans les cartes, pas dans la facture. En plus : avec votre matériel, l'IA est toujours allumée — aucun token payant, aucune limite d'utilisation, les données restent chez vous. Sur le cloud, le coût suit votre usage : si vous générez 10 h/jour, le local s'amortit en quelques mois ; si vous l'utilisez une heure par jour, le cloud peut coûter moins cher pendant un an entier.

Et les limites ?

• Langues : allemand et anglais, point. Le corpus est à 62,5 % anglais et 23,9 % allemand : pour un travail dans d'autres langues, Qwen ou Gemma donnent aujourd'hui des résultats plus fiables. Kolibri est un modèle européen sérieux, mais ce n'est pas un modèle multilingue.
• Friction : un patch à compiler, pas d'Ollama, pas de LM Studio. Pour le flux « ça marche en 10 minutes », ce n'est pas encore le moment de Kolibri.
• VRAM : même en Q4_K_M, ce sont 47,5 Go. Les cartes à 16 Go restent en dehors du jeu.
• Benchmarks : ce sont tous des chiffres du vendor ; les mesures indépendantes sur du matériel local sont encore rares.
• Contexte 1M : validé par le vendor, mais la recommandation est ≤ 262K tokens pour l'efficacité et la qualité sur les tâches complexes.

Par où commencer

Pour comprendre le MoE avant d'engager du matériel : quand un grand modèle ne sert à rien. Pour dimensionner la RAM : cache KV : pourquoi la RAM compte plus que le modèle. Et pour la voie multilingue : Qwen, le modèle open au meilleur support multilingue.

En synthèse

Kolibri est le MoE open-weights européen de référence de cet automne : 78,1B de paramètres avec 3,46B actifs par token, contexte jusqu'à 1M (256K recommandés), poids FP8, licence Apache 2.0, mode de raisonnement et tool calling. Les benchmarks du vendor le placent en tête en raisonnement et en mathématiques, près de la frontière d'efficacité ; le coût réel est en VRAM (~78 Go en FP8, 47,5 Go en Q4_K_M) et dans la friction du patch llama.cpp que Ollama et LM Studio n'ont pas encore. Pour les autres langues, les versions multilingues restent à venir : aujourd'hui la voie est Qwen. Quand l'architecture kolibri1 entrera dans llama.cpp et Ollama, Kolibri sera le premier modèle à mettre à l'épreuve sur votre matériel.

Article généré par IA