Open Source
Une course de relais de GPU loués a entraîné le MoE 2,7B de NanoColibri pour 200 $
NanoColibri-Instruct est passé de poids vierges à un MoE 2,7B fonctionnel pour environ 200 $. Des bénévoles ont fait passer un témoin d'entraînement sur le Hugging Face Hub, un GPU loué à la fois, avec un bail compare-and-swap pour que jamais deux personnes n'entraînent la même étape.
Emmanuel Fabrice Omgbwa Yasse Assisté par IA
2026-08-04 · 6 min de lecture

Préentraîner un modèle de langue de zéro implique d'habitude un cluster, une facture de calcul à six chiffres et des gens payés pour maintenir l'exécution. La réponse d'un nouveau projet open source est plus courte. NanoColibri-Instruct, un modèle Mixture-of-Experts de 2,7 milliards de paramètres avec 0,34 milliard de paramètres actifs par jeton, est passé de poids aléatoires à un modèle utilisable pour environ 180 à 260 $, sans cluster, des contributeurs se relayant sur des GPU loués un à la fois. Le code, les checkpoints et un registre public de qui a entraîné quoi se trouvent dans le dépôt d'entraînement.
Le modèle n'a jamais été la finalité. Le compte rendu présente Nano comme la preuve de boucle d'une idée plus large : des modèles dont les conteneurs int4 sont délibérément plus grands que la mémoire d'une machine grand public, diffusant les experts depuis le NVMe sous un budget RAM fixe. Un ordinateur portable de 16 Go ne peut pas contenir un modèle de 24 à 28B en RAM. Dans un MoE à granularité fine, chaque jeton ne touche que le backbone dense, un expert partagé toujours résident, et deux ou trois experts routés de 3 à 4 Mo. Mettez les experts en cache avec un LRU, laissez le disque servir les défauts. Nano exerce tout le pipeline, export int4 compris, à un prix où les erreurs ne font pas mal.
L'architecture correspond à la forme native du moteur de service, HYV3 : 24 couches (une dense, 23 MoE), largeur cachée 1024, 64 experts de largeur 512 avec routage top-2, un expert partagé de 2048 de large qui ne quitte jamais la mémoire, attention à requêtes groupées 4x avec normalisation QK par tête, et un routeur sigmoïde plus biais. L'équilibrage de charge suit la recette DeepSeek-V3 : ajuster le biais d'expert de chaque couche par gamma multiplié par le signe de cible moins charge.
Entraînement en relais : un compare-and-swap sur le Hub
On ne peut pas répartir un préentraînement séquentiel entre des bénévoles comme on répartit un codebase. Chaque étape dépend de la précédente, alors l'exécution vit dans un seul dépôt de modèle Hugging Face, poids plus état de l'optimiseur, training_state.json, RELAY.json, LEDGER.md, et les contributeurs se relaient : revendiquer, tirer, entraîner une étape, pousser, libérer.
La collision est la partie qui doit être infaillible. Si deux personnes entraînent la même étape, celui qui pousse en second détruit silencieusement un GPU-jour. La revendication du témoin est donc un bail, un véritable compare-and-swap contre le Hub plutôt qu'une convention de courtoisie, renouvelé par battement de cœur pendant l'entraînement, ce qui signifie qu'une instance spot préemptée libère le témoin d'elle-même. Un tableau de bord en lecture seule sur la machine d'entraînement affiche la perte, le débit, l'équilibre des experts et qui détient le témoin.
Ça a fonctionné : 20 000 mises à jour, environ 5,2 milliards de jetons de FineWeb-Edu, puis 1 500 mises à jour de SFT chat sur smol-smoltalk, environ 90 heures H100 au total.
Un résultat vaut la peine d'être volé : entraîner avec un routage top-2 même si vous servirez avec top-1. Avec top_k=1, le poids routé s'effondre en une constante et le routeur ne reçoit pratiquement aucun gradient de la perte LM, donc le routage reste figé à son initialisation aléatoire. top_k=2 rétablit le flux de gradient par la compétition entre deux gagnants. Au moment du service, le moteur exécute toujours un expert par jeton. L'équilibrage sans perte auxiliaire a tenu à cette échelle : la fraction d'experts morts est restée faible, la charge est restée saine, et la légère asymétrie de routage qui subsiste est ce qu'un cache de streaming apprécie.
Le déséquilibre des experts est le même mode de défaillance à l'autre extrémité du spectre MoE. Les notes de terrain de Nous Research sur le préentraînement d'un modèle de 1 000 milliards de paramètres décrivent le défi central comme des routeurs envoyant un trafic disproportionné vers certains experts, laissant certains GPU inactifs pendant que d'autres font la queue. La version NanoColibri de ce problème n'a coûté que quelques centaines de dollars à affronter.
Ce que 5,4 milliards de jetons achètent
Les chiffres sont accompagnés de leur méthodologie. Les benchmarks ont été exécutés via un harnais compatible lm-evaluation-harness dans le dépôt, mêmes invites, même notation, et les références denses ont été exécutées avec le même code plutôt que de se fier aux lignes publiées.
| modèle | paramètres actifs | jetons | lambada | piqa | wino | arc-e | arc-c | obqa | hswag |
|---|---|---|---|---|---|---|---|---|---|
| NanoColibri (chat) | 341M | 5.4B | 26.3 | 62.7 | 49.2 | 43.4 | 22.8 | 22.0 | 31.1 |
| Pythia-410M @ step3000 | 405M | 6.3B | 26.3 | 59.8 | 50.9 | 41.3 | 18.8 | 15.6 | 27.0 |
| Cerebras-GPT-256M (final) | 256M | 5.1B | 29.3 | 61.3 | 51.1 | 41.0 | 17.0 | 15.8 | 27.4 |
NanoColibri gagne 5 des 7 comparaisons contre les deux références, fait match nul sur LAMBADA contre Pythia, et se situe dans le bruit sur WinoGrande (±1,4 à n=1267). Les réserves sont publiques. Le checkpoint Pythia n'est qu'à environ 2 % de son programme de taux d'apprentissage, ce qui le désavantage ; la ligne Cerebras-GPT-256M entièrement recuite est la comparaison conservatrice, et Nano gagne aussi celle-là. Le retard sur LAMBADA semble au moins en partie un artefact de données : FineWeb-Edu ne contient pratiquement pas de fiction, et LAMBADA est construit à partir de romans.
L'analyse du projet est mesurée : à ce budget, un MoE de 2,7 milliards de paramètres au total se comporte comme un bon modèle dense de la classe 300 à 600M, le nombre total de paramètres apportant un réel avantage sur deux références denses appariées en jetons. L'écart avec les chiffres de la classe SmolLM2 est de trois ordres de grandeur en données, pas en architecture.
Deux leçons embarrassantes
La première est le piège du cache de pages. Pour « mesurer » le streaming, l'équipe a donné au moteur de service des budgets RAM inférieurs à la taille du conteneur sur un serveur loué et a obtenu des vitesses étrangement plates jusqu'à un budget cinq fois plus petit que le conteneur. La RAM du serveur éclipsait le conteneur de 1,2 Go, si bien que le cache de pages du système d'exploitation couvrait silencieusement chaque défaut. Ces exécutions n'ont jamais touché le disque ; elles ont caractérisé la comptabilité du cache du moteur. De véritables chiffres de pression disque nécessitent des cgroups à mémoire plafonnée sur du matériel où le plafond est appliqué et, admet l'équipe, un conteneur plus grand. Un bug de benchmark trouvé depuis dans le harnais de vitesse explique pourquoi l'article ne contient aucune revendication de tokens/s. La discipline de mesure coûte moins cher à apprendre à 200 $.
La seconde est le cosinus épuisé. Un programme de taux d'apprentissage en cosinus fixé à un objectif d'étapes est épuisé au moment où on l'atteint, sans marge pour continuer l'entraînement sur l'élan. Les exécutions suivantes utilisent WSD, warmup-stable-decay : une longue phase stable qui convient aux étapes de relais, avec une seule décroissance, quand l'équipe le choisit.
Et maintenant : une répétition à 7B, puis un conteneur de 24 à 28B
La feuille de route dans NEXT_MODEL.md comporte deux étapes. Colibri-Micro : 7B au total, 1B actif, 100B de jetons, un mélange riche en code, SFT puis RLVR pour le code, et un conteneur réellement assez grand, 3,8 Go en int4, pour mesurer le véritable streaming disque sur les ordinateurs portables ciblés. Ensuite Colibri-Grande, 24 à 28B au total avec environ 2,4B actifs, dont le conteneur sursouscrit délibérément la mémoire d'un ordinateur portable de 16 Go. Le nombre d'experts de Grande n'est figé qu'une fois que les courbes mesurées de défauts de cache et de vitesse de Micro existent. Tout est publié en open source : poids, recette de données, code d'entraînement, protocole de relais, JSON de benchmark, registre.
Nano a été financé sur fonds propres. La prochaine étape nécessite quelques milliers d'heures H100, environ 9 000 à 12 000 $ aux taux du marché, et l'auteur demande des subventions de calcul. La preuve de boucle à 200 $ est terminée. Les leçons qu'elle a chiffrées, le cache de pages et le cosinus épuisé, sont exactement celles qu'une exécution à 9 000 $ ne peut pas se permettre d'apprendre à neuf.
- Source : A relay race of rented GPUs trained NanoColibri's 2.7B MoE for $200 — 2026-07-29
L'essentiel de la tech en 3 minutes chaque matin
Un email, chaque jour ouvré, avec ce qui compte vraiment en IA et en tech.