Un développeur entraîne seul, à partir de zéro, un modèle de langage de 260M sur une RTX 4060 de 8 Go

La plupart des histoires de « modèle maison » se révèlent en réalité n'être que du fine-tuning de poids d'autrui. Ici, ce n'est pas le cas. L'auteur de la gamme dpp-gpt a tout fait lui-même : tokenizer, pré-entraînement, SFT, RL et benchmarks. Le matériel : une RTX 4060 domestique avec 8 Go de mémoire. La dernière version, 2.2 Pro, avec 259 millions de paramètres, ne dépasse pas les petits modèles professionnels, mais ce projet montre bien à quoi ressemble un cycle d'entraînement complet sans le budget d'un laboratoire.

Ce qu'il y a dedans et sur quoi il a été entraîné

L'architecture est familière, héritée de Llama : RMSNorm, RoPE, SwiGLU, GQA. Le modèle compte 20 couches, une largeur de 1024, un contexte de 8192 tokens et son propre vocabulaire BPE de 16 384 tokens, où les chiffres sont des tokens séparés. Langues : russe, anglais, français.

Le pré-entraînement a porté sur environ 31 milliards de tokens. Le mélange est soigneusement composé : Wikipédia en trois langues (23 %), texte web CulturaX, code Python, mathématiques (14 %), poésie, traductions et données synthétiques pour le travail sur le texte.

La partie la plus intéressante, ce sont les maths. Elles sont générées par un script, et la réponse est écrite par rang : centaines, dizaines, unités, puis le total. Chaque exemple est vérifié par Python, il n'y a donc aucune erreur dans les données. Le modèle apprend ainsi à calculer des nombres allant jusqu'à 40 chiffres : il répète un algorithme au lieu de deviner la réponse.

Le jeu SFT a atteint 60 millions de tokens (environ 122 000 dialogues). Presque tout a été généré par DeepSeek via OpenRouter, et les réponses contenant des nombres ont été revérifiées par du code. Les données ont coûté environ 3000 roubles. 32 % de données de pré-entraînement ont été mélangées à l'entraînement pour que le modèle n'oublie pas sa base.

RL sur 8 Go : ce qui a marché et ce qui s'est cassé

La version finale a été obtenue via GRPO. Pour chaque requête, le modèle écrit 8 réponses, reçoit une récompense et apprend à partir de l'écart au sein du groupe. La récompense est attribuée soit par du code (arithmétique, tests pour Python, JSON, appel d'outils), soit par un juge local, Gemma 4 E4B, pour les rédactions, les poèmes et les faits.

Une astuce utile : l'ajustement de la difficulté. Si une tâche est toujours résolue ou jamais résolue, les 8 réponses reçoivent la même récompense et il n'y a pas de gradient. Ces types de tâches sont donc tirés moins souvent, et ceux où le modèle en résout environ la moitié, plus souvent.

Impossible d'échapper au reward hacking classique. Lors des premiers essais, la récompense pour le texte était calculée par du code à partir d'indices indirects, et le modèle a appris à répondre court. Les rédactions et les questions générales se sont dégradées. Il a fallu ajouter un juge et rééquilibrer l'entraînement.

Une fois les problèmes évidents réglés, la progression s'est arrêtée : chaque nouveau checkpoint gagnait quelque part et perdait ailleurs. Une simple moyenne des poids a aidé : 0,4 · GRPO8 + 0,3 · GRPO9 + 0,3 · GRPO5. Cette « soupe » s'est révélée meilleure que n'importe lequel des checkpoints.

Un autre désagrément : le SFT a fait chuter les maths. Le modèle de base obtenait 47,6 % sur le benchmark maison, 26 % après le premier SFT, 36,8 % après l'ajustement du mélange.

Les chiffres sans fard

Sur son propre jeu de 2450 questions, la moyenne est passée de 8,3 (version 2.15) à 24,2. Le modèle domine en arithmétique et en appel d'outils, mais en moyenne il n'est qu'au niveau de Falcon-H1-Tiny 100M et derrière Gemma 3 270M. Réserve de l'auteur : le jeu est conçu pour ses formats et le favorise.

Sur les tests anglophones courants, le tableau est plus faible. HellaSwag : 28,9 % contre 39,3 % pour Gemma 3 270M et 42,9 % pour SmolLM2 135M. GSM8K : 1,8 %, IFEval : 14,1 %. La base sans SFT donne les mêmes 28,8 % sur HellaSwag, donc le plafond est fixé par le pré-entraînement : 31 milliards de tokens contre des milliers de milliards. Le RL n'a pas fait bouger ces tests ; son gain porte sur l'arithmétique, les outils, le JSON et les instructions.

Les points faibles sont aussi nommés : la multiplication de nombres à 5–6 chiffres n'est correcte que dans environ 30 % des cas, le modèle perd le fil entre les messages, obéit mal à des consignes comme « réponds en un mot », et le mode « avec réflexion » n'aide pas encore. L'appel d'outils ne fonctionne que dans le format sur lequel il a été entraîné.

Ce qu'il faut en retenir

Premièrement : pour des tâches étroites (sortie structurée, appel de fonctions, arithmétique), des données synthétiques vérifiables et une récompense par code apportent un gain notable même sur un tout petit modèle. Deuxièmement : si la récompense RL a un point faible, le modèle le trouvera ; il faut donc des vérifications variées et un juge. Troisièmement : la moyenne des poids de checkpoints proches ne coûte presque rien et peut battre la recherche du « meilleur ».

Et quatrièmement : en connaissances générales, un petit modèle avec un petit budget de tokens n'est pas compétitif. Prochaines étapes de l'auteur : une version flash de 140M avec une part de Python corrigée, et un vocabulaire élargi avec attention locale pour accélérer le tout.