Accueil › Guides › Fine-Tuning

Fine-tuning de LLM : guide complet LoRA, QLoRA et bonnes pratiques

Le fine-tuning permet d’adapter un LLM pré-entraîné à votre domaine métier spécifique. Grâce à QLoRA, vous pouvez fine-tuner un modèle de 70 milliards de paramètres sur un seul GPU grand public (RTX 4090). Ce guide couvre les techniques, le hardware, les datasets et le déploiement.

Quand fine-tuner (et quand ne pas le faire)

Le fine-tuning n’est pas toujours nécessaire. Avant de vous lancer, évaluez ces trois approches par ordre de complexité croissante :

1. Prompt engineering d’abord : si votre tâche peut être résolue avec un bon prompt système et des exemples few-shot, pas besoin de fine-tuning. C’est la solution la plus rapide, la moins coûteuse, et la plus flexible. Testez toujours cette approche en premier.

2. RAG ensuite : si vous avez besoin que le modèle accède à des connaissances spécifiques (documentation interne, base de connaissances, FAQ), le RAG (Retrieval-Augmented Generation) injecte ces informations au moment de l’inférence sans modifier le modèle. C’est plus simple que le fine-tuning et ne nécessite aucun entraînement.

3. Fine-tuning quand c’est nécessaire : le fine-tuning est justifié quand vous devez changer fondamentalement le comportement du modèle : lui apprendre un format de sortie spécifique, un ton particulier, une terminologie métier, ou lui enseigner une tâche que le prompting seul ne résout pas. Exemples typiques : transformer un modèle généraliste en assistant juridique, en chatbot de support technique, ou en analyste financier spécialisé.

LoRA et QLoRA : le standard du fine-tuning

Le problème du fine-tuning classique

Fine-tuner un modèle de 7 milliards de paramètres de manière classique (full fine-tuning) nécessite de stocker en mémoire GPU les poids du modèle (14 Go en FP16), les gradients (14 Go) et les états de l’optimiseur AdamW (28 Go). Total : plus de 56 Go de VRAM, ce qui dépasse la capacité de tout GPU grand public. Pour un modèle de 70B, comptez plus de 500 Go.

LoRA : adapter sans tout modifier

LoRA (Low-Rank Adaptation) repose sur une observation fondamentale : les mises à jour des poids lors du fine-tuning ont un rang intrinsèque faible. Au lieu de modifier les 7 milliards de paramètres, LoRA ajoute deux petites matrices entraînables (A et B) à chaque couche ciblée. Seules ces matrices sont optimisées, le modèle original reste gelé.

Résultat : vous n’entraînez que ≈ 1% des paramètres. Un fine-tuning LoRA de Llama 7B nécessite seulement 2 à 4 Go de VRAM, contre 56 Go en full fine-tuning. Les adapters LoRA font environ 10 Mo, contre 14 Go pour le modèle complet. Le ratio coût/efficacité est imbattable.

QLoRA : encore moins de mémoire

QLoRA combine la quantification 4-bit du modèle de base avec l’entraînement LoRA. Le modèle est chargé en précision NormalFloat 4-bit (NF4), tandis que les adapters LoRA et les calculs restent en BF16/FP16. Résultat : un modèle de 70B tient sur un seul GPU de 24 Go (RTX 4090).

QLoRA introduit trois innovations : le NormalFloat 4-bit (NF4), un type de données optimisé pour les poids de réseaux de neurones distribués normalement ; la double quantification (quantification des constantes de quantification, économisant 0,5 bit par paramètre) ; et les optimiseurs paginés (swap CPU/GPU quand la VRAM est pleine).

En 2026, LoRA et QLoRA restent les techniques PEFT dominantes. Des variantes comme DoRA (Weight-Decomposed Low-Rank Adaptation) et rsLoRA apportent des améliorations incrémentales, mais LoRA/QLoRA demeurent le standard de facto.

Guide pratique pas à pas

Étape 1 : Choisir le modèle de base

Le modèle de base détermine le plafond de performance de votre fine-tuning. Recommandations en 2026 :

Étape 2 : Préparer le dataset

La qualité du dataset est le facteur le plus important du fine-tuning. Un petit dataset de haute qualité (500-2 000 exemples) produit de meilleurs résultats qu’un grand dataset bruyant (50 000 exemples médiocres).

Format instruction-tuning : chaque exemple est un couple (instruction, réponse attendue). Format standard :

{"instruction": "Résume ce contrat de bail en 3 points clés", 
 "input": "[texte du contrat]", 
 "output": "1. Durée : bail de 3 ans... 2. Loyer : 1200€/mois... 3. Clause..."}

Règles pour un bon dataset : diversité des exemples (couvrez tous les cas d’usage attendus), cohérence du format de sortie (le modèle apprend le pattern), vérification humaine de chaque exemple (erreurs dans le dataset = erreurs dans le modèle), et équilibre des catégories (pas 90% d’un type et 10% d’un autre).

Génération de données synthétiques : utilisez un modèle puissant (Claude Opus 4.6, GPT-5.4) pour générer des exemples d’entraînement, puis faites valider par un humain. C’est la méthode la plus rapide pour constituer un dataset de qualité. Mistral Forge propose ce service de data pipeline pour les entreprises.

Étape 3 : Configurer l’entraînement

Les hyperparamètres recommandés pour commencer (QLoRA) :

# Configuration LoRA
r = 16              # Rang (16 = bon compromis, augmenter si nécessaire)
lora_alpha = 32     # Alpha (typiquement 2× le rang)
lora_dropout = 0.05 # Dropout (régularisation)
target_modules = ["q_proj", "k_proj", "v_proj", "o_proj", 
                  "gate_proj", "up_proj", "down_proj"]  # Toutes les couches

# Configuration entraînement
learning_rate = 2e-4        # Point de départ recommandé
num_train_epochs = 1-3      # 1 epoch suffit souvent
per_device_batch_size = 4   # Ajuster selon VRAM
gradient_accumulation = 4   # Compense un petit batch size
max_seq_length = 2048       # Selon votre cas d'usage

Outils recommandés :

Unsloth : 2× plus rapide et 60% de mémoire en moins que l’implémentation Hugging Face standard. Compatible avec l’écosystème HF. C’est le choix par défaut en 2026 pour le fine-tuning local.

Hugging Face (transformers + peft + trl) : l’écosystème de référence. SFTTrainer simplifie le processus d’entraînement. Combiné avec Unsloth pour les optimisations.

Axolotl : framework de fine-tuning qui abstrait la configuration. Bon pour les utilisateurs qui veulent un setup rapide via des fichiers YAML.

Étape 4 : Entraîner

# Exemple simplifié avec Unsloth + Hugging Face
from unsloth import FastLanguageModel
from trl import SFTTrainer

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/llama-3.1-8b-bnb-4bit",
    max_seq_length=2048,
    load_in_4bit=True,  # QLoRA
)

model = FastLanguageModel.get_peft_model(model, r=16, lora_alpha=32)

trainer = SFTTrainer(
    model=model,
    train_dataset=dataset,
    max_seq_length=2048,
    # ... autres paramètres
)

trainer.train()

Surveillez la training loss et la validation loss. Si la validation loss remonte alors que la training loss continue de baisser, vous êtes en overfitting. Arrêtez l’entraînement ou réduisez le nombre d’epochs.

Étape 5 : Évaluer et déployer

Évaluation : testez le modèle fine-tuné sur des exemples non vus pendant l’entraînement. Comparez côte à côte avec le modèle de base pour mesurer l’amélioration. Utilisez des métriques quantitatives (ROUGE, exact match) et qualitatives (évaluation humaine de la pertinence et du format).

Merge et export : fusionnez les adapters LoRA avec le modèle de base, puis exportez au format GGUF pour l’inférence locale avec Ollama ou llama.cpp :

# Merger les adapters
model.merge_and_unload()

# Exporter en GGUF pour Ollama
model.save_pretrained_gguf("mon-modele", tokenizer, quantization_method="q4_k_m")

Votre modèle custom est maintenant utilisable dans Ollama comme n’importe quel autre modèle.

Hardware et coûts

Pour un premier fine-tuning, Google Colab gratuit (GPU T4) suffit pour un modèle 3-7B. C’est le meilleur moyen de tester sans investissement.

Cas d’usage concrets

Chatbot de support technique : fine-tunez un modèle 8B sur les conversations passées de votre support (tickets résolus, FAQ, documentation). Le chatbot résultant comprend la terminologie de votre produit, connaît les problèmes courants et leurs solutions, et répond dans le ton de votre marque. Résultat typique : 60 à 70% des tickets de niveau 1 résolus sans intervention humaine.

Assistant juridique : fine-tunez sur des arrêts de jurisprudence, des contrats-types et des analyses juridiques validées. Le modèle apprend la structure des raisonnements juridiques, la terminologie précise et les formats de documents attendus. Attention : le fine-tuning ne rend pas le modèle infaillible. La revue humaine reste obligatoire pour tout document juridique.

Analyse financière : entraînez le modèle sur des rapports d’analystes, des bilans financiers annotés et des recommandations structurées. Le modèle apprend à extraire les KPIs pertinents, à structurer les analyses et à formuler des recommandations dans le format attendu par votre équipe.

Génération de code spécialisé : fine-tunez un modèle de code sur votre base de code interne (conventions, patterns, framework propriétaire). L’assistant résultant génère du code conforme à vos standards sans configuration supplémentaire. C’est l’équivalent d’un .cursorrules intégré dans les poids du modèle.

Services de fine-tuning managés

Si vous ne voulez pas gérer le GPU et le code vous-même, plusieurs services proposent du fine-tuning managé :

OpenAI Fine-tuning : fine-tuning de GPT-4o et GPT-4o-mini via l’API. Interface simple, pas de GPU à gérer. Mais vous restez dépendant de l’écosystème OpenAI et ne pouvez pas exporter le modèle.

Mistral Fine-tuning / Forge : fine-tuning des modèles Mistral via l’API ou via Forge (modèles sur mesure). Les modèles restent hébergeables en souveraineté européenne. Forge va au-delà du fine-tuning avec la création de modèles complets sur données privées.

Together AI, Fireworks AI : plateformes de fine-tuning et d’hébergement de modèles custom. Prix compétitifs, support des principaux modèles open source.

Techniques avancées

DPO (Direct Preference Optimization) : après le fine-tuning supervisé (SFT), le DPO permet d’aligner le modèle sur les préférences humaines sans la complexité du RLHF. Vous fournissez des paires (réponse préférée, réponse rejetée) et le modèle apprend à privilégier les bonnes réponses. C’est devenu le standard pour l’alignement post-SFT en 2026, plus simple et plus stable que le RLHF classique.

Données synthétiques + distillation : utilisez un modèle puissant (Opus 4.6, GPT-5.4) pour générer des réponses de haute qualité sur votre domaine, puis fine-tunez un modèle plus petit sur ces données. Vous obtenez 80-90% de la performance du grand modèle pour une fraction du coût d’inférence. C’est la stratégie la plus rentable pour les déploiements en production.

Multi-task fine-tuning : entraînez le modèle sur plusieurs tâches simultanément (résumé + classification + extraction) plutôt que sur une seule. Le modèle généralise mieux et conserve davantage ses capacités de base. Structurez votre dataset avec des instructions variées qui couvrent tous les cas d’usage.

Evaluation as a loop : le fine-tuning n’est pas un one-shot. Entraînez, évaluez, identifiez les faiblesses, ajoutez des exemples ciblés dans le dataset, réentraînez. Les meilleurs modèles spécialisés sont le résultat de 3 à 5 itérations. Automatisez l’évaluation avec des métriques reproductibles et un pipeline CI/CD pour les modèles.

Les pièges courants

Dataset de mauvaise qualité : « garbage in, garbage out » s’applique à 200%. Chaque erreur dans vos données d’entraînement sera reproduite par le modèle. Investissez plus de temps dans la curation du dataset que dans le tuning des hyperparamètres.

Overfitting : avec un petit dataset (< 1 000 exemples), le modèle peut mémoriser les exemples au lieu d'apprendre le pattern. Symptôme : excellent sur les données d'entraînement, médiocre sur des exemples nouveaux. Solution : augmenter la diversité des données, ajouter du dropout, réduire le nombre d'epochs.

Catastrophic forgetting : le modèle perd ses capacités générales en se spécialisant trop. Solution : LoRA atténue naturellement ce problème (le modèle de base reste gelé), mais vérifiez que le modèle fine-tuné conserve ses capacités de base en testant sur des tâches générales.

Choisir un modèle de base inadapté : un modèle 3B ne sera pas magiquement transformé en expert juridique par le fine-tuning. Le modèle de base doit déjà avoir une bonne compréhension du langage et du domaine. Partez du plus grand modèle que votre hardware supporte.

Le fine-tuning ne crée pas de l’intelligence, il la spécialise. La qualité de vos données détermine le plafond. La technique (LoRA, QLoRA) détermine l’accessibilité.