Avant de toucher au code : ce dont vous avez vraiment besoin pour entraîner un LLM
Entraîner un modèle de langage à partir de zéro ne consiste pas à télécharger un script et à appuyer sur Entrée. C’est un projet d’ingénierie avec trois fronts à résoudre avant la première ligne : les données, le calcul et l’évaluation. Selon la documentation officielle de frameworks comme PyTorch et Hugging Face, la plupart des échecs dans les projets d’entraînement ne viennent pas du code, mais d’une planification déficiente du corpus et d’une infrastructure mal dimensionnée.
Cet article décrit une configuration pas à pas en supposant que vous voulez construire un modèle petit ou moyen (entre 100M et 1 500M de paramètres) pour un domaine spécifique, et non un concurrent des grands modèles généralistes. Si votre objectif est un modèle de 70B paramètres avec des données multilingues massives, le budget se compte en millions de dollars et ce tutoriel est insuffisant : reconnaissez-le dès le départ.
Étape 1 : définition de la portée et du budget de calcul
Avant d’écrire le tokenizer, décidez de la taille du modèle en fonction des GPU disponibles. La règle pratique utilisée dans l’industrie relie les tokens d’entraînement aux paramètres : un modèle bien entraîné consomme généralement entre 20 et 100 fois plus de tokens que de paramètres. Pour un modèle de 125M paramètres, un corpus de 2 500M à 10 000M de tokens est raisonnable.
Estimation de la VRAM et du temps
La mémoire nécessaire pendant l’entraînement ne dépend pas uniquement de la taille du modèle. Les états de l’optimiseur AdamW multiplient par quatre le poids du modèle en précision mixte. Un modèle de 125M paramètres peut consommer entre 2 et 3 Go rien qu’en états de l’optimiseur, plus les activations et les gradients. Sur un GPU de 24 Go, vous pouvez entraîner des modèles jusqu’à 300-400M paramètres avec un petit batch et le gradient checkpointing.
Une erreur courante que j’ai vue dans des équipes novices : supposer qu’une RTX 4090 grand public permet d’entraîner un modèle de 1B paramètres sans techniques d’économie de mémoire. La réalité est que l’entraînement s’arrête par OOM (out of memory) après quelques pas, et le temps de débogage dépasse celui de l’entraînement.
Étape 2 : construction et nettoyage du corpus
Le dataset est l’actif le plus précieux et le plus négligé. Pour un modèle de domaine (juridique, médical, technique, service client), vous avez besoin d’entre 1 000 et 10 000 millions de tokens de texte de qualité. Si vous partez de zéro, le pipeline de nettoyage doit inclure :
- Déduplication au niveau du document et du paragraphe avec MinHash ou SimHash. Sans cela, le modèle mémorise et sur-ajuste sur des phrases répétées.
- Filtrage de langue avec un classifieur léger (fastText fonctionne bien) pour écarter le contenu qui n’est pas en espagnol si c’est votre domaine.
- Élimination du boilerplate (menus de navigation, avis de cookies, footers) qui empoisonnent le signal d’entraînement.
- Contrôle qualité heuristique : ratio de caractères alphabétiques, longueur moyenne de phrase, présence de répétitions n-grammes.
Selon des études du secteur sur des datasets publics comme C4 et The Pile, entre 40 % et 60 % du texte brut est écarté après le nettoyage. Planifiez le stockage en conséquence : un corpus de 10 000M tokens en texte brut occupe environ 40 Go.
Étape 3 : tokenizer spécifique au domaine
Ne réutilisez pas le tokenizer de GPT-2 ou Llama si votre domaine possède son propre vocabulaire. Un tokenizer BPE entraîné sur votre corpus réduit le nombre de tokens par document et accélère l’entraînement. La configuration avec la bibliothèque tokenizers de Hugging Face est directe :
from tokenizers import Tokenizer, models, trainers, pre_tokenizers
tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»))
tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False)
trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»])
tokenizer.train_from_iterator(corpus_iter, trainer=trainer)
tokenizer.save(«tokenizer_dominio.json»)
Un vocabulaire entre 32 000 et 50 000 tokens couvre bien l’espagnol général. Pour des domaines techniques avec beaucoup d’acronymes, envisagez 48 000. Vérifiez le taux de compression : si votre tokenizer génère plus de 1,4 token par mot en moyenne, vous avez probablement besoin de plus de vocabulaire ou d’un corpus d’entraînement plus représentatif.
Étape 4 : architecture du modèle et configuration initiale
Pour un modèle à partir de zéro, une architecture decoder-only de type GPT est le standard. La configuration doit être cohérente : dimension cachée (d_model), nombre de couches, têtes d’attention et dimension de feed-forward. Une règle qui fonctionne : feed-forward = 4 × d_model, et nombre de têtes tel que la dimension par tête soit 64 ou 128.
Exemple de configuration pour un modèle de 125M
{
«vocab_size»: 32000,
«hidden_size»: 768,
«num_hidden_layers»: 12,
«num_attention_heads»: 12,
«intermediate_size»: 3072,
«max_position_embeddings»: 1024,
«hidden_act»: «gelu»,
«dropout»: 0.1
}
Avec cette configuration, le modèle compte environ 125M de paramètres. Si votre GPU est de 16 Go, réduisez le batch par dispositif à 8 et utilisez une accumulation de gradients de 4 pour un batch effectif de 32. Le learning rate initial typique est de 3e-4 avec un scheduler cosinus et un warmup de 2 000 pas.
Étape 5 : boucle d’entraînement avec PyTorch et Accelerate
La configuration minimale viable utilise transformers avec Trainer ou une boucle manuelle avec accelerate. Pour un contrôle total, la boucle manuelle est préférable. Les points critiques :
- Précision mixte (fp16 ou bf16) avec torch.cuda.amp. Sur les GPU Ampere ou supérieurs, bf16 est plus stable.
- Gradient checkpointing activé si le modèle ne tient pas en mémoire.
- Sauvegarde des checkpoints tous les 500 pas, pas à chaque époque. Sur les grands modèles, une époque peut être irréalisable.
- Évaluation de la perplexité sur un ensemble de validation de 5 % du corpus.
Un détail qui ne s’apprend qu’avec la pratique : la loss peut sembler stable mais la perplexité de validation diverger si le corpus de validation a une distribution différente. Assurez-vous que la validation est extraite aléatoirement du même corpus nettoyé, et non d’une source différente.
Étape 6 : évaluation et signaux d’alarme
La perplexité ne suffit pas. Vous devez évaluer le modèle sur des tâches concrètes : génération de texte, classification ou réponse à des questions. Pour un petit modèle, utilisez des benchmarks légers comme un sous-ensemble de la tâche de raisonnement ou des tests manuels de génération avec des prompts de votre domaine.
Signaux que quelque chose va mal :
- Loss qui baisse mais génération incohérente : probablement un sur-ajustement dû aux doublons dans le corpus.
- Perplexité de validation qui remonte après un minimum : learning rate trop élevé ou corpus trop petit pour la taille du modèle.
- Répétitions dans la génération : manque de diversité dans le corpus ou tokenizer mal entraîné.
Étape 7 : ajustement fin et déploiement
Un modèle de base entraîné à partir de zéro ne répond pas aux instructions. Pour un usage pratique, vous avez besoin d’une phase d’instruction ou d’ajustement fin supervisé avec des paires question-réponse de votre domaine. Cette phase est plus légère : entre 10 000 et 100 000 exemples de qualité suffisent généralement pour un petit modèle.
Le déploiement avec vLLM ou llama.cpp permet de servir le modèle avec une quantification à 8 ou 4 bits, réduisant les besoins en VRAM. Un modèle de 125M quantifié à 4 bits occupe moins de 100 Mo et peut tourner sur CPU, bien que la latence soit plus élevée.
Limites que vous devez assumer
Entraîner à partir de zéro ne garantit pas la qualité. Un modèle de 125M entraîné avec 5 000M de tokens en espagnol aura une connaissance factuelle limitée et hallucinera fréquemment. Il ne rivalise pas avec des modèles pré-entraînés de plus grande taille. Si votre objectif est un assistant conversationnel général, l’ajustement fin d’un modèle existant est plus efficace en coût et en temps. L’entraînement à partir de zéro a du sens lorsque vous avez besoin d’un contrôle total sur le vocabulaire, la licence ou l’architecture, ou lorsque vous étudiez les dynamiques d’entraînement.
Selon la documentation officielle de PyTorch et les guides de Hugging Face, le coût d’un entraînement de 125M paramètres avec 5 000M de tokens sur un seul GPU de 24 Go peut osciller entre plusieurs jours et une semaine, selon le throughput. Il n’y a pas de raccourcis : le pipeline de données consomme autant de temps que l’entraînement.
Si vous décidez d’avancer, commencez avec un corpus de 500M tokens et un modèle de 50M paramètres. Validez le pipeline complet avant de passer à l’échelle. L’expérience montre que 80 % des erreurs apparaissent dans les premières 24 heures d’entraînement et sont plus faciles à corriger avec un petit modèle.