12 novembre 2026 · Équipe VRAMfarm

Fine-tuner un LLM : combien de VRAM et de GPU pour QLoRA, LoRA et le fine-tuning complet

La plupart des fine-tunings demandent un GPU, pas huit. QLoRA entraîne un modèle 8B sur une carte de 16 Go, un modèle 32B sur une carte de 48 Go et un modèle 70B sur une seule carte de 80 Go. LoRA en 16 bits demande deux à trois fois plus. Seul le fine-tuning complet, qui met à jour tous les poids, vous oblige à prendre plusieurs cartes de 80 Go, même pour un modèle 8B, car il coûte environ 16 octets par paramètre avant les activations. Un entraînement QLoRA typique sur un modèle 8B avec 15 millions de tokens d’entraînement prend 2 à 4 heures sur une RTX 4090 et coûte 1,65 € de temps GPU.

D’abord : avez-vous besoin de fine-tuner ?

Le fine-tuning apprend à un modèle un format, un ton ou une tâche ciblée : répondre dans le style de votre support, extraire des champs dans votre schéma JSON, classer des tickets dans vos catégories. C’est un mauvais moyen d’ajouter des connaissances. Si le modèle doit connaître la documentation de votre produit, mettez les documents sous ses yeux au moment de la question (recherche documentaire, ou simplement un long prompt) et tenez-les à jour sans réentraîner. Essayez d’abord un bon prompt avec quelques exemples sur le modèle de base ; s’il se trompe encore de format ou de style une fois sur cinq, un fine-tuning en vaut la peine.

La mémoire selon la méthode : le calcul

Trois méthodes, trois factures de mémoire très différentes :

• QLoRA charge le modèle de base en 4 bits (environ 0,6 octet par paramètre) et entraîne de petites matrices d’adaptation à côté. La base reste figée : pas de gradients ni d’états d’optimiseur pour elle.
• LoRA fait la même chose avec la base en 16 bits : 2 octets par paramètre, une qualité légèrement meilleure, plus de mémoire.
• Le fine-tuning complet met à jour tous les poids. Avec l’optimiseur AdamW standard en précision mixte, chaque paramètre coûte environ 16 octets : poids et gradients en 16 bits, une copie maîtresse en fp32 et deux états d’optimiseur en fp32. Un optimiseur 8 bits et des poids en 16 bits sans copie maîtresse ramènent cela à environ 6 à 8 octets.

S’y ajoutent les activations, qui grossissent avec la longueur des séquences et la taille du lot. Les chiffres ci-dessous supposent des séquences de 2 000 à 4 000 tokens, un petit lot et le gradient checkpointing, qui recalcule les activations au lieu de les stocker.

Ce sont des fourchettes, car les outils d’entraînement diffèrent : les noyaux d’Unsloth demandent nettement moins que du code Hugging Face standard, et les longues séquences font grimper chaque ligne. Le guide de la VRAM explique le calcul en octets par paramètre, et le guide CUDA out of memory les réglages à actionner quand un entraînement ne tient pas : taille du lot, longueur des séquences, gradient checkpointing, optimiseurs 8 bits.

Une tâche demande rarement un fine-tuning complet. LoRA sur toutes les couches linéaires avec un rang de 16 à 64 récupère l’essentiel du gain pour le style, le format et les tâches ciblées. Le fine-tuning complet justifie son coût pour un pré-entraînement continu sur un grand corpus, une nouvelle langue ou un changement de domaine profond.

Une carte ou plusieurs

Ajouter des cartes peut produire deux effets différents, et un seul économise de la mémoire.

Parallélisme de données (DDP) : chaque carte contient une copie complète du modèle et traite des lots différents. La mémoire par carte reste la même ; la vitesse augmente, environ 1,8 fois avec deux cartes et 3,5 fois avec quatre. Utile quand un entraînement tient sur une carte mais prendrait toute la nuit.

Sharding (FSDP, DeepSpeed ZeRO-3) : poids, gradients et états d’optimiseur sont répartis entre les cartes, qui contiennent ainsi ensemble un modèle qu’aucune ne pourrait contenir seule. C’est ainsi que fonctionnent le fine-tuning complet et LoRA en 16 bits des gros modèles. Les cartes échangent des données à chaque étape, la connexion compte donc : les machines de data center avec NVLink, comme 8 × H100, passent bien à l’échelle ; les cartes grand public comme la RTX 4090 et la 5090 communiquent en PCIe et passent nettement moins bien à l’échelle. QLoRA combiné à FSDP peut même répartir un modèle 70B sur deux cartes de 24 Go, à une vitesse modeste.

La règle pratique : si la tâche tient sur une carte, utilisez une carte. C’est plus simple, et rien ne peut mal tourner entre les cartes. Une seule H100 finit souvent plus tôt et pour moins cher que deux cartes grand public. Prenez plusieurs cartes quand le modèle ne tient sur aucune carte seule, ou quand un entraînement sur une carte prendrait plus d’une journée de travail. Les machines à 2, 4 et 8 cartes sont listées à part dans le catalogue, et les bases de l’entraînement multi-GPU couvrent l’installation ; une machine multi-cartes coûte à peu près le nombre de cartes multiplié par le prix d’une carte, soit environ 15,60 € de l’heure pour 4 × H100.

Les outils : Unsloth, Axolotl, TRL

Unsloth est le moyen le plus rapide de faire du QLoRA ou du LoRA sur une carte. Ses noyaux sur mesure réduisent la mémoire et le temps, il fournit des versions 4 bits prêtes à l’emploi des modèles populaires, et il exporte le résultat sous forme d’adaptateur, de modèle 16 bits fusionné pour vLLM ou de GGUF pour Ollama. Sa prise en charge du multi-GPU est plus récente et plus limitée que celle des deux autres.

pip install unsloth

Si pip remplace au passage le PyTorch de l’image, vérifiez que la nouvelle version correspond à la version CUDA affichée pour la machine avant le lancement ; python -c "import torch; print(torch.cuda.is_available())" doit afficher True.

from unsloth import FastLanguageModel
from trl import SFTTrainer, SFTConfig
from datasets import load_dataset

model, tokenizer = FastLanguageModel.from_pretrained(
    "unsloth/Qwen3-8B", max_seq_length=2048, load_in_4bit=True)
model = FastLanguageModel.get_peft_model(model, r=16, lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    use_gradient_checkpointing="unsloth")

data = load_dataset("json", data_files="/workspace/data/train.jsonl", split="train")
trainer = SFTTrainer(model=model, processing_class=tokenizer, train_dataset=data,
    args=SFTConfig(output_dir="/workspace/out", per_device_train_batch_size=2,
        gradient_accumulation_steps=4, num_train_epochs=3, learning_rate=2e-4,
        logging_steps=10, save_steps=200, bf16=True))
trainer.train()
model.save_pretrained("/workspace/out/adapter")

train.jsonl contient un exemple par ligne, chacun étant une liste messages au format chat (system, user, assistant), que l’outil d’entraînement met en forme avec le modèle de chat propre au modèle.

Axolotl décrit tout l’entraînement dans un seul fichier YAML : modèle, jeu de données, LoRA ou complet, longueur des séquences, et façon d’utiliser plusieurs GPU. Les entraînements deviennent ainsi reproductibles et faciles à comparer. Installez-le avec pip comme l’indique sa documentation (les extras pour flash-attention et DeepSpeed dépendent de votre configuration), puis axolotl fetch examples télécharge des configurations prêtes pour les modèles courants, et axolotl train your-config.yaml lance l’entraînement. Pour un modèle qui ne tient pas sur une carte, ajoutez une section DeepSpeed ZeRO-3 ou FSDP à la configuration ; c’est là qu’Axolotl est plus fort qu’Unsloth.

TRL, de Hugging Face, est la bibliothèque qui se trouve sous une bonne partie de ce qui précède : entraîneurs pour le fine-tuning supervisé, DPO et GRPO, PEFT pour LoRA. Choisissez-la si vous voulez votre propre code d’entraînement. Un script qui fonctionne sur une carte tourne sur quatre avec accelerate launch --num_processes 4 train.py.

Durée et coût

Des fourchettes de planification pour un même jeu de données : 10 000 exemples d’environ 500 tokens, trois epochs, 15 millions de tokens d’entraînement. Les débits viennent du calcul théorique et de retours publics de la communauté, pas de nos propres benchmarks. La durée est proportionnelle aux tokens : deux fois plus de données, deux fois plus d’heures.

Deux tendances ressortent. Les cartes de data center plus rapides coûtent souvent moins cher par entraînement terminé, car les heures diminuent plus vite que le prix n’augmente : comparez les deux lignes 70B. Et le fine-tuning complet d’un modèle 8B est court en temps GPU ; ce qui prend plus longtemps, c’est la préparation des données et l’évaluation autour.

Ajoutez l’installation : 5 à 10 minutes pour installer l’outil d’entraînement, et le téléchargement du modèle, facturé en trafic et en minutes. Pour QLoRA, prenez la version 4 bits quand elle existe ; pour un modèle 70B, cela fait environ 40 Go au lieu de 141 Go. L’article sur le coût par million de tokens applique la même méthode à l’exécution des modèles après l’entraînement.

Faire tourner l’entraînement sur un serveur loué sans perdre de travail

1. Testez d’abord en petit. Entraînez sur 1 % des données pendant les 15 premières minutes, que vous payez de toute façon. Notez les tokens par seconde affichés par l’outil d’entraînement et la mémoire dans nvidia-smi, puis extrapolez avant de lancer l’entraînement complet.
2. Faites-le tourner sans vous. Lancez l’entraînement dans tmux (apt-get install -y tmux, tmux new -s train) ou avec nohup python train.py > /workspace/train.log 2>&1 &. Fermer le navigateur ou la session SSH ne l’arrête alors pas.
3. Faites des checkpoints et copiez-les ailleurs. Réglez save_steps pour qu’un checkpoint arrive toutes les 15 à 30 minutes dans /workspace/out. Le matériel tombe parfois en panne ; si une machine disparaît, la facturation s’arrête à ce moment-là, mais son disque disparaît avec elle. Copiez les checkpoints au fur et à mesure : un dépôt Hugging Face privé, rsync vers votre ordinateur ou votre propre bucket. L’article sur les fichiers après un arrêt explique ce que garde le dossier enregistré.
4. Gardez l’adaptateur, pas la base. Un adaptateur LoRA pèse de quelques dizaines à quelques centaines de Mo : il ne coûte presque rien dans le dossier enregistré, à 0,03 € par Go et par mois. Le modèle de base public peut être retéléchargé.
5. Arrêtez quand c’est fini. La facturation s’arrête dans la minute où vous arrêtez le serveur. La protection contre l’inactivité vous envoie un e-mail après 2 heures sans SSH, Jupyter ni charge GPU, et une heure plus tard enregistre le dossier et arrête le serveur, mais ces heures d’inactivité sont facturées.

Pour utiliser le résultat, servez le modèle de base avec l’adaptateur dans vLLM : vllm serve Qwen/Qwen3-8B --enable-lora --lora-modules support=/workspace/out/adapter, puis appelez le modèle support via son API compatible OpenAI. Ou fusionnez l’adaptateur avec la base dans Unsloth et exportez un GGUF pour Ollama. La comparaison des moteurs d’exécution vous aide à choisir.