Unsloth : fine-tuner des LLM open source rapidement sur du matériel modeste

Comment adapter un modèle de langage à ses données métier en quelques heures, avec LoRA et QLoRA, sans cluster GPU et l’intégrer dans sa stack open source existante.

Pourquoi fine-tuner un LLM ?

Ollama et vLLM permettent de servir des modèles open source comme Llama 3, Mistral ou Qwen en production. Mais un modèle généraliste ne connaît pas votre terminologie métier, vos formats de sortie, ni le ton attendu par vos utilisateurs. Le fine-tuning (ajustement fin) consiste à ré-entraîner partiellement un modèle sur vos propres données pour qu’il devienne spécialiste de votre domaine, sans repartir de zéro.

Les cas d’usage concrets sont nombreux : un LLM qui répond aux questions sur la documentation interne d’une collectivité, un modèle qui génère des fiches DCAT conformes à votre schéma de métadonnées, un assistant qui produit du JSON structuré selon votre API, ou encore un chatbot qui adopte le vocabulaire d’un secteur technique précis.

Unsloth : le fine-tuning accessible

Unsloth est une bibliothèque Python open source (licence Apache 2.0) qui accélère le fine-tuning de LLM d’un facteur 2 à 5x tout en réduisant la consommation mémoire GPU de 70 à 80 %. Concrètement, un fine-tuning qui nécessitait un GPU A100 80 Go devient réalisable sur un GPU grand public de 16 à 24 Go (RTX 4090, RTX 3090, ou même un T4 gratuit sur Google Colab).

Le projet repose sur des optimisations noyau (kernels Triton compilés manuellement) qui accélèrent les opérations critiques de l’entraînement : attention, normalisation RMS, cross-entropy, sans compromettre la précision numérique. Unsloth ne modifie pas l’architecture du modèle : il rend le processus d’entraînement plus efficace.

LoRA et QLoRA : adapter sans tout réécrire

Le fine-tuning complet d’un LLM de 7 milliards de paramètres exige des centaines de gigaoctets de mémoire. LoRA (Low-Rank Adaptation) contourne cette contrainte en gelant les poids originaux du modèle et en entraînant uniquement de petites matrices de rang faible injectées dans les couches d’attention. On n’entraîne ainsi que 0,1 à 1 % des paramètres, pour un résultat souvent comparable au fine-tuning complet.

QLoRA pousse l’optimisation plus loin en quantifiant le modèle de base en 4 bits (NF4) avant d’appliquer LoRA. Le modèle gelé occupe quatre fois moins de mémoire, et seuls les adaptateurs LoRA restent en précision complète. C’est cette combinaison : quantification 4 bits du modèle de base + adaptateurs LoRA en bf16 qu’Unsloth optimise et simplifie.

Préparer un jeu de données d’entraînement

La qualité du fine-tuning dépend directement de la qualité des données. Unsloth attend un jeu de données au format conversationnel (liste de messages avec rôles system/user/assistant) ou au format instruction/output. Quelques centaines d’exemples de haute qualité suffisent pour un fine-tuning efficace par LoRA, inutile de viser des millions de lignes.

Pour constituer ce jeu de données, plusieurs approches sont possibles : annoter manuellement des exemples représentatifs, utiliser un LLM plus puissant pour générer des paires question-réponse à partir de documents existants (distillation synthétique), ou extraire et reformater des données existantes avec Docling. Le jeu de données peut être stocké en JSON, CSV ou directement au format Hugging Face Datasets.

Workflow type avec Unsloth

Un fine-tuning typique avec Unsloth se déroule en cinq étapes :

1. Charger le modèle de base quantifié. Unsloth fournit des versions pré-quantifiées des modèles populaires (Llama 3.1, Mistral v0.3, Qwen 2.5, Phi-3, Gemma 2) prêtes à l’emploi. Un appel à FastLanguageModel.from_pretrained() charge le modèle en 4 bits avec les optimisations Unsloth activées.

2. Appliquer les adaptateurs LoRA. On spécifie le rang (r=16 ou r=32 typiquement), les couches cibles (q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj), et le facteur alpha. Unsloth optimise automatiquement les gradients pour ces couches.

3. Formater le jeu de données. Les données sont converties au format attendu par le modèle via un template de chat (ChatML, Llama-3, Mistral). Unsloth inclut des helpers pour les formats courants.

4. Lancer l’entraînement. Unsloth s’appuie sur le Trainer de Hugging Face (SFTTrainer de la bibliothèque TRL). On configure les hyperparamètres classiques : taux d’apprentissage (2e-4 typiquement), nombre d’époques (1 à 3), taille de batch, warmup. L’entraînement sur 1 000 exemples avec un modèle 7B prend environ 20 à 40 minutes sur un GPU 24 Go.

5. Exporter et déployer. Le modèle fine-tuné peut être exporté en plusieurs formats : adaptateurs LoRA seuls (quelques Mo), modèle fusionné en fp16, ou directement en GGUF pour Ollama. Cette dernière option permet de déployer immédiatement le modèle personnalisé dans la stack existante avec ollama create.

Intégration dans la stack existante

Un modèle fine-tuné avec Unsloth s’intègre naturellement dans l’écosystème déjà couvert sur ce site. L’export GGUF se charge directement dans Ollama ou vLLM pour le serving. LiteLLM peut router certaines requêtes vers le modèle spécialisé et d’autres vers un modèle généraliste. Langfuse permet de comparer les performances du modèle fine-tuné par rapport au modèle de base sur des métriques concrètes (qualité des réponses, respect du format, pertinence métier). Et n8n ou LangGraph orchestrent les workflows qui appellent le modèle adapté.

Pour évaluer objectivement le gain, une bonne pratique consiste à constituer un jeu de test séparé (50 à 100 exemples annotés) et à comparer les réponses du modèle de base et du modèle fine-tuné avec Langfuse. Les métriques à suivre dépendent du cas d’usage : respect du format JSON (mesurable avec Outlines), pertinence des réponses RAG (évaluable avec RAGAS), ou score humain sur un échantillon.

Limites et bonnes pratiques

Le fine-tuning n’est pas une solution universelle. Il est inutile si le prompting ou le RAG suffisent à obtenir le résultat souhaité : toujours tester ces approches d’abord. Il est contre-productif sur un jeu de données trop petit (moins de 50 exemples) ou de mauvaise qualité (réponses incohérentes, erreurs factuelles). Et il introduit un risque de surapprentissage (overfitting) : le modèle peut mémoriser les exemples au lieu de généraliser.

Quelques garde-fous essentiels : toujours séparer données d’entraînement et données de test, surveiller la loss de validation pendant l’entraînement, limiter le nombre d’époques (1 à 3 suffisent généralement), et versionner les adaptateurs LoRA comme du code (ils ne font que quelques Mo et se stockent facilement dans Git).

Ressources

Le dépôt GitHub d’Unsloth contient des notebooks Colab prêts à l’emploi pour chaque famille de modèles, permettant de tester le fine-tuning en quelques minutes sans infrastructure locale. La documentation couvre l’ensemble du workflow, de la préparation des données à l’export GGUF. Le wiki du projet détaille les hyperparamètres recommandés par taille de modèle et par type de tâche.