Fine-tuning con LoRA: guida pratica

L'affinamento fine con LoRA (Low-Rank Adaptation) è un metodo efficiente in termini di parametri per adattare un modello linguistico preaddestrato a un compito specifico. Invece di aggiornare ogni peso del modello, LoRA congela i pesi originali e inserisce piccole matrici addestrabili negli strati di attenzione. Il risultato è un adattatore — un file spesso inferiore a 100 MB — che si applica al modello base in fase di inferenza. Si ottiene un comportamento specializzato senza dover riaddestrare miliardi di parametri.

Come funziona LoRA

Una matrice standard di pesi transformer potrebbe essere 4096 × 4096. LoRA decompone l' aggiornamento di tale matrice in due matrici molto più piccole: una di dimensione 4096 × r e l'altra di r × 4096, dove r è il rank (comunemente compreso tra 4 e 64). Durante l'addestramento vengono aggiornate solo queste matrici a basso rank. In fase di inferenza, il prodotto delle due piccole matrici viene sommato nuovamente ai pesi originali congelati — nella maggior parte delle implementazioni non si ha alcun ritardo aggiuntivo, poiché l'adattatore viene unito prima della distribuzione.

Questo è cruciale per l'hardware: poiché i pesi del modello base sono congelati, non richiedono stati dell'ottimizzatore né gradienti. Solo i parametri dell'adattatore ne necessitano. È per questo motivo che i requisiti di VRAM diminuiscono drasticamente rispetto all'affinamento fine completo.

LoRA vs QLoRA

QLoRA, introdotta da Dettmers et al. (2023), carica il modello base in quantizzazione 4-bit NormalFloat (NF4) e mantiene l’adattatore in precisione completa. L’addestramento è più lento rispetto al LoRA standard a causa dell’overhead di dequantizzazione ad ogni passaggio forward, ma i risparmi di VRAM consentono di addestrare modelli da 13B e 70B su hardware accessibile alla maggior parte degli utenti. La qualità rispetto al LoRA completo è solitamente trascurabile per fine-tuning specifici di un compito; per compiti complessi di ragionamento, è possibile una leggera degradazione.

Prima di impegnarsi sull’acquisto di hardware, eseguire il modello target attraverso lo strumento Calcolatore VRAM — tiene conto della dimensione del batch e della lunghezza della sequenza, entrambe fattori che influenzano significativamente i valori indicati.

Rank e Alpha: cosa fanno realmente

Rank (r) controlla l’espressività dell’adattatore. Un rank pari a 4 aggiunge pochissimi parametri e produce modifiche molto sottili; un rank pari a 64 conferisce all’adattatore maggiore capacità di modificare il comportamento del modello, ma aumenta il consumo di VRAM e il rischio di overfitting.

Alpha (α) è un fattore di scala applicato all’output LoRA prima che venga sommato ai pesi congelati. La velocità effettiva di apprendimento dell’adattatore scala come α / r. Mantenere alpha pari al doppio del rank (es. r=16, alpha=32) è il punto di partenza più comune ed è generalmente efficace nella pratica.

Un rank più elevato non garantisce necessariamente risultati migliori. Per la maggior parte dei fine-tuning orientati all’esecuzione di istruzioni, r=16 è sufficiente. Se la loss sul validation set non migliora, aumentare il rank o aggiungere più dati prima di incrementare il numero di epoche.

Requisiti realistici di VRAM e tempo

I valori riportati di seguito presuppongono QLoRA con dimensione del batch pari a 1 e lunghezza della sequenza pari a 2048. Le configurazioni multi-GPU scalano approssimativamente in modo lineare con la VRAM disponibile, ma richiedono una configurazione FSDP o DeepSpeed.

I costi cloud variano. Un singolo A100 da 80 GB su Lambda Labs costa circa $1,50–$2,00/ora a metà del 2026. Un fine-tuning QLoRA su un modello da 7B con 50.000 esempi si conclude tipicamente in meno di due ore — per un costo ben inferiore a $5. Per decisioni relative all’acquisto di GPU, consultare la guida alle GPU per LLM locali.

Strumenti: come eseguire effettivamente un affinamento fine con LoRA

I due framework più diffusi sono Hugging Face TRL + PEFT e Axolotl. Entrambi supportano LoRA e QLoRA. Unsloth è una popolare terza opzione che permette un addestramento fino a 2× più veloce grazie a kernel CUDA personalizzati.

Esempio minimo con 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,  # richiede una colonna "text"
    args=SFTConfig(output_dir="./output", num_train_epochs=3),
)
trainer.train()
model.save_pretrained("./my-lora-adapter")

L’adattatore salvato in ./my-lora-adapter ha tipicamente dimensioni comprese tra 50 e 300 MB. Per ottenere prestazioni di inferenza più rapide, è possibile integrarlo nel modello base utilizzando model.merge_and_unload() prima del salvataggio.

Axolotl (basato su configurazione)

Axolotl gestisce l’intera pipeline a partire da un file YAML, rendendo più semplice la riproducibilità degli esperimenti. Installare con pip install axolotl, quindi:

# 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

Quando l'affinamento fine è lo strumento sbagliato

Il fine-tuning con LoRA risolve un problema specifico: modificare come il comportamento o le risposte di un modello. Non inserisce in modo affidabile conoscenze fattuali. Se il tuo caso d’uso rientra in una di queste categorie, un approccio diverso produrrà risultati migliori con meno sforzo:

• Il modello non dispone di conoscenze aggiornate o proprietarie. Utilizza la generazione con recupero aumentato (RAG). Il fine-tuning su fatti produce modelli che «allucinano» con grande sicurezza su qualsiasi argomento al di fuori della porzione di dati utilizzata per l’addestramento.
• Hai bisogno che il modello segua istruzioni specifiche. Prova innanzitutto un prompt di sistema dettagliato. Un prompt ben progettato su un modello base performante spesso supera in prestazioni un modello più piccolo ma fine-tuned sullo stesso compito.
• Disponi di meno di circa 500 esempi di alta qualità. Il rapporto segnale-rumore è troppo basso; il modello tenderà probabilmente a overfitting. Arricchisci il dataset con ulteriori dati o ricorri invece al few-shot prompting.
• Stai effettuando una prototipazione. Il fine-tuning fissa definitivamente un determinato comportamento. Utilizza l’API e itera sui prompt finché il comportamento non diventa stabile, quindi valuta se procedere con il fine-tuning per ridurre i costi dei token su larga scala. Il Calcolatore dei costi API ti aiuta a quantificare il punto in cui il fine-tuning di un modello locale diventa più economico rispetto al pagamento per ogni token.

Se stai valutando a lungo termine un modello locale fine-tuned rispetto a un’API ospitata, il Calcolatore del punto di pareggio tra auto-hosting e utilizzo di API ti fornisce il punto di pareggio in base al tuo volume di utilizzo e ai costi GPU.

Domande frequenti

Quanti dati servono per il fine-tuning LoRA?

Per l’apprendimento di istruzioni o cambiamenti di stile, spesso bastano da 500 a 2000 esempi di alta qualità e diversificati. Per un adattamento complesso a un dominio specifico, 5000–20000 esempi producono risultati più robusti. La qualità conta molto più della quantità: 200 esempi accuratamente curati superano 2000 esempi rumorosi.

Posso eseguire l’inferenza LoRA su hardware consumer?

Sì. Un adattatore unito (merged) non introduce alcun overhead durante l’inferenza rispetto al modello base. Un adattatore non unito (unmerged) aggiunge una piccola quantità di calcolo per ogni passaggio forward. Sia llama.cpp che Ollama supportano il caricamento diretto di adattatori LoRA convertiti in formato GGUF. Consulta il Guida ai requisiti di VRAM per i dati relativi alla memoria richiesta esclusivamente per l’inferenza.

Qual è la differenza tra LoRA e il fine-tuning completo?

Il fine-tuning completo aggiorna tutti i pesi del modello e richiede di memorizzare gli stati dell’ottimizzatore per ciascuno di essi — circa 16–20 byte per parametro in precisione mista con Adam. LoRA aggiorna soltanto le matrici dell’adattatore a basso rango, riducendo drasticamente il numero di parametri addestrabili (da 10× a 1000×). Il compromesso riguarda la capacità: il fine-tuning completo può ridefinire il modello in modo più radicale, ma per la maggior parte dei compiti pratici LoRA offre prestazioni equivalenti.

Su quali layer devo applicare LoRA?

I layer di proiezione dell’attenzione (q_proj e v_proj) sono i target più comuni e funzionano bene nella maggior parte dei casi. Aggiungere k_proj, o_proj, nonché i layer MLP (gate_proj, up_proj, down_proj) aumenta la capacità a scapito di maggiore VRAM e tempi di addestramento leggermente più lunghi. Se la VRAM è limitata, inizia con le sole proiezioni q e v.

QLoRA produce un modello peggiore rispetto a LoRA completo?

Per la maggior parte dei fine-tuning specifici per compito, la differenza è trascurabile. I benchmark pubblicati mostrano QLoRA entro 1–2 punti percentuali rispetto a LoRA completo su valutazioni standard. Questo divario può ampliarsi su compiti complessi di ragionamento con dataset molto piccoli, poiché il rumore introdotto dalla quantizzazione si somma al segnale già limitato. Se l’accuratezza è critica e disponi di sufficiente VRAM, preferisci LoRA su un modello base in bf16.

Come valuto se il mio fine-tuning ha effettivamente migliorato le prestazioni?

Riserva il 10–20% dei tuoi dati come set di validazione e monitora la loss di validazione durante l’addestramento. Interrompi l’addestramento quando la loss di validazione smette di migliorare (early stopping). Successivamente esegui valutazioni specifiche per il compito: per classificazione, misura l’accuratezza su esempi tenuti da parte; per generazione, utilizza una revisione umana o una configurazione LLM-as-judge su 50–100 esempi. Una diminuzione della loss di validazione che non si traduce in un miglioramento delle prestazioni sul compito è un segnale di mismatch distributivo tra i dati di addestramento e gli input reali.