Introduction : Pourquoi Fine-Tuner un LLM en 2026
Soyons honnêtes : les grands modèles de langage comme Llama 4, Qwen 3 ou DeepSeek V3 sont bluffants dès qu'on les installe. Mais dès qu'on les met en production sur un vrai cas métier — support client spécialisé, analyse juridique, rédaction médicale — les limites sautent aux yeux. Vocabulaire approximatif, ton inadapté, réponses trop génériques là où on attend de la précision chirurgicale.
Le fine-tuning résout exactement ce problème. Il transforme un généraliste en spécialiste de votre domaine.
Le hic, c'est que jusqu'à récemment, fine-tuner un modèle de 8 milliards de paramètres exigeait plusieurs GPU A100 et un budget conséquent. Plus maintenant. Grâce à LoRA, QLoRA et des outils comme Unsloth, vous pouvez adapter un LLM à vos données en quelques heures sur un seul GPU grand public — avec des résultats qui rivalisent avec le fine-tuning complet. Personnellement, j'ai été surpris la première fois que j'ai vu les benchmarks : la différence de performance est souvent négligeable.
Dans ce guide, on va construire ensemble un pipeline de fine-tuning de A à Z. De la théorie derrière LoRA et QLoRA, jusqu'au code fonctionnel pour fine-tuner Llama 3.1 8B avec Unsloth. Chaque étape est reproductible, que vous soyez sur Google Colab ou sur votre propre machine avec un GPU de 16 Go.
LoRA et QLoRA : Comprendre la Théorie
Avant de plonger dans le code, prenons quelques minutes pour comprendre pourquoi ces techniques fonctionnent. Ça change vraiment la manière dont on aborde le fine-tuning — et ça vous évitera de tâtonner sur les hyperparamètres plus tard.
Le Problème du Fine-Tuning Classique
Le fine-tuning complet (full fine-tuning), c'est simple sur le papier : on ré-entraîne tous les paramètres d'un modèle pré-entraîné sur vos données. En pratique ? Pour un modèle de 8 milliards de paramètres en float16, comptez environ 16 Go juste pour les poids. Ajoutez les gradients, les états de l'optimiseur et les activations, et on arrive facilement à 60-80 Go de VRAM nécessaires.
Sans parler du risque de catastrophic forgetting — le modèle qui oublie ses connaissances générales en se spécialisant trop. Pas idéal.
LoRA : L'Adaptation par Rang Faible
Low-Rank Adaptation (LoRA), proposé par Hu et al. en 2021, repose sur une observation élégante : lors du fine-tuning, les modifications apportées aux matrices de poids vivent dans un sous-espace de dimension beaucoup plus faible que la dimension totale. Dit autrement, on n'a pas besoin de toucher aux milliards de paramètres — une approximation de rang faible suffit largement.
Concrètement, pour chaque matrice de poids W de dimension d×k, LoRA gèle W et ajoute deux petites matrices : A (d×r) et B (r×k), où r est le rang — typiquement entre 8 et 64. Au lieu de modifier d×k paramètres, on n'entraîne que (d+k)×r paramètres. Pour une matrice de 4096×4096 avec r=16, ça passe de 16,7 millions à 131 000 paramètres. Soit une réduction de 99,2 %. Oui, vous avez bien lu.
# Intuition mathématique de LoRA
# Au lieu de : W_nouveau = W + delta_W (où delta_W est d×k)
# On fait : W_nouveau = W + B @ A (où B est d×r et A est r×k)
# Le facteur d'échelle est : alpha / r
# Exemple pour une couche d'attention (4096 × 4096)
import torch
d, k = 4096, 4096
r = 16 # Rang LoRA
# Poids originaux gelés
W = torch.randn(d, k, requires_grad=False)
# Matrices LoRA entraînables
A = torch.randn(r, k, requires_grad=True) # Initialisé aléatoirement
B = torch.zeros(d, r, requires_grad=True) # Initialisé à zéro
alpha = 16 # Facteur d'échelle
scaling = alpha / r
# Passe avant avec LoRA
x = torch.randn(1, k)
sortie = x @ W.T + (x @ A.T @ B.T) * scaling
# Paramètres : originaux vs LoRA
print(f"Paramètres originaux : {d * k:,} = {d*k/1e6:.1f}M")
print(f"Paramètres LoRA : {(d + k) * r:,} = {(d+k)*r/1e3:.0f}K")
print(f"Réduction : {(1 - (d+k)*r/(d*k))*100:.1f}%")QLoRA : Aller Encore Plus Loin avec la Quantification
QLoRA, introduit par Dettmers et al. en 2023, pousse le concept encore plus loin en combinant LoRA avec une quantification agressive du modèle de base. L'idée : charger le modèle pré-entraîné en précision 4 bits (au lieu de 16 bits), tout en effectuant les calculs LoRA en précision complète. Trois innovations rendent cela possible :
- NormalFloat 4-bit (NF4) : un type de données optimisé pour les poids de réseaux de neurones, qui suivent une distribution normale. NF4 minimise l'erreur de quantification par rapport à l'INT4 classique.
- Double quantification : les constantes de quantification elles-mêmes sont quantifiées, économisant environ 0,37 bit par paramètre (ça paraît peu, mais ça s'additionne vite).
- Optimiseurs paginés : la mémoire GPU est gérée dynamiquement, évitant les pics de consommation lors du traitement de séquences longues.
Résultat concret : un modèle de 8 milliards de paramètres passe de 16 Go (float16) à environ 4-5 Go en mémoire. Avec les adaptateurs LoRA et les états d'entraînement, le total reste sous 6-8 Go de VRAM. Un GPU grand public comme un RTX 3090 ou même un RTX 4060 Ti 16 Go suffit amplement.
Pourquoi Unsloth en 2026
L'écosystème du fine-tuning a beaucoup évolué ces dernières années. Hugging Face PEFT + TRL reste une combinaison solide, mais Unsloth s'est clairement imposé comme la référence pour le fine-tuning efficace — et en 2026, l'écart de performance s'est encore creusé.
Quelques chiffres qui parlent d'eux-mêmes :
- 2× plus rapide que les méthodes Hugging Face classiques, grâce à des kernels Triton optimisés pour l'attention et les opérations linéaires.
- 70-80 % de VRAM en moins, ce qui permet de fine-tuner des modèles de 8B paramètres sur 6,5 Go de VRAM en QLoRA 4 bits.
- Quantification dynamique 2.0 : introduite début 2026, elle récupère environ 70 % de la perte de précision liée à la quantification. Autrement dit, QLoRA devient quasi-équivalent à LoRA 16 bits sur la plupart des benchmarks.
- MoE 12× plus rapide : les dernières mises à jour permettent de fine-tuner des modèles Mixture of Experts (comme DeepSeek) avec 35 % de VRAM en moins.
- Support étendu : Llama 4, Qwen 3.5, DeepSeek V3, Gemma 3, et même les modèles Text-to-Speech comme Sesame CSM-1B.
Franchement, quand on compare le rapport facilité/performance, c'est difficile de justifier une autre approche pour la plupart des projets.
Installation et Configuration de l'Environnement
Bon, passons aux choses concrètes. Unsloth fonctionne sur Google Colab (gratuit avec un GPU T4), Kaggle, ou en local avec un GPU NVIDIA.
# Installation sur Google Colab ou en local
pip install unsloth
# Dépendances complémentaires (si nécessaire)
pip install --no-deps bitsandbytes accelerate xformers
pip install sentencepiece protobuf datasets huggingface_hub
# Vérifier l'installation
python -c "from unsloth import FastLanguageModel; print('Unsloth installé avec succès !')"Si vous êtes sur Colab avec un GPU T4 (15 Go de VRAM), QLoRA 4 bits est votre meilleur choix — et honnêtement, c'est suffisant pour la grande majorité des cas d'usage. Sur un GPU A100 (40/80 Go), vous pouvez opter pour LoRA 16 bits ou même travailler avec des modèles plus gros (70B paramètres).
Préparer son Dataset : Alpaca vs ShareGPT
La qualité de votre dataset est probablement le facteur le plus déterminant pour le résultat final. Je ne le dirai jamais assez : un modèle fine-tuné sur des données médiocres produira des résultats médiocres, quelle que soit la sophistication de votre pipeline d'entraînement.
Le Format Alpaca : Pour les Tâches Simples
Le format Alpaca est structuré en triplets (instruction, input, output). Il est idéal pour les tâches mono-tour : classification, extraction d'entités, résumé, traduction.
# Exemple de dataset au format Alpaca
dataset_alpaca = [
{
"instruction": "Résume le texte suivant en une phrase.",
"input": "L'intelligence artificielle transforme les industries...",
"output": "L'IA révolutionne de nombreux secteurs économiques."
},
{
"instruction": "Classifie le sentiment de cette phrase.",
"input": "Ce produit est absolument fantastique !",
"output": "Positif"
}
]Le Format ShareGPT : Pour les Conversations Multi-Tours
Le format ShareGPT est conçu pour les conversations multi-tours, plus proches de l'usage réel d'un chatbot ou assistant IA. Chaque exemple est une séquence d'échanges entre un humain et un assistant.
# Exemple de dataset au format ShareGPT
dataset_sharegpt = [
{
"conversations": [
{"from": "human", "value": "Qu'est-ce que LoRA en fine-tuning ?"},
{"from": "gpt", "value": "LoRA (Low-Rank Adaptation) est une technique..."},
{"from": "human", "value": "Et QLoRA, c'est quoi la différence ?"},
{"from": "gpt", "value": "QLoRA combine LoRA avec la quantification 4 bits..."}
]
}
]Conseils Pratiques pour les Données
- Qualité plutôt que quantité : 1 000 exemples de haute qualité surpassent souvent 10 000 exemples bruités. Prenez le temps de vérifier manuellement un échantillon de vos données — ça vaut vraiment le coup.
- Diversité : combinez vos données métier avec un dataset généraliste (comme ShareGPT depuis Hugging Face) pour éviter que le modèle ne devienne trop spécialisé.
- Génération synthétique : utilisez GPT-4o ou Claude pour générer des paires question-réponse à partir de vos documents internes (PDF, pages web, bases de données). C'est une approche qui fonctionne étonnamment bien.
- Préférez les modèles Instruct comme point de départ : ils sont déjà formatés pour suivre des instructions, ce qui réduit considérablement la quantité de données nécessaire.
Fine-Tuner Llama 3.1 8B : Guide Étape par Étape
Allez, passons au concret. On va fine-tuner Llama 3.1 8B Instruct avec QLoRA pour créer un assistant spécialisé. Le code complet est reproductible sur Google Colab avec un GPU T4.
Étape 1 : Charger le Modèle avec Unsloth
from unsloth import FastLanguageModel
import torch
# Charger le modèle en 4 bits (QLoRA)
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/Meta-Llama-3.1-8B-Instruct-bnb-4bit",
max_seq_length=2048,
dtype=None, # Détection automatique (float16 ou bfloat16)
load_in_4bit=True, # QLoRA : quantification 4 bits
)
print(f"Modèle chargé : {model.config._name_or_path}")
print(f"VRAM utilisée : ~5 Go")Étape 2 : Ajouter les Adaptateurs LoRA
# Configurer les adaptateurs LoRA
model = FastLanguageModel.get_peft_model(
model,
r=16, # Rang LoRA : 16 est un bon compromis
target_modules=[ # Appliquer à toutes les couches linéaires
"q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj",
],
lora_alpha=32, # Alpha = 2 × r (recommandation standard)
lora_dropout=0, # 0 est optimisé par Unsloth
bias="none", # "none" pour de meilleures performances
use_gradient_checkpointing="unsloth", # Réduit la VRAM de 30%
random_state=42,
)
# Afficher les paramètres entraînables
params_entrainables = sum(p.numel() for p in model.parameters() if p.requires_grad)
params_total = sum(p.numel() for p in model.parameters())
print(f"Paramètres entraînables : {params_entrainables:,} / {params_total:,}")
print(f"Soit {params_entrainables/params_total*100:.2f}% du modèle")Un détail important ici : on applique LoRA à toutes les couches linéaires (attention + MLP). On verra plus bas pourquoi c'est le choix le plus impactant.
Étape 3 : Préparer le Dataset
from datasets import load_dataset
# Charger un dataset depuis Hugging Face
dataset = load_dataset("yahma/alpaca-cleaned", split="train")
# Template de prompt pour Llama 3.1 Instruct
prompt_template = """<|begin_of_text|><|start_header_id|>system<|end_header_id|>
Tu es un assistant IA utile et précis. Réponds toujours en français.<|eot_id|><|start_header_id|>user<|end_header_id|>
{instruction}
{input}<|eot_id|><|start_header_id|>assistant<|end_header_id|>
{output}<|eot_id|>"""
EOS_TOKEN = tokenizer.eos_token
def formater_exemple(exemple):
"""Formate un exemple Alpaca en prompt Llama 3.1."""
input_text = exemple["input"]
if input_text:
input_text = f"\nContexte : {input_text}"
else:
input_text = ""
texte = prompt_template.format(
instruction=exemple["instruction"],
input=input_text,
output=exemple["output"],
) + EOS_TOKEN
return {"text": texte}
# Appliquer le formatage
dataset = dataset.map(formater_exemple)
print(f"Dataset prêt : {len(dataset)} exemples")
print(f"Exemple :\n{dataset[0]['text'][:300]}...")Étape 4 : Lancer l'Entraînement
from trl import SFTTrainer, SFTConfig
trainer = SFTTrainer(
model=model,
tokenizer=tokenizer,
train_dataset=dataset,
args=SFTConfig(
dataset_text_field="text",
per_device_train_batch_size=2,
gradient_accumulation_steps=4, # Batch effectif = 2 × 4 = 8
warmup_steps=10,
num_train_epochs=1, # 1 epoch suffit souvent
learning_rate=2e-4, # Taux standard pour LoRA
fp16=not torch.cuda.is_bf16_supported(),
bf16=torch.cuda.is_bf16_supported(),
logging_steps=10,
optim="adamw_8bit", # Optimiseur 8 bits pour économiser la VRAM
weight_decay=0.01,
lr_scheduler_type="linear",
seed=42,
output_dir="outputs",
report_to="none", # Ou "wandb" pour le suivi
),
)
# Statistiques avant entraînement
gpu_stats = torch.cuda.get_device_properties(0)
print(f"GPU : {gpu_stats.name} ({gpu_stats.total_mem / 1e9:.1f} Go)")
# Lancer le fine-tuning
resultats = trainer.train()
# Résumé
print(f"\nEntraînement terminé !")
print(f"Loss finale : {resultats.training_loss:.4f}")
print(f"Durée : {resultats.metrics['train_runtime']/60:.1f} minutes")Sur un GPU T4, comptez environ 30-45 minutes pour une epoch complète sur Alpaca-Cleaned. C'est le moment d'aller chercher un café.
Étape 5 : Tester le Modèle Fine-Tuné
# Passer en mode inférence
FastLanguageModel.for_inference(model)
# Tester avec un prompt
messages = [
{"role": "system", "content": "Tu es un assistant IA utile et précis."},
{"role": "user", "content": "Explique-moi la différence entre LoRA et QLoRA."},
]
inputs = tokenizer.apply_chat_template(
messages,
tokenize=True,
add_generation_prompt=True,
return_tensors="pt",
).to("cuda")
outputs = model.generate(
input_ids=inputs,
max_new_tokens=256,
temperature=0.7,
top_p=0.9,
)
reponse = tokenizer.decode(outputs[0], skip_special_tokens=True)
print(reponse)Les Hyperparamètres Clés et Comment les Choisir
Le choix des hyperparamètres LoRA peut faire ou défaire votre fine-tuning. Voici ce qu'on a appris de centaines d'expériences publiées en 2025-2026 — et quelques leçons tirées de mes propres essais.
Le Rang (r) : Capacité vs Efficacité
Le rang contrôle la dimensionnalité des matrices LoRA et donc la capacité d'adaptation du modèle. Les études empiriques montrent que la performance sature rapidement au-delà de r=16 pour la plupart des tâches. Le papier QLoRA a même démontré très peu de différence statistique entre r=8 et r=256 quand LoRA est appliqué à toutes les couches.
En pratique :
- r=8-16 : suffisant pour la majorité des tâches (classification, chatbot, Q&A)
- r=32-64 : pour des tâches complexes (génération de code, raisonnement mathématique)
- r=128-256 : pour des adaptations profondes du domaine (médical, juridique)
Alpha (α) : Le Facteur d'Échelle
Le facteur alpha/r contrôle l'intensité des modifications LoRA. La recommandation standard est de fixer alpha = 2×r (ratio de 2). Ce ratio fonctionne un peu comme un taux d'apprentissage supplémentaire — si vous ajustez l'un, vous pouvez généralement laisser l'autre constant. Pour débuter, alpha=32 avec r=16 est un point de départ fiable qui marche dans la grande majorité des cas.
Les Modules Cibles : Le Facteur le Plus Déterminant
C'est en fait l'hyperparamètre le plus critique, et c'est assez contre-intuitif. Appliquer LoRA à toutes les couches linéaires du transformer (attention + MLP) donne systématiquement de meilleurs résultats qu'augmenter le rang sur quelques couches seulement.
Le papier QLoRA original le confirme clairement : la configuration « QLoRA-All » surpasse toutes les autres, indépendamment du rang. Donc avant de jouer avec r=128, assurez-vous d'abord d'appliquer LoRA à toutes les couches avec r=16.
Tableau Récapitulatif
| Hyperparamètre | Recommandation | Remarque |
|---|---|---|
| Rang (r) | 16 | Augmenter à 64 pour les tâches complexes |
| Alpha (α) | 2 × r | Ratio de 2 comme point de départ |
| Learning rate | 2e-4 | Réduire à 5e-5 si instable |
| Modules cibles | Tous (attention + MLP) | Le facteur le plus important |
| Dropout | 0 | Unsloth optimise mieux sans dropout |
| Époques | 1-3 | 1 epoch souvent suffisant |
| Batch effectif | 8-16 | Via gradient accumulation |
Sauvegarder et Déployer son Modèle
Une fois le fine-tuning terminé, plusieurs options s'offrent à vous selon votre cas d'usage. Voyons les plus courantes.
Sauvegarde des Adaptateurs LoRA
La méthode la plus légère : on ne sauvegarde que les adaptateurs (quelques dizaines de Mo), pas le modèle complet. C'est idéal pour versionner plusieurs spécialisations d'un même modèle de base — un adaptateur pour le support technique, un autre pour la rédaction marketing, etc.
# Sauvegarder uniquement les adaptateurs LoRA (léger : ~50 Mo)
model.save_pretrained("mon-modele-lora")
tokenizer.save_pretrained("mon-modele-lora")
# Pousser sur Hugging Face Hub
model.push_to_hub("votre-username/mon-modele-lora", token="hf_...")
tokenizer.push_to_hub("votre-username/mon-modele-lora", token="hf_...")Fusion et Export en GGUF
Pour le déploiement avec llama.cpp, Ollama ou LM Studio, exportez en format GGUF quantifié. C'est la voie la plus simple pour obtenir un modèle utilisable localement.
# Fusionner les adaptateurs et exporter en GGUF Q4_K_M
model.save_pretrained_gguf(
"mon-modele-gguf",
tokenizer,
quantization_method="q4_k_m", # Bon compromis taille/qualité
)
# Ou exporter en float16 pour un maximum de précision
model.save_pretrained_merged(
"mon-modele-merged",
tokenizer,
save_method="merged_16bit",
)Aller Plus Loin : DPO et Apprentissage par Renforcement
Le fine-tuning supervisé (SFT) est une première étape — et pour beaucoup de cas d'usage, elle suffit. Mais pour affiner davantage le comportement du modèle, notamment sa capacité à produire des réponses que les utilisateurs préfèrent réellement, l'étape suivante est l'alignement par préférences.
DPO : Direct Preference Optimization
DPO est une alternative élégante au RLHF classique. Au lieu d'entraîner un modèle de récompense séparé (ce qui est pénible à mettre en place), DPO optimise directement la politique du modèle à partir de paires de réponses : une préférée, une rejetée. Plus simple à implémenter, plus stable à entraîner.
from trl import DPOTrainer, DPOConfig
# Dataset DPO : chaque exemple contient une réponse choisie et une rejetée
# Format : {"prompt": "...", "chosen": "...", "rejected": "..."}
dpo_dataset = load_dataset("votre-dataset-dpo", split="train")
dpo_trainer = DPOTrainer(
model=model,
ref_model=None, # Unsloth gère le modèle de référence
train_dataset=dpo_dataset,
tokenizer=tokenizer,
args=DPOConfig(
per_device_train_batch_size=2,
gradient_accumulation_steps=4,
learning_rate=5e-5, # Plus bas que SFT
num_train_epochs=1,
beta=0.1, # Paramètre de régularisation KL
output_dir="outputs-dpo",
),
)
dpo_trainer.train()GRPO : L'Apprentissage par Renforcement Nouvelle Génération
En 2026, le Group Relative Policy Optimization (GRPO), popularisé par DeepSeek, s'est imposé comme une alternative prometteuse au PPO et au DPO. Le principe est malin : GRPO génère plusieurs réponses par prompt, les classe relativement entre elles, et utilise ce classement comme signal de récompense. Pas besoin de modèle de récompense externe.
Unsloth supporte GRPO nativement et permet même de l'exécuter avec seulement 5 Go de VRAM grâce à ses optimisations de contexte ultra-long. Pour ceux qui veulent aller au-delà du SFT classique, c'est une piste à explorer sérieusement.
Erreurs Courantes et Comment les Éviter
Après avoir accompagné plusieurs projets de fine-tuning, voici les pièges les plus fréquents :
- Trop de données, pas assez de qualité : 500 à 2 000 exemples de haute qualité suffisent généralement pour un SFT efficace. Vérifiez vos données manuellement avant de lancer l'entraînement. Sérieusement, prenez le temps de lire au moins 50 exemples.
- Sauter directement au fine-tuning complet : commencez toujours par QLoRA. Dans la majorité des cas, les résultats sont comparables au fine-tuning complet pour une fraction du coût. Vous pourrez toujours passer au full fine-tuning si les résultats ne sont pas satisfaisants.
- Ignorer le template de prompt : chaque modèle a son format de prompt spécifique (Llama utilise des tokens spéciaux comme
<|begin_of_text|>). Un mauvais template produit des résultats incohérents, et c'est un bug frustrant à diagnostiquer. - Sur-entraîner : une à trois époques suffisent pour du SFT. Au-delà, le modèle commence à mémoriser les données d'entraînement au lieu de généraliser. Si votre modèle récite vos exemples mot pour mot, c'est mauvais signe.
- Ne pas évaluer : gardez toujours un jeu de validation séparé (10-20 % des données) et surveillez la loss de validation. Si elle remonte alors que la loss d'entraînement continue de baisser, vous êtes en train de sur-apprendre.
FAQ : Questions Fréquentes sur le Fine-Tuning avec LoRA
Quelle est la différence entre LoRA et le fine-tuning complet ?
Le fine-tuning complet modifie tous les paramètres du modèle, nécessitant 60-80 Go de VRAM pour un modèle de 8B. LoRA gèle le modèle original et n'entraîne que de petites matrices d'adaptation, réduisant les besoins à 6-16 Go de VRAM. Les études montrent que LoRA atteint des performances comparables au fine-tuning complet dans la majorité des cas, tout en évitant mieux le catastrophic forgetting.
LoRA peut-il faire apprendre de nouvelles connaissances à un LLM ?
LoRA est principalement conçu pour adapter le comportement du modèle — ton, format, style de réponse — plutôt que pour injecter de nouvelles connaissances factuelles. Pour ajouter des connaissances spécifiques à un domaine, la meilleure approche est de combiner le fine-tuning avec un système RAG (Retrieval-Augmented Generation). Les deux sont complémentaires, pas interchangeables.
Combien de données faut-il pour fine-tuner un LLM avec LoRA ?
Pour du SFT avec un modèle Instruct, 500 à 2 000 exemples de haute qualité sont généralement suffisants. La qualité prime largement sur la quantité. Des datasets générés synthétiquement par GPT-4 ou Claude, puis vérifiés manuellement, donnent d'excellents résultats. Pour le pré-entraînement continu sur un domaine spécifique, prévoyez plutôt 10 000 à 100 000 exemples.
Peut-on fine-tuner un LLM gratuitement ?
Tout à fait. Google Colab offre gratuitement un GPU T4 (15 Go de VRAM), suffisant pour fine-tuner des modèles jusqu'à 8B paramètres en QLoRA 4 bits avec Unsloth. Kaggle propose également des GPU T4×2 et même des TPU gratuitement. Unsloth est entièrement open source et gratuit — il n'y a donc vraiment aucune barrière financière pour commencer.
Quand choisir QLoRA plutôt que LoRA 16 bits ?
Choisissez QLoRA quand vous avez moins de 24 Go de VRAM, que vous voulez itérer rapidement, ou que vous travaillez sur Colab/Kaggle. Optez pour LoRA 16 bits si vous disposez d'un GPU A100 et que vous cherchez la précision maximale. Avec la quantification dynamique 2.0 d'Unsloth en 2026, l'écart de performance entre QLoRA et LoRA 16 bits s'est tellement réduit que QLoRA est devenu le choix par défaut pour la plupart des praticiens.