Ottobre 2026 è stato segnato da tre aggiornamenti quasi simultanei nel mondo del fine-tuning open source: Unsloth ha pubblicato la release 2026.10.2 su PyPI il 7 ottobre, Hugging Face TRL ha tagliato la versione 1.14.2 il 6 ottobre e Axolotl aveva già rilasciato la 0.20.0 il 30 settembre. Per chi in Italia e in Europa deve addestrare o adattare un modello linguistico con un budget GPU limitato, la domanda non è più “si può fare open source”, ma “con quale framework si fa prima e si spende meno”. Questo confronto mette a terra numeri verificati su velocità, consumo di VRAM, licenze e supporto multi-GPU, invece di ripetere gli slogan dei siti ufficiali.
Il contesto aiuta a capire perché il tema è caldo proprio ora. Settembre 2026 è stato il mese con più lanci di modelli dell’ultimo anno, 42 release monitorate secondo BenchLM, il che significa più checkpoint da adattare, più varianti da validare e più pressione sui team che devono scegliere uno strumento di addestramento senza perdere settimane in configurazione. Unsloth, Axolotl e Hugging Face TRL sono oggi le tre opzioni open source più citate per questo lavoro, ciascuna con una filosofia diversa: velocità su GPU singola, controllo granulare via configurazione, oppure integrazione profonda nell’ecosistema Transformers per reinforcement learning e allineamento.
Per chi segue la categoria intelligenza artificiale e machine learning, questo confronto si inserisce in un filone già aperto sul sito: un anno fa la scelta più discussa era tra LLaMA-Factory, Axolotl e Hugging Face generico, oggi la domanda si è spostata su un confronto più specifico, perché Unsloth è passato da curiosità per hobbisti a progetto con 77 mila stelle GitHub e un piano commerciale vero e proprio. Il fine-tuning, va ricordato, non è un punto di arrivo isolato: una volta addestrato un modello, va quasi sempre testato per robustezza e poi servito in produzione, due passaggi su cui questo stesso sito ha già pubblicato confronti dedicati a strumenti come Garak, PyRIT e Giskard per il red teaming e a Ollama, LM Studio e vLLM per l’inferenza.
Cos’è Unsloth e perché la community lo sceglie per la velocità
Unsloth è una libreria Python che riscrive a mano i kernel Triton usati per il fine-tuning, in particolare per RoPE e per gli strati MLP, con l’obiettivo dichiarato di accelerare l’addestramento e ridurre la memoria video necessaria. Il progetto distribuisce il nucleo open source sotto licenza Apache 2.0, mentre l’interfaccia desktop Unsloth Studio è separata e distribuita con licenza AGPL-3.0. Al 8 ottobre 2026 il repository unslothai/unsloth su GitHub conta 77.490 stelle e 7.147 fork, numeri che lo rendono, per popolarità su GitHub, il più seguito dei tre framework analizzati in questo articolo.
Sul fronte release, la libreria segue due canali paralleli: il pacchetto stabile su PyPI è arrivato alla versione 2026.10.2 il 7 ottobre 2026, mentre il canale beta su GitHub ha già pubblicato la release v0.1.905-beta l’8 ottobre 2026. Questo doppio binario, stabile su PyPI e beta su GitHub, è tipico dei progetti che aggiornano i kernel più volte a settimana per inseguire i nuovi modelli, da Gemma 4 a Qwen3.5.
Il punto di forza dichiarato da Unsloth è la combinazione di velocità e risparmio di memoria su GPU singola: la pagina del pacchetto elenca moltiplicatori che vanno da 1,5x a 2x più rapido secondo il workload, con riduzioni di VRAM comprese tra il 20% e l’80%, numeri che sono però claim del produttore e non benchmark indipendenti verificati da terze parti.
Cos’è Axolotl: configurazione YAML e controllo granulare
Axolotl nasce con una filosofia diversa: non punta a essere il motore più rapido in assoluto, ma lo strumento che permette di definire ogni singolo parametro di un addestramento in un file YAML versionabile. Questo approccio piace a chi lavora in team e deve poter riprodurre esattamente lo stesso esperimento settimane dopo, con lo stesso dataset e la stessa configurazione di quantizzazione. Il progetto è ospitato su axolotl-ai-cloud/axolotl, distribuito con licenza Apache 2.0 e, all’8 ottobre 2026, conta 12.537 stelle su GitHub.
L’ultima release stabile è la v0.20.0, pubblicata il 30 settembre 2026 secondo la pagina delle release ufficiale. Axolotl integra anche Unsloth come backend opzionale per accelerare singoli passaggi di training, ma lo fa con dei limiti espliciti: la documentazione ufficiale del progetto chiarisce che “Unsloth provides hand-written optimized kernels for LLM finetuning that slightly improve speed and VRAM over standard industry baselines” e, soprattutto, avverte che “these options are specific to LoRA finetuning and cannot be used for multi-GPU finetuning”, come riportato nella documentazione ufficiale di Axolotl. In altre parole, chi ha bisogno di più GPU in parallelo non può semplicemente attivare l’integrazione Unsloth dentro Axolotl e sperare nello stesso guadagno di velocità riportato per il setup a GPU singola.
Cos’è Hugging Face TRL: l’ecosistema per RLHF, DPO e GRPO
TRL (Transformers Reinforcement Learning) è la libreria di Hugging Face pensata non solo per il fine-tuning supervisionato, ma per l’intera gamma di tecniche di post-training: SFT, DPO, GRPO e reinforcement learning con feedback umano. È il framework con la base di utenti più ampia in termini di ecosistema, perché si appoggia direttamente su Transformers e su Accelerate per la distribuzione multi-GPU e multi-nodo. Il repository huggingface/trl è distribuito con licenza Apache 2.0 e conta 19.470 stelle all’8 ottobre 2026, con l’ultima release, la v1.14.2, pubblicata il 6 ottobre 2026.
Tra le novità più recenti, la release di ottobre introduce il supporto per il modello Nemotron 3.5 Lightning e una guida al training su contesti oltre il milione di token, con un esempio che addestra Qwen3-8B su un singolo nodo da 8 GPU. TRL ha anche integrato una funzione di loss “chunked” per il SFT che, secondo l’attività pubblicata dal team Hugging Face Smol Models, riduce il picco di VRAM fino a 14 volte per quello specifico caso d’uso, non come guadagno generale applicabile a ogni training.
Tabella comparativa: le specifiche tecniche a confronto
Prima di entrare nei benchmark, ecco un quadro sintetico delle caratteristiche verificabili di ciascun framework, raccolte da repository GitHub, pagine ufficiali e documentazione tecnica all’8 ottobre 2026.
| Caratteristica | Unsloth | Axolotl | Hugging Face TRL |
|---|---|---|---|
| Versione più recente | 2026.10.2 (PyPI, 7 ott 2026) | v0.20.0 (30 set 2026) | v1.14.2 (6 ott 2026) |
| Licenza nucleo | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Licenza interfaccia/Studio | AGPL-3.0 (Unsloth Studio) | Non applicabile | Non applicabile |
| Stelle GitHub (8 ott 2026) | 77.490 | 12.537 | 19.470 |
| Fork GitHub | 7.147 | Non pubblicato nei dati raccolti | Non pubblicato nei dati raccolti |
| Formato di configurazione | Script Python / notebook | File YAML | Script Python / Trainer API |
| Target GPU dichiarato (versione gratuita) | GPU singola (ottimizzato) | Multi-GPU | Multi-GPU e multi-nodo |
| Backend distribuito | Proprietario + integrazioni | Accelerate / DeepSpeed | Accelerate, DDP, DeepSpeed |
| Hardware supportato | NVIDIA, AMD, Intel, CPU, Vulkan | Principalmente NVIDIA via CUDA | Dipende dal backend Accelerate |
| Tecniche di post-training | SFT, LoRA, QLoRA, GRPO | SFT, LoRA, QLoRA, DPO | SFT, DPO, GRPO, RLHF |
| Integrazione tra loro | Usato come backend da Axolotl e TRL | Può integrare i kernel Unsloth (solo LoRA, no multi-GPU) | Può integrare i kernel Unsloth |
| Modalità di utilizzo | Libreria + Unsloth Studio (UI locale) | Libreria a riga di comando | Libreria + Trainer API Transformers |
Benchmark di velocità e consumo di VRAM: i dati reali
Qui serve una distinzione netta tra claim di marketing e misure indipendenti. La pagina ufficiale del pacchetto Unsloth su PyPI pubblica una tabella di guadagni specifici per modello: Gemma 4 E2B a 1,5x più rapido con il 50% di VRAM in meno, Qwen3.5 4B a 1,5x con il 60% in meno, gpt-oss 20B a 2x con il 70% in meno, e un caso limite di addestramento GRPO su gpt-oss 20B che arriva a un risparmio di memoria dell’80%. Per i modelli a esperti misti (MoE) come DeepSeek, GLM, Qwen e gpt-oss, Unsloth dichiara un guadagno fino a 12 volte sulla velocità con il 35% di VRAM in meno, grazie a kernel RoPE e MLP scritti su misura.
I numeri di Axolotl e TRL: meno marketing, meno dati pubblici
Axolotl non pubblica una tabella equivalente con percentuali di velocità o di risparmio di memoria riferite al framework nel suo complesso: la sua proposta di valore è il controllo di configurazione, non un numero di velocità headline. Questo non significa che sia più lento, significa solo che il progetto non comunica un benchmark comparabile riga per riga con quello di Unsloth, e qualsiasi cifra di velocità per Axolotl trovata in articoli terzi dovrebbe essere verificata rispetto allo stesso modello, alla stessa lunghezza di sequenza e allo stesso hardware prima di essere usata per decidere.
Hugging Face TRL, invece, pubblica un singolo claim di memoria molto specifico: la funzione di loss chunked per il SFT riduce il picco di VRAM fino a 14 volte, ma questo è legato a quella particolare funzione di loss e non è un moltiplicatore applicabile a ogni training TRL. Una fonte terza, il confronto pubblicato da SecondTalent sulle piattaforme di fine-tuning open source 2026, cita per Unsloth un risparmio di VRAM del 70% come claim del fornitore e un totale di 77,3 mila stelle GitHub, un dato coerente con quanto verificato direttamente su GitHub in questo articolo. Una seconda fonte indipendente, l’analisi di Pinggy sui tool LLM locali più usati nel 2026, confermava lo stesso ordine di grandezza per le stelle GitHub di Unsloth pochi giorni prima.
La lettura corretta di questi numeri è quindi: Unsloth comunica benchmark propri aggressivi e verificabili nella forma, le percentuali sono pubblicate, ma non indipendenti; Axolotl non comunica un numero headline; TRL comunica un singolo guadagno enorme ma circoscritto a una funzione specifica. Nessuno dei tre framework ha, al momento, un benchmark indipendente pubblicato da un laboratorio terzo che confronti tutti e tre sullo stesso modello, sullo stesso hardware e sullo stesso dataset.
Cosa cambia rispetto al confronto con LLaMA-Factory
Chi ha letto il nostro confronto precedente tra LLaMA-Factory, Axolotl e Hugging Face noterà che Axolotl resta il filo conduttore tra le due analisi: è l’unico dei tre framework di allora ancora al centro della scena, mentre LLaMA-Factory si è spostato verso un pubblico più orientato alla riga di comando semplificata e TRL si è ritagliato uno spazio specifico sulle tecniche di allineamento, DPO e GRPO, più che sul fine-tuning supervisionato puro. Unsloth, che in quel confronto non compariva come protagonista, è oggi il nome che genera più discussione proprio perché ha introdotto un modello di business a pagamento sopra un nucleo gratuito, una scelta che nessuno dei concorrenti citati in precedenza ha ancora replicato.
Prezzi e licenze: cosa costa davvero il fine-tuning open source
Tutti e tre i framework sono gratuiti nel loro nucleo open source, ma le strutture di monetizzazione divergono. Axolotl e TRL restano completamente gratuiti: non esiste un livello Pro o Enterprise a pagamento, e il solo costo da sostenere è quello dell’infrastruttura GPU su cui si esegue il training, che sia una workstation locale o un’istanza cloud. Unsloth, al contrario, affianca al nucleo Apache 2.0 un livello Pro e un livello superiore pensati per team e aziende, con prezzo comunicato solo su richiesta commerciale, “contact us” sulla pagina ufficiale, senza una cifra pubblica fissa.
| Piano | Unsloth | Axolotl | Hugging Face TRL |
|---|---|---|---|
| Nucleo open source | Gratuito, Apache 2.0 | Gratuito, Apache 2.0 | Gratuito, Apache 2.0 |
| Livello intermedio | Unsloth Pro: 2,5x più rapido, 20% meno VRAM della versione OSS, fino a 8 GPU, prezzo su richiesta | Non disponibile | Non disponibile |
| Livello avanzato | Tier superiore: fino a 32 GPU, prezzo su richiesta | Non disponibile | Non disponibile |
| Interfaccia grafica | Unsloth Studio (AGPL-3.0), gratuita in locale | Nessuna, solo CLI/YAML | Nessuna, solo API Python |
| Costo di infrastruttura | A carico dell’utente (cloud o locale) | A carico dell’utente (cloud o locale) | A carico dell’utente (cloud o locale) |
| Supporto commerciale dedicato | Sì, nei piani Pro/Enterprise | No, solo community | No, solo community Hugging Face |
Per un team italiano o europeo con un solo tecnico e una GPU consumer, questo significa che il costo reale di ingresso è zero con qualsiasi dei tre framework. La differenza emerge quando si scala: se il collo di bottiglia diventa il numero di GPU disponibili in parallelo, Unsloth spinge verso il piano Pro a pagamento per sbloccare fino a 8 o 32 GPU, mentre Axolotl e TRL restano gratuiti anche in configurazioni multi-nodo, appoggiandosi rispettivamente a DeepSpeed e Accelerate.
Il costo totale, in ogni caso, non dipende solo dalla licenza del framework ma anche dall’affitto della GPU. A titolo di riferimento, una singola NVIDIA H100 80GB su RunPod parte da 1,99 dollari l’ora on-demand per il modello base, con varianti PCIe e SXM che salgono rispettivamente a partire da 2,89 e 3,49 dollari l’ora. Su questa base, un training di alcune ore su un singolo nodo resta accessibile anche per una piccola software house europea, mentre un cluster da 8 GPU per un weekend di addestramento intensivo comincia a pesare seriamente sul budget, a prescindere dal framework scelto: è qui che il risparmio di VRAM dichiarato da Unsloth, se confermato sul proprio workload specifico, può tradursi in un numero di GPU inferiore e quindi in un conto cloud più basso.
Supporto multi-GPU: dove ciascun framework incontra il suo limite
Il multi-GPU è probabilmente il criterio che separa più nettamente i tre progetti. Unsloth, nella sua versione gratuita, è pensato principalmente per GPU singola: la documentazione di Axolotl lo confirma indirettamente, specificando che le ottimizzazioni Unsloth integrate al suo interno funzionano solo con LoRA e non sono compatibili con il fine-tuning multi-GPU. Per sbloccare il multi-GPU nativo di Unsloth serve il piano Pro, fino a 8 GPU, o il livello superiore, fino a 32 GPU secondo la pagina prezzi ufficiale.
Axolotl, invece, offre controllo multi-GPU già nella versione gratuita, sfruttando Accelerate e DeepSpeed per distribuire il carico. TRL segue la stessa logica ma con un ecosistema più ampio: supporta DDP, DeepSpeed e configurazioni multi-nodo, con un esempio concreto nella documentazione che addestra Qwen3-8B su sequenze oltre il milione di token usando un singolo nodo da 8 GPU. Per chi deve scalare oltre una singola macchina senza pagare una licenza commerciale, Axolotl e TRL restano quindi le opzioni più dirette.
Questo criterio, da solo, basta spesso a decidere il framework prima ancora di guardare i benchmark di velocità. Un’azienda che sa già di dover addestrare su più di una GPU fin dal primo giorno, per esempio perché lavora su un modello da 70 miliardi di parametri o più, dovrebbe partire direttamente da Axolotl o TRL, evitando di costruire una pipeline attorno a Unsloth gratuito per poi scoprire a metà progetto che il salto al piano Pro, con prezzo comunicato solo su richiesta, non è compatibile con il budget previsto.
Modelli supportati: Llama, Qwen, Gemma e i modelli MoE
Unsloth elenca esplicitamente nella sua documentazione il supporto per famiglie come Llama, inclusa Llama 3.1, Qwen, Qwen3 e Qwen3.5, incluso l’addestramento GSPO, Gemma, Gemma 4 ed embeddinggemma, e gpt-oss, oltre al supporto per i modelli MoE di DeepSeek, GLM e Qwen tramite i suoi kernel ottimizzati. TRL, dal lato suo, ha aggiunto nella release di ottobre il supporto per Nemotron 3.5 Lightning e lavora in modo nativo con Qwen3 tramite l’integrazione diretta con Transformers.
Perché Axolotl non ha una lista ufficiale così dettagliata
Axolotl, essendo costruito sopra l’API Transformers e configurato via YAML, eredita in teoria il supporto di qualsiasi architettura compatibile con Transformers, ma il progetto non pubblica una matrice ufficiale e aggiornata famiglia per famiglia che permetta di affermare con certezza quali modelli specifici di ultima generazione siano già testati all’8 ottobre 2026. Chi lavora con un modello appena uscito dovrebbe sempre controllare il changelog della release più recente prima di dare per scontato il supporto.
Facilità d’uso: notebook, YAML o Trainer API
I tre framework richiedono competenze diverse. Unsloth punta su notebook pronti all’uso e su Unsloth Studio, un’interfaccia locale pensata per chi vuole partire da zero senza scrivere molto codice di infrastruttura, e funziona su Windows, Linux, WSL e macOS. Axolotl richiede di imparare la sintassi dei file YAML, i campi per dataset, quantizzazione e parallelismo: più verboso all’inizio, ma più facile da versionare in un repository Git e da riprodurre identico mesi dopo. TRL, essendo una libreria nativa dell’ecosistema Hugging Face, richiede familiarità con Transformers, con Accelerate e con il trainer specifico scelto, SFTTrainer, DPOTrainer o GRPOTrainer, il che lo rende la scelta con la curva di apprendimento più lunga ma anche la più flessibile per chi fa ricerca su tecniche di allineamento.
# Esempio minimo di configurazione Axolotl (estratto YAML)
base_model: meta-llama/Llama-3.1-8B
load_in_4bit: true
adapter: qlora
lora_r: 16
lora_alpha: 32
datasets:
- path: tatsu-lab/alpaca
type: alpaca
micro_batch_size: 2
num_epochs: 3
learning_rate: 0.0002Lo stesso tipo di addestramento con Unsloth richiede invece poche righe di Python dentro un notebook, mentre con TRL passa attraverso la classe SFTTrainer di Transformers con configurazione via oggetti Python piuttosto che file YAML. Per chi arriva da zero, questa differenza di formato pesa più della differenza di velocità: un file YAML si legge e si modifica anche senza aprire un editor di codice completo, mentre uno script Python richiede comunque un minimo di familiarità con l’ambiente di esecuzione, che sia un notebook Jupyter o un terminale locale.
Cinque scenari reali: quale framework scegliere
Più che una classifica unica, la scelta dipende dal contesto operativo. Ecco cinque situazioni concrete che ricorrono spesso tra chi fa fine-tuning in produzione o in ricerca.
- Startup con una sola RTX o A100 e budget zero per il training. Unsloth è la scelta più diretta, grazie ai claim di velocità 1,5x-2x e al risparmio di VRAM fino all’80% su workload specifici, che permettono di addestrare modelli altrimenti troppo grandi per una singola scheda. Per un piccolo team italiano che deve adattare un modello da 7-8 miliardi di parametri senza accesso a un cluster, questa è spesso l’unica strada praticabile entro i tempi di un sprint.
- Team che deve riprodurre esperimenti identici settimane dopo per audit o compliance. Axolotl, con la sua configurazione YAML versionabile in Git, riduce il rischio di non ricordare più come era stato configurato un training, un vantaggio concreto per aziende regolamentate che devono documentare ogni passaggio del ciclo di vita del modello, dal dataset di partenza agli iperparametri usati.
- Laboratorio di ricerca che lavora su allineamento, DPO o RLHF. TRL resta il punto di riferimento perché offre i trainer nativi per queste tecniche e si integra senza attriti con l’intero stack Transformers, incluso l’esempio documentato di training su contesti oltre il milione di token con Qwen3-8B.
- Azienda che deve addestrare modelli MoE, DeepSeek, GLM, Qwen MoE, con hardware limitato. Il claim di Unsloth di 12x di velocità e 35% di VRAM in meno per i MoE è il più specifico disponibile su questo scenario tra i tre framework, e può fare la differenza tra riuscire o non riuscire a far entrare il modello in una singola GPU da 80 GB.
- Team enterprise con cluster multi-nodo da 8 o più GPU e contesti oltre il milione di token. TRL, con il suo esempio documentato su Qwen3-8B su un nodo da 8 GPU, e Axolotl, con il supporto DeepSpeed nativo e gratuito, sono le opzioni che non richiedono un piano Pro a pagamento per scalare, a differenza della versione gratuita di Unsloth.
- Freelance o consulente che deve consegnare un modello fine-tuned a un cliente senza infrastruttura propria. La combinazione di Unsloth Studio in locale e di un notebook cloud gratuito o a basso costo permette di consegnare un primo prototipo funzionante senza dover giustificare al cliente l’affitto di un intero nodo multi-GPU.
Dopo il fine-tuning: test di sicurezza e messa in produzione
Un modello addestrato con Unsloth, Axolotl o TRL non è pronto per la produzione nel momento in cui finisce l’ultima epoca di training. Prima di esporlo a utenti reali, la pratica più solida è sottoporlo a test di robustezza contro input malevoli: il nostro confronto tra Garak, PyRIT e Giskard copre esattamente questo passaggio, con tassi di adozione che per questi strumenti di red teaming arrivano al 34% e al 28% secondo i dati raccolti in quell’articolo. Chi lavora specificamente su resistenza agli attacchi di prompt injection può anche guardare ai dati raccolti nel pezzo dedicato a filtri e fine-tuning come difesa dal prompt injection, dove il fine-tuning mirato arriva a bloccare il 92% degli attacchi testati, un risultato che dipende direttamente dalla qualità del framework usato per l’addestramento del classificatore di sicurezza.
Superata la fase di validazione, il modello va servito. Nessuno dei tre framework di questo confronto, Unsloth, Axolotl o TRL, è pensato per l’inferenza a basso tempo di risposta su larga scala: quello è il lavoro di motori dedicati come quelli analizzati nel confronto tra Ollama, LM Studio e vLLM, dove le differenze di velocità misurate arrivano a un rapporto di quasi 20 a 1 tra la soluzione più lenta e quella più rapida in determinati scenari. In altre parole, la scelta del framework di fine-tuning e la scelta del motore di inferenza sono due decisioni separate, ed è un errore comune valutarle come se fossero la stessa cosa.
Guida alla migrazione: passare da un framework all’altro
Cambiare framework di fine-tuning a metà progetto è comune quando un team scopre che il collo di bottiglia non è più la velocità, ma la scalabilità multi-GPU o il bisogno di tecniche di allineamento più sofisticate. Succede anche nel verso opposto: un team che ha costruito la propria pipeline su TRL per fare ricerca su DPO può voler passare a Unsloth in un secondo momento, semplicemente per accelerare l’iterazione quotidiana su una singola GPU durante la fase di sperimentazione, prima di tornare a un setup distribuito per il training finale. Ecco i passaggi pratici per una migrazione senza perdere il lavoro già fatto.
- Esporta gli adapter LoRA e QLoRA nel formato standard di Hugging Face PEFT: tutti e tre i framework sono compatibili con questo formato, quindi i pesi addestrati non vanno persi nel passaggio.
- Verifica la versione di Transformers richiesta dal framework di destinazione: Axolotl e TRL aggiornano spesso la dipendenza minima da Transformers, quindi un ambiente virtuale dedicato evita conflitti.
- Se migri da Unsloth ad Axolotl, ricorda che l’integrazione Unsloth dentro Axolotl funziona solo con LoRA e non con il multi-GPU: se il progetto richiede training distribuito, pianifica di disattivare quell’integrazione.
- Ricostruisci la configurazione in formato YAML se passi a Axolotl, mappando manualmente batch size, learning rate, numero di epoche e target dei moduli LoRA dal tuo script Python originale.
- Se migri verso TRL, scegli il trainer corretto per l’obiettivo, SFTTrainer per il fine-tuning supervisionato, DPOTrainer per la preference optimization, GRPOTrainer per il reinforcement learning, prima di riscrivere la pipeline.
- Ri-esegui un benchmark di velocità e consumo di VRAM sul nuovo framework con lo stesso dataset e la stessa lunghezza di sequenza, perché i moltiplicatori pubblicati da ciascun progetto sono specifici per modello e non si trasferiscono automaticamente al tuo caso.
- Aggiorna la pipeline CI/CD o gli script di addestramento automatizzato con i nuovi comandi: Axolotl usa un comando CLI con il path al file YAML, mentre Unsloth e TRL restano script Python eseguiti direttamente o tramite notebook.
- Conserva i checkpoint intermedi del vecchio framework fino a quando il nuovo setup non ha superato gli stessi test di validazione, per poter tornare indietro senza dover ripetere l’intero addestramento.
Pro e contro di ciascun framework
Riassumendo quanto visto finora in una forma più rapida da consultare, ecco i vantaggi e i limiti principali di ciascun framework, utili per chi deve prendere una decisione senza rileggere tutto l’articolo.
| Framework | Pro | Contro |
|---|---|---|
| Unsloth | Claim di velocità aggressivi su GPU singola; supporto multi-backend, NVIDIA, AMD, Intel, Vulkan; community enorme con 77,5 mila stelle | Multi-GPU gratuito limitato; prezzo Pro non pubblico; Studio con licenza AGPL-3.0 più restrittiva |
| Axolotl | Configurazione YAML riproducibile; multi-GPU gratuito via Accelerate e DeepSpeed; licenza Apache 2.0 su tutto lo stack | Nessun benchmark headline pubblico di velocità o VRAM; curva di apprendimento della sintassi YAML |
| Hugging Face TRL | Trainer nativi per SFT, DPO, GRPO e RLHF; scalabilità multi-nodo documentata; integrazione diretta con Transformers | Richiede familiarità con l’intero stack Hugging Face; nessun claim di velocità generale pubblicato |
Cosa dice la documentazione ufficiale
Oltre ai numeri di velocità e VRAM, vale la pena riportare testualmente cosa scrive la documentazione ufficiale di Axolotl sull’integrazione con Unsloth, perché è la fonte più diretta su uno dei limiti tecnici più rilevanti di questo confronto. La documentazione ufficiale di Axolotl descrive l’integrazione così: “Unsloth provides hand-written optimized kernels for LLM finetuning that slightly improve speed and VRAM over standard industry baselines”. Nella stessa pagina, il team specifica anche il limite più importante per chi pianifica un training distribuito: “these options are specific to LoRA finetuning and cannot be used for multi-GPU finetuning”. È un dettaglio tecnico che vale più di qualsiasi slogan, perché chiarisce che il guadagno di velocità di Unsloth, quando usato dentro Axolotl, non si estende automaticamente agli scenari multi-GPU che molti team enterprise stanno pianificando per il 2027.
Verdetto finale: quale framework vince nel 2026
Non esiste un vincitore unico, ma esiste una scelta corretta per ogni priorità. Se il criterio è la velocità su una singola GPU e il risparmio di memoria per modelli grandi o MoE, Unsloth ha i claim più aggressivi, fino a 12x su MoE, fino all’80% di VRAM in meno su workload specifici, e la community più ampia con 77.490 stelle GitHub all’8 ottobre 2026. Se il criterio è la riproducibilità e il controllo granulare della configurazione senza pagare nulla per il multi-GPU, Axolotl resta la scelta più solida, con 12.537 stelle e una release aggiornata al 30 settembre 2026. Se il criterio è la ricerca su allineamento, DPO, GRPO o RLHF con scalabilità multi-nodo documentata, Hugging Face TRL, con 19.470 stelle e l’ultima release del 6 ottobre 2026, è lo strumento con l’ecosistema più maturo.
Vale anche la pena ricordare che la scelta non è necessariamente definitiva. Molti team che oggi usano Axolotl o TRL in produzione hanno iniziato i primi test con Unsloth su un notebook gratuito, proprio perché la barriera d’ingresso più bassa permette di validare un’idea in poche ore prima di investire tempo in una pipeline più strutturata. Allo stesso modo, un progetto che cresce da un singolo prototipo a un servizio con più clienti finisce quasi sempre per aver bisogno del multi-GPU gratuito offerto da Axolotl o TRL, a meno che il budget per il piano Pro di Unsloth non sia già stato messo a bilancio fin dall’inizio.
Il dato che più interessa chi deve decidere oggi è questo: nessuno dei tre framework richiede un investimento iniziale, tutti e tre sono open source con licenza Apache 2.0 nel loro nucleo, e la vera differenza di costo emerge solo quando si scala su più GPU, dove Unsloth sposta parte della proposta verso un piano Pro a pagamento mentre Axolotl e TRL restano gratuiti.
Domande frequenti
Unsloth, Axolotl e TRL si possono usare insieme nello stesso progetto?
Sì, in parte: sia Axolotl che TRL possono integrare i kernel ottimizzati di Unsloth come backend per accelerare singoli passaggi di training, ma nel caso di Axolotl questa integrazione è limitata al fine-tuning LoRA e non funziona in configurazioni multi-GPU.
Qual è il framework più adatto per chi inizia da zero con il fine-tuning?
Unsloth, grazie ai notebook pronti e a Unsloth Studio, ha la barriera d’ingresso più bassa per chi non ha ancora esperienza con pipeline di training complesse.
Axolotl e TRL sono davvero gratuiti anche per uso commerciale?
Sì, entrambi sono distribuiti con licenza Apache 2.0 senza un livello Pro a pagamento; il solo costo da sostenere è quello dell’infrastruttura GPU usata per l’addestramento.
Cosa succede se ho bisogno di multi-GPU ma voglio restare sulla versione gratuita di Unsloth?
La versione open source di Unsloth è pensata principalmente per GPU singola; per il multi-GPU nativo serve il piano Pro, fino a 8 GPU, o il livello superiore, fino a 32 GPU, entrambi con prezzo comunicato solo su richiesta.
I numeri di velocità pubblicati da Unsloth sono verificati da terzi?
No, sono claim pubblicati direttamente dal produttore sulla pagina del pacchetto PyPI e sul sito ufficiale; al momento non risultano benchmark indipendenti che confrontino tutti e tre i framework sullo stesso modello, hardware e dataset.
Quale framework è più adatto per modelli MoE come DeepSeek o GLM?
Unsloth è il solo dei tre a pubblicare un claim specifico per i modelli a esperti misti, con un guadagno dichiarato fino a 12 volte sulla velocità e il 35% di VRAM in meno.
Serve conoscere Python per usare Axolotl?
Non è strettamente necessario per i casi d’uso standard, perché la configurazione avviene tramite file YAML, ma una conoscenza base di Python aiuta a personalizzare dataset e loop di addestramento non coperti dalla configurazione predefinita.
TRL supporta anche i modelli più recenti come Qwen3 e Nemotron 3.5 Lightning?
Sì, la release v1.14.2 del 6 ottobre 2026 ha aggiunto il supporto per Nemotron 3.5 Lightning, mentre Qwen3 è già documentato nelle guide ufficiali per il training su contesti lunghi.
Cosa devo fare dopo aver completato il fine-tuning con uno di questi tre framework?
Il passo successivo è testare il modello contro input malevoli prima di metterlo in produzione, usando strumenti di red teaming come quelli confrontati nel nostro articolo su Garak, PyRIT e Giskard, e poi scegliere un motore di inferenza dedicato, come Ollama, LM Studio o vLLM, perché nessuno dei tre framework di fine-tuning qui trattati è pensato per servire richieste in produzione a basso tempo di risposta.
