Fine-tuning d’un modèle 70B sur une seule carte.

Ce qui tient réellement

LoRA gèle le modèle et entraîne une petite paire de matrices de rang faible à côté de chaque matrice de poids. QLoRA va plus loin et conserve les poids gelés en 4 bits. Ce que vous devez garder en mémoire change complètement en conséquence.

Pourquoi ce n’est pas le cas pour le fine-tuning complet

Le fine-tuning complet en BF16 nécessite environ 16 octets par paramètre : 2 pour le poids, 2 pour son gradient, et 8 pour les deux moments d’Adam en FP32, plus la copie maîtresse. C’est un multiplicateur fixe, et c’est brutal.

Ce sont des ordres de grandeur avec une marge modeste pour les activations — suffisant pour choisir une machine, pas pour garantir un run précis. La longueur de séquence et la taille de lot font bouger sensiblement la colonne QLoRA ; la colonne fine-tuning complet bouge à peine, car elle est dominée par les 16 octets fixes par paramètre.

Modèle par modèle

Le nœud le moins cher de notre catalogue capable d’entraîner chaque modèle avec QLoRA, ainsi que la machine dont vous auriez besoin pour servir le résultat.

L’entraînement veut de la mémoire ; l’inférence veut de la mémoire et de la bande passante. Il est courant que la bonne carte pour l’entraînement soit une carte bon marché à grande mémoire, et que la bonne carte pour l’inférence soit une carte rapide et coûteuse — et comme les deux sont mensuelles ici, faire tourner les deux sur des machines différentes est souvent moins cher que de faire un compromis sur une seule.

Son exécution

Axolotl est préinstallé comme l’une des images du configurateur. Voici un run complet sur une seule carte, depuis une machine vierge.

$ mkdir -p /scratch/ft && cd /scratch/ft
$ cat > qlora.yml <<'YAML'
base_model: meta-llama/Llama-3.3-70B-Instruct
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_linear: true

sequence_len: 2048
sample_packing: true
gradient_checkpointing: true
micro_batch_size: 1
gradient_accumulation_steps: 16
num_epochs: 2
learning_rate: 0.0001
optimizer: paged_adamw_8bit
bf16: true

datasets:
  - path: /scratch/ft/data.jsonl
    type: chat_template
output_dir: /scratch/ft/out
YAML

$ docker run --rm --gpus all --ipc=host --shm-size=16g \
    -v /scratch/ft:/workspace -v /scratch/models:/root/.cache/huggingface \
    -e HF_TOKEN="$HF_TOKEN" \
    axolotlai/axolotl:main-latest \
    axolotl train /workspace/qlora.yml

$ nvidia-smi dmon -s um

# If memory sits just under the card's total, you are one long batch
# away from an out-of-memory error four hours into the run.
# Lower sequence_len or micro_batch_size now, not then.

Les réglages qui comptent

Ce que coûte un mois

La raison pour laquelle le mensuel compte plus pour l’entraînement que pour l’inférence : un projet de fine-tuning n’est pas un seul run. C’est un premier run qui échoue à cause d’un bug de données, un deuxième qui surapprend, un troisième qui fonctionne, puis cinq autres avec des rangs différents.

Comparez cela à une tarification à l’heure sur la durée d’un projet plutôt que d’un run : le guide du seuil de rentabilité fait le calcul. Une machine qui existe pendant trois semaines pendant que vous itérez est exactement le cas où un compteur coûte plus cher qu’une durée d’engagement.

Où LoRA cesse de fonctionner

C’est une très bonne technique avec une limite réelle, et il vaut la peine de savoir de quel côté de cette limite vous vous trouvez avant de louer quoi que ce soit.

Pour tout le reste — un ton, un format, un schéma, un domaine que le modèle de base connaît déjà à moitié — QLoRA sur une seule carte atteint l’essentiel de la qualité pour une fraction de la machine. C’est le compromis, et pour les modèles sur lesquels la plupart des gens font réellement du fine-tuning, c’est un bon compromis.