Recherche
Helix, partie 1 : entraîner un modèle de langue européen
Nous entraînons notre propre modèle de langue. Il est petit – 320 millions de paramètres –, mais il lit les 24 langues officielles de l’Union européenne et il s’entraîne sur des cartes graphiques conçues pour le jeu vidéo. Cette première partie raconte comment nous en sommes arrivés là ; la seconde suivra à la fin de l’entraînement.
Pourquoi un studio de jeux entraîne un modèle de langue
NETBYTE crée des jeux, des applications et des sites web. Les modèles de langue s’invitent de plus en plus dans ces produits : personnages qui répondent, aide qui comprend une question, outils qui agissent. La plupart des modèles ouverts pensent d’abord en anglais ; l’estonien, l’irlandais ou le maltais viennent après coup. Nous voulions comprendre toute la chaîne par nous-mêmes – données, tokenizer, architecture, entraînement – et savoir où part vraiment l’argent.
- paramètres
- 320 M
- langues officielles de l’UE
- 24
- tokens d’entraînement
- 6,5 Md
- pour les GPU loués
- ≈ 12 $
Helix est né comme prototype de recherche. Tout ce qui suit est une décision qui l’a façonné, chacune appuyée par une mesure – ainsi que les erreurs qui nous ont coûté le plus de temps.
Quatre idées, une seule survivante
Le prototype s’attaquait à quatre faiblesses connues des générateurs de texte actuels. Il écrit par blocs de 16 tokens au lieu d’un token à la fois, il peut parcourir plusieurs fois un noyau de couches partagé, il prédit un « plan » compact pour chaque bloc, et il combine une attention locale peu coûteuse avec une attention linéaire pour les longues distances.
L’écriture par blocs a fonctionné d’emblée : un petit modèle de test a écrit 64 tokens en 13 passages dans le réseau, là où un modèle classique a besoin d’un passage par token – environ un cinquième du travail. Les trois autres idées ont échoué à un test plus exigeant. Nous avons construit des tâches dont la réponse se trouve bien au-delà de la fenêtre locale, si bien que le modèle doit remonter tout le texte.
Afficher les données
| Variante | Correct |
|---|---|
| Fenêtre locale seule | 23,1 % |
| + attention linéaire, plan et boucles | 23,1 % |
| + 2 têtes globales exactes | 49,4 % |
| Attention complète (contrôle) | 49,0 % |
| Hasard (25 %) | 25,0 % |
Seule une attention exacte sur toute la distance les a résolues. Attention linéaire, plan et boucles sont restés au niveau du hasard ; l’optimiseur avait même réduit la mémoire linéaire à une demi-vie de moins d’un token. Deux têtes globales exactes ont suffi pour égaler l’attention complète.
Le modèle final garde donc huit têtes locales avec une fenêtre de 256 tokens dans chaque couche et ajoute deux têtes globales exactes une couche sur deux ; les couches intermédiaires gardent deux têtes d’attention linéaire à porte. Plan et boucles sont désactivés. Ils restent dans le code et sont testés, mais sur du texte réel ils n’ont pas justifié leur coût.
- Locale, fenêtre de 256 tokens
- Attention globale exacte
- Attention linéaire à porte
Afficher les données
| Type de tête | Couches | Têtes par couche |
|---|---|---|
| Locale, fenêtre de 256 tokens | 1–12 | 8 |
| Attention globale exacte | 1, 3, 5, 7, 9, 11 | 2 |
| Attention linéaire à porte | 2, 4, 6, 8, 10, 12 | 2 |
Mesurer plutôt que supposer
Nous avons testé chaque astuce d’entraînement sur un modèle de 94 millions de paramètres avec le même budget par essai : 29,5 millions de tokens, la même graine, le même ordre des données. Deux essais de la même configuration diffèrent de ±0,03 ; tout ce qui est plus petit relève du bruit.
Afficher les données
| Modification | Δ perte (nats) |
|---|---|
| Muon + calendrier WSD | -0,587 |
| Optimiseur Muon | -0,347 |
| Réseau plus profond et plus étroit | -0,099 |
| Calendrier WSD | -0,080 |
| Résiduel de valeur | -0,007 |
| z-loss | +0,029 |
| Attention à requêtes groupées | +0,088 |
L’optimiseur Muon a été le seul grand levier, et il se combine avec un calendrier de taux d’apprentissage warmup-stable-decay. Remettre l’embedding et la couche de sortie sous AdamW, comme le recommandent les auteurs de Muon, a apporté encore 0,12 et accéléré l’entraînement de 5 %. Les combinaisons ne s’additionnent pas simplement : un réseau plus profond et plus étroit aidait sous AdamW et nuisait sous Muon. C’est pourquoi chaque combinaison prometteuse a eu son propre essai.
24 langues, 6,5 milliards de tokens
Helix lit du texte web issu de FineWeb-Edu pour l’anglais et de FineWeb-2 pour les 23 autres langues – pour les plus grandes, de son dixième supérieur filtré par qualité. Du code, des mathématiques et un petit flux de chat synthétique complètent le mélange. L’anglais reçoit un tiers. Les autres langues sont pondérées selon la quantité de texte disponible, lissée pour que l’irlandais et le maltais ne soient pas noyés, et aucune source n’est répétée plus de quatre fois – jusque-là, la répétition vaut à peu près des données neuves.
Afficher les données
| Source | Part |
|---|---|
| 23 autres langues de l’UE | 51,6 % |
| Anglais | 33,0 % |
| Code et balisage | 10,0 % |
| Mathématiques | 3,0 % |
| Chat et outils synthétiques | 2,4 % |
Le flux de chat est extractif : les réponses sont reprises de vrais paragraphes, et les résultats d’outils sont calculés au lieu d’être inventés. Il enseigne la forme, pas le savoir. Le tokenizer est un BPE au niveau de l’octet avec 64 000 entrées ; il place entre 3,3 et 4 octets de texte dans un token pour chaque langue en écriture latine.
Trois bugs qui méritent d’être racontés
- Le modèle qui lisait la réponse. Dans un chemin du code, les têtes globales ignoraient le masque causal et voyaient les tokens futurs. La perte est tombée de 6,85 à 1,71 en 75 pas, et un essai de 16 heures n’a servi à rien. Une perte étonnamment bonne est un rapport de bug ; un test de non-régression surveille désormais exactement ce cas.
- Les caractères ne sont pas des octets. La compression était comptée en caractères au lieu d’octets UTF-8. Cela inventait une « faiblesse » en chinois et faisait paraître le grec et le bulgare presque deux fois plus mauvais qu’ils ne le sont.
- Des documents coupés à chaque ligne vide. L’encodeur séparait les documents à chaque ligne vide – et il y en a au milieu de presque tous les fichiers source. Jusqu’à 35 % du texte de code et de mathématiques ont été perdus. Nous avons corrigé le séparateur et reconstruit tout le corpus le 31 octobre ; cela a pris 2 heures et 12 minutes.
Du bureau à une machine louée
Les premiers 1,66 milliard de tokens ont tourné sur une seule AMD Radeon RX 7800 XT. Deux choses ont rendu cela possible : une option du noyau d’attention désactivée par défaut – sans elle, l’attention était 12 fois plus lente – et la compilation de chaque couche avec torch.compile. À une médiane de 11 800 tokens par seconde, le reste aurait encore pris presque cinq jours.
Nous avons donc écrit un pilote automatique. Il loue des GPU sur Vast.ai, envoie code, corpus et checkpoint, entraîne, rapatrie un checkpoint toutes les trois heures et s’arrête avant que le crédit soit épuisé. Le 2 novembre, il est passé par trois machines que leurs hébergeurs n’ont jamais démarrées, puis s’est arrêté sur deux RTX 4070 Ti Super en Allemagne pour 0,363 $ de l’heure. L’envoi de 15,4 Gio a pris 40 minutes.
Afficher les données
| Configuration | Tokens/s |
|---|---|
| Local, avant optimisation | 8 319 |
| Local, compilé | 11 830 |
| Loué, 2 GPU | 41 367 |
41 400 tokens par seconde, c’est 3,5 fois le bureau. La partie louée – 4,8 milliards de tokens en 33 heures environ – coûte à peu près 12 $.
Où en est Helix aujourd’hui
- Réservé
- Entraînement
Perte (nats par token)
Milliards de tokens lus
Afficher les données
| Milliards de tokens lus | Réservé | Entraînement |
|---|---|---|
| 0,06 | 4,571 | 4,261 |
| 0,55 | 3,776 | 3,574 |
| 1,04 | 3,694 | 3,469 |
| 1,54 | 3,596 | 3,421 |
| 2,03 | 3,426 | 3,238 |
| 2,52 | 3,329 | 3,143 |
| 3,01 | 3,291 | 3,113 |
| 3,50 | 3,263 | 3,076 |
| 3,99 | 3,225 | 3,079 |
| 4,49 | 3,244 | 3,076 |
| 4,98 | 3,218 | 3,036 |
| 5,35 | 3,123 | 2,884 |
Au 3 novembre 2026, Helix a lu 5,35 de ses 6,5 milliards de tokens. Depuis 5,2 milliards, il est en phase de refroidissement : le taux d’apprentissage baisse et le mélange se déplace vers les mathématiques, le code et le chat. Sur du texte réservé de tous les flux, il en est à 3,12 nats par token.
Afficher les données
| Langue | Bits par octet |
|---|---|
| grec | 0,721 |
| bulgare | 0,844 |
| français | 1,065 |
| anglais | 1,086 |
| espagnol | 1,135 |
| portugais | 1,219 |
| allemand | 1,257 |
| néerlandais | 1,268 |
| italien | 1,277 |
| polonais | 1,355 |
| danois | 1,364 |
| hongrois | 1,407 |
| slovaque | 1,412 |
| maltais | 1,415 |
| roumain | 1,416 |
| suédois | 1,418 |
| irlandais | 1,422 |
| slovène | 1,431 |
| tchèque | 1,444 |
| lituanien | 1,450 |
| letton | 1,451 |
| croate | 1,507 |
| finnois | 1,508 |
| estonien | 1,727 |
Ce que cela signifie en pratique se voit le mieux dans un échantillon non retouché, tiré d’un checkpoint à environ 4,9 milliards de tokens. Le début est de nous, la suite est de Helix :
Amorce: The history of the printing press begins in the fifteenth century, when Johannes Gutenberg introduced movable type to Europe. Before that, books
Sortie du modèle: for printing were usually in the form of texts, usually in the format of illustrations. In its introduction to the printing press, Gutenberg uses one line-of-action model to illustrate a series of printed pieces of a book.
La grammaire, le choix des mots et le sujet tiennent ; les faits, non. C’est à peu près ce qu’on peut attendre de 320 millions de paramètres et 6,5 milliards de tokens : un modèle fluide qui invente.
La suite
Le pré-entraînement se termine dans quelques heures. Viendront ensuite une phase à contexte long avec des livres du Project Gutenberg et des textes juridiques européens d’EUR-Lex, un affinage pour la conversation et l’usage d’outils, et un petit modèle de brouillon qui accélère la génération.