---
title: "Ce que j'ai appris en entraînant mon propre modèle"
author: "Jakub Ćwirlej"
id: training-lessons
language: fr
url: "https://jakubcwirlej.com/fr/articles/training-lessons.md"
page: "https://jakubcwirlej.com/fr/ai-dev/"
translations:
  pl: "https://jakubcwirlej.com/pl/articles/training-lessons.md"
  en: "https://jakubcwirlej.com/articles/training-lessons.md"
  nl: "https://jakubcwirlej.com/nl/articles/training-lessons.md"
updated: 2026-10-14
words: 2822
summary: "Dix leçons pratiques tirées de l'expérience de l'auteur, qui entraîne lui-même des modèles de langage. Elles portent sur les estimations de calcul trop optimistes, le fait de commencer petit, la surveillance constante, les changements isolés et les tests d'ablation, le choix des données, des attentes réalistes, la patience pendant les plateaux et le besoin de plus d'un GPU. Il conclut que les petits modèles spécialisés construits par des particuliers ont toujours un sens."
summary_type: editorial
---

# Ce que j'ai appris en entraînant mon propre modèle

Jakub Ćwirlej · langue du texte: FR · 2822 mots

## Résumé (éditorial)

Dix leçons pratiques tirées de l'expérience de l'auteur, qui entraîne lui-même des modèles de langage. Elles portent sur les estimations de calcul trop optimistes, le fait de commencer petit, la surveillance constante, les changements isolés et les tests d'ablation, le choix des données, des attentes réalistes, la patience pendant les plateaux et le besoin de plus d'un GPU. Il conclut que les petits modèles spécialisés construits par des particuliers ont toujours un sens.

## Points clés (éditorial)

- L'utilisation réelle du matériel (MFU) est bien inférieure à ce que suggèrent les fiches techniques ; son premier modèle, de 1,5 milliard de paramètres, est resté sous-entraîné.
- Suivre les normes et comparer chaque jour les réponses révèle des problèmes que la loss ne montre pas ; il est passé d'AdamW à MuonH.
- Il faut ne changer qu'une chose à la fois ; il a dû reconstruire son jeu de données à partir de zéro trois fois.
- Les capacités progressent souvent par bonds après de longs plateaux, et surveiller le top10 peut montrer des progrès que le top1 cache.
- De petits modèles ciblés, exécutables en local ou sur CPU, peuvent être plus rentables que les plus grands modèles, et en entraîner un est le meilleur moyen de comprendre comment fonctionne l'IA.

## Texte intégral (les mots de l'auteur)

### 1. Les calculs faits sur le papier seront toujours trop optimistes

Quand on pense à l'entraînement d'un modèle, c'est naturellement le processus d'apprentissage automatique qui vient à l'esprit – un travail qu'accomplissent pour nous de puissants clusters Nvidia dans des centres de données ou, avec un peu plus de chance, notre propre station de travail, d'une puissance infernale. En lisant les fiches techniques, on oublie facilement que le MFU (Model FLOPs Utilization) réel est bien inférieur à ce que suggèrent les documents marketing des fabricants de cartes. Selon l'architecture et la granularité, le matériel ne vous laissera tirer du silicium qu'une fraction de sa puissance de calcul. À quoi bon une carte qui calcule en FP4, si l'entraînement d'un modèle de base à partir de zéro n'y est pas stable, ou si, à la largeur de votre modèle, descendre sous le BF16 n'apporte aucun gain ?

Le moment où vous comprenez que vous ne pourrez pas entraîner le modèle prévu dans les délais escomptés, ni même dans une taille approchante, n'est pas facile à vivre. Surtout si vous avez passé des semaines à arriver au point où vous pouvez lancer l'entraînement, pour découvrir soudain que tout le plan était irréaliste. Sur le papier, pourtant, tout collait ! Premier réflexe : chercher des méthodes d'optimisation – torch compile, autocast, flash attention, FLCE, des têtes et un minibatch dont la taille est calée sur les préférences de CUDA. Tout cela fonctionne, mais on ne triche pas avec la physique du silicium. Si vous entraînez un petit modèle, sa faible largeur jouera contre vous. Si vous n'avez pas les moyens d'entraîner un grand modèle, vous n'avez pas non plus les moyens de tirer le maximum de votre GPU. Arriver à exploiter la carte de façon optimale peut prendre des jours, et une baisse finale du TPS (Tokens Per Second) de 30 à 40 % à l'entraînement par rapport aux calculs initiaux, cela représente des jours, voire des semaines de travail de la carte.

### 2. Commencez toujours à la plus petite échelle capable de valider vos idées

Mon premier modèle comptait 1,5 milliard de paramètres, et je n'ai pu l'entraîner que jusqu'à trois Chinchilla. J'ai commis beaucoup d'erreurs en le construisant, mais il fonctionnait malgré tout. Ce qui l'a condamné à n'être presque d'aucune utilité, c'est avant tout le sous-entraînement. Si, avec le même budget, j'avais choisi d'entraîner un modèle dix fois plus petit, j'aurais pu me targuer d'un modèle bien entraîné et utile. J'aurais eu le temps de faire des tests et j'aurais certainement évité bien des erreurs, ce qui m'aurait permis de construire une meilleure architecture. Bien sûr, la taille compte, mais les données, l'architecture et l'efficacité de calcul comptent encore davantage. Les chances de concevoir un bon modèle à partir de la littérature, sans tests et sans erreurs, sont à peu près celles de gagner au Loto.

### 3. Un modèle ne s'entraîne pas tout seul

Entraîner un modèle, ça a l'air sympa, mais c'est bien plus ennuyeux qu'on ne l'imagine. En réalité, il s'agit surtout de concevoir sans cesse des expériences, de faire des mesures, d'analyser les résultats du modèle et de chercher des solutions aux problèmes qui surgissent en cours de route. Tout le temps, en boucle, jour après jour. Si vous ne savez pas tirer de satisfaction des petites découvertes et des modestes réussites, cela risque de vous paraître trop ennuyeux. Or c'est précisément une constance de fer dans les mesures qui décide de tout. Même avec des paramètres d'entraînement bien choisis, il peut s'avérer avec le temps que notre modèle a besoin de nouvelles données, ou qu'il se dégrade d'une manière difficile à repérer au premier coup d'œil. Vous ne le remarquerez pas sans un bon monitoring et des tests continus, et moins vous en faites, plus vous perdrez de temps si le modèle se met à se comporter de manière indésirable.

Prenons un scénario fréquent. Après quelques jours d'entraînement, vous vous apercevez que le modèle répond de plus en plus brièvement, tout en étant de plus en plus sûr de lui. La loss et l'ensemble held-out ont bonne mine, mais quelque chose cloche avec le modèle. Si vous analysez les normes au fil de l'eau et comparez chaque jour les réponses du modèle à celles de la veille, vous pouvez vite repérer la hausse des logits et comprendre que le modèle attribue une probabilité de plus en plus forte à certains tokens. Cette arrogance est une ruse de l'optimiseur paresseux : AdamW a trouvé le moyen de nous tromper et, au lieu de faire apprendre le modèle, il réduit la perte autrement. Si vous le repérez au bout de quelques jours, vous en serez peut-être pour quelques dizaines de dollars ; si vous laissez tourner l'entraînement en comptant sur le GPU Nvidia pour faire tout le travail, vous risquez d'en dépenser des centaines, voire des milliers, et le modèle sera peut-être déjà impossible à sauver.

J'ai moi-même passé des semaines à regarder Adam gonfler les normes de mes modèles, en abaissant le learning rate (LR) effectif, et ce malgré la normalisation QK-norm et un weight decay de 0,1. L'entraînement ralentissait, à me désespérer, car, comme on le sait, c'est le théorème de Pythagore qui joue ici : plus le vecteur de poids grandit, plus il est difficile de le faire tourner avec un LR constant. Le phénomène est bien décrit dans la littérature, mais tant que vous ne l'aurez pas vu de vos yeux, vous ne comprendrez pas pourquoi il vaut mieux passer à un autre optimiseur. Après tout, AdamW a permis d'entraîner des centaines de modèles. J'ai finalement opté pour MuonH, et ce fut l'une des meilleures décisions que j'aie prises. Bien sûr, beaucoup de choses de ce genre se trouvent dans la littérature, dans les manuels ou dans les articles publiés sur arXiv, mais on ne sait jamais comment elles fonctionneront chez soi. Nombre de solutions qui, en théorie, devraient apporter des bénéfices bien documentés n'ont pas fonctionné chez moi. Vous n'en aurez le cœur net qu'en vérifiant par vous-même, et pour cela, il faut rester vigilant et suivre les progrès en continu.

### 4. Ne changez jamais qu'une seule chose à la fois, et faites des tests d'ablation

Ces derniers mois, j'ai testé des centaines de petits modèles – aussi bien des transformers classiques que mes propres idées… et je sais aujourd'hui que je n'ai pas assez testé. À vouloir avancer trop vite, j'ai perdu du temps pour rien. Nombre de couches, ratio FFN, d_model, partage des poids, taille des têtes, nombre de têtes KV, batch, optimiseur, récurrence, parcimonie (sparsity), données d'entraînement : les facteurs qui influent sur le comportement du modèle se comptent par dizaines, et leurs combinaisons donnent des milliers d'architectures possibles. Et même si, grosso modo, tout fonctionne comme on peut s'y attendre après avoir lu un premier manuel d'ingénierie de l'IA, tant que vous n'aurez pas testé vous-même votre architecture, vous ne saurez pas où vous en êtes. Or de petites modifications peuvent souvent entraîner de grandes différences d'efficacité de calcul et de résultats aux benchmarks, et ce à jeu de données et taille de batch identiques. Si vous n'introduisez pas les changements un par un, il est facile de s'y perdre. J'ai moi-même commis cette erreur bien des fois. Ce n'est pas que les modifications étaient mauvaises. Même si elles l'étaient souvent. Le vrai problème, c'est que lorsque je faisais réellement un pas en avant, j'étais incapable de dire à quelle modification je le devais.

### 5. Commencez par les données

Pour entraîner un petit modèle, Hugging Face offre un réservoir de données d'une ampleur inimaginable. On pourrait croire que, si ces données sont à portée de main, en quantités qui dépassent largement les besoins de n'importe quel projet de garage, l'affaire est réglée. Pourtant, le choix des données compte bien plus qu'on ne le pense au départ. Et le fait qu'elles aient déjà été rassemblées en jeux de données prêts à l'emploi ne simplifie en rien les choses. S'y ajoute le choix du bon tokeniseur, des langues qu'on veut apprendre au modèle, ou des proportions. Par exemple, décider quelle part des données doit être du code, quelle part des mathématiques et quelle part de la langue naturelle. Puis choisir les domaines dans lesquels notre modèle doit se spécialiser. Plus on creuse, plus les possibilités se multiplient. J'ai moi-même dû préparer mon jeu de données à partir de zéro pas moins de trois fois. J'ai aussi connu quelques ratés de moindre ampleur, comme une fuite du template instruct que je n'avais pas repérée lors de la préparation des données. Chacune de ces erreurs m'obligeait à ramener l'entraînement plusieurs heures, voire plusieurs jours en arrière.

### 6. N'en attendez pas trop

À voir les grands laboratoires, et les plus petits, repousser sans cesse les limites de ce dont l'IA est capable, on a vite fait de croire qu'entraîner un modèle utile est au fond une affaire simple. Mais si repousser ces limites coûte des milliards de dollars, ce n'est pas sans raison. Que votre modèle se mette à parler comme un humain ou qu'il obtienne de bons scores sur les benchmarks populaires ne dit rien de sa qualité finale ni de son utilité. Les modèles apprennent très vite au début, dans les premiers jours de l'entraînement, mais chaque point de pourcentage supplémentaire se gagne à force d'astuce, d'attention et d'abnégation. Surtout quand, pendant des jours, vous voyez le modèle stagner sur un plateau, voire régresser. Par ailleurs, les benchmarks populaires en disent peu sur les capacités réelles d'un modèle. Votre modèle peut être bon en Python et faire d'excellents scores sur HumanEval et MBPP, mais s'il ne connaît pas les bibliothèques les plus récentes, son utilité dans le monde réel restera modeste.

### 7. Armez-vous de patience

Beaucoup de capacités des modèles progressent par bonds. Ce phénomène bien décrit, le grokking, est souvent précédé d'un long plateau qui peut durer des jours. Quand vous voyez le modèle ne faire aucun progrès, alors que chaque heure d'entraînement vous coûte des dollars en location de puissance de calcul, ou ne serait-ce qu'en électricité, difficile de ne pas douter. Vous vous dites : « Le modèle a atteint sa capacité, il n'apprendra plus rien », ou : « Les grands labos, qui entraînent jusqu'à 1000× Chinchilla, ont sûrement des astuces. » Or les capacités progressent souvent par bonds. Il suffit que le modèle apprenne à terminer proprement une fonction pour que, d'un coup, ce ne soit plus une seule tâche de MBPP qui passe, mais une bonne dizaine. Souvent aussi, le modèle fait de vrais progrès, mais si, par souci d'économie, vous ne surveillez que le top1 des réponses au lieu du top10, vous pouvez ne rien en voir pendant longtemps. Le modèle doit apprendre à attribuer davantage de confiance, et cela prend du temps.

### 8. Une seule carte ne suffit pas

On pourrait croire que, si vous disposez d'un H100 ou d'une RTX PRO 6000 (96 Go), seul votre budget vous limite. Le problème, c'est que l'entraînement exige des tests et des mesures en continu, pour savoir où l'on en est. Un GPU de plus peut aussi être nécessaire pour générer des données d'entraînement supplémentaires. J'ai moi-même fait des progrès notables dans l'entraînement de mon modèle avec la méthode STaR, qui consiste à faire générer par mon propre modèle une grande quantité de tâches et à ajouter au jeu de données celles qui sont correctes, ainsi qu'avec un ensemble de données contenant des exemples de traduction entre langages de programmation

Interrompre l'entraînement sur une carte puissante le temps que le modèle génère des réponses coûte très cher et n'est tout simplement pas rentable ; générer en parallèle – même si la VRAM le permet – peut faire courir un risque sérieux. La dernière chose que vous souhaitez, c'est découvrir au bout de trois jours, quand les résultats du modèle chutent, que pendant la génération lancée sur la carte à côté de l'entraînement, le loader a connu par exemple un « affamement » passager, et que la loss a de ce fait discrètement cessé de baisser. À un stade avancé de l'entraînement, ce genre de chose est souvent extrêmement difficile à repérer, même avec un monitoring qui vous alerte en cas de pics de normes.

### 9. Commencez par quelque chose de simple

J'ai commencé à construire mon premier modèle sur une intuition : on pouvait exploiter, dans l'entraînement d'un LLM, les propres activations du modèle, et les suivre pendant l'apprentissage devait aider à construire un modèle plus intelligent et plus véridique. Aujourd'hui, je n'en reviens pas d'avoir abordé les choses avec tant de naïveté. Non pas parce que je pense aujourd'hui que c'est impossible, mais parce que, sans avoir la moindre idée de ce à quoi ressemble l'entraînement d'un LLM, je me suis mis à expérimenter avec quelque chose qui me dépassait. J'ai dû assimiler une énorme quantité de connaissances, tout en testant à la fois des solutions propres à l'architecture des transformers classiques et mes propres idées, qui – le temps l'a montré – étaient en grande partie irréalisables.

J'ai alors buté sur toute une série de problèmes : une fois normalisé, le signal d'activation des portes SwiGLU perdait son sens ; sans normalisation, AdamW exploitait mes modifications pour gonfler les normes du modèle. Ce n'est qu'avec le temps que j'ai compris qu'une bonne partie des avantages que j'avais trouvés à mon premier modèle venait d'un phénomène proche d'une régularisation par le bruit. De plus, le seul calcul du Gini à partir des activations des portes SwiGLU coûtait cher : il ajoutait quelques pour cent de compute, sans que les résultats le rentabilisent en qualité.

J'entraîne actuellement un petit modèle de 160M d'architecture standard, spécialisé dans le code. C'était la meilleure décision que je pouvais prendre, car je me suis donné une chance de créer quelque chose qui puisse être réellement utile. Et les premiers résultats du modèle montrent que les leçons tirées de mes erreurs n'ont pas été perdues.

### 10. Ne construisez pas un modèle censé être bon en tout

Vu les coûts astronomiques, et la faisabilité même de l'entreprise, construire un modèle généraliste quand on est seul ou une petite structure n'a aujourd'hui aucun sens, pour des raisons purement économiques. Face aux géants, ou même aux plus petits laboratoires qui publient des modèles ouverts, la partie est perdue d'avance sans des moyens et une expérience considérables. Mais cela ne veut pas du tout dire que construire ses propres modèles n'a pas de sens.

On peut imaginer des centaines d'applications où de petits modèles entraînés à partir de zéro, ou affinés sur des données uniques, auront l'avantage sur les géants – et cet avantage ne tiendra pas forcément au savoir. Il suffit que le modèle soit rapide et puisse tourner en local dans un navigateur, ou sur le processeur de n'importe quelle station de travail. Pour des usages précis et étroits, il peut être bien plus rentable d'utiliser un micro-modèle de quelques centaines de millions de paramètres que de mobiliser les modèles les plus puissants d'OpenAI ou d'Anthropic. Ce n'est pas qu'une question de coût. Même si l'écart est colossal. Un modèle spécialisé dans un domaine étroit est bien plus facile non seulement à entraîner, mais aussi à contrôler et à adapter aux besoins de l'utilisateur. Et surtout, c'est une tâche qui reste à la portée d'une personne ordinaire, prête à relever ce défi.

Les modèles des grands laboratoires sont entraînés sur des milliers de puces très coûteuses. Un exemple : l'entraînement d'un modèle de la classe de Llama 3 400B a nécessité un cluster de 16 000 cartes H100. Les coûts se chiffrent en dizaines de millions de dollars. L'entraînement du tout dernier GPT Astra a probablement placé la barre bien plus haut. Comme tout ce secteur se développe à crédit, et que le déploiement de l'IA à grande échelle, avec les coûts actuels des API et les questions de sécurité des données, est souvent difficile à justifier sur le plan économique, on peut s'attendre à ce qu'à long terme, les petits modèles jouent un rôle croissant. Les petits modèles seront aussi de plus en plus performants. Je ne serais pas surpris qu'à l'avenir, un modèle de l'ordre de 7 milliards de paramètres nous suffise pour la plupart des tâches. L'éclatement de la « bulle de l'IA », dont les médias parlent de plus en plus souvent, ne pourrait qu'accélérer ce processus.

C'est pourquoi je pense que construire de petits modèles a un sens profond. D'abord, il n'y a pas de meilleur moyen de comprendre comment fonctionne l'IA que d'entraîner son propre modèle. Ensuite, même si, dans les grands laboratoires, le développement de l'IA est de plus en plus souvent assuré… par l'IA elle-même, on peut s'attendre à ce que l'humanité, prenant au sérieux les questions de sécurité, exige un contrôle et une supervision humaine du processus d'entraînement. Pour cela, il est indispensable de comprendre comment ce processus se déroule en pratique. Bien sûr, il suffit aujourd'hui d'ouvrir LinkedIn pour être submergé de publications sur l'intelligence artificielle, signées des spécialistes les plus divers, qui proposent tutoriels et formations. Mais combien d'entre eux ont réellement entraîné leur propre modèle ?

---

Jakub Ćwirlej — Journaliste qui construit avec l'IA · sur le site: https://jakubcwirlej.com/fr/ai-dev/
Contexte complet: https://jakubcwirlej.com/context/fr.md · https://jakubcwirlej.com/llms.txt