Quelles librairies choisir pour fine-tuning LLM local ?

Le bon choix dépend surtout de votre GPU, de votre niveau et du type d’adaptation voulu. Unsloth vise la vitesse, PEFT réduit les paramètres entraînés, DeepSpeed distribue la charge, TRL gère l’alignement. Voici comment sélectionner une librairie sans perdre des jours en tests inutiles.

Quel outil choisir avec peu de VRAM ?

Quand la VRAM est limitée, le bon choix n’est pas forcément la librairie la plus complète. C’est celle qui permet de lancer vite un essai, de ne pas saturer le GPU, puis d’itérer sans passer son temps à régler des erreurs mémoire.

La VRAM, ou mémoire vidéo, est la mémoire directement disponible sur le GPU. Elle stocke le modèle, les activations intermédiaires, les gradients et une partie de l’état de l’optimiseur pendant l’entraînement. Avec un grand modèle de langage, elle devient vite le premier goulot d’étranglement, parce que chaque milliard de paramètres ajoute une pression mémoire importante, même avant de traiter vos données.

Avec peu de VRAM, je privilégie d’abord Unsloth. Le projet se positionne clairement sur le fine-tuning local efficace, notamment pour les GPU grand public, Google Colab ou Kaggle. Selon la présentation du projet, Unsloth peut aller jusqu’à 2 fois plus vite et économiser environ 70 % de VRAM. Ce sont des gains précieux quand vous voulez tester plusieurs jeux de données, plusieurs tailles de batch ou plusieurs modèles sans louer une machine plus chère.

Unsloth est particulièrement intéressant si votre objectif est simple : adapter rapidement un modèle existant avec des techniques comme LoRA ou QLoRA. LoRA signifie Low-Rank Adaptation : au lieu de modifier tous les poids du modèle, on entraîne de petits modules ajoutés au modèle. QLoRA ajoute de la quantification, c’est-à-dire une représentation plus compacte des poids, pour réduire encore la mémoire nécessaire.

Si vous voulez comprendre plus finement ce qui se passe pendant l’entraînement, torchtune devient très intéressant. C’est une bibliothèque native PyTorch orientée recettes modulaires. PyTorch est le framework de référence utilisé par beaucoup de chercheurs et d’équipes ML. Avec torchtune, les blocs sont plus lisibles et plus faciles à modifier proprement : chargement du modèle, tokenizer, boucle d’entraînement, configuration, évaluation.

LitGPT suit une logique proche : fournir des recettes lisibles pour le pré-entraînement, le fine-tuning, l’évaluation et le déploiement. Son intérêt est d’offrir un cadre clair, avec support de LoRA, QLoRA et de la quantification. C’est pratique si vous voulez garder une base compréhensible tout en couvrant plusieurs étapes du cycle de vie d’un modèle.

Réduire la mémoire utilisée par les outils ne suffit pas toujours. Le vrai levier suivant consiste à réduire le nombre de paramètres réellement entraînés, ce qui amène naturellement aux méthodes de fine-tuning efficaces en paramètres.

Comment réduire le coût du fine-tuning ?

Fine-tuner un LLM local coûte vite cher en mémoire GPU, en temps de calcul et en préparation des données. Pour éviter de réentraîner tout le modèle, je privilégie PEFT, pour Parameter-Efficient Fine-Tuning, c’est-à-dire l’adaptation efficace en paramètres.

L’idée est simple : partir d’un modèle déjà entraîné, puis ne modifier qu’une petite partie de ses paramètres. Le modèle garde donc l’essentiel de ses connaissances, et l’entraînement se concentre sur ce que vous voulez lui apprendre : un style, un format, un vocabulaire métier ou des exemples de réponses.

LoRA, pour Low-Rank Adaptation, est souvent le bon point de départ. Au lieu de mettre à jour tous les poids du modèle, LoRA ajoute de petites matrices entraînables dans certaines couches du réseau. Ces matrices apprennent l’adaptation, pendant que les poids principaux restent gelés. Le papier de référence est Hu et al., 2021, “LoRA: Low-Rank Adaptation of Large Language Models”, publié sur arXiv.

QLoRA va plus loin en combinant cette logique avec la quantification. La quantification consiste à représenter les poids du modèle avec moins de bits, par exemple 4 bits au lieu de 16, pour réduire fortement la mémoire nécessaire. Le papier Dettmers et al., 2023, “QLoRA: Efficient Finetuning of Quantized LLMs”, montre qu’il devient possible de fine-tuner de grands modèles avec beaucoup moins de VRAM, tout en conservant de bonnes performances.

Axolotl est utile dans ce contexte parce qu’il permet de configurer des entraînements reproductibles avec LoRA ou QLoRA, des datasets personnalisés et des environnements multi-GPU. Il sert surtout à éviter les scripts bricolés impossibles à relancer proprement.

La limite reste la même : un mauvais dataset produit un mauvais modèle. Un corpus trop petit, redondant ou mal nettoyé peut provoquer du surapprentissage, c’est-à-dire un modèle qui mémorise vos exemples au lieu de généraliser. Une évaluation sérieuse reste indispensable avant mise en production.

Quand le modèle devient trop gros, que le dataset explose ou que les temps d’entraînement deviennent ingérables, le poste local ne suffit plus. Il faut alors passer à un entraînement distribué.

Quand faut-il passer au multi GPU ?

Je passe au multi GPU quand le modèle, le dataset ou la durée d’entraînement dépasse ce qu’un seul GPU, c’est-à-dire un processeur graphique, peut absorber proprement. Le signal n’est pas seulement une erreur mémoire. C’est aussi un entraînement qui prend trois jours pour un test simple, une configuration impossible à reproduire, ou un pipeline qui doit comparer plusieurs modèles sans bricolage permanent.

DeepSpeed devient utile dès que l’entraînement sort du cadre “notebook local”. C’est une bibliothèque Microsoft conçue pour optimiser l’entraînement et l’inférence de grands modèles à grande échelle. Son intérêt principal : mieux utiliser la mémoire GPU et distribuer le calcul sur plusieurs cartes ou plusieurs machines.

La technique la plus connue de DeepSpeed s’appelle ZeRO, pour Zero Redundancy Optimizer. L’idée est simple : dans un entraînement distribué classique, chaque GPU garde souvent une copie redondante de certaines informations, comme les états de l’optimiseur, les gradients ou les paramètres. ZeRO répartit ces éléments entre les GPU pour réduire la mémoire consommée par chaque carte. Cette approche est documentée dans l’article scientifique de Rajbhandari et al., 2020, “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models”.

Axolotl répond à un autre problème : l’industrialisation. Il sert de couche de configuration pour construire des pipelines de fine-tuning personnalisés, reproductibles et moins fragiles. Au lieu d’empiler des scripts maison, vous décrivez le modèle, le dataset, la méthode de fine-tuning, la quantification, les paramètres d’entraînement et les sorties attendues. C’est précieux quand vous testez plusieurs variantes ou quand un entraînement doit être relancé proprement dans trois semaines.

SWIFT, issu de l’écosystème ModelScope, vise le fine-tuning, l’alignement, la quantification et le déploiement de grands modèles, y compris multimodaux. Il est particulièrement intéressant si vous travaillez avec des workflows autour de modèles comme Qwen, ou si vos données mélangent texte, image, audio ou vidéo.

Les signaux de passage à l’échelle sont généralement faciles à repérer :

• Des erreurs mémoire répétées, même après réduction du batch size.
• Un temps d’entraînement incompatible avec votre rythme d’expérimentation.
• Un besoin de reproductibilité entre plusieurs runs, machines ou datasets.
• Des tests réguliers sur plusieurs modèles, tailles ou méthodes de fine-tuning.
• Des données multimodales qui augmentent fortement la charge mémoire et calcul.

Comment aligner un LLM sur des préférences ?

Quand le problème n’est plus seulement “le modèle connaît-il la réponse ?”, mais “la réponse est-elle utile, sûre, concise et conforme à ma consigne ?”, je passe de l’entraînement classique à l’alignement sur des préférences. C’est là que TRL, la librairie de Hugging Face pour l’entraînement par renforcement et l’alignement des LLM, devient intéressante.

SFT, pour Supervised Fine-Tuning, consiste à entraîner le modèle sur des exemples de bonnes réponses. On lui donne une instruction et la réponse attendue. C’est efficace pour apprendre un format, un ton, un domaine métier ou une façon de répondre. Mais le SFT ne dit pas toujours pourquoi une réponse est meilleure qu’une autre.

L’alignement va plus loin. Il cherche à rapprocher le comportement du modèle de préférences humaines ou métier. Par exemple : répondre plus court, mieux respecter une contrainte, refuser une demande dangereuse, ou préférer une réponse structurée en étapes plutôt qu’un bloc de texte confus.

DPO, pour Direct Preference Optimization, publié par Rafailov et al. en 2023, apprend directement à préférer une réponse à une autre à partir de paires annotées. L’intérêt pratique : éviter de mettre en place toute une boucle RLHF, c’est-à-dire Reinforcement Learning from Human Feedback, souvent plus lourde à maintenir.

PPO, pour Proximal Policy Optimization, publié par Schulman et al. en 2017, reste une brique importante de certains pipelines RLHF. TRL couvre aussi des approches comme GRPO et le reward modeling, qui consiste à entraîner un modèle capable de noter ou classer des réponses. Ces outils sont puissants, mais ils ne remplacent pas la qualité des données.

• Des préférences incohérentes produisent un modèle incohérent.
• Des critères flous rendent l’évaluation impossible.
• Des choix non tracés empêchent de comprendre une régression.
• Des tests humains restent nécessaires pour vérifier la qualité perçue.

Je surveille donc les métriques automatiques, mais aussi des évaluations humaines : taux de préférence, respect des consignes, taux de refus correct, concision, factualité. Si l’équipe veut éviter de coder toute cette chaîne avec TRL, il existe des outils plus accessibles pour préparer, lancer et comparer ces entraînements localement.

Quelle interface pour démarrer vite ?

Pour démarrer vite, je choisis surtout LLaMA-Factory ou AutoTrain Advanced. Ces deux outils réduisent la friction au départ : moins de code à écrire, plus de guidage, et une configuration plus lisible qu’un empilement manuel de scripts PyTorch.

LLaMA-Factory est un framework de fine-tuning LLM avec une CLI et une Web UI. Une CLI, ou Command Line Interface, est une interface en ligne de commande : vous lancez l’entraînement avec des commandes dans un terminal. Une Web UI est une interface graphique dans le navigateur : plus pratique pour choisir un modèle, un dataset, une méthode comme LoRA, puis lancer un test sans tout coder à la main.

Son intérêt est simple : il reste accessible aux débutants, mais assez complet pour des expérimentations sérieuses. Il prend en charge plusieurs familles de modèles, plusieurs méthodes de fine-tuning et des scénarios comme le supervised fine-tuning, c’est-à-dire l’apprentissage sur des exemples entrée-sortie annotés.

AutoTrain Advanced, de Hugging Face, vise plutôt les workflows no-code ou low-code. No-code signifie sans écrire de code. Low-code signifie avec peu de code. L’outil permet d’entraîner des modèles sur des datasets personnalisés, localement ou dans le cloud, avec une approche plus guidée. C’est utile si votre priorité est de valider rapidement une idée avant d’entrer dans des réglages plus fins.

Le choix dépend ensuite de votre contrainte principale :

• Unsloth est souvent choisi quand la vitesse et la faible VRAM comptent. La VRAM est la mémoire vidéo du GPU.
• PEFT, pour Parameter-Efficient Fine-Tuning, donne un contrôle précis sur les adaptateurs comme LoRA.
• Axolotl convient aux configurations reproductibles via fichiers YAML.
• DeepSpeed sert surtout aux entraînements distribués et multi-GPU.
• TRL, Transformer Reinforcement Learning, est adapté à l’alignement comme DPO ou PPO.
• Torchtune et LitGPT parlent davantage aux profils PyTorch et recherche.
• SWIFT est intéressant quand les scénarios multi-modèles ou multimodaux entrent en jeu.

Le meilleur outil n’est pas le plus connu, c’est celui qui correspond à votre contrainte principale.

Alors, quelle librairie allez-vous tester en premier ?

Le fine-tuning LLM local n’impose pas de choisir une seule librairie universelle. Si votre contrainte principale est la VRAM, Unsloth, PEFT, LoRA ou QLoRA sont souvent les premiers réflexes. Si vous voulez garder le contrôle, Axolotl, torchtune et LitGPT donnent des bases plus modulaires. Si vous passez à l’échelle, DeepSpeed et SWIFT deviennent plus pertinents. Pour l’alignement, TRL couvre les workflows SFT, DPO, PPO ou reward modeling. Pour aller vite sans tout coder, LLaMA-Factory et AutoTrain Advanced simplifient l’entrée. Le bénéfice pour vous : choisir plus vite, dépenser moins, et tester avec méthode.

FAQ

• Quelle est la meilleure librairie pour faire du fine-tuning LLM local ? La meilleure librairie dépend de votre contrainte principale. Unsloth est pertinent pour la vitesse et la faible VRAM, PEFT pour entraîner peu de paramètres, Axolotl pour des configurations reproductibles, DeepSpeed pour le multi-GPU, TRL pour l’alignement et AutoTrain Advanced ou LLaMA-Factory pour démarrer avec moins de code.
• Peut-on fine-tuner un LLM avec un GPU grand public ? Oui, surtout avec des approches économes comme LoRA, QLoRA, PEFT ou Unsloth. Il faut rester réaliste sur la taille du modèle, la longueur du contexte, le batch size et la qualité du dataset. La VRAM disponible reste le facteur limitant principal.
• Quelle différence entre LoRA, QLoRA et PEFT ? PEFT désigne une famille de méthodes qui adaptent un modèle en entraînant peu de paramètres. LoRA est l’une de ces méthodes. QLoRA ajoute une logique de quantification pour réduire encore les besoins mémoire pendant l’adaptation du modèle.
• Quand utiliser TRL plutôt qu’un fine-tuning classique ? TRL devient utile quand vous voulez optimiser les préférences de réponse, pas seulement apprendre à reproduire des exemples. Il couvre des workflows comme SFT, DPO, PPO, GRPO et reward modeling, souvent utilisés pour améliorer l’alignement d’un assistant.
• Faut-il choisir une interface graphique ou un framework en code ? Une interface graphique comme LLaMA-Factory ou AutoTrain Advanced aide à démarrer vite. Un framework plus configurable comme Axolotl, torchtune ou LitGPT devient préférable quand vous voulez contrôler précisément les datasets, hyperparamètres, recettes d’entraînement et évaluations.

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation no-code et low-code avec n8n, l’intégration de l’IA dans les process business, ainsi que le SEO et le GEO. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet IA, automatiser vos workflows ou former vos équipes, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.