Fine-tuning LoRA des LLM sur un GPU cloud

Le fine-tuning LoRA permet d’adapter un grand modèle de langage sans réentraîner tous ses paramètres.

Au lieu de modifier des milliards de poids dans le modèle de base, LoRA ajoute de petites matrices entraînables à certaines couches et conserve les poids d’origine figés. Vous entraînez ces paramètres supplémentaires sur vos propres exemples, puis les enregistrez dans un adaptateur qui peut être chargé avec le modèle d’origine.

Pour un modèle 8B, cela change considérablement les besoins matériels. Un fine-tuning complet peut nécessiter beaucoup plus de mémoire GPU que l’inférence, car l’entraînement doit conserver en mémoire les gradients, les états de l’optimiseur, les activations et d’autres données intermédiaires. LoRA réduit cette charge en n’entraînant qu’une fraction des paramètres du modèle.

QLoRA réduit encore les besoins en mémoire. Il charge le modèle de base figé avec une précision de 4 bits et entraîne des adaptateurs LoRA par-dessus. Le fine-tuning de modèles utiles sur un seul GPU devient ainsi beaucoup plus accessible. Les bibliothèques PEFT et TRL actuelles de Hugging Face prennent directement en charge cette méthode.

Ce guide présente un exemple QLoRA non testé pour Llama 3.1 8B Instruct, avec une RTX 5090 comme matériel envisagé. Les exemples d’installation, d’entraînement et de chargement de l’adaptateur n’ont pas été exécutés de bout en bout pour cet article. Ils ne démontrent ni la compatibilité, ni la capacité mémoire, ni la durée d’entraînement, ni la qualité du modèle dans votre environnement.

La configuration illustrative utilise :

• 1 × NVIDIA RTX 5090 avec 32GB de VRAM
• Llama 3.1 8B Instruct
• une quantification NF4 sur 4 bits
• des adaptateurs LoRA
• Hugging Face Transformers, PEFT, TRL et bitsandbytes
• un jeu de données conversationnelles au format JSON

Si vous cherchez l’infrastructure sans suivre le tutoriel, consultez la page entraînement et fine-tuning avec Hivenet.

Qu’est-ce que le fine-tuning LoRA ?

LoRA signifie Low-Rank Adaptation.

La méthode part d’une observation sur le fine-tuning des grands réseaux de neurones : il n’est souvent pas nécessaire de mettre à jour toute la matrice de poids pour apprendre une tâche plus ciblée à un modèle préentraîné.

LoRA conserve la matrice d’origine figée et apprend sa mise à jour au moyen de deux matrices beaucoup plus petites.

Vous n’avez pas besoin de maîtriser l’algèbre linéaire pour l’utiliser, mais cette différence compte.

Supposons qu’une couche contienne une grande matrice de poids :

W

Un fine-tuning complet modifie toute cette matrice.

LoRA apprend une mise à jour :

W + ΔW

où ΔW est représenté par le produit de deux matrices de faible rang.

Comme le rang est bien inférieur aux dimensions de la matrice d’origine, le nombre de paramètres entraînables diminue fortement.

Le modèle de base reste intact. Le comportement adapté est porté par l’adaptateur.

Cela a plusieurs conséquences pratiques :

• l’entraînement nécessite moins de mémoire GPU
• les adaptateurs occupent moins d’espace de stockage qu’un second modèle complet
• un même modèle de base peut être associé à différents adaptateurs
• les essais sont plus faciles à abandonner ou à remplacer
• vous pouvez conserver le modèle d’origine sans produire un nouveau point de contrôle complet après chaque exécution

LoRA a été présenté comme une méthode d’adaptation utilisant moins de paramètres qu’un fine-tuning complet.

LoRA, QLoRA et fine-tuning complet : trois approches différentes

Ces termes sont souvent confondus, ce qui rend les conseils matériels difficiles à interpréter.

LoRA réduit la quantité de paramètres du modèle à entraîner.

‍

‍

QLoRA réduit aussi la mémoire occupée par le modèle de base figé.

Les travaux d’origine sur QLoRA utilisaient un modèle quantifié sur 4 bits tout en conservant les paramètres LoRA entraînables à une précision supérieure. Les outils Hugging Face actuels proposent le même principe avec BitsAndBytesConfig et PEFT.

Cet exemple utilise QLoRA pour réduire la mémoire occupée par le modèle de base figé. Le choix entre cette méthode et LoRA avec des poids BF16 dépend de la mémoire disponible, des logiciels compatibles et des résultats d’évaluation.

À quoi sert LoRA ?

Le fine-tuning est surtout utile pour modifier le comportement d’un modèle.

Voici quelques exemples :

• apprendre un format de sortie cohérent
• adapter la terminologie à un domaine spécialisé
• apprendre une tâche de classification ou d’extraction
• suivre un schéma d’instructions particulier
• produire des réponses structurées
• améliorer les performances sur un type de problème précis
• adapter le style ou le ton
• apprendre à traiter les exemples d’un processus de travail particulier

Cette méthode est beaucoup moins convaincante pour tenir un modèle informé de faits qui changent chaque semaine.

Si votre besoin principal est de « répondre aux questions à partir de ces documents », modifier les poids du modèle peut ne pas résoudre le bon problème. Un système de recherche documentaire permet de changer les documents sous-jacents sans réentraîner le modèle.

C’est la distinction expliquée dans notre page sur le RAG avec Hivenet.

Utilisez le fine-tuning pour que le modèle se comporte différemment. Utilisez la recherche documentaire lorsque vous voulez surtout qu’il dispose d’autres informations au moment de la requête.

Les applications réelles combinent souvent les deux.

Quelle quantité de mémoire GPU faut-il pour le fine-tuning LoRA ?

Il n’existe pas de besoin fixe en VRAM pour « LoRA ».

La mémoire nécessaire dépend des éléments suivants :

• la taille du modèle
• la précision du modèle de base
• la longueur des séquences
• la taille des lots
• le rang LoRA
• les couches auxquelles des adaptateurs sont ajoutés
• l’optimiseur
• le gradient checkpointing
• le framework d’entraînement

C’est pourquoi une affirmation comme « LoRA nécessite 16GB » est peu utile sans autre précision.

Charger le modèle de base Llama 3.1 8B sur 4 bits réduit la mémoire des poids par rapport à BF16, sans démontrer la mémoire restante pour l’entraînement. Mesurez le pic de mémoire GPU avec les données, la longueur des séquences, les lots et les versions logicielles retenus avant de supposer que cet exemple tient sur une RTX 5090.

La RTX 5090 dispose de 32GB de VRAM. Notre guide sur la VRAM de la RTX 5090 explique le calcul pour les seuls poids et pourquoi les besoins en mémoire de l’entraînement diffèrent de ceux de l’inférence.

Le calcul change lorsque la taille du modèle augmente. Le fine-tuning d’un modèle 70B pose un autre problème d’infrastructure que l’adaptation d’un modèle 8B. Notre guide des besoins GPU de Llama 3.3 70B explique ces besoins en mémoire supérieurs.

Pourquoi utiliser Llama 3.1 8B pour ce tutoriel ?

Llama 3.1 8B fournit un modèle concret pour expliquer les données, les adaptateurs et l’évaluation. Ce choix ne prouve pas que l’exemple complet a fonctionné sur un seul GPU.

Meta propose des variantes préentraînées et adaptées aux instructions de Llama 3.1 avec 8B, 70B et 405B paramètres. Le modèle 8B Instruct prend en charge une fenêtre de contexte de 128K, mais utiliser ce contexte complet pendant l’entraînement demanderait bien plus de mémoire que la longueur de séquence modeste retenue ici.

Nous utiliserons :

meta-llama/Llama-3.1-8B-Instruct

Vous devez accepter les conditions de licence Llama 3.1 de Meta sur Hugging Face avant de télécharger le modèle. L’accès au dépôt est contrôlé et soumis à la Llama 3.1 Community License.

Faites-le avant de lancer une instance GPU coûteuse. Il est inutile de payer un GPU pendant que vous attendez l’accès au modèle.

Étape 1 : lancer une RTX 5090

Créez une instance GPU dans Compute avec Hivenet.

Pour tester la configuration illustrative, vérifiez d’abord la disponibilité et la compatibilité des éléments suivants :

1. 1 × RTX 5090
2. un environnement PyTorch ou une configuration Ubuntu adaptée
3. assez d’espace disque pour le modèle de base, les jeux de données, les points de contrôle et les sorties
4. un accès SSH ou Jupyter

Hivenet prend en charge les images PyTorch et les instances GPU pour les tâches d’entraînement. La RTX 5090 dispose de 32GB de VRAM, et Compute facture l’utilisation du GPU à la seconde.

S’il s’agit de votre première instance, suivez le guide de démarrage rapide de Compute.

Connectez-vous et vérifiez que le GPU est visible :

nvidia-smi

Vérifiez ensuite PyTorch :

python - <<'PY'
import torch

print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())

if torch.cuda.is_available():
print("GPU:", torch.cuda.get_device_name(0))
PY

La détection du GPU n’est qu’un premier contrôle. Avant d’exécuter les exemples, consignez le GPU, le pilote, le système, Python, PyTorch et CUDA, ainsi que les versions de Transformers, datasets, Accelerate, PEFT, TRL et bitsandbytes et les révisions du modèle et du tokeniseur. Vérifiez la compatibilité de cette combinaison dans sa documentation, testez une petite opération GPU et conservez les commandes d’installation et les dépendances verrouillées. Cet article ne fournit pas de combinaison de versions testée.

Étape 2 : installer les bibliothèques de fine-tuning

Créez un environnement Python isolé si votre modèle d’instance n’en fournit pas déjà un :

python -m venv ~/lora-env
source ~/lora-env/bin/activate

Mettez pip à jour :

pip install --upgrade pip

La commande ci-dessous énumère les paquets Hugging Face de l’exemple. Elle installe des versions récentes non fixées : ce n’est pas une procédure d’installation reproductible ou validée. Choisissez et fixez un environnement compatible avant de l’adapter ; une mise à jour peut modifier les API ou remplacer des dépendances de l’image de l’instance.

pip install --upgrade \
transformers \
datasets \
accelerate \
peft \
trl \
bitsandbytes \
huggingface_hub

TRL s’intègre directement à PEFT pour l’entraînement LoRA et QLoRA. QLoRA nécessite aussi bitsandbytes pour le chargement sur 4 bits.

Étape 3 : s’authentifier auprès de Hugging Face

Après avoir obtenu l’accès au dépôt Llama, authentifiez-vous depuis l’instance :

hf auth login

Collez un jeton d’accès utilisateur Hugging Face lorsque cela vous est demandé.

Vous pouvez vérifier le compte actif avec :

hf auth whoami

La CLI Hugging Face actuelle utilise hf auth login pour une authentification locale persistante.

Traitez ce jeton comme un identifiant d’accès confidentiel. Ne l’insérez pas directement dans un script d’entraînement et ne l’enregistrez pas dans un dépôt de code.

Étape 4 : préparer les données d’entraînement

Le modèle apprend à partir des exemples que vous lui fournissez. La qualité des données compte donc davantage qu’on ne le reconnaît souvent.

Pour le fine-tuning supervisé conversationnel, TRL accepte des jeux de données contenant des messages structurés avec des rôles et du contenu.

Créez un fichier nommé :

train.jsonl

Chaque ligne doit contenir un exemple d’entraînement :

{"messages":[{"role":"user","content":"Rewrite this incident report as a concise technical summary: The service became unavailable after the database connection pool was exhausted."},{"role":"assistant","content":"The service became unavailable after exhausting its database connection pool."}]}
{"messages":[{"role":"user","content":"Rewrite this incident report as a concise technical summary: Requests slowed after a deployment increased memory use across all workers."},{"role":"assistant","content":"Requests slowed after a deployment increased memory consumption across the worker pool."}]}

Ces exemples sont volontairement simples.

Un véritable jeu de données d’entraînement doit être assez varié pour apprendre le comportement recherché, sans encourager la mémorisation de quelques phrases.

Vos données doivent aussi ressembler aux requêtes que le modèle recevra après son déploiement.

Si les requêtes de production contiennent de longs documents, mais que vos exemples d’entraînement ne contiennent qu’une phrase en entrée, vous entraînez le modèle sur un autre problème.

Ne commencez pas par verser tous vos documents dans le jeu de données

Davantage d’exemples peut être utile.

Davantage de bruit ne l’est pas.

Avant l’entraînement, recherchez dans le jeu de données :

• les exemples dupliqués
• les réponses contradictoires
• les secrets inclus par erreur
• les informations personnelles identifiantes dont vous n’avez pas besoin
• les conversations mal formées
• les exemples non pertinents
• les réponses contraires au comportement recherché
• les fuites entre les données d’entraînement et de test
• les exemples générés automatiquement qui n’ont jamais été vérifiés

Le fine-tuning amplifie les effets de vos choix de données.

Un jeu de mille exemples propres peut être plus utile qu’un grand jeu de données assemblé sans contrôle éditorial.

Étape 5 : créer le script d’entraînement QLoRA

Créez :

train_lora.py

Le script non testé ci-dessous est un exemple à adapter à l’environnement consigné :

import torch
from datasets import load_dataset
from peft import LoraConfig
from transformers import BitsAndBytesConfig
from trl import SFTConfig, SFTTrainer

MODEL_ID = "meta-llama/Llama-3.1-8B-Instruct"

# Load conversational JSONL data.
dataset = load_dataset(
"json",
data_files="train.jsonl",
split="train",
)

# Load the frozen base model in 4-bit.
quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_use_double_quant=True,
)

# Train LoRA adapters across the model's linear layers.
lora_config = LoraConfig(
r=16,
lora_alpha=32,
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
target_modules="all-linear",
)

training_config = SFTConfig(
output_dir="llama-3.1-8b-qlora",
learning_rate=2e-4,
num_train_epochs=1,
per_device_train_batch_size=1,
gradient_accumulation_steps=16,
gradient_checkpointing=True,
bf16=True,
max_length=2048,
packing=True,
logging_steps=10,
save_strategy="epoch",
report_to="none",
)

trainer = SFTTrainer(
model=MODEL_ID,
args=training_config,
train_dataset=dataset,
quantization_config=quantization_config,
peft_config=lora_config,
)

trainer.train()

trainer.save_model("llama-3.1-8b-lora-adapter")

Il s’agit d’une configuration illustrative, pas d’un environnement testé ni d’hyperparamètres universellement optimaux. Vérifiez l’interface de votre version de TRL, le format de conversation, la troncature et le regroupement avec un petit jeu de données représentatif. Les deux lignes JSONL ci-dessus illustrent le format ; elles ne valident pas l’entraînement et ne garantissent pas un lot regroupé exploitable.

Hugging Face recommande actuellement NF4 pour l’entraînement de type QLoRA sur 4 bits et permet d’appliquer LoRA aux modules all-linear. L’intégration TRL indique aussi que l’entraînement d’adaptateurs utilise généralement un taux d’apprentissage supérieur à celui du fine-tuning complet.

Ce que fait la configuration QLoRA

La partie la plus importante est la suivante :

BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_use_double_quant=True,
)

Cela ne transforme pas votre adaptateur final en une approximation grossière sur 4 bits.

Le modèle de base est chargé sur 4 bits et reste figé. Les calculs utilisent BF16 lorsque la configuration le prévoit, tandis que les paramètres LoRA sont entraînés séparément.

C’est le principe de QLoRA.

Hugging Face recommande actuellement NF4 pour ce type d’entraînement et prend en charge la quantification imbriquée, ou double quantification, pour économiser davantage de mémoire.

Que signifie le rang LoRA ?

Notre configuration utilise :

r=16

Le rang détermine la taille des matrices de faible rang apprises par LoRA.

Un rang supérieur donne à l’adaptateur davantage de capacité entraînable, mais augmente aussi le nombre de paramètres et la mémoire utilisée.

Cela ne signifie pas qu’il faut choisir automatiquement le rang le plus élevé que votre GPU peut accueillir.

Les valeurs courantes comprennent :

8
16
32
64

La valeur utile dépend de la tâche et du jeu de données.

Une adaptation limitée du format peut ne pas bénéficier d’un rang élevé. Une modification plus complexe du comportement peut en bénéficier.

Commencez par une valeur modeste, évaluez-la et augmentez-la si les résultats le justifient, plutôt que de supposer qu’une valeur plus grande est plus sûre.

Pourquoi cibler toutes les couches linéaires ?

Le script utilise :

target_modules="all-linear"

Cela suit l’approche de type QLoRA prise en charge par PEFT.

Vous pouvez aussi limiter LoRA à certaines projections d’attention, par exemple :

["q_proj", "v_proj"]

Cela réduit encore le nombre de paramètres entraînables.

Le compromis est simple : cibler davantage de couches permet à l’adaptateur d’apprendre des modifications à plus d’endroits ; en cibler moins réduit le coût d’entraînement.

La documentation actuelle de PEFT recommande all-linear pour l’entraînement de type QLoRA, car cette option applique l’adaptateur aux couches linéaires du Transformer sans nécessiter les noms propres à chaque architecture.

Étape 6 : lancer le fine-tuning

Avant d’utiliser la commande ci-dessous pour un entraînement complet, adaptez l’exemple à un test court avec des limites explicites de pas et de durée. Avec un accès autorisé au modèle, vérifiez le chargement sur 4 bits, la présence de paramètres d’adaptateur entraînables et un passage avant/arrière. Recherchez les noyaux GPU non pris en charge, les pertes non finies et les erreurs de mémoire ; consignez le pic de mémoire, la durée et les journaux. Le script affiché prévoit une époque, pas une limite explicite de test court.

python train_lora.py

Dans un autre terminal, surveillez le GPU :

watch -n 1 nvidia-smi

Consultez aussi les journaux d’entraînement.

Il ne suffit pas de constater que le GPU travaille.

Vérifiez :

• que la perte diminue
• que l’exécution reste numériquement stable
• que l’utilisation de la mémoire laisse une marge
• que les points de contrôle sont correctement enregistrés
• que les exemples d’entraînement sont interprétés comme prévu

Un entraînement sans erreur peut malgré tout produire un mauvais modèle.

Vérifiez les sorties avant d’optimiser l’utilisation du GPU

Il est tentant d’augmenter la taille des lots jusqu’à occuper chaque mégaoctet de VRAM.

Ce n’est pas le premier objectif.

Commencez par :

per_device_train_batch_size = 1
gradient_accumulation_steps = 16

L’accumulation des gradients permet à l’optimiseur de traiter l’équivalent d’un lot plus grand sans conserver tous les exemples en mémoire GPU en même temps.

Une fois le processus fonctionnel, vous pouvez tester un lot plus grand par appareil et mesurer son effet sur le débit d’entraînement.

Le taux d’utilisation le plus élevé ne correspond pas automatiquement à la meilleure configuration.

La longueur des séquences influe fortement sur la mémoire

Ce tutoriel définit :

max_length=2048

Llama 3.1 prend en charge des contextes bien plus longs, mais l’entraînement avec le contexte maximal du modèle pose un tout autre problème de mémoire.

Si la plupart de vos exemples ne font que quelques centaines de jetons, un entraînement à 128K gaspillerait énormément de calcul et de mémoire.

Choisissez une longueur de séquence adaptée à vos données.

Si des exemples sont tronqués, augmentez-la avec précaution.

Si presque tous les exemples sont courts, une longueur maximale très élevée n’améliore pas le modèle.

Le regroupement peut réduire le coût d’entraînement des exemples courts

Nous activons :

packing=True

Le regroupement, ou packing, combine plusieurs exemples courts dans des séquences plus remplies, au lieu de compléter chaque exemple séparément jusqu’à la longueur maximale.

Cela peut améliorer l’efficacité de l’entraînement lorsque le jeu de données contient beaucoup d’exemples courts. TRL prend actuellement en charge ce regroupement directement avec SFTConfig.

Si vos exemples occupent déjà presque toute la longueur de séquence, le gain est plus faible.

Étape 7 : enregistrer l’adaptateur

À la fin de l’entraînement :

trainer.save_model("llama-3.1-8b-lora-adapter")

Après un enregistrement réussi, la sortie attendue est l’adaptateur LoRA, pas une nouvelle copie complète de Llama 3.1. Inspectez les fichiers et vérifiez le rechargement de l’adaptateur avec la révision consignée du modèle de base avant d’utiliser cette sortie.

Gardez cette relation à l’esprit :

Base model
meta-llama/Llama-3.1-8B-Instruct

+

Adapter
llama-3.1-8b-lora-adapter

Ensemble, ils constituent votre modèle adapté.

Cette séparation est un avantage pratique de LoRA. Vous pouvez conserver plusieurs adaptateurs pour un même modèle de base au lieu de copier le point de contrôle complet à chaque essai.

Étape 8 : tester l’adaptateur

Créez :

test_adapter.py

L’exemple non testé de chargement ci-dessous suppose un adaptateur correctement enregistré et un environnement compatible :

import torch
from peft import PeftModel
from transformers import (
AutoModelForCausalLM,
AutoTokenizer,
BitsAndBytesConfig,
)

MODEL_ID = "meta-llama/Llama-3.1-8B-Instruct"
ADAPTER_PATH = "llama-3.1-8b-lora-adapter"

quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_quant_type="nf4",
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_use_double_quant=True,
)

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

base_model = AutoModelForCausalLM.from_pretrained(
MODEL_ID,
quantization_config=quantization_config,
device_map="auto",
)

model = PeftModel.from_pretrained(
base_model,
ADAPTER_PATH,
)

messages = [
{
"role": "user",
"content": (
"Rewrite this incident report as a concise technical summary: "
"Users could not log in after a configuration change caused "
"authentication requests to time out."
),
}
]

inputs = tokenizer.apply_chat_template(
messages,
add_generation_prompt=True,
return_tensors="pt",
return_dict=True,
).to(model.device)

with torch.inference_mode():
outputs = model.generate(
**inputs,
max_new_tokens=100,
do_sample=False,
)

response = tokenizer.decode(
outputs[0][inputs["input_ids"].shape[-1]:],
skip_special_tokens=True,
)

print(response)

Après ces contrôles, testez l’exemple de chargement avec :

python test_adapter.py

Une seule sortie vous apprend peu de choses.

Testez l’adaptateur sur un jeu d’évaluation distinct, comprenant des exemples qui ne figuraient pas dans les données d’entraînement.

Comparez aussi ces réponses à celles du modèle de base non modifié.

Sans cette référence, vous ne pouvez pas déterminer si le fine-tuning a été utile.

L’évaluation fait partie du fine-tuning

La perte d’entraînement est utile.

Ce n’est pas un indicateur produit.

Si votre objectif est l’extraction structurée, mesurez l’exactitude de l’extraction.

Si le modèle doit produire du JSON valide, mesurez la validité du JSON.

S’il doit suivre une politique d’assistance particulière, construisez un jeu de test autour de cette politique.

Si vous adaptez la terminologie, vérifiez la terminologie.

Le jugement vague selon lequel les réponses « sonnent mieux » constitue une preuve faible, sauf si le style est précisément l’objectif de l’entraînement.

Construisez l’évaluation avant de passer des semaines à ajuster les rangs, les époques et les taux d’apprentissage.

Davantage d’époques n’est pas automatiquement préférable

La configuration illustrative utilise :

num_train_epochs=1

Ce choix est volontairement prudent.

Les jeux de données petits ou répétitifs peuvent rapidement conduire au surapprentissage. Choisir cinq époques parce qu’une seule semble insuffisante peut produire un modèle qui reproduit très bien les schémas d’entraînement, mais généralise mal.

Évaluez les résultats après la première exécution.

Décidez ensuite s’il vous faut :

• davantage d’époques
• davantage de données
• de meilleures données
• un autre rang
• un autre taux d’apprentissage
• un modèle plus grand

Le réglage des hyperparamètres ne peut pas compenser un mauvais jeu de données.

Quand utiliser LoRA plutôt que QLoRA ?

QLoRA est utile lorsque la mémoire GPU constitue la contrainte.

LoRA peut convenir lorsque le modèle tient confortablement en BF16 et que vous voulez éviter de quantifier le modèle de base figé pendant l’entraînement.

Les 32GB d’une RTX 5090 ne suffisent pas à démontrer qu’un entraînement LoRA ou QLoRA d’un modèle 8B tiendra en mémoire. Vérifiez la charge complète et les logiciels pour chaque approche, puis mesurez la mémoire avant d’augmenter les lots ou la longueur des séquences.

Pour les modèles plus grands, QLoRA devient de plus en plus utile, car le modèle figé lui-même consomme beaucoup moins de VRAM.

Ne considérez pas QLoRA comme un algorithme universellement meilleur. C’est une manière de réaliser un entraînement LoRA en utilisant moins de mémoire.

Seule l’évaluation permet de déterminer si une différence compte pour votre application.

LoRA ne vous donne pas la propriété du modèle de base

Entraîner un adaptateur ne supprime pas la licence du modèle sous-jacent.

Notre exemple utilise Llama 3.1, distribué sous la Llama 3.1 Community License de Meta. Le dépôt du modèle définit aussi des conditions de redistribution et de création de modèles dérivés.

Avant de publier ou de distribuer un adaptateur, vérifiez :

• la licence du modèle de base
• les licences des jeux de données
• les droits sur les données d’entraînement
• les conditions de redistribution
• les exigences de dénomination et d’attribution

« Poids ouverts » ne signifie pas « sans conditions ».

Combien coûte le fine-tuning LoRA sur un GPU cloud ?

Le calcul utile est le suivant :

GPU hourly rate × training runtime

Au 28 septembre 2026, Hivenet annonce la RTX 5090 à partir de €0.75 par GPU-heure, avec une facturation à la seconde. Les exemples ci-dessous illustrent uniquement le coût du GPU à ce tarif de départ. Vérifiez le tarif affiché pour votre instance avant de la lancer.

Pour une RTX 5090 :

Durée d’utilisation du GPU et coût indicatif :

• 30 minutes: €0.38
• 1 heure: €0.75
• 2 heures: €1.50
• 4 heures: €3.00
• 8 heures: €6.00

Ce sont des exemples de coûts, pas des estimations de la durée de votre fine-tuning.

La durée d’entraînement dépend de la taille du jeu de données, de la longueur des séquences, de la configuration des lots, de la taille du modèle, du nombre d’époques et des logiciels utilisés.

Mesurez une exécution représentative avant de prévoir un budget d’entraînement important.

Arrêtez l’instance lorsque la tâche est terminée.

LoRA permet de garder des essais de taille raisonnable

L’intérêt de LoRA est parfois résumé à un fine-tuning bon marché.

Cette description passe à côté d’un avantage important.

LoRA limite les modifications apportées au modèle pendant les essais.

Vous pouvez conserver un modèle de base stable, entraîner un adaptateur pour une tâche et un autre pour une autre tâche, les comparer, écarter les mauvais résultats et relancer l’entraînement sans produire chaque fois un point de contrôle complet du modèle.

Cela change la manière dont les équipes peuvent travailler.

Vous n’avez pas à décider qu’un seul fine-tuning deviendra le modèle.

Vous pouvez traiter l’adaptation comme un essai avec un jeu de données, une configuration, une évaluation et un adaptateur définis.

Cette approche est plus raisonnable que de supposer que chaque problème de modèle exige un entraînement de grande ampleur.

Que faire après l’entraînement ?

Une fois l’adaptateur validé par l’évaluation, plusieurs choix s’offrent à vous.

Vous pouvez conserver l’adaptateur séparé du modèle de base, le fusionner lorsque les outils et le mode de déploiement le permettent, ou le servir avec une configuration compatible LoRA.

Si vous prévoyez d’exposer le modèle au moyen d’un serveur d’inférence, consultez notre guide vLLM.

Pour des tâches d’entraînement reproductibles, vous pouvez aussi enregistrer l’environnement fonctionnel sous forme de configuration Compute réutilisable, au lieu de reconstruire les dépendances à chaque essai.

Si le modèle dépasse ce qu’un seul GPU peut traiter confortablement, passez à une configuration GPU plus importante parce que la charge de travail l’exige, pas parce que le multi-GPU semble préférable en soi.

FAQ sur le fine-tuning LoRA

Qu’est-ce que le fine-tuning LoRA ?

LoRA, ou Low-Rank Adaptation, est une méthode de fine-tuning économe en paramètres. Elle fige les poids d’origine du modèle et entraîne de petites matrices de faible rang ajoutées à certaines couches.

Quelle est la différence entre LoRA et QLoRA ?

LoRA entraîne des adaptateurs tout en conservant le modèle de base figé. QLoRA quantifie aussi ce modèle, généralement sur 4 bits, ce qui réduit davantage les besoins en mémoire GPU.

LoRA modifie-t-il tous les poids du modèle ?

Non. Les poids d’origine restent figés. L’entraînement modifie les paramètres de l’adaptateur LoRA.

Peut-on adapter Llama avec LoRA ?

Oui. Hugging Face PEFT et TRL prennent en charge l’entraînement LoRA et QLoRA pour les modèles de langage causaux comme Llama.

Peut-on adapter Llama 3.1 8B sur un seul GPU ?

Un entraînement sur un seul GPU peut être possible avec une configuration adaptée et économe en paramètres. QLoRA réduit la mémoire du modèle de base figé, mais il faut vérifier la capacité mémoire et la compatibilité logicielle pour la charge réelle. Cet article ne fournit pas d’exécution validée de Llama 3.1 8B sur un GPU de 32GB.

Quelle quantité de VRAM faut-il pour le fine-tuning LoRA ?

Il n’existe pas de valeur unique. La taille du modèle, la précision, la taille des lots, la longueur des séquences, le rang LoRA, les couches ciblées et la configuration d’entraînement influent tous sur l’utilisation de la VRAM.

Quel rang LoRA choisir ?

Les rangs 8, 16, 32 et 64 sont des points de départ courants. Un rang supérieur augmente la capacité entraînable et le nombre de paramètres. Si la tâche le justifie, évaluez plusieurs valeurs au lieu de supposer que le rang le plus élevé est le meilleur.

LoRA est-il préférable à un fine-tuning complet ?

Cela dépend de la tâche. LoRA consomme beaucoup moins de ressources et suffit souvent pour adapter une tâche ou un comportement. Le fine-tuning complet donne le contrôle sur tous les paramètres du modèle, mais exige beaucoup plus de calcul et de mémoire.

Faut-il utiliser LoRA ou le RAG ?

Utilisez LoRA pour modifier le comportement du modèle. Utilisez le RAG lorsque le besoin principal est de récupérer des informations factuelles dans des documents ou des données susceptibles de changer. Les deux approches peuvent aussi être combinées.

Quelle quantité de données d’entraînement faut-il pour LoRA ?

Il n’existe pas de nombre universel utile. La quantité adaptée dépend de la tâche, du modèle, de la variété des entrées et de la qualité des exemples. Un petit jeu de données propre peut être plus performant qu’un jeu beaucoup plus grand et bruité.

Peut-on utiliser plusieurs adaptateurs LoRA avec un seul modèle de base ?

Oui. Conserver les adaptateurs séparés permet de maintenir plusieurs adaptations pour le même modèle sous-jacent, selon les capacités de votre environnement d’inférence.

Faut-il plusieurs GPU pour le fine-tuning LoRA ?

Pas nécessairement. Les modèles plus petits et les configurations QLoRA peuvent fonctionner sur un seul GPU suffisamment puissant. Le multi-GPU devient utile lorsque la taille du modèle, la longueur des séquences, les besoins en lots ou la vitesse d’entraînement le justifient.

‍