COLIBRI : faire tourner GLM-5.2 avec 25 Go de RAM

https://github.com/JustVugg/colibri

📌 COLIBRI est un runtime d’inférence en C qui fait fonctionner GLM-5.2, un modèle de 744 milliards de paramètres, sur une machine grand public équipée d’environ 25 Go de RAM.

Le projet part d’une idée simple, mais assez vertigineuse : un modèle Mixture-of-Experts n’active pas tous ses paramètres à chaque token. Colibri garde donc la partie dense en mémoire, tandis que ses 19 456 experts routés restent stockés sur le disque et sont chargés à la demande. La RAM, la VRAM et le SSD deviennent une seule hiérarchie de mémoire, avec un cache LRU par couche et la possibilité de conserver les experts les plus utilisés.

Dans la pratique, vous pouvez lancer une conversation en local avec un moteur écrit en C, sans BLAS, sans Python au runtime et sans GPU obligatoire. Le dépôt fournit aussi un convertisseur qui passe les poids FP8 vers un conteneur int4, un serveur compatible avec l’API OpenAI et une interface web qui affiche les métriques, le matériel et la répartition des experts entre les différents niveaux de stockage.

L’image la plus parlante reste celle du dashboard. Colibri ne cache pas le coût de son approche : il montre quels experts sont en VRAM, lesquels sont en RAM et lesquels doivent encore être lus sur le disque. Une seconde vue, appelée Brain, représente les experts comme un cortex de 76 × 256 cellules et fait varier leur luminosité selon le routage observé. C’est une manière assez réussie de rendre visible un mécanisme qui reste normalement abstrait.

Les éléments qui rendent le projet intéressant :

• 🧠 GLM-5.2 exécuté avec environ 9,9 Go de RAM résidente pour sa partie dense
• 💾 Experts int4 streamés depuis un modèle d’environ 370 Go
• 🧮 Moteur C sans dépendance Python pendant l’inférence
• 🖥️ Dashboard web avec métriques, matériel et niveaux de mémoire
• 🔌 Serveur HTTP compatible avec les endpoints OpenAI principaux

Il faut toutefois lire les performances avec beaucoup de recul. Sur la configuration de référence, un token froid peut nécessiter environ 11 Go de lectures disque, ce qui ramène le débit à 0,05–0,1 token par seconde avec un SSD plafonnant autour de 1 Go/s. Le cache, les experts épinglés en RAM et le MTP peuvent améliorer la situation, mais ils ne suppriment pas les contraintes physiques. Le modèle tient dans une petite machine ; cela ne signifie pas qu’il y devient confortable à utiliser.

Je trouve néanmoins l’expérience convaincante comme démonstration d’ingénierie. Colibri ne prétend pas faire rentrer magiquement 744 milliards de paramètres dans 25 Go : il transforme le disque en mémoire lente et accepte d’attendre. La nuance est importante. Pour discuter quelques minutes avec GLM-5.2, ce sera probablement frustrant. Pour étudier le fonctionnement d’un runtime MoE, tester le routage ou exploiter une grosse machine équipée de beaucoup de RAM, l’approche devient nettement plus pertinente.

Le projet supporte Linux, macOS et Windows 11 natif via MinGW-w64. Un backend Metal expérimental existe également sur Apple Silicon, tandis que CUDA peut accélérer les tenseurs résidents. La licence du code est Apache 2.0 ; les poids GLM-5.2 sont distribués séparément sous licence MIT.

COLIBRI est donc moins un chatbot prêt à l’emploi qu’un laboratoire compact consacré à l’inférence de très grands modèles. Et c’est précisément ce qui le rend intéressant : il montre jusqu’où on peut pousser une machine ordinaire, à condition d’accepter que le SSD fasse partie du calcul.