Perché il fine‑tuning è ora accessibile
Un team ha ricevuto un preventivo di 50 000 $ da un fornitore per costruire un “modello AI personalizzato” addestrato sui propri ticket di supporto. Uno dei membri, scettico, ha dedicato un weekend a testare la tecnica alla base del preventivo. Il conto della GPU è risultato inferiore a 10 $, dimostrando che la differenza non è un errore di arrotondamento ma una realtà consolidata.
Il fine‑tuning dei LLM è spesso percepito come un’attività riservata ai laboratori di ricerca: addestrare un modello di frontiera da zero può costare decine o centinaia di milioni di dollari. Tuttavia, adattare un modello open‑weight già pre‑addestrato a un compito specifico rientra in una categoria di costo molto diversa. Molti tutorial si fermano a una sola tecnica o non mostrano codice eseguibile. Questo articolo colma entrambe le lacune, presentando cinque approcci concreti, con esempi pratici e script funzionanti.
Quando è davvero opportuno il fine‑tuning
Il fine‑tuning parte da un modello già pre‑addestrato su un corpus generico e lo riaddestra su un dataset più ristretto e specifico. Il risultato è un comportamento più allineato a requisiti di formato, dominio o tono, senza dover partire da zero.
È importante confrontare il fine‑tuning con altre strategie di personalizzazione: prompt engineering, esempi few‑shot e retrieval‑augmented generation. Queste tecniche non modificano i pesi del modello, quindi sono più veloci da testare e più facili da aggiornare. Il fine‑tuning, al contrario, altera il modello stesso e richiede un impegno più strutturato.
Secondo la guida di Let’s Data Science (2026), il fine‑tuning è vantaggioso in tre scenari tipici:
- Il dominio è altamente specializzato (es. linguaggio medico, legale).
- Il formato di output deve rispettare standard rigidi (es. report strutturati).
- Le performance con prompt ottimizzati rimangono insufficienti per i requisiti di accuratezza.
Al contrario, circa l’80 % delle richieste che si presentano come “necessitiamo di fine‑tuning” può essere risolta con un miglioramento del retrieval, secondo hjLabs (2026). Pertanto, è fondamentale valutare attentamente la motivazione prima di impegnarsi.
Modelli open‑weight compatibili
Molti famosi family di modelli supportano il fine‑tuning direttamente, grazie a tool maturi e community attive:
- Llama 3.x
- Qwen 2.5 e 3
- Mistral
- Gemma 2‑4
- Phi
Tutte e cinque le tecniche descritte qui funzionano con queste architetture, rendendo la scelta del modello una questione di preferenze di licenza e performance.
Opzioni gestite vs. self‑hosted
Per i team che non vogliono gestire l’infrastruttura di training, esistono API di fine‑tuning gestite. OpenAI e Google offrono servizi di fine‑tuning per modelli selezionati; provider come Together AI e Fireworks propongono il “pay‑per‑token LoRA”, che elimina la gestione hardware a costo di un token‑price leggermente più alto.
Queste soluzioni sono ideali per sperimentazioni rapide o per piccole imprese, ma possono diventare costose su volumi elevati di token o quando è necessario un controllo fine sulla pipeline di training.
Limiti di scala e costi reali (2026)
Le tecniche illustrate presuppongono modelli densi tra 2 B e 13 B di parametri, gestibili su una singola GPU. Oltre i 70 B, o con architetture mixture‑of‑experts, anche QLoRA richiede più GPU per contenere i pesi quantizzati.
Ecco una panoramica dei costi di GPU a metà 2026:
- Metodo a parametri efficienti (LoRA/QLoRA) su modello 2‑8 B: < 10 $ di tempo GPU.
- Fine‑tuning completo di modello più grande su infrastruttura premium: > 10 000 $.
- LoRA o QLoRA su modello 7‑8 B: 3‑10 $ su A100 (2‑4 h) o < 3 $ su RTX 4090.
- QLoRA su modello 70 B: 15‑30 $ di GPU.
Nonostante il costo di calcolo sia ora marginale, il vero budget di progetto è dominato da:
- Creazione e pulizia del dataset.
- Iterazioni multiple di training ed eval.
- Manutenzione continuativa con aggiornamenti del modello di base.
Per questo motivo, i progetti reali si attestano ancora tra 5 000 $ e 15 000 $, anche quando il singolo run di GPU costa pochi dollari.
Le cinque tecniche in sintesi
Le tecniche sono organizzate così:
- Algoritmica: LoRA.
- Algoritmica + quantizzazione: QLoRA.
- Ottimizzazione tool: Unsloth (accelerazione training).
- Obiettivo di training più economico: DPO (Direct Preference Optimization).
- Decisione infrastrutturale: Right‑sizing della GPU (scegliere la scheda più adeguata).
Ogni metodo è progettato per integrarsi con gli altri, creando una catena di risparmio.
1. LoRA – Low‑Rank Adaptation
LoRA è il punto di partenza. Invece di aggiornare tutti i pesi, si “congela” il modello base e si aggiungono matrici a basso rango addestrabili accanto a quelle esistenti. L’idea, introdotta da Hu et al. (2021), è che le modifiche necessarie per un nuovo compito hanno un rango intrinseco basso, quindi pochi parametri bastano.
Un tipico script in Python (usando peft e transformers) per fine‑tuning di Llama 3.1 8B su Dolly 15k appare così:
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, getpeftmodel, preparemodelforint8training
model_name = "meta-llama/Meta-Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.frompretrained(modelname)
model = AutoModelForCausalLM.frompretrained(modelname, torch_dtype="float16")
Preparazione base
model = preparemodelforint8training(model)
lora_cfg = LoraConfig(
r=16, # rank
target_modules="all-linear",
lora_alpha=32,
lora_dropout=0.05,
bias="none",
tasktype="CAUSALLM"
)
model = getpeftmodel(model, lora_cfg)
model.printtrainableparameters() # <1 % dei pesi totali
training loop (simplificato)
for batch in dataloader:
outputs = model(**batch)
loss = outputs.loss
loss.backward()
optimizer.step()
optimizer.zero_grad()
Nota che non c’è quantizzazione; il modello deve stare in VRAM a 16 bit, richiedendo una GPU da 24 GB.
2. QLoRA – Quantized LoRA
QLoRA combina LoRA con la quantizzazione a 4‑bit (NormalFloat). Il modello base viene quantizzato, riducendo la memoria di circa 4 ×, mentre gli adapter LoRA rimangono in precisione più alta.
Lo script precedente si adatta così:
from transformers import BitsAndBytesConfig, AutoModelForCausalLM
from peft import preparemodelforkbittraining
bnb_cfg = BitsAndBytesConfig(
loadin4bit=True,
bnb4bitcompute_dtype="float16",
bnb4bitquant_type="nf4"
)
model = AutoModelForCausalLM.from_pretrained(
model_name,
quantizationconfig=bnbcfg,
device_map="auto"
)
model = preparemodelforkbittraining(model)
... resto identico a LoRA
Con QLoRA, lo stesso fine‑tuning di Llama 3.1 8B può essere eseguito su una RTX 4090 (12 GB), con costi GPU inferiori a 3 $ per una sessione di 2‑3 h.
3. Unsloth – Acceleration toolkit
Unsloth è una libreria open‑source che ottimizza il training su GPU consumer, sfruttando kernel CUDA personalizzati e una gestione più efficiente dei gradienti. L’obiettivo è ridurre il tempo di epoch senza alterare il risultato finale.
Per usarla basta aggiungere due righe al proprio script:
import unsloth
unsloth.optimizeforlow_memory()
In test interni, Unsloth ha ridotto il tempo di training di un 30 % su RTX 3080, portando il costo di una run LoRA da 4 $ a circa 2,8 $.
4. DPO – Direct Preference Optimization
DPO è una tecnica di allineamento che sostituisce il tradizionale RLHF (Reinforcement Learning from Human Feedback) con un semplice ottimizzatore di preferenze basato su coppie di risposte. Il vantaggio principale è la drasticità della riduzione dei costi computazionali, perché non richiede step di roll‑out o modello di reward separato.
Esempio di prompt per DPO:
prompt = "Spiega la differenza tra LoRA e QLoRA in 2 frasi."
chosen = model.generate(prompt, temperature=0.0) # risposta preferita
rejected = model.generate(prompt, temperature=0.7) # risposta meno buona
loss DPO (semplificato)
loss = -torch.log(torch.sigmoid(logitschosen - logitsrejected))
Con DPO è possibile allineare un modello su dataset di preferenze con un budget GPU di meno di 5 $, anche per modelli da 10 B parametri.
5. Right‑sizing della GPU
L’ultimo elemento non è una tecnica di algoritmo, ma una decisione infrastrutturale. Spesso i team acquistano o noleggiano GPU di fascia alta (A100, H100) quando una RTX 4090 o una RTX 6000 può essere sufficiente per LoRA/QLoRA su modelli ≤ 13 B.
Linee guida pratiche:
- Modelli 2‑4 B: GPU da 8‑12 GB (RTX 3060/3070) bastano.
- Modelli 5‑10 B: RTX 4080 o RTX 4090 (12‑24 GB).
- Modelli 11‑13 B con QLoRA: RTX 4090 è ottimale; con LoRA puro, considerare A100 40 GB.
Il risparmio più significativo si ottiene scegliendo la GPU più piccola che soddisfi il requisito di memoria, poiché il costo orario di una RTX 4090 è di circa 0,30 $, contro 2,50 $ per un A100 su provider cloud.
Come combinare le cinque tecniche
Un workflow tipico per ottenere il massimo risparmio:
- Seleziona un modello denso ≤ 13 B (es. Llama 3.1 8B).
- Applica QLoRA per ridurre la memoria.
- Abilita Unsloth per accelerare il training.
- Usa DPO come obiettivo di allineamento se hai dati di preferenza.
- Esegui il tutto su una RTX 4090 o una GPU simile, monitorando il consumo di VRAM.
Con questa catena, una pipeline completa – dall’ingestione dei dati alla valutazione finale – può essere realizzata con un costo di GPU inferiore a 5 $, mentre il budget totale rimane intorno ai 3 000‑5 000 $ per coprire data‑engineering, iterazioni e test.
Conclusioni
Il fine‑tuning dei LLM non è più una prerogativa esclusiva dei laboratori di ricerca. Grazie a LoRA, QLoRA, tool come Unsloth, obiettivi di allineamento economici come DPO e una scelta oculata della GPU, è possibile adattare modelli di dimensioni medie a compiti specifici spendendo cifre contenute.
Riconoscere quando il fine‑tuning è davvero necessario, selezionare il modello adatto, e combinare le tecniche presentate, permette a startup, team di prodotto e ricercatori indipendenti di ottenere risultati di livello industriale senza superare il budget di poche migliaia di dollari.
