Unsloth: fine-tuning alla portata
Addestrare un modello sul tuo dominio con la memoria che hai. Il motore che ha spostato il fine-tuning da 'serve un datacenter' a 'sta su una GPU da gioco'.
Il video parte solo se lo chiedi: nessuna richiesta a YouTube prima del click.
Unsloth non è un modello e non è un’interfaccia: è il motore che rende l’addestramento possibile su hardware modesto. Riscrive a mano le parti più pesanti del processo, e il risultato — senza perdita di qualità — è circa il doppio della velocità con una frazione della memoria richiesta.
Tradotto: il fine-tuning passa da “serve un datacenter” a “sta su una GPU da gioco o su un notebook gratuito in cloud”.
Prima di partire: ti serve davvero?
Vale la pena ripetere quello che diceva la lezione sul fine-tuning, perché è l’errore più costoso in circolazione.
| Vuoi… | Serve il fine-tuning? |
|---|---|
| Insegnare uno stile, un tono, un formato | sì, è il suo mestiere |
| Insegnare fatti, documenti, dati aggiornabili | no, serve il RAG |
| Migliorare su un compito ripetitivo e ben definito | probabilmente sì |
| Aggiungere conoscenza che cambia nel tempo | mai |
La distinzione in una riga: il fine-tuning cambia come il modello risponde, il RAG cambia cosa sa. Confonderli porta a mesi persi.
Come funziona in pratica
Il percorso è sempre lo stesso. Si prepara un insieme di esempi nel formato istruzione-risposta; si sceglie un modello base; si addestra un adattatore LoRA — quindi senza toccare i pesi originali, come nella lezione dedicata; si prova; si esporta.
Il passo che chiude il cerchio è proprio l’esportazione: il modello addestrato si converte in GGUF e si carica in Ollama, dove diventa un modello come tutti gli altri, richiamabile per nome.
Dove si vince e dove si perde
Il fattore decisivo non è la potenza della macchina, sono i dati. Cinquecento esempi scritti bene e coerenti battono cinquemila raccogliticci. Se vuoi un certo tono, ogni singolo esempio deve avere quel tono: le eccezioni insegnano al modello che l’eccezione è ammessa.
L’insidia da conoscere è l’overfitting: il modello impara a memoria invece di generalizzare, e si riconosce perché va benissimo sugli esempi di addestramento e male su tutto il resto. Si evita tenendo da parte una fetta di dati per il controllo e fermandosi presto, senza esagerare con i cicli.
Una nota realistica sulla scala: il fine-tuning è alla portata, ma non è istantaneo. Preparare i dati richiede più tempo dell’addestramento vero e proprio, ed è la parte che nessuno racconta nei tutorial.
Il dataset: dove si vince davvero
Tutto il resto — hardware, parametri, durata dell’addestramento — conta meno della qualità degli esempi. È la parte che i tutorial liquidano in due righe ed è quella che occupa la maggior parte del tempo vero.
| Regola | Perché |
|---|---|
| Coerenza assoluta nello stile | Le eccezioni insegnano che l’eccezione è ammessa |
| Varietà nei casi | Esempi tutti simili producono un modello fragile |
| Includere i casi difficili | Con soli esempi facili, il modello cede sui casi veri |
| Qualità sopra quantità | 500 esempi curati battono 5.000 raccogliticci |
L’errore più frequente è il primo: si raccolgono esempi da fonti diverse, con toni diversi, e si spera che il modello faccia la media. Non fa la media: impara che qualsiasi tono è accettabile e ne sceglie uno a caso.
Un modo pratico di partire: scrivi a mano venti esempi perfetti, quelli che rappresentano esattamente ciò che vuoi, e usali come riferimento per generarne o selezionarne altri.
Come capire se è servito
Finito l’addestramento serve la risposta a una domanda sola: è meglio di prima? Tre misure, tutte necessarie.
Prima, su esempi mai visti, tenuti fuori dall’addestramento dall’inizio. Seconda, contro il modello base: stessi esempi, risposte affiancate — se non c’è differenza visibile, il fine-tuning non è servito. Terza, su compiti generici fuori dal dominio, per accorgersi di cosa il modello ha perso strada facendo.
La terza è quella che si salta ed è quella che fa male: è facile ottenere un modello bravissimo sul proprio compito e diventato inutile su tutto il resto.
E una nota realistica: preparare i dati richiede più tempo dell’addestramento vero e proprio. Metti in conto tre giri prima di avere qualcosa di usabile.
Il percorso completo, passo per passo
Vale la pena vedere l’intero giro, perché la parte di addestramento — quella che tutti raccontano — è la più breve.
1. DATI coppie istruzione/risposta, coerenti e verificate
(il 60-70% del tempo reale sta qui)
↓
2. ADDESTRA LoRA/QLoRA sopra un modello base
(i minuti che vedi nei tutorial)
↓
3. VALUTA esempi tenuti da parte + confronto col base + regressioni
↓
4. ESPORTA adattatore unito al modello, conversione in GGUF
↓
5. USA importato in Ollama, diventa un modello come gli altri
Il passo che chiude il cerchio è il quarto: senza l’esportazione ti resta un adattatore che vive solo nell’ambiente di addestramento. Convertito, il modello si richiama per nome come qualsiasi altro, e a quel punto tutto ciò che sai fare con i modelli locali vale anche per il tuo.
Dove gira e dove no
Punto pratico che evita mezze giornate perse: serve una scheda grafica NVIDIA. Su Apple Silicon questa libreria non gira — per il fine-tuning su Mac esiste un’altra strada, basata sul framework di Apple.
| Situazione | Praticabile? |
|---|---|
| GPU NVIDIA da 8-12 GB | Sì, modelli fino a 7-8B con QLoRA |
| GPU NVIDIA da 24 GB | Sì, comodo, anche modelli più grandi |
| Notebook cloud gratuito | Sì, con i limiti di tempo della sessione |
| Apple Silicon | No, serve l’alternativa basata su MLX |
| Solo processore | No |
Il notebook cloud gratuito è il modo più veloce per capire se la strada ha senso prima di comprare qualcosa: ci si prova con cento esempi, si guarda il risultato, e solo dopo si decide se il problema meritava davvero il fine-tuning o se bastava un prompt migliore.
In sintesi
| Concetto | In una riga |
|---|---|
| Cos’è | Il motore che rende il fine-tuning fattibile su hardware normale |
| Il guadagno | Circa doppia velocità e molta meno memoria, a parità di qualità |
| Il percorso | Dati → LoRA → prova → esporta in GGUF → Ollama |
| Il fattore decisivo | La qualità e la coerenza degli esempi, non la macchina |
| La trappola | Overfitting: bene sugli esempi, male su tutto il resto |
| Dataset | Coerenza e varietà contano più della quantità e dell’hardware |
| Valutazione | Esempi nuovi, confronto col base, e controllo delle regressioni |
| Il giro completo | Dati, addestramento, valutazione, esportazione, uso in Ollama |
| Dove gira | Serve una GPU NVIDIA: su Apple Silicon si usa l’alternativa MLX |
- Unsloth
- Fine-tuning
- LoRA
Lezioni collegate
- Fine-tuning e LoRA
Specializzare un modello senza riaddestrarlo da zero. E la domanda che viene prima: ti serve davvero il fine-tuning, o basta un prompt migliore o un RAG?
- Hardware per LLM in locale
La memoria è il collo di bottiglia, tutto il resto viene dopo. Come calcolare cosa ti serve davvero e cosa aspettarti dalla macchina che hai già.