Guide du fine-tuning d’un LLM : étapes, outils et coûts

Le fine-tuning d’un LLM consiste à adapter un modèle de langage préentraîné à un domaine, un style ou une tâche précise. Ce guide détaille les étapes, outils et coûts d’un fine-tuning, depuis la préparation des données jusqu’au déploiement et au suivi des performances.

Qu’est-ce que le fine-tuning d’un LLM ?

Le fine-tuning, ou affinage de modèle, consiste à poursuivre l’entraînement d’un LLM existant sur un jeu de données spécialisé. Le modèle conserve ses connaissances générales, mais apprend à mieux répondre à un type de demande particulier.

Par exemple, un fine-tuning peut servir à :

produire des réponses dans le ton d’une marque ;
classer automatiquement des tickets de support ;
extraire des informations depuis des documents ;
générer du code dans un framework spécifique ;
suivre un format de sortie strict ;
répondre selon le vocabulaire d’un secteur juridique, médical ou industriel ;
appliquer un workflow métier répétitif.

Le fine-tuning ne consiste donc pas à créer un modèle depuis zéro. L’entraînement initial d’un LLM nécessite d’immenses volumes de données et des milliers de GPU. L’affinage part d’un modèle déjà entraîné, ce qui réduit fortement les besoins en données, en temps et en calcul.

Fine-tuning, prompting et RAG : quelles différences ?

Trois approches sont souvent confondues.

| Approche | Fonctionnement | Cas d’usage principal |

|---|---|---|

| Prompt engineering | Modification des instructions envoyées au modèle | Améliorer rapidement les réponses |

| RAG | Recherche de documents pertinents ajoutés au contexte | Répondre à partir de données actualisées |

| Fine-tuning | Modification partielle ou complète des poids du modèle | Apprendre un comportement ou un format durable |

Le RAG est généralement préférable pour intégrer une base documentaire qui change régulièrement. Un fine-tuning ne permet pas de mettre à jour simplement des informations comme des tarifs, une réglementation ou un catalogue produit.

Le fine-tuning devient pertinent lorsque le problème concerne davantage le comportement du modèle que l’accès à l’information. Il convient notamment pour améliorer la régularité du style, la classification, l’extraction ou le respect d’un format.

Pourquoi fine-tuner un LLM ?

Les principaux bénéfices

Un modèle affiné peut offrir plusieurs avantages :

meilleure précision sur une tâche spécialisée ;
réponses plus homogènes ;
réduction de la longueur des prompts ;
diminution des instructions répétées ;
meilleur respect d’un format JSON ou d’une structure définie ;
adaptation à un vocabulaire métier ;
possibilité d’utiliser un modèle plus petit et moins coûteux en production.

Un modèle de 7 milliards de paramètres bien spécialisé peut parfois être plus efficace sur une tâche donnée qu’un modèle généraliste beaucoup plus grand.

Les limites à connaître

Le fine-tuning ne corrige pas tous les problèmes. Il peut aussi :

provoquer un surapprentissage ;
réduire les capacités générales du modèle ;
introduire des biais présents dans les données ;
renforcer des erreurs factuelles ;
augmenter le coût de maintenance ;
rendre les résultats difficiles à interpréter ;
mémoriser des données sensibles si le corpus est mal préparé.

Un modèle affiné n’est pas automatiquement plus fiable. La qualité des données, l’évaluation et la surveillance restent indispensables.

Quand faut-il fine-tuner un modèle ?

Le fine-tuning est généralement adapté dans les situations suivantes :

Les mêmes instructions sont répétées dans presque chaque requête.
Le modèle doit produire une sortie selon une structure très précise.
La tâche est stable et suffisamment fréquente pour justifier un entraînement.
Un ensemble d’exemples fiables est disponible.
Le style ou le comportement attendu ne peut pas être obtenu avec un prompt bien conçu.
La latence et le coût des longs contextes posent problème.

Le fine-tuning est moins adapté lorsque :

les données changent quotidiennement ;
la tâche nécessite des connaissances absentes du modèle ;
le jeu de données contient peu d’exemples ;
le problème provient d’un mauvais prompt ;
une recherche documentaire RAG répond déjà au besoin ;
les critères de réussite ne sont pas mesurables.

Une bonne démarche consiste à établir un baseline avec le modèle original, un prompt optimisé et, si nécessaire, un système RAG. Le fine-tuning doit être comparé à ces solutions sur un jeu de test indépendant.

Les différents types de fine-tuning

Supervised Fine-Tuning, ou SFT

Le Supervised Fine-Tuning consiste à entraîner le modèle sur des exemples composés d’une entrée et d’une réponse attendue.

Exemple conceptuel :

instruction : « Résume ce ticket client en trois points »
entrée : contenu du ticket
réponse cible : résumé structuré en trois points

Le SFT est la méthode la plus courante pour adapter le style, le format et le comportement d’un modèle.

Fine-tuning complet

Le fine-tuning complet modifie tous les poids du modèle. Cette méthode offre une grande capacité d’adaptation, mais elle exige :

beaucoup de mémoire GPU ;
davantage de données ;
des temps d’entraînement plus longs ;
une infrastructure distribuée pour les grands modèles ;
une gestion plus complexe des versions.

Elle est surtout utilisée par les organisations disposant d’une infrastructure importante ou pour des adaptations très profondes.

LoRA et QLoRA

LoRA, pour Low-Rank Adaptation, gèle le modèle principal et entraîne de petits modules supplémentaires appelés adaptateurs. Le nombre de paramètres mis à jour est donc fortement réduit.

QLoRA combine LoRA avec une quantification du modèle de base, souvent en 4 bits. Cette technique diminue la mémoire nécessaire tout en conservant de bonnes performances sur de nombreuses tâches.

Avantages de LoRA et QLoRA :

coût GPU réduit ;
entraînement plus rapide ;
stockage d’un petit fichier d’adaptation ;
possibilité de conserver plusieurs adaptateurs pour différents métiers ;
déploiement plus flexible.

Pour la plupart des projets expérimentaux et de nombreux projets professionnels, QLoRA constitue un point de départ pratique.

DPO et entraînement par préférences

Le Direct Preference Optimization, ou DPO, entraîne un modèle à partir de préférences entre deux réponses : une réponse préférée et une réponse rejetée.

Cette méthode peut améliorer :

la qualité rédactionnelle ;
le respect des consignes ;
le ton des réponses ;
la préférence pour une réponse plus utile ou plus sûre.

Le DPO nécessite toutefois un jeu de données adapté et une méthode d’évaluation rigoureuse. Il ne remplace pas forcément un SFT : un entraînement supervisé est souvent utilisé avant l’optimisation par préférences.

Étapes d’un fine-tuning de LLM

1. Définir l’objectif métier

L’objectif doit être formulé de manière mesurable. « Améliorer le modèle » est trop vague.

Exemples d’objectifs exploitables :

atteindre 90 % de précision sur une classification à six catégories ;
produire une réponse JSON valide dans 98 % des cas ;
réduire de 30 % la longueur moyenne des réponses ;
respecter un style éditorial défini ;
extraire correctement 10 champs depuis une facture.

Il faut également déterminer les cas d’échec acceptables et les contraintes de latence, de confidentialité et de coût.

2. Choisir le modèle de base

Le choix dépend de plusieurs critères :

taille du modèle ;
qualité dans la langue cible ;
licence commerciale ;
longueur de contexte ;
compatibilité avec les outils ;
capacité de déploiement ;
coût d’inférence ;
performances sur la tâche visée.

Les modèles open weight permettent un contrôle plus important, tandis que les API commerciales simplifient l’infrastructure. La licence doit être examinée avant toute utilisation professionnelle, notamment pour les restrictions commerciales, la redistribution et les données d’entraînement.

3. Constituer les données d’entraînement

La qualité du corpus est souvent plus importante que son volume brut. Un ensemble de données plus petit, mais cohérent et bien annoté, peut surpasser un corpus volumineux et bruité.

Les données peuvent provenir :

de conversations validées par des experts ;
de tickets de support anonymisés ;
de documents annotés ;
de sorties corrigées manuellement ;
de données synthétiques contrôlées ;
de bases de classification existantes.

Chaque exemple doit représenter un cas réellement rencontré en production.

4. Nettoyer et anonymiser le corpus

Avant l’entraînement, plusieurs contrôles sont nécessaires :

supprimer les doublons ;
corriger les erreurs de format ;
éliminer les exemples contradictoires ;
retirer les données personnelles ;
vérifier les droits d’utilisation ;
filtrer les réponses dangereuses ou incorrectes ;
uniformiser les unités, les dates et les libellés ;
contrôler la longueur des exemples.

Les données personnelles doivent être traitées conformément au RGPD. Les noms, adresses, numéros de téléphone, identifiants clients et informations médicales peuvent être remplacés par des valeurs génériques.

5. Formater les exemples

Les modèles conversationnels attendent généralement un format composé de messages avec des rôles :

`system` ;
`user` ;
`assistant`.

Le format exact dépend du modèle et de son chat template. Une erreur de template peut dégrader fortement les résultats, même avec de bonnes données.

Le corpus doit aussi définir clairement :

les tokens de début et de fin ;
la longueur maximale ;
les champs à masquer dans la loss ;
la présence éventuelle d’une instruction système ;
le format de sortie attendu.

Pour une tâche structurée, les exemples doivent refléter exactement le format utilisé en production.

6. Séparer entraînement, validation et test

Une séparation courante consiste à prévoir :

80 % pour l’entraînement ;
10 % pour la validation ;
10 % pour le test.

Ces proportions peuvent varier selon la taille du corpus. Le jeu de test doit rester isolé jusqu’à l’évaluation finale.

Il faut éviter qu’un même document, client ou texte apparaisse dans plusieurs ensembles. Sinon, les performances mesurées seront artificiellement élevées.

7. Établir une référence avant entraînement

Le modèle de base doit être testé sur le même jeu de test avant le fine-tuning. Cette étape permet de mesurer le gain réel.

Les indicateurs peuvent inclure :

exactitude ou accuracy ;
précision, rappel et F1 ;
taux de sortie JSON valide ;
taux d’hallucination ;
score de similarité ;
évaluation humaine ;
temps de réponse ;
coût par requête.

Une comparaison qualitative avec des exemples représentatifs complète les métriques automatiques.

8. Configurer l’entraînement

Les paramètres importants sont les suivants :

taux d’apprentissage ;
nombre d’époques ;
taille de batch ;
accumulation de gradients ;
longueur maximale des séquences ;
taux de dropout ;
rang LoRA ;
poids de régularisation ;
précision numérique ;
stratégie d’évaluation ;
fréquence de sauvegarde.

Pour un premier essai, il est préférable de modifier peu de paramètres à la fois. Un taux d’apprentissage trop élevé peut détériorer les capacités générales du modèle.

Le nombre d’époques dépend du corpus. Un petit jeu de données peut nécessiter seulement une à trois époques, tandis qu’un corpus plus vaste demande une analyse de la courbe de validation. Une perte d’entraînement qui baisse alors que la validation se dégrade indique souvent un surapprentissage.

9. Évaluer le modèle

L’évaluation doit combiner mesures automatiques et contrôle humain.

Les tests doivent couvrir :

les cas fréquents ;
les cas difficiles ;
les formulations imprévues ;
les entrées très longues ;
les demandes ambiguës ;
les tentatives de contournement ;
les sujets sensibles ;
les langues ou variantes régionales concernées.

Il est utile de créer un jeu de régression contenant les erreurs déjà corrigées. Ce jeu permet de vérifier qu’une nouvelle version ne dégrade pas une fonctionnalité existante.

10. Déployer progressivement

Le modèle affiné peut être déployé :

derrière une API interne ;
dans un serveur de génération comme vLLM ou TGI ;
sur une plateforme cloud ;
dans une application locale ;
sur un équipement disposant de ressources limitées.

Un déploiement progressif permet de comparer le modèle affiné au modèle de base. Le suivi doit mesurer les erreurs, les retours utilisateurs, la latence, l’utilisation mémoire et le coût réel.

Quels outils utiliser pour fine-tuner un LLM ?

Écosystème Hugging Face

L’écosystème Hugging Face est une référence pour les modèles open weight.

Les principaux composants sont :

Transformers : chargement et entraînement des modèles ;
Datasets : préparation des jeux de données ;
PEFT : LoRA, QLoRA et autres méthodes à paramètres efficaces ;
TRL : SFT, DPO et entraînement par préférences ;
Accelerate : gestion du calcul sur plusieurs GPU ;
Evaluate : calcul de métriques.

Cette combinaison convient aux projets nécessitant un contrôle détaillé.

Unsloth

Unsloth simplifie et accélère certains entraînements LoRA et QLoRA. L’outil est particulièrement intéressant pour les expérimentations sur un GPU unique, à condition de vérifier la compatibilité avec le modèle et l’environnement utilisé.

Axolotl et LLaMA-Factory

Axolotl et LLaMA-Factory proposent des configurations prêtes à l’emploi pour entraîner différents modèles conversationnels. Ils réduisent la quantité de code à écrire et facilitent les essais avec plusieurs méthodes d’adaptation.

torchtune

torchtune, développé autour de PyTorch, fournit des recettes d’entraînement pour plusieurs architectures. Il s’adresse davantage aux utilisateurs souhaitant garder une maîtrise technique de la configuration.

Plateformes cloud et API

Les fournisseurs cloud proposent des GPU à l’heure ou des services managés. Les API de certains fournisseurs permettent aussi de fine-tuner des modèles propriétaires sans gérer directement les GPU.

Le choix dépend de quatre facteurs :

degré de contrôle souhaité ;
sensibilité des données ;
volume d’entraînement ;
besoin de déployer le modèle ailleurs.

Une API est souvent plus simple pour un premier prototype. Un modèle open weight est généralement préférable lorsqu’une maîtrise complète des données, du modèle et de l’infrastructure est nécessaire.

Combien coûte le fine-tuning d’un LLM ?

Le coût total ne se limite pas à la facture GPU. Il faut inclure :

la préparation et l’annotation des données ;
le stockage ;
le calcul d’entraînement ;
les évaluations ;
le déploiement ;
l’inférence ;
la maintenance.

Coût d’un fine-tuning via API

Les fournisseurs facturent généralement l’entraînement en fonction du nombre de tokens traités, parfois multiplié par le nombre d’époques.

La formule indicative est :

Coût d’entraînement = tokens du corpus × nombre d’époques × tarif par million de tokens

Exemple :

corpus de 12 millions de tokens ;
3 époques ;
36 millions de tokens traités ;
tarif hypothétique de 5 € par million de tokens.

Le coût d’entraînement serait alors d’environ 180 €, hors validation, stockage et utilisation du modèle après entraînement.

Les tarifs des API évoluent régulièrement. La page tarifaire officielle du fournisseur doit être consultée avant le lancement, en distinguant le coût de l’entraînement du prix des tokens d’entrée et de sortie en production.

Coût d’un entraînement sur GPU

Les fourchettes suivantes sont indicatives et varient selon le fournisseur, la région, le type d’instance et l’utilisation d’instances préemptibles :

| Configuration | Ordre de grandeur du coût GPU |

|---|---:|

| GPU grand public ou cloud d’entrée de gamme | environ 0,30 à 1,50 € par heure |

| GPU professionnel de type A10, L4 ou équivalent | environ 0,80 à 3 € par heure |

| A100 ou GPU comparable | environ 2 à 8 € par heure |

| H100 ou infrastructure haut de gamme | plusieurs euros à plus de 10 € par heure |

Un fine-tuning QLoRA d’un modèle de 7 milliards de paramètres peut prendre quelques heures sur un GPU adapté. Un modèle de 13 milliards de paramètres ou un corpus volumineux peut demander une durée nettement supérieure. Le fine-tuning complet d’un grand modèle implique souvent plusieurs GPU et des coûts qui peuvent atteindre plusieurs centaines, voire plusieurs milliers d’euros.

Mémoire GPU nécessaire

À titre indicatif :

un modèle de 7 milliards de paramètres en QLoRA peut fonctionner sur une carte de 16 à 24 Go selon la longueur des séquences ;
un entraînement LoRA en précision supérieure peut nécessiter 24 à 48 Go ;
un modèle de 13 milliards de paramètres demande généralement davantage de mémoire ;
le fine-tuning complet nécessite beaucoup plus de mémoire à cause des gradients et des états de l’optimiseur.

La longueur des séquences et la taille des batches peuvent multiplier la consommation mémoire. Le gradient checkpointing, la quantification et l’accumulation de gradients permettent de réduire les besoins.

Le coût des données est souvent dominant

L’annotation humaine peut dépasser le coût du calcul. Un corpus de 20 000 exemples annotés par des experts représente un investissement important, surtout dans les secteurs juridique, médical ou financier.

Il faut également prévoir :

la relecture ;
la validation par un spécialiste ;
le nettoyage ;
l’anonymisation ;
les tests ;
la maintenance du corpus.

Un modèle entraîné sur des données médiocres ne devient pas fiable simplement parce que l’entraînement a été coûteux.

Bonnes pratiques pour réussir son fine-tuning

Commencer par un petit corpus de haute qualité.
Comparer systématiquement le modèle affiné au modèle de base.
Utiliser LoRA ou QLoRA avant d’envisager un fine-tuning complet.
Conserver un jeu de test indépendant.
Contrôler les licences et les données personnelles.
Ne pas mélanger des réponses correctes et incorrectes sans étiquetage clair.
Utiliser le même template de conversation à l’entraînement et en production.
Surveiller le surapprentissage.
Tester les prompts adverses et les données inattendues.
Versionner le modèle, le corpus, les paramètres et les résultats.
Mesurer le coût d’inférence après déploiement.
Prévoir une procédure de retour au modèle précédent.

Erreurs fréquentes à éviter

Utiliser le fine-tuning pour mémoriser une base documentaire

Le fine-tuning n’est pas une base de données fiable. Pour des informations fréquemment mises à jour, un système RAG avec citations et contrôle des sources est généralement plus adapté.

Entraîner sur des exemples artificiels non contrôlés

Les données synthétiques peuvent accélérer la constitution d’un corpus, mais elles doivent être vérifiées. Les erreurs générées automatiquement risquent d’être apprises et répétées par le modèle.

Optimiser uniquement la loss

Une baisse de la loss ne garantit pas de meilleures réponses en production. Les métriques métier, les évaluations humaines et les tests de robustesse sont indispensables.

Ignorer la licence du modèle

Un modèle disponible publiquement n’est pas nécessairement libre pour tous les usages commerciaux. La licence, les conditions d’utilisation et les éventuelles restrictions doivent être examinées avant le déploiement.

Conclusion : les points clés à retenir

Le fine-tuning d’un LLM permet d’adapter un modèle à une tâche, un style ou un domaine précis, mais il ne remplace ni une base documentaire ni une évaluation rigoureuse.

Les points essentiels sont les suivants :

définir un objectif mesurable avant l’entraînement ;
comparer le fine-tuning au prompting et au RAG ;
privilégier des données fiables, cohérentes et anonymisées ;
commencer par LoRA ou QLoRA pour limiter les coûts ;
utiliser un format compatible avec le chat template du modèle ;
séparer soigneusement entraînement, validation et test ;
mesurer les performances avant et après l’affinage ;
intégrer les coûts de données, de GPU, d’inférence et de maintenance ;
contrôler la sécurité, les biais, la confidentialité et la licence ;
déployer progressivement avec un suivi des erreurs et des coûts.

Pour la majorité des projets, le meilleur point de départ est un petit modèle open weight, un corpus spécialisé de qualité, un entraînement QLoRA et une évaluation comparative face à un modèle généraliste correctement configuré.