Approfondimenti tecnici

Fine-tuning dei modelli fondazionali: LoRA, QLoRA e oltre

Impara le tecniche per adattare grandi modelli preaddestrati al tuo caso d’uso specifico. Una panoramica del fine-tuning completo, di LoRA, QLoRA, dei metodi basati su adapter e delle strategie PEFT.

AI.info Team · 2026-08-11

Perché il fine-tuning ha bisogno di una strada meno costosa

Il fine-tuning completo aggiorna tutti i pesi di un modello preaddestrato. Per un modello da 7 miliardi di parametri addestrato con Adam in precisione mista, questo significa circa 14 GB per i pesi BF16, altri 14 GB per i gradienti BF16 e circa 56 GB per i due buffer FP32 dei momenti di Adam: nell’ordine di 84–112 GB di memoria GPU, prima ancora di considerare le attivazioni, a seconda di come vengono conservati i pesi master. Se si passa a un modello da 65B, il fine-tuning completo non è più un’operazione da svolgere su una singola GPU: diventa un lavoro distribuito su più nodi, con gli stati dell’ottimizzatore suddivisi tra di essi.

Il fine-tuning efficiente in termini di parametri (PEFT) esiste perché, per adattare un modello a un nuovo compito, gran parte di questa infrastruttura è superflua. I pesi preaddestrati codificano già quasi tutto ciò che serve; di solito l’adattamento consiste in una correzione a bassa dimensionalità che vi si sovrappone. Low-Rank Adaptation (LoRA), introdotto da Edward Hu e coautori di Microsoft nel 2021 (arXiv:2106.09685), ha formalizzato questa intuizione ed è diventato il punto di partenza abituale per un fine-tuning efficiente.

QLoRA, sviluppato da Tim Dettmers e coautori dell’Università di Washington (arXiv:2305.14314, NeurIPS 2023), ha poi combinato LoRA con una quantizzazione spinta, rendendo applicabile la stessa idea a hardware di uso comune. Insieme, hanno trasformato il fine-tuning da un problema di infrastruttura in un’operazione gestibile da una sola GPU di una workstation, anche per modelli con decine di miliardi di parametri.

La matematica di LoRA

L’idea alla base di LoRA è questa: data una matrice di pesi preaddestrati W₀ (di dimensioni d × k) all’interno di un livello lineare, non si modifica affatto W₀. La si mantiene fissa e si aggiunge invece, in parallelo, un aggiornamento a basso rango:

h = W₀x + ΔWx = W₀x + BAx

Qui A è una matrice r × k inizializzata con valori gaussiani casuali, B è una matrice d × r inizializzata a zero (così ΔW = 0 all’inizio dell’addestramento e il modello si comporta esattamente come il modello di base) e r è il rango, in genere molto più piccolo di d o k. Si addestrano soltanto A e B; W₀ resta fissa per tutto il processo. Il paper introduce anche un fattore di scala α, per cui l’aggiornamento effettivo diventa (α/r)·BAx: questo permette di regolarne l’entità indipendentemente da r durante la ricerca degli iperparametri.

Il risparmio di parametri cresce rapidamente. Se W₀ è 4096 × 4096 (all’incirca le dimensioni di una proiezione dell’attenzione in un modello della classe 7B), un aggiornamento completo riguarda circa 16,8 milioni di parametri. Con r=8, BA comprende soltanto (4096×8 + 8×4096) ≈ 65.000 parametri: una riduzione di circa 250 volte per quella singola matrice. Il paper originale riferisce che, applicando il metodo a GPT-3 175B, i parametri addestrabili si riducono di 10.000 volte e la memoria GPU necessaria di 3 volte rispetto al fine-tuning completo con Adam, mentre la qualità eguaglia o supera quella del fine-tuning completo nei benchmark di RoBERTa, DeBERTa, GPT-2 e GPT-3.

Dal punto di vista operativo, contano due proprietà. Primo: poiché gradienti e stato dell’ottimizzatore devono essere mantenuti solo per A e B, la memoria necessaria per i parametri addestrabili cala di diversi ordini di grandezza. I pesi fissi del modello di base devono comunque risiedere in memoria (oppure essere caricati in forma quantizzata, ed è qui che entra in gioco QLoRA), ma non occorre conservare per essi né i gradienti né i momenti di Adam.

Secondo: poiché ΔW = BA ha le stesse dimensioni di W₀, dopo l’addestramento può essere integrato nei pesi di base (W₀ + BA), ottenendo un modello senza latenza aggiuntiva in inferenza né modifiche architetturali. È grazie a questa possibilità di integrazione che gli adapter LoRA si prestano bene alle infrastrutture di distribuzione dei modelli: si possono cambiare gli adapter per ogni richiesta senza toccare il modello di base. È il meccanismo su cui si fondano i sistemi multi-tenant per la distribuzione degli adapter come S-LoRA.

Secondo le indicazioni della libreria PEFT e la prassi della comunità, tra cui gli esperimenti ampiamente citati di Sebastian Raschka, le scelte tipiche degli iperparametri sono: r=8 come ragionevole punto di partenza per un semplice instruction-tuning o un adattamento stilistico; r=16–32 per un adattamento più generale; r=64–256 quando il compito da affrontare si discosta notevolmente dalla distribuzione dei dati di preaddestramento oppure il dataset è ampio e vario.

Un tempo, come punto di partenza, si impostava alpha al doppio del rango (α=2r). Le indicazioni di riferimento sono poi cambiate. In «LoRA Without Regret» (Thinking Machines Lab, 29 settembre 2025), John Schulman e colleghi mantengono α fisso a 32 e regolano invece il tasso di apprendimento, perché la scala 1/r di LoRA rende il tasso di apprendimento ottimale approssimativamente indipendente dal rango. Nei loro esperimenti, il miglior tasso di apprendimento per LoRA è circa dieci volte superiore a quello del fine-tuning completo sullo stesso compito.

La scelta delle matrici di pesi a cui applicare LoRA conta più di entrambi i valori. Applicare LoRA soltanto alle proiezioni query e value dell’attenzione costa meno, ma lo stesso studio ha rilevato che questa scelta dà risultati inferiori anche aumentando il rango fino a raggiungere lo stesso numero di parametri; è l’estensione dell’adapter a tutti i livelli lineari, e in particolare alle proiezioni up e down dell’MLP, a colmare il divario rispetto al fine-tuning completo.

QLoRA: un modello da 65 miliardi di parametri su una sola GPU

LoRA riduce il numero di parametri addestrabili, ma il modello di base, i cui pesi restano congelati, deve comunque risiedere in memoria in un qualche formato numerico: normalmente a 16 bit, che per un modello da 65 miliardi di parametri significa circa 130 GB, ancora troppi per una sola GPU. Il contributo di QLoRA è mantenere il modello di base quantizzato a 4 bit mentre si sottopongono a fine-tuning gli adattatori LoRA applicati al modello, propagando i gradienti attraverso i pesi quantizzati e congelati fino alle matrici degli adattatori, in precisione piena (o a 16 bit).

Tre soluzioni ingegneristiche rendono possibile tutto questo senza compromettere la qualità:

• NormalFloat a 4 bit (NF4). Un tipo di dato per la quantizzazione progettato sulla base di un dato empirico: i pesi delle reti neurali preaddestrate seguono approssimativamente una distribuzione normale. Anziché usare intervalli uniformi (come nel formato int4 standard), NF4 usa intervalli basati sui quantili e calibrati su una distribuzione normale a media zero, così che ogni intervallo contenga la stessa quota della massa di probabilità della distribuzione dei pesi. Dal punto di vista della teoria dell’informazione, per questa specifica distribuzione dei pesi è una soluzione più vicina all’ottimo rispetto a un generico formato a 4 bit, in virgola mobile o intero.
• Doppia quantizzazione. Il processo di quantizzazione introduce a sua volta costanti di scala per ciascun blocco (in genere un numero in virgola mobile a 32 bit per ogni blocco di 64 pesi). QLoRA quantizza anche queste costanti, usando una rappresentazione a 8 bit con blocchi più grandi: in media, riduce così il costo aggiuntivo di circa 0,37 bit per parametro, un risparmio significativo su una scala di decine di miliardi di parametri.
• Ottimizzatori con paginazione. Basata sulla memoria unificata di NVIDIA, questa funzione trasferisce automaticamente le informazioni sullo stato dell’ottimizzatore tra la memoria della GPU e quella della CPU quando, durante il gradient checkpointing, la GPU esaurirebbe altrimenti la memoria. Evita così che i picchi di utilizzo durante l’addestramento provochino arresti per memoria esaurita (OOM), senza richiedere che l’intero stato dell’ottimizzatore risieda stabilmente nella VRAM.

Il risultato principale: QLoRA consente di sottoporre a fine-tuning un modello da 65 miliardi di parametri su una sola GPU da 48 GB, eguagliando le prestazioni del fine-tuning LoRA a 16 bit. Negli esperimenti dell’articolo, la configurazione NF4 con doppia quantizzazione recupera interamente le prestazioni di LoRA a 16 bit su MMLU. La famiglia di modelli Guanaco presentata nell’articolo, addestrata con QLoRA, ha raggiunto il 99,3% del livello di prestazioni di ChatGPT nel benchmark Vicuna con circa 24 ore di fine-tuning su una sola GPU; una variante Guanaco più piccola ha raggiunto il 97,8% in meno di 12 ore su hardware di largo consumo.

Tra i modelli più piccoli, Guanaco da 7 miliardi di parametri occupa circa 5 GB di memoria. Sono questi i numeri che hanno reso «sottoporre a fine-tuning un modello capace su una sola 3090 o 4090» un progetto realistico per un fine settimana, anziché un’impresa da laboratorio di ricerca.

Vale la pena precisare che cosa offre QLoRA e a quale costo: quantizzare il modello di base a 4 bit fa risparmiare memoria, ma aggiunge un passaggio di dequantizzazione al volo durante la propagazione in avanti e all’indietro. Per questo, sulle macchine che hanno memoria sufficiente per eseguire LoRA in precisione piena, l’addestramento con QLoRA è in genere più lento a ogni passo. Il compromesso riguarda la possibilità di far entrare modelli grandi in una memoria limitata, non la velocità di addestramento in sé.

DoRA e gli altri adattatori

Il vincolo di LoRA — ogni aggiornamento deve poter essere espresso come una matrice a rango ridotto — lascia, in alcune attività, un divario misurabile rispetto al fine-tuning completo. DoRA (Weight-Decomposed Low-Rank Adaptation), di Shih-Yang Liu, Min-Hung Chen e altri coautori di NVIDIA (arXiv:2402.09353, presentato oralmente a ICML 2024), affronta direttamente questo divario. DoRA scompone ogni matrice di pesi preaddestrati in una componente di magnitudine e una direzionale; applica poi alla componente direzionale un aggiornamento LoRA standard tramite fine-tuning, addestrando separatamente la componente di magnitudine.

La motivazione è che questa scomposizione rispecchia meglio il modo in cui il fine-tuning completo aggiorna effettivamente i pesi, secondo un’analisi degli autori che confronta le dinamiche di apprendimento di LoRA con quelle del fine-tuning completo. Sul piano empirico, DoRA supera sistematicamente LoRA nei benchmark con LLaMA, LLaVA e VL-BART — relativi al ragionamento basato sul senso comune, al fine-tuning su istruzioni visive e ad attività che combinano immagini o video e testo — senza costi aggiuntivi in fase di inferenza una volta incorporato nel modello: dopo l’addestramento, anche la scomposizione in magnitudine e direzione può essere ricondotta a una matrice di pesi densa.

DoRA non è l’unica variante da conoscere. La libreria PEFT di Hugging Face, l’implementazione di riferimento di fatto per tutta questa famiglia, ne comprende diverse: LoHa (Low-Rank Hadamard Product) e LoKr (Low-Rank Kronecker Product) riprendono tecniche di scomposizione dalla letteratura sugli adattatori per i modelli di diffusione per ridurre ulteriormente il numero di parametri; AdaLoRA assegna il rango ai diversi livelli in modo adattivo, sulla base di un punteggio di importanza, anziché usare ovunque un valore fisso di r, destinando più capacità dove il modello ne ha bisogno; X-LoRA combina più esperti LoRA addestrati mediante un meccanismo di instradamento, secondo un principio simile a quello dei mixture-of-experts.

Tutte queste varianti si basano sulla stessa idea — congelare il modello di base e addestrare accanto a esso una componente piccola — ma comportano compromessi diversi in termini di numero di parametri, capacità espressiva e stabilità dell’addestramento. Per la maggior parte degli impieghi pratici, LoRA nella sua forma semplice o QLoRA rimane la scelta predefinita; vale la pena ricorrere a DoRA quando, in un’attività con dati ragionevolmente diversificati, LoRA rende meno del fine-tuning completo più di quanto si vorrebbe.

L’oblio catastrofico e perché il PEFT lo attenua in parte

Il fine-tuning su un dataset circoscritto può peggiorare la capacità di un modello di seguire istruzioni più generali o le sue conoscenze generali: è il classico problema dell’oblio catastrofico. Si manifesta soprattutto nel fine-tuning completo, in cui tutti i pesi possono cambiare e la discesa del gradiente non ha motivo di preservare le capacità che il dataset usato non rafforza.

Un’analisi del 2024 («LoRA Learns Less and Forgets Less», arXiv:2405.09673) chiarisce il meccanismo: LoRA ottiene risultati inferiori al fine-tuning completo nei compiti che richiedono di apprendere molte informazioni nuove, come la programmazione o la matematica. Ma quello stesso vincolo — l’aggiornamento resta in un sottospazio a rango ridotto, vicino ai pesi originali — fa sì che LoRA dimentichi meno di ciò che il modello di base già sapeva.

Da allora, questa interpretazione è stata precisata, non smentita. Lo studio di Thinking Machines del 2025 rileva che LoRA eguaglia il fine-tuning completo quando si verificano insieme tre condizioni: l’adapter copre tutti i livelli lineari, non soltanto quelli dell’attenzione; il rango è abbastanza alto per il dataset (gli autori usano r=256 per dati supervisionati alla scala del post-training e r=1–32 per l’apprendimento per rinforzo, in cui un gradiente della policy trasporta circa un bit di informazione per episodio); e il tasso di apprendimento viene aumentato di conseguenza. Con questa configurazione, LoRA richiede poco più di due terzi dei FLOP impiegati dal fine-tuning completo per ogni passaggio.

Restano due limiti. Se un dataset supera la capacità dell’adapter, LoRA continua a ottenere risultati inferiori al fine-tuning completo: è questa la lettura corretta del risultato del 2024. Inoltre, LoRA tollera i batch grandi peggio del fine-tuning completo — la riproduzione di Hugging Face con TRL raccomanda una dimensione effettiva del batch inferiore a 32 — e aumentare il rango non elimina questo svantaggio.

Il compromesso è chiaro, ma non privo di costi: l’efficienza parametrica di LoRA e la sua resistenza all’oblio derivano dalla stessa fonte, una capacità espressiva limitata.

Ci sono accorgimenti pratici importanti a prescindere dal metodo di adattamento usato: mantenere basso il numero di epoche (da uno a tre passaggi sul dataset di fine-tuning spesso bastano; andare oltre aumenta il rischio di sovradattamento alla distribuzione circoscritta), mescolare ai dati specifici del dominio una quota di dati generali per l’addestramento a seguire istruzioni, così che il modello continui a esercitare capacità più ampie, e valutare il modello su benchmark generali tenuti da parte, non solo sul compito bersaglio, prima di distribuire un checkpoint sottoposto a fine-tuning.

Nulla di tutto questo è esclusivo di LoRA, ma LoRA e QLoRA rendono il problema meno catastrofico per come sono progettati: i pesi congelati del modello di base restano sempre accessibili con una chiamata. Eliminando l’adapter o riducendone il peso nella fusione si recupera esattamente il comportamento del modello originale.

Quando il fine-tuning non è lo strumento giusto

Il fine-tuning, anche quando costa poco, non è la risposta automatica a «il modello non conosce X» o «il modello non si comporta come Y». Due strumenti affini risolvono problemi diversi:

• La generazione aumentata dal recupero di informazioni (RAG) inserisce nel contesto informazioni aggiornate o proprietarie al momento dell’inferenza. È la scelta giusta quando le conoscenze necessarie cambiano spesso (listini prezzi, documentazione, inventario), quando servono fonti verificabili per una risposta o quando non si hanno abbastanza esempi etichettati per eseguire bene il fine-tuning. La RAG non modifica i pesi del modello: non comporta quindi rischi di oblio né costi di riaddestramento quando la base di conoscenza viene aggiornata.
• Il prompt engineering / few-shot prompting costa ancora meno e spesso basta per controllare il formato, il tono o aspetti circoscritti del comportamento, soprattutto con modelli di base capaci e addestrati a seguire istruzioni.

Il fine-tuning, tramite LoRA/QLoRA o altri metodi, giustifica il suo costo quando il comportamento desiderato riguarda come il modello risponde, anziché che cosa sa: un formato di output coerente, uno stile o una terminologia specifici del dominio, la specializzazione in compiti come la classificazione o l’estrazione strutturata quando serve una bassa latenza e non si vuole inviare un lungo prompt di sistema a ogni chiamata, oppure la distillazione di un modello più circoscritto ed economico affinché eguagli il comportamento di uno più grande in un compito definito.

Una regola pratica ragionevole è iniziare dal prompting, aggiungere la RAG quando al modello mancano fatti recuperabili di cui ha bisogno e ricorrere al fine-tuning solo quando si dispone di abbastanza esempi rappresentativi (in genere da alcune centinaia a poche migliaia per un adattamento su scala LoRA) e si vuole ottenere un comportamento che né il recupero di informazioni né il prompting riescono davvero a produrre. Nella pratica, è comune che i team combinino tutti e tre gli strumenti — una pipeline RAG che alimenta un modello adattato con LoRA, a cui viene dato un conciso messaggio di sistema — invece di considerarli alternative che si escludono a vicenda.

Gli strumenti nella pratica

L’implementazione di riferimento per quanto descritto sopra è la libreria PEFT di Hugging Face, che offre LoRA, QLoRA (tramite l’integrazione con la libreria di quantizzazione bitsandbytes), DoRA, AdaLoRA, LoHa, LoKr e X-LoRA attraverso un’API coerente. Produce checkpoint degli adapter che, a seconda del rango, dei moduli interessati e delle dimensioni del modello di base, vanno in genere da pochi megabyte a qualche centinaio di megabyte. bitsandbytes fornisce le routine di quantizzazione NF4 e degli ottimizzatori paginati da cui dipende QLoRA.

Al livello superiore ci sono framework di addestramento pensati per rendere più semplice la gestione dell’intera pipeline (caricamento dei dati, addestramento distribuito, salvataggio dei checkpoint):

• Axolotl si configura tramite YAML, offre un controllo granulare su quasi ogni parametro di addestramento e si integra con DeepSpeed e con le configurazioni standard di parallelismo distribuito dei dati: è la scelta giusta quando un team ha bisogno di configurazioni di addestramento riproducibili e sottoposte a controllo di versione.
• Unsloth punta sull’efficienza con una sola GPU e con hardware di fascia consumer. Usa kernel Triton personalizzati per accelerare l’addestramento con LoRA/QLoRA e ridurre sensibilmente il consumo di memoria rispetto a un normale ciclo di addestramento con transformers di Hugging Face.
• torchtune, la libreria di post-addestramento di PyTorch, non è più tra questi strumenti. Il 15 luglio 2025 i suoi manutentori hanno annunciato l’interruzione dello sviluppo attivo, promettendo correzioni dei bug critici e patch di sicurezza fino alla fine del 2025, ma nessuna nuova funzionalità. Il repository ora si apre con la frase «Torchtune non è più mantenuto attivamente: lo sviluppo di torchtune si è concluso nel 2025». Le pipeline esistenti funzionano ancora. Per quelle nuove è meglio partire da un altro strumento.

I checkpoint sono ampiamente interoperabili tra gli strumenti ancora attivi, perché tutti salvano gli adapter nel formato di Hugging Face transformers/PEFT: un adapter addestrato con un framework, in genere, può essere caricato e incorporato senza problemi in un altro. È un aspetto importante se un team sperimenta con uno strumento e ne sceglie un altro come standard per l’addestramento in produzione.

Come combinare gli approcci

Il percorso decisionale pratico per adattare un modello di base è questo: partire dal prompting, aggiungere la RAG quando il compito richiede fatti che il modello non conosce e considerare il fine-tuning uno strumento per cambiare il comportamento, non le conoscenze. Nel fine-tuning, LoRA è la scelta predefinita per tutto ciò che entra nelle GPU disponibili a 16 bit; QLoRA è l’alternativa quando il modello di base non vi entra, a scapito di parte della velocità di addestramento. Vale la pena provare DoRA quando un addestramento con LoRA non raggiunge la qualità possibile e il costo aggiuntivo della scomposizione direzionale è sostenibile.

Ora c’è un ordine in cui regolare i parametri. Prima i moduli interessati: includere ogni livello lineare prima di mettere a punto qualsiasi altra cosa. Poi il tasso di apprendimento, all’incirca un ordine di grandezza superiore a quello che si userebbe per lo stesso addestramento con fine-tuning completo. Terzo, il rango, commisurato a quanto il dataset deve effettivamente insegnare, anziché a un valore predefinito. Infine, verificare i risultati sui benchmark delle capacità generali oltre che sul compito specifico, per individuare eventuali perdite di capacità prima della messa in produzione.