- Affinage fin LoRA entraîne uniquement un petit ensemble de poids adaptateurs au lieu du modèle entier — typiquement 1 à 5 % des paramètres totaux — ce qui permet d’affiner un modèle de 7 milliards de paramètres (7B) sur un seul GPU grand public.
- QLoRA ajoute une quantification 4 bits au modèle de base figé, réduisant encore davantage la consommation de VRAM : un modèle de 7B tient dans ~6 Go, un modèle de 13B dans ~10 Go.
- Rang (r) et alpha sont les deux paramètres ajustables qui déterminent dans quelle mesure l’adaptateur peut modifier le comportement du modèle. Commencez avec r = 16 et alpha = 32.
- L’affinage fin est souvent la mauvaise approche. Si votre problème relève d’un manque de connaissances, utilisez RAG. Si c’est une question de format ou de ton, améliorez d’abord votre prompt système.
L’affinage fin LoRA (Low-Rank Adaptation) est une méthode efficace en paramètres pour adapter un modèle de langage pré-entraîné à une tâche spécifique. Plutôt que de mettre à jour tous les poids du modèle, LoRA fige les poids originaux et insère de petites matrices entraînables dans les couches d’attention. Le résultat est un adaptateur — un fichier souvent inférieur à 100 Mo — qui s’ajuste au modèle de base au moment de l’inférence. Vous obtenez un comportement spécialisé sans avoir à réentraîner des milliards de paramètres.
Fonctionnement de LoRA
Une matrice de poids standard de type transformeur pourrait être de taille 4096 × 4096. LoRA décompose la mise à jour de cette matrice en deux matrices beaucoup plus petites : l’une de dimension 4096 × r et l’autre de dimension r × 4096, où r est le rang (généralement compris entre 4 et 64). Pendant l’entraînement, seules ces matrices de faible rang sont mises à jour. À l’inférence, le produit des deux petites matrices est ajouté à la matrice originale figée — aucune latence supplémentaire dans la plupart des implémentations, car l’adaptateur est fusionné avant déploiement.
Cela a une incidence sur le matériel : comme les poids du modèle de base sont figés, ils ne nécessitent ni états d’optimiseur ni gradients. Seuls les paramètres de l’adaptateur en ont besoin. C’est pourquoi les besoins en VRAM chutent si fortement comparés à un affinage fin complet.
LoRA contre QLoRA
| Méthode | Précision du modèle de base | Précision de l’adaptateur | VRAM requise pour un modèle 7B (entraînement) | 13 Go de VRAM (entraînement) |
|---|---|---|---|---|
| Affinage complet | bf16/fp16 | — | ~60 Go | ~110 Go |
| LoRA | bf16/fp16 | bf16/fp16 | ~16 Go | ~28 Go |
| QLoRA | Quantification 4 bits (NF4) | bf16/fp16 | ~6 Go | ~10 Go |
QLoRA, introduit par Dettmers et al. (2023), charge le modèle de base en quantification 4 bits NormalFloat (NF4) et conserve l’adaptateur en précision pleine. L’entraînement est plus lent que celui de LoRA standard en raison de la surcharge liée à la déquantification à chaque passage avant, mais les économies de VRAM permettent d’entraîner des modèles de 13 milliards et 70 milliards de paramètres sur du matériel accessible à la plupart des utilisateurs. La perte de qualité par rapport à un LoRA complet est généralement négligeable pour des affinages spécifiques à une tâche ; toutefois, pour des tâches complexes impliquant un raisonnement poussé, une légère dégradation est possible.
Avant de vous engager dans un achat matériel, exécutez votre modèle cible via le Calculateur de VRAM — il prend en compte la taille du lot (batch size) et la longueur de séquence, deux paramètres qui modifient sensiblement les estimations.
Rang et alpha : ce qu’ils font réellement
Rang (r) contrôle l’expressivité de l’adaptateur. Un rang de 4 ajoute très peu de paramètres et produit des modifications subtiles ; un rang de 64 confère davantage de capacité à l’adaptateur pour remodeler le comportement du modèle, mais augmente la consommation de VRAM ainsi que le risque de surapprentissage.
Alpha (α) est un facteur d’échelle appliqué à la sortie LoRA avant son ajout aux poids gelés. Le taux d’apprentissage effectif de l’adaptateur évolue proportionnellement à α / r. Conserver alpha à environ deux fois le rang (par exemple, r = 16, alpha = 32) constitue le point de départ le plus courant et fonctionne bien en pratique.
| Cas d’usage | Rang recommandé (r) | Alpha recommandé (α) |
|---|---|---|
| Changement de style ou de ton | 4–8 | 8–16 |
| Questions-réponses spécialisées par domaine | 16 | 32 |
| Nouveau format de tâche (ex. appel de fonction) | 32–64 | 64–128 |
| Changement complexe de comportement | 64 | 128 |
Un rang plus élevé ne garantit pas systématiquement de meilleurs résultats. Pour la plupart des affinages axés sur le suivi d’instructions, r = 16 suffit largement. Si la perte sur l’ensemble de validation ne diminue pas, augmentez plutôt le rang ou ajoutez davantage de données avant d’augmenter le nombre d’époques.
Exigences réalistes en VRAM et en temps
Les chiffres ci-dessous supposent un entraînement QLoRA avec une taille de lot de 1 et une longueur de séquence de 2048. Les configurations multi-GPU échelonnent approximativement linéairement la consommation de VRAM, mais nécessitent une configuration FSDP ou DeepSpeed.
| Taille du modèle | GPU minimal | GPU confortable | ~1 000 itérations (A100) |
|---|---|---|---|
| 3 milliards de paramètres | RTX 3060 (12 Go) | RTX 4070 (12 Go) | ~5 minutes |
| 7B | RTX 3060 (12 Go) | RTX 4080 (16 Go) | ~15 minutes |
| 13 milliards de paramètres | RTX 3090 (24 Go) | RTX 4090 (24 Go) | ~30 min |
| 34 milliards de paramètres | 2× RTX 3090 | A100 (40 Go) | ~90 minutes |
| 70B | 2 × A100 (40 Go) | 4 × A100 | ~4 heures |
Les coûts cloud varient. Un seul GPU A100 (80 Go) sur Lambda Labs coûte environ 1,50 à 2,00 $ l’heure mi-2026. Un affinage QLoRA sur un modèle de 7 milliards de paramètres, avec 50 000 exemples, s’achève généralement en moins de deux heures — soit un coût nettement inférieur à 5 $. Pour des conseils sur l’achat de GPU, consultez le guide GPU pour les LLM locaux.
Outils : comment effectuer concrètement un affinage fin LoRA
Les deux frameworks dominants sont Hugging Face TRL + PEFT et Axolotl. Les deux prennent en charge LoRA et QLoRA. Unsloth est une troisième option populaire qui accélère l’entraînement d’un facteur 2 grâce à des noyaux CUDA personnalisés.
Exemple minimal avec TRL + PEFT (Python)
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer, SFTConfig
import torch
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Meta-Llama-3-8B-Instruct",
quantization_config=bnb_config,
device_map="auto",
)
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_config)
trainer = SFTTrainer(
model=model,
train_dataset=your_dataset, # attend une colonne "text"
args=SFTConfig(output_dir="./output", num_train_epochs=3),
)
trainer.train()
model.save_pretrained("./my-lora-adapter")
L’adaptateur sauvegardé dans ./my-lora-adapter pèse typiquement entre 50 et 300 Mo. Fusionnez-le avec le modèle de base pour accélérer l’inférence à l’aide de model.merge_and_unload() avant la sauvegarde.
Axolotl (piloté par configuration)
Axolotl orchestre l’intégralité du pipeline à partir d’un fichier YAML, ce qui facilite la reproductibilité des expériences. Installez-le avec pip install axolotl, puis :
# config.yml
base_model: meta-llama/Meta-Llama-3-8B-Instruct
load_in_4bit: true
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
datasets:
- path: ./data/train.jsonl
type: alpaca
output_dir: ./output
num_epochs: 3
accelerate launch -m axolotl.cli.train config.yml
Quand l’affinage fin n’est pas la bonne solution
Le réglage fin LoRA résout un problème spécifique : modifier comment le comportement ou les réponses d’un modèle. Il n’injecte pas de manière fiable des connaissances factuelles. Si votre cas d’usage relève de l’une des catégories suivantes, une autre approche produira de meilleurs résultats avec moins d’efforts :
- Le modèle ne dispose pas de connaissances à jour ou propriétaires. Utilisez la génération augmentée par recherche (RAG). Un réglage fin fondé sur des faits produit des modèles qui « hallucinent » de façon convaincante sur tout ce qui échappe à la tranche de données d’entraînement.
- Vous souhaitez que le modèle suive des instructions précises. Commencez par tester une instruction système détaillée. Une instruction bien conçue, appliquée à un modèle de base performant, donne souvent de meilleurs résultats qu’un modèle plus petit, mais réglé finement, sur la même tâche.
- Vous disposez de moins d’environ 500 exemples de haute qualité. Le rapport signal-bruit est trop faible ; le modèle risque fortement de surajuster. Améliorez la qualité et la quantité de vos données, ou privilégiez plutôt le prompting à quelques exemples (few-shot).
- Vous êtes en phase de prototypage. Le réglage fin fige un comportement donné. Utilisez plutôt l’API et itérez sur les instructions jusqu’à stabiliser le comportement souhaité, puis envisagez un réglage fin pour réduire les coûts liés aux jetons à grande échelle. Le Calculateur de coûts d’API permet de quantifier le seuil à partir duquel régler finement un modèle local devient moins coûteux que de payer par jeton.
Si vous comparez à long terme un modèle local réglé finement à une API hébergée, le Calculateur de seuil de rentabilité entre hébergement local et utilisation d’une API vous indique le point d’inversion (crossover point), en fonction de votre volume d’utilisation et de vos coûts GPU.
Questions fréquemment posées
De quelle quantité de données ai-je besoin pour un réglage fin LoRA ?
Pour l’apprentissage du suivi d’instructions ou la modification de style, 500 à 2 000 exemples de haute qualité et variés sont souvent suffisants. Pour une adaptation complexe à un domaine spécifique, 5 000 à 20 000 exemples permettent d’obtenir des résultats plus robustes. La qualité prime largement sur la quantité : 200 exemples soigneusement sélectionnés surpassent 2 000 exemples bruités.
Puis-je exécuter une inférence LoRA sur du matériel grand public ?
Oui. Un adaptateur fusionné n’entraîne aucun surcoût d’inférence par rapport au modèle de base. Un adaptateur non fusionné ajoute une faible charge calculatoire supplémentaire à chaque passage avant (forward pass). Les deux frameworks llama.cpp et Ollama prennent nativement en charge le chargement direct d’adaptateurs LoRA convertis au format GGUF. Consultez le Guide des exigences en VRAM pour connaître les besoins mémoire spécifiques à l’inférence seule.
Quelle est la différence entre LoRA et le réglage fin complet ?
Le réglage fin complet met à jour tous les poids du modèle et nécessite de stocker les états de l’optimiseur pour chacun d’eux — environ 16 à 20 octets par paramètre en précision mixte avec l’optimiseur Adam. LoRA, quant à lui, met à jour uniquement les matrices d’adaptateurs à faible rang, réduisant ainsi le nombre de paramètres entraînables d’un facteur 10 à 1 000. Le compromis porte sur la capacité : le réglage fin complet peut remodeler le modèle de façon plus complète, mais pour la plupart des tâches pratiques, LoRA y parvient tout aussi bien.
Quelles couches faut-il cibler avec LoRA ?
Les couches de projection d’attention (q_proj et v_proj) sont les cibles les plus courantes et donnent de bons résultats pour la plupart des tâches. Ajouter k_proj, o_projet les couches du réseau à propagation avant (MLP) (gate_proj, up_proj, down_proj) augmente la capacité du modèle, au prix d’une consommation accrue de VRAM et d’un temps d’entraînement légèrement plus long. En cas de contrainte stricte sur la VRAM, commencez par cibler uniquement les projections q et v.
QLoRA produit-il un modèle inférieur à LoRA complet ?
Pour la plupart des réglages fins spécialisés, la différence est négligeable. Les benchmarks publiés montrent que QLoRA obtient des performances à moins de 1 à 2 points de pourcentage de celles de LoRA complet sur les évaluations standard. Cet écart peut s’élargir sur des tâches complexes de raisonnement impliquant des jeux de données très restreints, car le bruit introduit par la quantification se cumule avec un signal limité. Si la précision est critique et que vous disposez de suffisamment de VRAM, privilégiez LoRA sur un modèle de base en bf16.
Comment évaluer si mon réglage fin a réellement apporté une amélioration ?
Réservez 10 à 20 % de vos données comme jeu de validation et suivez la perte de validation pendant l’entraînement. Arrêtez l’entraînement dès que la perte de validation cesse de s’améliorer (arrêt précoce, early stopping). Exécutez ensuite des évaluations spécifiques à la tâche : pour une classification, mesurez l’exactitude (accuracy) sur les exemples réservés ; pour une génération, procédez à une évaluation humaine ou utilisez un dispositif « LLM-as-judge » sur 50 à 100 exemples. Une baisse de la perte de validation qui ne se traduit pas par une amélioration des performances réelles sur la tâche est un signe de désaccord (mismatch) entre la distribution de vos données d’entraînement et celle des entrées réelles.
