Fare fine-tuning di un modello 70B su una scheda.

Cosa ci sta davvero

LoRA congela il modello e addestra una piccola coppia di matrici a basso rango accanto a ogni matrice di pesi. QLoRA va oltre e mantiene i pesi congelati a 4 bit. Ciò che deve restare in memoria cambia completamente di conseguenza.

Perché il fine-tuning completo no

Il full fine-tuning in BF16 richiede circa 16 byte per parametro: 2 per il peso, 2 per il suo gradiente, e 8 per i due momenti di Adam in FP32, più la copia master. È un moltiplicatore fisso, ed è spietato.

Queste sono cifre di ordine di grandezza, con un margine modesto per le attivazioni — sufficienti per scegliere una macchina, non per garantire un’esecuzione specifica. La lunghezza della sequenza e la dimensione del batch influenzano notevolmente la colonna QLoRA; la colonna del fine-tuning completo si sposta a malapena, perché è dominata dai 16 byte fissi per parametro.

Modello per modello

Il nodo più economico del nostro catalogo in grado di addestrare ciascun modello con QLoRA, insieme alla macchina che servirebbe per il serving del risultato.

L’addestramento vuole memoria; il serving vuole memoria e larghezza di banda. È comune che la scheda giusta per l’addestramento sia una economica e con molta memoria, e che la scheda giusta per il serving sia una veloce e costosa — e poiché qui sono entrambe mensili, eseguire le due su macchine diverse è spesso più economico che scendere a compromessi su una sola.

Eseguirlo

Axolotl è preinstallato come una delle immagini del configuratore. Questo è un run completo su una singola scheda, a partire da una macchina vuota.

$ 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.

Le impostazioni che contano

Quanto costa un mese

Il motivo per cui il mensile conta di più per l’addestramento che per il serving: un progetto di fine-tuning non è un run solo. È un primo run che fallisce per un bug nei dati, un secondo che va in overfitting, un terzo che funziona, e poi altri cinque con rank diversi.

Lo confronti con la tariffazione oraria calcolata sull’intero progetto anziché su una singola run: la guida al punto di pareggio fa i conti. Una macchina che esiste per tre settimane mentre lei itera è esattamente il caso in cui un contatore costa più di un abbonamento.

Dove LoRA smette di funzionare

È una tecnica molto valida con un limite reale, ed è utile sapere da che parte di quel limite ci si trova prima di noleggiare qualcosa.

Per tutto il resto — un tono, un formato, uno schema, un dominio che il modello base conosce già in parte — QLoRA su una singola scheda raggiunge gran parte della qualità con una frazione della macchina. Questo è il compromesso, ed è un buon compromesso per i modelli su cui la maggior parte delle persone fa davvero fine-tuning.