Unsloth : fine-tuner un LLM sur une carte grand public

#La question à trancher avant d'installer quoi que ce soit

Oui, on peut fine-tuner un modèle de 7 ou 8 milliards de paramètres sur une carte grand public : la documentation d'Unsloth donne un minimum de 5 à 6 Go de VRAM en QLoRA 4 bits, donc une carte de 12 Go convient, avec de la marge pour le contexte et le lot. Unsloth réécrit les étapes lourdes du fine-tuning LoRA et QLoRA pour, selon l'éditeur, aller jusqu'à deux fois plus vite avec 70 % de VRAM en moins, chiffre qui vaut pour certains notebooks seulement. Le résultat s'exporte en GGUF pour tourner dans Ollama. Mais la vraie question précède l'installation : le fine-tuning change le comportement d'un modèle (ton, format, registre), pas ce qu'il sait à jour. Si vous voulez qu'il connaisse vos documents, construisez d'abord une recherche documentaire. Comptez aussi que la préparation du jeu de données prend plus de temps que l'entraînement.

Le fine-tuning change la manière dont un modèle se comporte. La recherche documentaire change ce qu'il sait au moment de répondre. Confondre les deux fait perdre des semaines.

• Fine-tuning ou RAG : l'arbre de décision détaillé
• LoRA et QLoRA : comment ça marche vraiment
• Un exemple complet de fine-tuning LoRA
• Évaluer si un RAG ferait mieux, avec des chiffres

#Ce qu'Unsloth change concrètement

La méthode n'est pas nouvelle : on gèle les poids du modèle et on n'entraîne que de fines matrices ajoutées à chaque poids, soit environ 1 % des paramètres selon le guide d'Unsloth. LoRA garde le modèle d'origine en 16 bits, QLoRA le quantifie en 4 bits, ce qui économise 75 % de mémoire. C'est l'approche standard, elle n'appartient pas à Unsloth.

Ce qu'apporte la bibliothèque, c'est l'implémentation, avec des noyaux de calcul réécrits pour les étapes lourdes. Le projet existe sous trois formes : Unsloth Desktop, une application native, Unsloth Studio, une interface web, et Unsloth Core, la version pilotée par code dont parle cet article. Il est publié sous double licence : Apache 2.0 pour le cœur, AGPL-3.0 pour certains composants optionnels comme l'interface Studio. Il revendique entraîner des modèles de langage, de diffusion, de synthèse vocale et d'embeddings deux fois plus vite avec 70 % de VRAM en moins, sans perte de précision. Sur les architectures à mélange d'experts (MoE), le gain publié grimpe encore : jusqu'à 12 fois plus rapide avec plus de 35 % de VRAM économisée sur certains modèles récents. Comme tous les chiffres d'éditeur, ils décrivent le meilleur cas : le README lui-même montre que le « deux fois, 70 % » ne vaut que pour certains notebooks.

#Quelle carte pour quel modèle

La documentation précise que ces chiffres sont des minima absolus : selon le modèle, il peut falloir davantage. Elle désigne la taille de lot trop élevée comme cause fréquente de mémoire saturée, à ramener à 1, 2 ou 3, et recommande une longueur de contexte de 2048 pour les premiers essais.

#Le jeu de données est le vrai travail

Un fine-tuning ne rate jamais à cause de la bibliothèque. Il rate à cause des données.

Format

Un jeu à deux colonnes, question et réponse, le plus souvent, dans la structure de conversation attendue par le modèle. Le guide recommande de partir d'un modèle Instruct : il accepte directement les gabarits de conversation (ChatML, ShareGPT) et demande moins de données qu'un modèle de base. La régularité compte plus que le volume.

Volume

Le guide d'Unsloth recommande au strict minimum 100 lignes, et plus de 1 000 lignes pour de meilleurs résultats. Le ton et le format se déplacent avec peu d'exemples ; un vrai comportement métier en demande davantage, cohérents entre eux.

Qualité

Le modèle imite ce qu'on lui montre, y compris les erreurs. Un défaut systématique dans les données devient un défaut systématique du modèle.

Jeu de contrôle

Des exemples que le modèle ne voit jamais à l'entraînement. Sans eux, impossible de distinguer l'apprentissage du simple par cœur.

Sans code

Unsloth Studio propose des Data Recipes, qui transforment des PDF, CSV ou DOCX en jeux de données par un flux visuel, avec un aperçu avant de lancer la construction complète.

#De l'adaptateur au modèle utilisable

Le parcours tient en trois temps : charger un modèle en 4 bits, l'entraîner avec l'un des notebooks officiels, puis l'exporter. Le premier bloc de code charge le modèle et ajoute les adaptateurs LoRA ; l'entraînement proprement dit est assuré par l'un des notebooks d'Unsloth, que le guide conseille de copier dans votre environnement local.

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="unsloth/Qwen3-8B-unsloth-bnb-4bit",  # quantification dynamique 4 bits d'Unsloth
    max_seq_length=2048,
    load_in_4bit=True,
)
model = FastLanguageModel.get_peft_model(model, r=16, lora_alpha=16)

Le suffixe du nom compte. Selon le guide, un modèle qui se termine par unsloth-bnb-4bit est une quantification dynamique 4 bits d'Unsloth : elle consomme un peu plus de VRAM qu'une quantification BitsAndBytes standard, mais offre une précision nettement supérieure. Un nom qui se termine seulement par bnb-4bit désigne la version standard. Le guide ajoute que l'entraînement et le service gagnent à utiliser la même précision : servir en 4 bits, c'est entraîner en 4 bits.

1. 01
   Entraîner

   Le résultat est un adaptateur LoRA, d'environ 100 Mo dans l'exemple d'Unsloth, pas un modèle complet.
2. 02
   Évaluer

   Contre le jeu de contrôle et contre le modèle d'origine. « Meilleur » se démontre, ne se suppose pas. Le guide note que les outils d'évaluation automatique peuvent mal refléter vos critères.
3. 03
   Fusionner ou garder à part

   L'adaptateur peut rester séparé et s'échanger, ou être fusionné dans les poids : model.save_pretrained_merged avec save_method="merged_16bit".
4. 04
   Exporter en GGUF et quantifier

   model.save_pretrained_gguf produit le fichier, avec q4_k_m, q8_0 ou f16 au choix. C'est ce qui rend le résultat exécutable par Ollama ou llama.cpp sur du matériel ordinaire.

model.save_pretrained_gguf(
    "mon-modele-q4", tokenizer, quantization_method="q4_k_m"
)
# puis, avec le Modelfile fourni : ollama create mon-modele -f Modelfile

• Importer un GGUF dans Ollama
• Choisir le niveau de quantification de votre modèle

#Les pièges classiques

Partir d'un modèle de base sans le savoir

Le guide recommande les modèles Instruct : ils acceptent les gabarits de conversation et demandent moins de données. Un modèle de base réclame un format différent (Alpaca, Vicuna) et davantage d'exemples.

Oublier le gabarit de conversation

Des exemples formatés autrement que ce qu'attend le modèle produisent un entraînement techniquement réussi et pratiquement inutile.

Mesurer sur les exemples d'entraînement

C'est l'erreur qui fait annoncer des résultats spectaculaires et livrer des modèles décevants.

Croire que ça remplacera la recherche documentaire

Ce qu'on apprend au modèle vieillit le jour où vos informations changent, et le modèle ne cite pas ses sources. Pour des faits qui évoluent, la recherche documentaire reste plus sûre.

Sous-estimer le nettoyage des exemples

Des doublons quasi identiques dans le jeu de données biaisent l'entraînement vers ces cas précis sans que rien ne l'indique dans les métriques suivies.

Changer plusieurs réglages à la fois

Modifier le taux d'apprentissage, le rang de l'adaptateur et la longueur de séquence dans le même essai empêche de savoir lequel a produit le changement observé.

#Cas d'usage concrets

Support client au ton constant

Un modèle ajusté sur des échanges réels répond avec la voix de la marque, sans consignes de style répétées dans chaque prompt.

Extraction dans un format strict

Fine-tuner sur des exemples entrée-sortie fixe le format de sortie plus fiablement qu'un prompt seul, utile avant d'envoyer le résultat à un système en aval.

Un point commun à ces cas : chacun se mesure. Avant de lancer un entraînement, formulez le critère de succès en une phrase vérifiable — « le format JSON est respecté dans au moins 95 % des sorties du jeu de contrôle », par exemple — plutôt qu'une impression générale de mieux. C'est ce critère, pas l'intuition, qui dira si le résultat justifie le temps investi.

• Source : dépôt officiel Unsloth (fonctions, matériel, double licence)
• Source : prérequis et VRAM minimale par taille de modèle
• Source : guide de fine-tuning d'Unsloth
• Source : export GGUF et problèmes de gabarit
• Source : chiffres de performance sur les modèles MoE

#Le coût réel, au-delà du prix de la carte

La carte graphique n'est qu'un poste parmi d'autres. Collecter et nettoyer des exemples cohérents, écrire un jeu de contrôle que le modèle ne verra jamais, puis comparer chaque version au modèle d'origine pèse souvent davantage que l'entraînement lui-même, que le guide d'Unsloth illustre avec un essai de 60 pas.

C'est pourquoi Unsloth, aussi rapide soit-il sur l'entraînement, ne raccourcit pas un projet autant qu'on l'espère : il élimine le goulot technique, pas le travail sur les données.

#FAQ

Matériel recommandé : RTX 5070 Ti 16 Go — carte NVIDIA 16 Go, suffisante pour affiner un modèle 7-8B en QLoRA. Tout le matériel IA →