Colibri, en C pur, fait tourner des modèles MoE de plus de 700 milliards de paramètres sans GPU
Le dépôt JustVugg/colibri a recueilli environ 47,4 mille étoiles sur GitHub, dont +802 en une journée. Il s'agit d'un moteur en C pur pour les modèles MoE géants : il ne conserve pas tous les poids en mémoire, mais va chercher sur le disque les « experts » nécessaires au fil de la génération. La prise en charge de GLM, Kimi, DeepSeek et Qwen est annoncée. Les modèles à partir de 700 milliards de paramètres seraient exécutables sans GPU, mais la vitesse n'est pas indiquée dans le post.
Traité par IA depuis X: @ai_radar_ ; édité par Hamidun News
Quand on parle d'exécuter d'énormes modèles open-weight, la conversation se termine d'ordinaire par la même phrase : « il faut une baie de GPU ». Le dépôt Colibri propose une autre voie. D'après un post de l'agrégateur AI Radar, le projet a réuni environ 47,4 mille étoiles, dont 802 en une seule journée. C'est un signal d'intérêt fort, même si le post lui-même n'a été consulté que 29 fois et ne contient presque aucun détail. Voyons ce que l'on sait et ce qu'il vaut mieux vérifier soi-même.
Ce qui est annoncé
Colibri est décrit comme un moteur en C pur pour exécuter de grands modèles MoE sur des ordinateurs ordinaires. L'idée clé : les experts sont chargés depuis le disque à mesure des besoins. La liste des familles prises en charge mentionne GLM, Kimi, DeepSeek et Qwen. Le principal argument de l'auteur du post : les modèles de 700B et plus peuvent tourner sans carte graphique.
Le C pur est ici aussi un argument. Cela signifie un minimum de dépendances, une compilation simple et un contrôle clair de la mémoire. Pour du code d'infrastructure, où il importe de savoir combien d'octets sont lus sur le disque et quand, c'est un choix raisonnable.
Comment cela fonctionne, par un exemple simple
Un MoE (Mixture of Experts) est conçu ainsi : chaque couche du modèle contient des dizaines, voire des centaines d'« experts », c'est-à-dire de blocs de poids distincts. Pour chaque token, un routeur spécialisé n'en choisit que quelques-uns. Les autres restent inactifs à cet instant.
Imaginez une bibliothèque de milliers de livres. Pour répondre à une question précise, il faut des pages de huit livres. L'approche classique apporte toute la bibliothèque dans la salle de travail, c'est-à-dire dans la mémoire vidéo ou la RAM. Pour un modèle de 700B, cela représente des centaines de gigaoctets. L'approche de Colibri, telle qu'on la décrit, est différente : seul le nécessaire est posé sur le bureau, le reste demeure sur les étagères, c'est-à-dire sur le SSD. Lorsque le routeur réclame de nouveaux experts, le moteur les lit sur le disque.
Un calcul simple donne l'échelle. 700 milliards de paramètres en format 4 bits occupent environ 350 Go. Cela ne tient pas dans la RAM d'un PC ordinaire, mais tient sur un bon disque NVMe. Pour un token, seule une fraction de ces poids est réellement lue, et toute l'idée repose là-dessus.
Les limites passées sous silence par le post
Premièrement, la vitesse. Un disque NVMe lit des ordres de grandeur plus lentement que la mémoire d'un GPU. Si chaque token exige de nouveaux experts, la génération sera limitée par le disque. Le post ne donne aucun chiffre de tokens par seconde, alors que c'est la métrique principale. Le résultat sera peut-être acceptable pour du traitement par lots ou des expérimentations, mais un chat interactif ou une boucle d'agent avec des dizaines d'appels pourrait devenir pénible.
Deuxièmement, le disque. Il faut des centaines de gigaoctets d'espace libre et un support rapide. Sur un vieux SATA ou un HDD, le tableau sera nettement moins bon.
Troisièmement, la qualité et la compatibilité. On ignore quels formats de quantification sont pris en charge et dans quelle mesure le résultat coïncide avec les implémentations de référence. La mention « fonctionne avec DeepSeek, Kimi, GLM, Qwen » ne signifie pas encore que chaque version de chaque modèle fonctionne.
Enfin, la source elle-même. Le post ressemble à un résumé automatique d'un dépôt en tendance. Mieux vaut vérifier directement sur GitHub le nombre d'étoiles et la liste des modèles.
Que faire en pratique
Si vous êtes développeur ou fondateur et évaluez des LLM auto-hébergés, Colibri mérite d'entrer dans votre liste de tests rapides. La marche à suivre est simple :
- Lisez le README ainsi que la liste des modèles et formats pris en charge.
- Prenez un modèle MoE de taille moyenne et mesurez les tokens par seconde sur votre SSD.
- Comparez le résultat à la location d'un GPU ou à une API classique. Pour des tâches rares, des données privées et des scénarios hors ligne, un disque à la place d'une carte graphique peut s'avérer plus avantageux.
- N'intégrez pas le projet en production tant que vous n'avez pas vu de benchmarks stables et un historique de commits actif.
Voici la vue d'ensemble : l'architecture MoE rend les modèles géants moins gourmands en calcul par token, et des outils comme Colibri tentent de les rendre moins exigeants en matériel. Si les affirmations se confirment, le seuil d'entrée pour expérimenter avec des modèles de classe 700B baissera nettement. Mais pour l'instant, c'est une promesse, pas un résultat mesuré.
- 8 nov. 2026dsh-baton délègue les longues tâches de Claude Code à DeepSeek : 3,16 $ au lieu de 14,18 $
- 8 nov. 2026Baidu publie ERNIE 5.5 Flash Base : 280 milliards de paramètres et des poids ouverts
- 8 nov. 2026Cent dollars : 10 tâches avec Opus 5.5 max, ou 2 500 avec GPT-6 Luna
- 8 nov. 2026Un seul modèle sur neuf a déchiffré le Rubik’s Cube, deux ont fourni une fausse « vérification »
Questions clés sur cet article
Que sait-on sur Ce qui est annoncé ?
Colibri est décrit comme un moteur en C pur pour exécuter de grands modèles MoE sur des ordinateurs ordinaires. L'idée clé : les experts sont chargés depuis le disque à mesure des besoins. La liste des familles prises en charge mentionne GLM, Kimi, DeepSeek et Qwen. Le principal argument de l'auteur du post : les modèles de 700B et plus peuvent tourner sans carte graphique. Le C pur est ici aussi un argument. Cela signifie un minimum de dépendances, une compilation simple et un contrôle clair de la mémoire.
Comment cela fonctionne, par un exemple simple?
Un MoE (Mixture of Experts) est conçu ainsi : chaque couche du modèle contient des dizaines, voire des centaines d'« experts », c'est-à-dire de blocs de poids distincts. Pour chaque token, un routeur spécialisé n'en choisit que quelques-uns. Les autres restent inactifs à cet instant. Imaginez une bibliothèque de milliers de livres. Pour répondre à une question précise, il faut des pages de huit livres.
Que sait-on sur Les limites passées sous silence par le post ?
Premièrement, la vitesse. Un disque NVMe lit des ordres de grandeur plus lentement que la mémoire d'un GPU. Si chaque token exige de nouveaux experts, la génération sera limitée par le disque. Le post ne donne aucun chiffre de tokens par seconde, alors que c'est la métrique principale. Le résultat sera peut-être acceptable pour du traitement par lots ou des expérimentations, mais un chat interactif ou une boucle d'agent avec des dizaines d'appels pourrait devenir pénible. Deuxièmement, le disque.
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.