Le fine-tuning local fait fantasmer : on imagine entraîner « son » modèle, lui injecter sa base documentaire, et obtenir un assistant maison qui connaît tout par cœur. La réalité 2026 est plus nuancée, et beaucoup plus accessible qu'on ne le croit côté matériel. Avec QLoRA et Unsloth, fine-tuner un modèle 7B tient sur un RTX 3060 12 Go. Mais avant de lancer le moindre entraînement, il faut comprendre ce que le fine-tuning sait faire — et surtout ce qu'il ne sait pas faire.
Cet article donne les chiffres réels : VRAM par taille de modèle, taille de dataset, frameworks, et le verdict honnête sur la question qui revient toujours : fine-tuning ou RAG ?
LoRA et QLoRA : pourquoi ça tient sur une carte gamer
Un fine-tuning « full » (tous les paramètres) d'un modèle 7B demande de loger en VRAM les poids, les gradients ET les états de l'optimiseur simultanément : 60 à 70 Go minimum. Hors de portée d'un GPU grand public.
LoRA (Low-Rank Adaptation) change la donne : on gèle le modèle de base et on n'entraîne que de petites matrices « adaptateurs » de bas rang greffées sur les couches d'attention. On passe de milliards de paramètres entraînables à quelques millions.
QLoRA pousse plus loin : le modèle de base est chargé en 4-bit NormalFloat (NF4), ce qui réduit la mémoire des poids d'environ 75 %, pendant que les adaptateurs LoRA s'entraînent en BF16. Seuls les gradients des adaptateurs et les états de l'optimiseur sont stockés. Le coût en qualité ? Dans la plupart des benchmarks, 1 à 2 % d'écart seulement face au full fine-tuning — négligeable pour une division par 10 du besoin matériel.
Combien de VRAM, concrètement ?
Voici le découpage mémoire réel d'un QLoRA sur un modèle 7B :
- Poids du modèle (NF4) : ~3,5 Go
- Adaptateurs LoRA (FP16) : ~0,1 Go
- États de l'optimiseur : ~0,4 Go
- Gradients + activations : ~4,0 Go
- Total : ~8 Go
Par taille de modèle, les recommandations 2026 sont les suivantes :
- 7B en QLoRA : 8 à 12 Go de VRAM. Un RTX 3060 12 Go suffit. Un RTX 4080 16 Go est confortable.
- 13B en QLoRA : passe sans drame sur un GPU 24 Go (RTX 3090 ou 4090).
- Full fine-tuning 7B : 60-70 Go — oubliez sur du grand public.
Attention : ces chiffres supposent que le GPU ne fait que ça. Si vous faites tourner de l'inférence en parallèle, ajoutez le budget correspondant. Prévoyez aussi 32 Go de RAM système pour un 7B, 64 Go pour 13B+, et un SSD NVMe pour le chargement des données. Pour bien dimensionner votre machine, notre guide de calcul VRAM/RAM pour LLM local détaille la méthode.
Unsloth vs Axolotl : lequel choisir ?
Deux frameworks dominent le fine-tuning local. Le choix n'est pas une question de goût.
Unsloth — le roi du mono-GPU
Unsloth réécrit les étapes de backpropagation de PyTorch en kernels Triton optimisés à la main. Résultat sur un benchmark 8B identique : 3,2 heures contre 5,8 heures pour Axolotl, soit ~2x plus rapide, avec jusqu'à 70-80 % de VRAM en moins par rapport à FlashAttention 2 — sans dégradation mesurable de la précision. Compatibilité large, de la GTX 1070 à la H100. Support de Llama 4, Qwen 3, DeepSeek-R1, Phi-4.
Limite décisive : Unsloth ne gère pas le multi-GPU.
Axolotl — la production et le multi-GPU
Axolotl s'appuie sur une config YAML versionnable, un excellent préprocessing de données et le support multi-GPU. Il est plus lent (couches d'abstraction au-dessus de Hugging Face Transformers) mais reproductible et fiable en pipeline. Subtilité : Axolotl peut utiliser Unsloth comme backend pour récupérer la vitesse.
Le verdict :
- Solo, mono-GPU, VRAM limitée → Unsloth, sans hésiter.
- Cluster, pipeline de production, alignement DPO/RLHF → Axolotl.
- Workflow hybride : Unsloth pour le SFT (compute-bound), Axolotl pour le DPO (qui double la VRAM avec un modèle de référence).
Le dataset : là où 90 % des fine-tunings échouent
La majorité des échecs ne sont pas des problèmes de matériel mais de données. LoRA, ayant peu de paramètres, est extrêmement sensible au bruit et aux incohérences. La règle d'or : 500 exemples propres battent 5 000 exemples bruités.
Combien d'exemples selon la tâche ?
- Classification ou formatage simple : 500 à 1 000 exemples suffisent à voir une amélioration mesurable.
- Instruction-following complexe / nouveau domaine : 3 000 à 10 000 exemples de qualité.
- Au-delà de 10 000 : rendements décroissants, sauf domaine très large.
Côté format, deux standards : Alpaca (champs instruction / input / output, idéal pour le single-turn) et ShareGPT/ChatML (messages role / content, pour les assistants conversationnels multi-tours).
Deux pièges majeurs documentés : générer ses données avec un autre LLM revient souvent à apprendre à imiter ce LLM plutôt qu'à enseigner une vraie compétence ; et multiplier les epochs nuit — sur Alpaca, passer de 1 à 2 epochs a dégradé les performances.
Fine-tuning ou RAG ? Le verdict honnête
C'est LA question, et la recherche 2025-2026 est claire : RAG est devenu le standard pour injecter de la connaissance. Plusieurs études (notamment « Fine-Tuning or Retrieval? ») montrent un avantage significatif du RAG sur le fine-tuning pour les tâches factuelles et l'actualité.
Pourquoi ? La contrainte de bas rang de LoRA est faite pour la forme, pas pour les faits. Une analyse fine de l'instruction tuning montre que LoRA apprend surtout « l'initiation de réponse » et les tokens de style, en extrayant l'essentiel du contenu de la connaissance déjà présente dans le modèle de base. Injecter des faits médicaux ou statistiques se diffuse sur trop de dimensions pour tenir dans des updates de bas rang — d'où entraînement instable et sorties incomplètes. S'ajoutent le catastrophic forgetting et la reversal curse, que le RAG (apprentissage in-context) évite.
Quand fine-tuner gagne :
- Style, ton, persona : faire parler le modèle d'une certaine façon, adopter une charte de marque.
- Format de sortie strict : JSON propre, structure imposée, format d'API maison.
- Terminologie métier et déclencheurs de comportement.
- Réduire la longueur des prompts : le comportement est dans les poids, plus besoin de tout réexpliquer à chaque requête.
Quand RAG gagne :
- Connaissance factuelle, documents propriétaires, données qui changent.
- Besoin de traçabilité et de sources citables.
- Pas de réentraînement à chaque mise à jour du corpus.
La hiérarchie de décision pragmatique : 1) prompt engineering d'abord ; 2) RAG pour la connaissance ; 3) LoRA/QLoRA seulement quand il faut changer le comportement du modèle. Et rien n'interdit l'hybride : un modèle fine-tuné pour le style, branché sur un pipeline RAG pour les faits.
Choisir son modèle de base
Pour fine-tuner en local, partez d'un modèle 7B-8B sous licence permissive : Llama 3.1 8B, Mistral 7B ou Qwen 2.5 7B. La famille Mistral 3 sous Apache 2.0 est un excellent point de départ côté européen et licence. Pour voir ce qui est disponible aujourd'hui, notre tour d'horizon des nouveaux modèles LLM local 2026 fait le point. Une fois l'adaptateur entraîné, vous pouvez le fusionner et le servir via Ollama comme n'importe quel modèle local.
Attentes réalistes
Le fine-tuning local n'est ni magique ni inaccessible. Il est accessible matériellement (un 7B sur un GPU à moins de 400 €) mais exigeant côté données. Il excelle à modeler le comportement, le style et le format. Il échoue à mémoriser des faits de façon fiable — pour ça, le RAG reste roi. Le meilleur réflexe en 2026 : essayer le prompt, puis le RAG, et ne sortir LoRA que quand on veut réellement changer la personnalité du modèle, pas son encyclopédie.
Commentaires