Aller au contenu principal

Colibrì : faire tourner un MoE de 744 milliards de paramètres depuis votre SSD (et ce que cela vous coûte vraiment)

Avancé
What you'll learn
  • Comprendre l'astuce à trois niveaux — poids denses en RAM, experts routés sur disque, niveau VRAM optionnel — et pourquoi le MoE la rend possible tout court
  • Lire honnêtement le tableau de benchmarks : quel matériel obtient 0,1 tok/s, lequel obtient ~2, lequel obtient ~6, et pourquoi le plafond est la bande passante NVMe, pas le CPU
  • Connaître les quatre pièges qui coûtent des journées : têtes MTP en int8, O_DIRECT sur le mauvais disque, décodage spéculatif perdant, et usure du SSD
  • Passer du git clone au premier token streamé sur GLM-5.2 ou DeepSeek V4.1 Flash
  • Décider quand Colibrì bat un offload GGUF plus Ollama, quand louer un GPU à la place, et quand une API hébergée est tout simplement la bonne réponse

Le 1er juillet 2026, un développeur publiant sous le nom de JustVugg a poussé un dépôt avec une promesse en une ligne : faire tourner des modèles MoE de frontière sur du matériel que vous possédez déjà — C pur, zéro dépendance, experts streamés depuis le disque. Le fil Show HN a atteint 453 points neuf jours plus tard. À la mi-septembre, le projet en est à 30,8 k étoiles et la version 1.11.0, publiée le 13 septembre, a ajouté une neuvième famille de modèles (DeepSeek V4.1 Flash, 552 Md) qui lit nativement le checkpoint publié sans étape de conversion. C'est le premier dépôt d'IA de la liste des tendances quotidiennes de GitHub au moment où cette page est écrite.

L'argumentaire ressemble à un tour de passe-passe, et en un sens c'en est un. Cette page explique ce tour avec assez de précision pour que vous puissiez prédire ce qu'il donnera sur votre machine avant de télécharger 370 Go.

La version en une phrase​

Un modèle à mélange d'experts ne touche qu'une petite fraction de ses poids par token, donc Colibrì garde la partie toujours utilisée (attention, embeddings, experts partagés) résidente en RAM et lit la partie rarement utilisée (les experts routés) depuis le NVMe à la demande — en échangeant des tokens par seconde contre la possibilité de faire tourner un modèle de 744 milliards de paramètres sur un portable.

Pourquoi le MoE rend cela possible​

Prenons GLM-5.2 comme cas de référence, puisque c'est le modèle autour duquel le projet a été construit :

GrandeurValeur
Paramètres totaux744 Md
Actifs par token~40 Md
Paramètres denses (toujours actifs)~17 Md → ~9,9 Go résidents en int4
Experts routésenviron vingt mille sur l'ensemble des couches → ~370 Go sur disque en int4
Poids d'experts qui change d'un token à l'autre (à froid)~11 Go
RAM minimale / RAM confortable16 Go / 24 Go

Chaque token a besoin des 9,9 Go denses plus la poignée d'experts que le routeur choisit dans chaque couche. La partie dense tient en RAM. Les experts, non — mais vous n'en avez besoin que de quelques-uns à la fois, et le token suivant réutilise souvent beaucoup des mêmes. Le moteur traite donc la VRAM, la RAM et le NVMe comme une seule hiérarchie mémoire : un cache LRU par couche des experts récemment utilisés en RAM, un « hot-store épinglé » appris regroupant les experts les plus souvent utilisés, un niveau VRAM optionnel si un GPU est présent, et le disque comme stockage de secours pour tout le reste.

Le choix de conception qui en fait un seul fichier C par modèle plutôt qu'un framework : pas de BLAS, pas de Python à l'exécution, pas de GPU requis. Le moteur GLM a démarré à environ 1 300 lignes de C. Zéro dépendance signifie aussi que le cache de pages de l'OS devient une deuxième couche de cache gratuite pour les lectures d'experts.

Quatre mécanismes qui valent la peine d'être compris​

1. Anticipation du routeur : le routage est prévisible à 71,6 % une couche à l'avance​

La partie coûteuse du streaming, c'est l'attente du disque. Colibrì exécute un thread d'anticipation (activé avec PILOT=1) qui prédit de quels experts la couche suivante aura besoin et lance les lectures en avance. Le chiffre mesuré dans le README est que les décisions de routage sont prévisibles à 71,6 % une couche à l'avance, ce qui suffit à masquer une large part de la latence d'E/S derrière le calcul. C'est pourquoi les « tok/s après préchauffage » sont un chiffre très différent des « tok/s à froid ».

2. Streaming sur deux SSD : deux disques, un modèle, bandes passantes additionnées​

Mettez une copie complète du modèle sur un second NVMe et le moteur streame depuis les deux à la fois. Chaque expert est haché de façon déterministe vers un disque, pondéré par la bande passante mesurée de chaque disque, de sorte qu'il n'y a pas de cache dupliqué et que la bande passante de lecture effective est à peu près la somme des deux. Le benchmark DeepSeek V4 Flash ci-dessous (RTX 5080 plus deux disques NVMe, ~1,6 tok/s) est une configuration à deux disques.

3. État KV compressé qui survit à un redémarrage​

Les modèles dotés d'une attention latente multi-têtes (MLA) permettent à Colibrì de stocker un état KV compressé — 576 flottants par token au lieu de 32 768, une réduction d'un facteur 57. Le moteur persiste cet état dans un fichier .coli_kv, si bien que rouvrir une conversation après un redémarrage ne demande aucun re-préremplissage et est identique octet pour octet à une session qui ne se serait jamais arrêtée. Sur une machine où le préremplissage tourne à la vitesse du streaming, ne pas re-préremplir un long contexte fait la différence entre utilisable et inutilisable.

4. La sémantique est garantie, la vitesse non​

Le contrat annoncé par le projet : un manque de mémoire rapide ne fait que le ralentir ; la précision et le comportement du routeur ne changent jamais silencieusement. La passe avant est validée token par token face à un oracle transformers. C'est le compromis inverse de la plupart des histoires de quantification « ça tient sur un portable », où l'on gagne en vitesse en acceptant un modèle différent.

Le tableau de benchmarks, lu honnêtement​

Chiffres issus du README du projet (GLM-5.2 sauf mention contraire), cache chaud là où c'est indiqué :

MatérielTok/sCe que cela signifie
6× RTX 5090, résidence complète des experts en VRAM5,8–6,8 (TTFT ~13 s)Le plafond : aucune E/S disque. C'est une machine à GPU, pas « du matériel que vous possédez déjà ».
Desktop 128 Go de RAM, CPU seul, cache chaud~1,8Le meilleur cas réaliste pour une grosse station de travail sans GPU.
RTX 5070 Ti unique (niveau VRAM ~24 Go)1,07Un GPU de classe portable double à peu près le plancher à froid sur disque.
RTX 5080 + 32 Go de RAM + 2 NVMe, DeepSeek V4 Flash~1,6 à 3k de contexte, après préchauffageLe chemin à deux SSD sur un modèle plus petit.
Portable 25 Go de RAM, NVMe lent, à froid0,05–0,1La configuration phare « 744 Md sur 25 Go ». Environ un token toutes les 10 à 20 secondes.

La variable qui détermine votre chiffre est la bande passante en lecture aléatoire du disque, pas le CPU. Un token à froid a besoin de l'ordre de 11 Go de lectures d'experts ; un NVMe PCIe 5.0 à 13–15 Go/s plafonne donc une configuration à froid et sans préchargement autour de 1 tok/s, et ce sont l'anticipation plus les succès de cache qui vous font passer au-dessus. Des commentateurs du fil de lancement rapportaient des taux de succès de cache autour de 23 % sur un Apple M5 Max de 128 Go et 0,091 tok/s sur un vieux bi-Xeon avec 192 Go de DDR3 — « viable pour des travaux de nuit ».

Les cas d'usage honnêtes sont donc : les lots nocturnes ou asynchrones, les expérimentations privées hors ligne avec un modèle de classe frontière, la recherche sur le comportement réel de l'inférence MoE, et le chat multi-tours à chaud sur une machine avec 100 Go+ de RAM. Le pair-programming interactif sur un portable de 32 Go n'est pas sur la liste.

Neuf familles de modèles, et ce que chacune coûte en disque​

ModèleTotal / actifDisqueRAM minNotes
OLMoE7 Md / 1 Md~7 Go8 GoLe modèle « est-ce que ma compilation marche »
Qwen3.635 Md / 3 Md~20 Go24 Go (résidence RAM complète)GPU optionnel ; accélération de 7× mesurée sur deux cartes de 8 Go
Qwen3.8-Flash-Next125 Md + 51 Md n-grammes / 6 Md~185,5 Go16 GoCPU seul
DeepSeek V4 Flash284 Md / 13 Md~167 Go16 GoExperts en fp4 natif ; GPU optionnel (Pascal ou plus récent)
GLM-5.3-Flash321 Md / 40 Md~195 Go25 GoCapable de vision
DeepSeek V4.1 Flash552 Md / 16 Md~203 Go16 GoNouveau en 1.11.0 ; lit le checkpoint publié sans conversion
GLM-5.2 / 5.3744 Md / 40 Md~372 Go16 GoLe modèle de référence ; poids sous licence MIT
Inkling975 Md / 41 Md~469 Go25 GoLe dense bf16 occupe 49,4 Go résidents par défaut ; un outil int4 le ramène à des hôtes de 25 Go
Kimi K32,8 T / 104 Md~1,6 To32 Go+MXFP4 natif ; exige le checkpoint brut, aucune conversion disponible

La quantification est par famille, pas un réglage global unique : int4 à échelle par groupe pour GLM et Inkling, int8 ou FP8 par blocs pour OLMoE et Qwen3.8, MXFP4 natif pour Kimi K3, experts en fp4 natif avec dense en fp8-e4m3 pour la lignée DeepSeek V4. Si vous avez déjà les poids de Kimi K3 ou de DeepSeek V4.1 Flash issus d'un déploiement vLLM, Colibrì lit ces mêmes fichiers.

Quatre pièges qui coûtent des journées​

  1. Les têtes MTP doivent être en int8. Les têtes de brouillon de prédiction multi-tokens quantifiées en int4 donnent 0 à 4 % d'acceptation de brouillon — le décodage spéculatif ne fait silencieusement rien (issue #8). Le conteneur GLM-5.2 pré-converti sur Hugging Face est en int4 pour le modèle et en int8 pour le MTP exactement pour cette raison.
  2. O_DIRECT aide sur certains disques et nuit sur d'autres. Contourner le cache de pages a mesuré +34 % sur des NVMe avec cache DRAM et marge de bande passante, et un effet neutre à négatif sur les disques QLC, sans DRAM et virtualisés. Mesurez les deux sur votre disque ; ne copiez pas l'option de quelqu'un d'autre.
  3. Le décodage spéculatif est souvent une perte nette en chat réel. Sur des conversations multi-tours, les brouilleurs MTP et grammaticaux acceptaient environ 1 à 10 tokens sur 24, et rejouer l'état d'attention récurrent du moteur pour les suffixes rejetés coûtait plus que ce que les brouillons acceptés faisaient gagner. Pour DeepSeek V4, le projet a mesuré 495 secondes de rejeu de suffixes rejetés et livre les deux brouilleurs désactivés par défaut (V4_DRAFT=0, V4_MTP=0). Ne les activez que si vous mesurez un gain.
  4. L'usure du SSD est réelle. Les lectures d'experts intensives provoquent un brassage du cache de pages ; le README met en garde contre l'usure sur les disques grand public, et le conseil du fil de lancement était de désactiver le swap et d'envisager un montage en lecture seule pour le répertoire du modèle. Un modèle de 370 Go streamé pendant des heures chaque jour est une charge de travail pour laquelle les NVMe grand public n'ont pas été vendus.

Un dernier point, moins un piège qu'une limitation : l'épinglage appris des experts peut surapprendre votre historique de routage. Il aide sur les charges répétées ; les mainteneurs disent qu'il faut encore des tests A/B en validation croisée et inter-sessions avant de faire confiance aux gains sur de nouveaux prompts.

Du clone au premier token​

Guided walkthrough1 of 5
  1. git clone https://github.com/JustVugg/colibri && cd colibri/c && ./setup.sh — puis make -C c glm pour GLM-5.2, ou make -C c inkling / make -C c kimi_k3 pour les autres. Commencez par OLMoE (7 Go) pour valider la compilation avant d'engager des centaines de gigaoctets de téléchargement.

Une première exécution minimale sur GLM-5.2 (Linux, un seul NVMe)

git clone https://github.com/JustVugg/colibri && cd colibri/c
./setup.sh
make -C c glm
./coli convert --model /nvme/glm52_i4        # one-time download + convert
COLI_MODEL=/nvme/glm52_i4 ./coli plan          # see what lands where
COLI_MODEL=/nvme/glm52_i4 PILOT=1 ./coli chat  # first streamed tokens

Colibrì face aux alternatives que vous connaissez déjà​

ApprocheSes points fortsCe qui distingue Colibrì
llama.cpp / Ollama avec offload GGUF (notre guide Ollama)Catalogue de modèles immense, offload GPU, outillage mature ; la page GLM-5.2 couvre la voie GGUF dynamique 2 bits de 239 GoL'offload GGUF a besoin du modèle quantifié entier en RAM plus VRAM (256 Go pour GLM-5.2 en 2 bits). Colibrì a besoin de 16 à 24 Go de RAM et d'un gros disque, à la précision publiée par le laboratoire, pas en 2 bits.
vLLM / SGLang sur GPU loués (guide de déploiement Kimi K3)Des dizaines de tokens par seconde, du batching, plusieurs utilisateursRapide parce que tout est résident en HBM. Colibrì existe pour le cas où ce matériel n'est pas disponible ou pas autorisé.
API hébergée (DeepSeek, Z.ai, Moonshot)De loin le moins cher par token, pas de matérielLa seule raison de préférer Colibrì est que les poids et les prompts ne doivent jamais quitter la machine, ou que vous voulez étudier l'inférence MoE elle-même.

La bonne façon de penser Colibrì n'est pas « un llama.cpp plus rapide ». C'est l'outil qui rend un modèle ouvert de taille frontière disponible sur une machine qui ne pourrait pas le charger autrement, à une vitesse autour de laquelle on planifie plutôt qu'on attend. Pour une pile axée sur la confidentialité qui mêle un petit modèle local rapide pour le travail interactif et un grand modèle lent pour les traitements par lots, voir Une pile d'IA locale privée.

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 7

Check yourself

0/5
  1. Pourquoi un modèle de 744 Md peut-il tourner sur une machine de 16 à 25 Go avec Colibrì, tout simplement ?
  2. Quelle est la contrainte limitante sur les tokens par seconde quand les experts sont streamés à froid ?
  3. Pourquoi le projet livre-t-il le décodage spéculatif de DeepSeek V4 désactivé par défaut ?
  4. Vous avez quantifié GLM-5.2 vous-même, tous les tenseurs en int4, et le décodage spéculatif affiche ~2 % d'acceptation de brouillon. Que s'est-il passé ?
  5. Pour quelle charge de travail Colibrì convient-il bien sur un portable de 32 Go avec un seul NVMe ?

Sources et lectures complémentaires​

Pour continuer​