Colibrì : le mini moteur qui fait tourner un modèle de 744B sur du matériel grand public

Chaque semaine, la communauté open source de l'intelligence artificielle locale semble se chercher un sujet de conversation favori, et celle qui vient de s'écouler semble avoir élu un dépôt sur GitHub au nom curieux et à la promesse presque absurde : faire tourner GLM-5.2, un modèle Mixture-of-Experts de 744 milliards de paramètres, sur un ordinateur avec seulement 25 Go de RAM. Le projet s'appelle Colibrì et est l'œuvre d'un seul développeur, JustVugg, qui dans la section des remerciements de son README admet avec une honnêteté désarmante avoir tout écrit et testé sur un ordinateur portable à douze cœurs. Aucun laboratoire, aucun cluster, aucune sponsorisation matérielle. Seulement une obsession technique menée jusqu'au bout.

Il faut le dire d'emblée, avec la même honnêteté que l'auteur réserve à son propre travail : Colibrì n'est pas conçu pour un public de masse, ce n'est pas un produit et il n'aspire pas à le devenir. C'est une expérience, au sens le plus classique du terme, celle de quelqu'un qui veut découvrir où se trouve réellement la limite physique d'une machine grand public lorsqu'on lui demande de supporter un modèle qui, dans des conditions normales, nécessiterait des centaines de gigaoctets de mémoire dédiée. Et c'est précisément ce cadre expérimental, plus que les performances en soi, qui le rend intéressant à raconter.

Ce qu'il y a dans le moteur

Le cœur de Colibrì réside dans un seul fichier C d'environ 2 400 lignes, glm.c, accompagné de quelques en-têtes minimaux. Zéro dépendance externe, zéro bibliothèque d'algèbre linéaire comme BLAS, zéro runtime Python pendant l'inférence proprement dite (Python n'intervient que dans la phase de conversion hors ligne du modèle, une tâche qu'il accomplit une seule fois avant de quitter la scène). C'est une approche qui rappelle la philosophie de certains projets historiques de l'informatique, ceux où le choix d'écrire moins de code, mais de bien l'écrire, devient en soi une déclaration d'intention.

Il y a quelque chose, dans cette obstination minimaliste, qui fait penser à certaines productions musicales de la scène IDM britannique des années 90 : peu d'instruments, des règles rigides, et pourtant des résultats étonnamment complexes qui émergent d'un système délibérément pauvre en éléments. Colibrì fonctionne à peu près ainsi : un moteur minuscule qui orchestre un modèle colossal, sans fioritures, sans niveaux d'abstraction superflus, avec l'objectif déclaré de faire tourner exactement une architecture, GLM-5.2, et de le faire avec une fidélité vérifiable par rapport à l'implémentation originale dans transformers.

GLM-5.2, le modèle monstrueux

Pour comprendre pourquoi cette entreprise a un sens technique, il faut d'abord comprendre ce que signifie réellement « 744 milliards de paramètres ». GLM-5.2 est un modèle Mixture-of-Experts, une architecture dans laquelle le réseau ne traite pas chaque token avec l'intégralité de sa capacité, mais le répartit entre des milliers de sous-réseaux spécialisés, appelés experts, n'en activant qu'une petite partie pour chaque token généré. Dans le cas de GLM-5.2, les experts routables sont au nombre de 21 504, répartis sur 75 couches MoE de 256 experts chacune, plus une tête supplémentaire pour le décodage spéculatif, pour un total global de 19 456 experts selon le décompte que le projet lui-même utilise dans son tableau de bord. De tout cela, seuls environ 40 milliards de paramètres sont réellement activés pour chaque token individuel, et parmi ceux-ci, à peine 11 Go changent réellement d'un token à l'autre, ceux acheminés par le routeur.

C'est une distinction cruciale, car elle signifie que le problème n'est plus « comment garder 744 milliards de paramètres en mémoire », mais « comment faire parvenir au processeur, en temps utile, seulement les 11 Go qui sont vraiment nécessaires à cet instant ». C'est le même principe, appliqué avec une radicalité extrême, qui régit d'autres moteurs d'inférence MoE nés ces dernières semaines, et qu'il convient de garder à l'esprit lorsque nous comparerons plus tard Colibrì à un cousin conceptuel né du côté de Redis. Le tableau de bord web de colibrì, image tirée du dépôt github

La hiérarchie de mémoire à trois niveaux

L'idée technique qui soutient tout le projet est, au fond, simple à expliquer par une analogie. Imaginez une bibliothèque immense où la partie du catalogue que vous consultez chaque jour se trouve sur votre bureau, celle dont vous avez besoin de temps en temps sur une étagère dans une autre pièce, et celle que vous ouvrez rarement dans un entrepôt extérieur d'où elle doit être demandée spécialement. Colibrì traite la VRAM, la RAM et le disque exactement comme trois niveaux de cette même bibliothèque, gérés comme une hiérarchie de mémoire unique.

La partie dense du modèle — attention, experts partagés, embedding, environ 17 milliards de paramètres — reste toujours résidente en RAM au format int4, occupant environ 9,9 Go. Les plus de 21 000 experts routés, en revanche, vivent sur disque dans un conteneur int4 pesant au total environ 370 Go, et sont chargés dynamiquement uniquement lorsque le routeur du modèle décide de les activer, grâce à un cache LRU pour chaque couche, un « store chaud » optionnel pour les experts les plus utilisés et le cache de page du système d'exploitation qui fait office de niveau intermédiaire gratuit. C'est à ce stade que le goulot d'étranglement se déplace, de manière presque philosophique, du calcul vers la lecture : ce n'est plus le CPU qui décide à quelle vitesse vous allez, c'est le disque.

Matériel minimum, attentes réalistes

Colibrì tourne sous Linux, WSL2, macOS et, depuis son évolution la plus récente, également sous Windows 11 natif grâce à une couche de compatibilité écrite spécifiquement. Il faut un processeur avec support AVX2, au moins 16 Go de RAM, et environ 370 Go libres sur une unité NVMe locale, jamais sur un partage réseau. Ce n'est pas une exigence anodine, mais c'est tout de même des ordres de grandeur plus abordable que le cluster de GPU qui serait nécessaire pour charger le même modèle dans son intégralité en pleine précision.

La distinction la plus importante ne concerne toutefois pas le matériel minimum, mais la différence entre « ça fonctionne » et « c'est praticable ». Colibrì fonctionne même sur la configuration la plus modeste testée par l'auteur, douze cœurs et 25 Go de RAM derrière une machine virtuelle WSL2 avec un disque qui lit à environ 1 Go par seconde. Mais à cette vitesse, le modèle produit des réponses à un rythme compris entre 0,05 et 0,1 token par seconde à partir d'un cache froid, une valeur qui rend l'expérience plus proche d'un télégramme que d'une conversation. C'est un projet conçu pour être poussé plus loin, pas pour être utilisé tel quel sur la configuration de départ.

Les chiffres honnêtes des performances

Le README du projet consacre une section entière, intitulée sans ironie « chiffres honnêtes », précisément pour clarifier cette distance entre théorie et pratique. Sur la machine de développement, un démarrage à froid (cold start) coûte environ 11 Go de lectures sur disque pour chaque token généré, ce qui signifie que la vitesse dépend presque entièrement du débit du disque lui-même : avec une limite physique d'environ 1 Go par seconde sur cette configuration, le résultat est précisément le 0,05-0,1 token par seconde mentionné plus haut.

Les choses changent sensiblement lorsque la communauté a commencé à tester Colibrì sur du matériel plus performant, et ici les données recueillies dans les issues du dépôt deviennent le véritable laboratoire du projet. Sur un Ryzen AI Max avec 128 Go de RAM, la vitesse monte à environ 0,37-0,40 token par seconde une fois le cache réchauffé. Sur un Mac avec puce M5 Max et 128 Go de mémoire unifiée, on atteint environ 1 token par seconde avec la configuration de base, et plus de 2 tokens par seconde en activant le backend expérimental Metal. Le point de données le plus extrême provient d'un banc de six cartes RTX 5090 connectées ensemble, où en gardant l'ensemble du parc d'experts résidant entre la VRAM et la RAM, on touche les 6 tokens par seconde en décodage sur une requête unique, un chiffre qui commence à s'approcher d'une utilisation réellement conversationnelle, bien qu'obtenu avec un investissement matériel qui n'a plus rien de grand public.

Un détail technique intéressant concerne le décodage spéculatif natif de GLM-5.2, le fameux MTP, dans lequel une petite tête supplémentaire du modèle tente de deviner à l'avance les tokens suivants, que le moteur principal vérifie ensuite en une seule étape. Cela ne fonctionne que si cette tête est quantifiée en 8 bits plutôt qu'en 4 : avec la mauvaise précision, l'acceptation des tokens proposés s'effondre à zéro, tandis qu'avec la bonne, elle monte entre 39 et 59 %, apportant jusqu'à 2,8 tokens générés pour chaque passage du modèle. C'est le genre de détail apparemment minuscule qui, sur un système ainsi poussé à ses limites, fait la différence entre un projet utilisable et un projet qui bloque sans raison apparente.

Le cache qui apprend

L'un des aspects les plus fascinants de Colibrì, d'un point de vue purement conceptuel, est que le moteur s'observe lui-même pendant qu'il travaille et apprend de ses propres schémas d'utilisation. Chaque session de chat met à jour un fichier qui enregistre quels experts ont été réellement activés, et au redémarrage suivant, le moteur utilise cet historique pour décider quels experts garder préchargés dans la RAM disponible. Plus on l'utilise, plus la machine devient, au sens propre, habituée à vos conversations.

À cela s'ajoute un mécanisme de préfetch prédictif, encore expérimental, qui exploite une régularité intéressante découverte dans le comportement du routeur : l'état d'une couche après l'attention permet d'anticiper correctement 71,6 % des experts qui seront activés par la couche suivante, une valeur mesurée par les contributeurs du projet eux-mêmes. Un thread d'E/S dédié peut donc commencer à lire sur le disque les experts de la couche suivante pendant que la couche actuelle est encore en train de calculer, superposant ainsi temps de lecture et temps de calcul au lieu de les additionner en séquence. La page « cerveau » de colibrì, image tirée du dépôt github

Une place à part dans le paysage local

Colibrì ne naît pas dans le vide. Au cours des mêmes semaines, un autre projet a catalysé l'attention de la communauté de l'inférence locale avec une philosophie étonnamment similaire : DwarfStar (nom de code DS4), le moteur écrit par Salvatore Sanfilippo, alias antirez, le créateur de Redis, dont j'ai parlé sur Codemotion. DwarfStar est également un moteur en C écrit de zéro, optimisé de manière maniaque pour un seul modèle, et là aussi la stratégie pour contourner les limites de la mémoire grand public passe par une combinaison de quantification agressive et de streaming des experts depuis le disque sur Mac avec architecture Metal.

Les différences sont toutefois tout aussi instructives que les similitudes. DwarfStar mise sur DeepSeek V4 Flash, un modèle MoE plus contenu avec 284 milliards de paramètres au total et 13 milliards actifs, et le compresse jusqu'à un fichier GGUF d'environ 81 Go grâce à une quantification asymétrique calibrée empiriquement sur les poids qui comptent vraiment. Colibrì, au contraire, choisit la voie opposée et plus radicale : il ne compresse pas le modèle pour le faire tenir dans la RAM disponible, il le laisse énorme, environ 370 Go sur disque, et construit à la place tout un système de mise en cache et de streaming pour gérer son immensité sans compromettre sa précision déclarée. Là où DwarfStar dit « je rends le modèle plus petit parce que la RAM est ce qu'elle est », Colibrì dit « je laisse le modèle grand tel quel et je réinvente la façon dont la mémoire le touche ». Ce sont deux réponses différentes à la même question, et leur comparaison raconte mieux que n'importe quel benchmark à quel point le bouillonnement autour de l'inférence locale de modèles de pointe est vif en ce moment.

Il y a ensuite une différence d'échelle qui mérite d'être soulignée : DwarfStar travaille sur un modèle de 284 milliards de paramètres conçu pour le matériel Apple haut de gamme, avec des benchmarks atteignant 25-36 tokens par seconde en génération sur Mac Studio. Colibrì s'attaque à un modèle presque trois fois plus grand, 744 milliards de paramètres, et le fait dans les conditions les plus hostiles possibles, un PC générique avec une RAM limitée et un disque quelconque, obtenant par conséquent des chiffres beaucoup plus modestes. Ce n'est pas une comparaison à armes égales, et il est juste de le dire clairement, mais c'est précisément la distance entre les deux approches qui rend évident à quel point l'espace de manœuvre entre « compression du modèle » et « streaming intelligent de la mémoire » reste encore à explorer.

Pourquoi c'est important, au-delà de la démo

Au-delà de la fascination technique immédiate, Colibrì touche à un thème redevenu central ces derniers mois dans le débat sur l'intelligence artificielle : la souveraineté technologique, c'est-à-dire la possibilité concrète d'exécuter des modèles performants sans dépendre d'une infrastructure cloud tierce. Un modèle qui tourne entièrement sur son propre matériel, même lentement, n'envoie pas un seul octet de conversation à un serveur externe, et cela pour certains contextes — recherche, développement d'outils propriétaires, expérimentation sur des données sensibles — a une valeur qui dépasse la simple curiosité technique.

Colibrì suggère également quelque chose de plus large sur l'avenir des modèles MoE sur le matériel grand public : que la voie pour démocratiser l'accès aux modèles de pointe ne passe pas nécessairement, ou seulement, par leur réduction de taille. Elle passe aussi par une remise en question radicale de la gestion de la mémoire, en traitant la RAM, la VRAM et le disque comme une ressource fluide unique plutôt que comme des compartiments étanches. C'est une intuition qui, si elle devait mûrir au-delà du stade expérimental, pourrait influencer la manière dont sont conçus les prochains environnements d'exécution d'inférence, bien au-delà du périmètre d'un seul projet personnel.

Les nœuds encore ouverts

Il serait malhonnête envers les lecteurs et envers l'esprit même du projet de conclure sans énumérer les points critiques que Colibrì traîne encore avec lui. La vitesse dans des conditions de cache froid reste extrêmement basse, à la limite de l'inutilisable pour toute tâche nécessitant des réponses rapides. La dépendance vis-à-vis des performances du stockage est totale : ceux qui ne disposent pas d'un NVMe réellement rapide verront des chiffres difficilement distinguables d'un dépassement de délai (timeout). Il y a ensuite la question, toujours ouverte, de la précision : un premier benchmark de qualité mené par la communauté a mesuré un score de 62,5 % sur une batterie de tests standards, sensiblement plus bas que les 85-95 % publiés pour la version originale du modèle en pleine précision, bien que l'auteur lui-même invite à la prudence, signalant que la méthode d'évaluation utilisée pénalise structurellement un modèle conçu pour raisonner étape par étape, et qu'une comparaison directe et contrôlée entre les deux précisions est encore nécessaire pour isoler réellement le coût de la quantification du bruit de la mesure.

Il faut ajouter, enfin, un constat plus prosaïque : l'utilisabilité pour un public non technique est, en l'état actuel, quasi nulle. Configurer Colibrì signifie télécharger des centaines de gigaoctets, convertir des poids, lire des variables d'environnement et interpréter des logs de diagnostic. C'est un outil pour ceux qui savent déjà ce qu'ils font, pas une application prête à l'emploi, et des benchmarks indépendants sur un matériel plus varié sont nécessaires avant de pouvoir dire avec certitude à quel point les chiffres publiés sont représentatifs en dehors du laboratoire artisanal dans lequel le projet est né.

Conclusions

Colibrì ne prouve pas que les modèles énormes sont devenus confortables à utiliser sur n'importe quel ordinateur, et il serait trompeur de le présenter ainsi. Il démontre plutôt que les frontières de l'inférence locale peuvent être poussées bien plus loin que ce que la plupart des initiés auraient parié il y a encore quelques semaines, en traitant la rareté de la mémoire non pas comme un obstacle insurmontable mais comme une contrainte de conception à contourner avec créativité technique. C'est un projet important à raconter précisément parce qu'avec des expériences parallèles comme DwarfStar, il montre où va réellement l'écosystème de l'IA open source en ce moment : non pas vers une solution unique et définitive, mais vers une pluralité de stratégies — certains compressent le modèle, d'autres réinventent la mémoire — qui se confrontent ouvertement sur le même terrain.

Colibrì n'est pas l'avenir de l'IA locale pour tous, mais c'est un signal très clair de la façon dont les runtimes deviennent plus créatifs pour surmonter les limites physiques du matériel.