Fine-tuning : adapter un modèle à vos données avec LoRA et QLoRA

Le fine-tuning est l'étape suivante quand le prompt engineering et le RAG ne suffisent plus : vous adaptez les poids d'un modèle à vos données, et le modèle apprend votre format, votre ton et vos règles. Pas besoin de data center : avec LoRA et QLoRA, un modèle 7B s'adapte sur un seul GPU grand public, et avec le bon outil, vous partez avec un fichier de configuration, pas du code à écrire de zéro.

Quand c'est vraiment nécessaire (et quand ce n'est pas le cas)

Première règle : ne faites pas de fine-tuning pour la mémoire. Si vous voulez que le modèle connaisse vos documents, la bonne réponse est le RAG : ajoutez un index de documents et le modèle les consulte à chaque réponse. Le fine-tuning modifie en revanche le comportement de base du modèle : le format de sortie, le registre de langue, le style des réponses, les conventions de votre domaine.

Un bon test : si vous pouvez expliquer au modèle ce que vous voulez avec un prompt (ou un exemple dans le prompt), arrêtez-vous là. Le prompt est gratuit, réversible et se modifie en une minute. En revanche, si vous répétez la même instruction dans chaque requête depuis des mois, le fine-tuning vous fait gagner du temps à chaque conversation.

Un troisième cas, souvent sous-estimé : réduire les tokens de contexte. Un modèle adapté à votre format de sortie répond avec des messages plus courts, car il a appris le schéma une seule fois au lieu de le relire à chaque prompt.

Comment ça fonctionne : LoRA et QLoRA en mots simples

Un modèle 7B a environ 7 milliards de paramètres. Réentraîner l'ensemble sur vos données coûte des dizaines de Go de VRAM et des heures de calcul. LoRA (Low-Rank Adaptation), la technique décrite dans le paper de 2021, contourne le problème : les poids d'origine restent gelés, et à côté de chaque couche importante on insère une petite matrice supplémentaire (l'adaptateur) qui est celle qui s'entraîne. À la fin, le résultat est un fichier de quelques Mo, pas un modèle de plusieurs gigaoctets.

Les chiffres du paper : avec une matrice de rang 8, le paramètre entraînable descend jusqu'à un millième de celui du modèle complet, sans perte mesurable de qualité. Et le rang (r) est le principal bouton de réglage : r=8-16 pour la plupart des cas, des valeurs plus hautes seulement quand les données l'exigent.

QLoRA (2023) pousse plus loin : il quantise le modèle de base à 4 bits (format NF4) avant l'entraînement, de sorte qu'un modèle de 65B tienne dans une seule carte graphique de 48 Go. En pratique, la frontière entre « modèles adaptatifs » et « modèles inaccessibles » s'est déplacée d'une génération de matériel.

L'avantage pratique le plus important : l'adaptateur est un fichier séparé. Vous pouvez garder trois adaptateurs (ton formel, sortie JSON, synthèse courte) sur le même modèle de base et charger celui qu'il faut. Même poids de base, trois comportements.

Préparer les données : 90 % du travail

L'outil compte, les données comptent davantage. Trois conseils qui font la différence :

Format. Le format le plus répandu et supporté par tous les outils est le fichier JSONL : une ligne par exemple, avec les champs de conversation. Pour LLaMA-Factory, le format alpaca (prompt, instruction, sortie) est celui que vous utiliserez dans 90 % des cas.

Quantité. Il ne faut pas des milliers d'exemples : pour un format de sortie bien défini, 100-500 exemples de qualité battent 10 000 générés à la volée. La qualité de l'étiquette (la réponse que vous enseignez) compte plus que la quantité.

Cohérence. Si vous voulez une sortie en JSON, tous les exemples doivent être du JSON valide. Si vous mélangez trois formats, le modèle apprend la moyenne, c'est-à-dire le désordre.

Une erreur classique : s'entraîner avec des données que le modèle sait déjà faire. Si le modèle répond déjà bien sans adaptateur, vous perdez du temps et de la VRAM pour un gain nul. Faites d'abord un test avec le prompt et regardez où il échoue vraiment.

Outils locaux pour le fine-tuning

LLaMA-Factory est le standard de facto pour le fine-tuning en local : un seul framework pour 100+ modèles (Qwen, Llama, Mistral, Gemma), des méthodes du SFT complet à LoRA/QLoRA et DPO, une interface web intégrée (WebUI) et un démarrage avec un fichier YAML. C'est le projet de fine-tuning le plus utilisé par la communauté, avec plus de 75 000 étoiles sur GitHub (repo).

Un exemple concret : pour adapter Qwen sur une RTX 4090 avec QLoRA, le fichier de configuration contient le modèle de base, le dataset (votre JSONL, enregistré dans dataset_info.json), la méthode LoRA avec le rang et les couches à adapter, et les paramètres d'entraînement. Puis une commande, et la WebUI vous montre la perte et la courbe d'entraînement.

Unsloth est l'alternative qui mise sur la vitesse : des optimisations qui réduisent l'usage de mémoire et augmentent la vitesse d'entraînement (le projet déclare jusqu'à 2x de vitesse et la mémoire divisée par deux par rapport aux méthodes standard), avec support des GPU NVIDIA et d'Apple Silicon (repo). Si votre GPU est à la limite, c'est souvent la voie la plus courte.

MLX est la voie Apple Silicon : le framework d'apprentissage automatique d'Apple pour la puce, avec la bibliothèque mlx-lm qui prend en charge l'entraînement et le fine-tuning de LLM directement sur Mac, avec la mémoire unifiée comme atout (repo). Sur M3/M4/M5 de 32-64 Go, un fine-tuning LoRA d'un modèle 7B est une soirée, pas un projet.

Combien de matériel faut-il ?

Règle pratique pour un modèle 7B :

• QLoRA (4 bits) : 8-12 Go de VRAM. Une RTX 3060 12Go ou un Mac avec 16-32 Go passe.
• LoRA pleine précision : 16-24 Go. RTX 4090 ou RTX 3090.
• Modèle 13-14B en QLoRA : 16-24 Go.
• Modèle 70B en QLoRA : 48 Go+ (RTX A100 48Go, ou Mac de 128+ Go).

Le contexte d'entraînement pèse plus qu'on ne le pense : 2048 tokens de contexte en plus multiplient presque par deux l'usage de mémoire. Partez avec 1024 si vos exemples sont courts.

Les limites pratiques

Soyez honnête sur ce que le fine-tuning ne peut pas faire :

1. Il n'ajoute pas de connaissances factuelles stables. Si vous enseignez un fait, le modèle l'« apprend » de manière fragile : il le dit aujourd'hui, l'oublie ou le contredit dans dix exemples. Pour la connaissance, RAG. Pour le comportement, fine-tuning.
2. Il oublie une partie du modèle de base. Le phénomène s'appelle l'oubli catastrophique (catastrophic forgetting) : plus vous entraînez, plus le modèle s'éloigne du comportement général. Les données de « remplissage » (exemples génériques mélangés aux vôtres) atténuent le phénomène.
3. Il faut une métrique. Sans un set de test avec des réponses correctes, vous ne savez pas si vous améliorez ou dégradez. Gardez 50-100 exemples de côté que vous n'utilisez pas pour l'entraînement et comparez les réponses avant/après.
4. Le modèle de base change, l'adaptateur non. Si vous passez d'une version du modèle à la suivante, l'adaptateur doit être refait. Prévoyez une heure de vérification à chaque mise à jour.

En résumé

• Prompt/RAG d'abord, fine-tuning quand le comportement répété ne tient pas.
• 100-500 exemples de qualité, format cohérent, étiquettes soignées.
• LLaMA-Factory pour démarrer, Unsloth si la VRAM est juste, MLX sur Mac.
• QLoRA est la porte d'entrée : 4 bits, adaptateur de quelques Mo, un GPU grand public.
• Mesurez toujours avant/après, et rappelez-vous : la connaissance va dans le RAG, le comportement dans le fine-tuning.

Références

• LoRA: Low-Rank Adaptation of Large Language Models (arXiv 2106.09685) — le paper original qui décrit la technique.
• QLoRA: Efficient Finetuning of Quantized LLMs (arXiv 2305.14314) — quantification à 4 bits + LoRA, fine-tuning de 65B sur une carte graphique.
• LLaMA-Factory (GitHub) — framework de fine-tuning unifié, 100+ modèles.
• Unsloth (GitHub) — fine-tuning optimisé, NVIDIA et Apple Silicon.
• MLX (GitHub) — framework Apple Silicon avec mlx-lm pour le fine-tuning de LLM.

Article généré par IA