A settembre 2026 il fine-tuning dei modelli linguistici open source non è più un esperimento da laboratorio universitario. È diventato un passaggio quasi ordinario per chi vuole adattare un LLM a un dominio specifico senza pagare le tariffe API dei modelli chiusi. Tre progetti dominano la scena: Axolotl, la libreria TRL di Hugging Face e LLaMA-Factory. Ognuno prende una strada diversa per risolvere lo stesso problema, e la scelta sbagliata costa settimane di lavoro perso su configurazioni che non scalano. Questo confronto mette a fianco le tre piattaforme di fine-tuning LLM open source più usate nel 2026, con dati verificati su GitHub, prezzi reali delle GPU cloud e casi d’uso concreti.
Il contesto aiuta a capire perché la domanda è tornata centrale. Ad agosto e settembre 2026 sono usciti in rapida successione diversi modelli open-weight di peso: Nemotron 3.5 Lightning 30B-A3B di NVIDIA l’11 agosto, DeepSeek V4 Pro passato a disponibilità generale il 13 agosto, e OLMo 2 32B dell’Allen Institute for AI il 4 settembre, con pesi, dati di addestramento e codice completamente aperti. Ogni nuovo modello aumenta la pressione su chi deve scegliere lo strumento giusto per personalizzarlo. Vediamo cosa cambia tra le tre piattaforme di fine-tuning open source più discusse quest’anno.
Perché il fine-tuning conta ancora nell’era dei modelli general-purpose
Con ChatGPT, Gemini e Claude che coprono la maggior parte dei casi d’uso generici, verrebbe da chiedersi perché un team dovrebbe ancora investire tempo nel fine-tuning. La risposta sta nei margini: un modello open source specializzato costa meno per milione di token, gira su hardware proprietario e non dipende dalla disponibilità di un’API esterna. Per un’azienda che processa milioni di richieste al mese, la differenza tra pagare un provider e ospitare un modello da 7-13 miliardi di parametri regolato sui propri dati può tradursi in risparmi enormi sul lungo periodo.
C’è poi la questione del controllo. Un modello fine-tuned in casa non manda dati sensibili a terze parti, un vincolo che diventa decisivo per banche, ospedali e pubbliche amministrazioni soggette a NIS2 o GDPR. Secondo la guida tecnica di zylos.ai sull’infrastruttura di fine-tuning open source, la raccomandazione pratica è di partire da un modello self-hosted come Llama 4 Scout o Qwen 2.5-72B, servirlo tramite vLLM o SGLang con API compatibili OpenAI, e usare QLoRA per l’adattamento ai task specifici. Il full fine-tuning, secondo la stessa fonte, ha senso solo quando si dispone di almeno 100.000 esempi di alta qualità: sotto quella soglia il rischio di overfitting supera i benefici.
Il terzo motivo è la velocità di iterazione. I framework di fine-tuning moderni permettono di passare da un dataset grezzo a un adapter LoRA funzionante in poche ore, non settimane. Ma “moderno” non vuol dire equivalente: le tre piattaforme che analizziamo in questo articolo si differenziano parecchio su curva di apprendimento, flessibilità e costo operativo.
Un quarto motivo, più specifico al mercato europeo, riguarda la sovranità dei dati. Un modello fine-tuned localmente e servito su infrastruttura europea permette di rispondere a clienti e authority senza dover spiegare dove finiscono i prompt inviati a un’API americana o cinese. Non è un dettaglio da poco per chi lavora con dati sanitari, finanziari o della pubblica amministrazione, dove la localizzazione del trattamento dati è spesso un requisito contrattuale prima ancora che normativo.
Axolotl: il framework YAML-first pensato per la produzione
Axolotl nasce come wrapper attorno a Transformers, PEFT, TRL e DeepSpeed, ma la sua identità è tutta nel file di configurazione YAML. Invece di scrivere script Python per ogni combinazione di iperparametri, si descrive l’esperimento in un unico documento dichiarativo e Axolotl si occupa della parte infrastrutturale. Secondo il repository ufficiale su GitHub, il progetto supporta full fine-tuning, LoRA, QLoRA, GPTQ, quantization-aware training (int8, int4, FP8, NVFP4, MXFP4), preference tuning con DPO, IPO, KTO e ORPO, oltre a reinforcement learning con GRPO e GDPO e reward modeling.
Il progetto è distribuito con licenza Apache 2.0 e conta 12,5mila stelle su GitHub, un numero che riflette l’adozione da parte di team che hanno superato la fase sperimentale sui notebook. Una recensione indipendente pubblicata da scored.tools a giugno 2026 assegna ad Axolotl un punteggio di 9,4 su 10, descrivendolo come il framework “verso cui convergono molti team di produzione” grazie ai default ragionevoli e al supporto nativo per multi-GPU, FSDP e DeepSpeed ZeRO-3.
Un esempio tipico di configurazione per il fine-tuning QLoRA di un modello da 7B assomiglia a questo:
base_model: mistralai/Mistral-7B-v0.3
load_in_4bit: true
adapter: qlora
lora_r: 32
lora_alpha: 16
lora_dropout: 0.05
datasets:
- path: dataset_personalizzato.jsonl
type: alpaca
sequence_len: 4096
gradient_accumulation_steps: 4
micro_batch_size: 2
num_epochs: 3
optimizer: adamw_bnb_8bit
learning_rate: 0.0002
deepspeed: deepspeed_configs/zero2.json
Il limite principale di Axolotl è proprio la sua forza: chi non conosce bene i parametri di training rischia di copiare configurazioni trovate online senza capirle davvero. Non esiste un’interfaccia grafica ufficiale, quindi il progetto resta orientato a team che già lavorano da riga di comando.
Hugging Face TRL: la libreria diventata standard de facto
TRL, acronimo di Transformer Reinforcement Learning, è la libreria ufficiale di Hugging Face per il post-training dei modelli linguistici. A differenza di Axolotl, che è un framework end-to-end, TRL è pensata per essere usata come componente all’interno di uno stack Python più ampio, insieme a Transformers, PEFT e Accelerate. La documentazione ufficiale la descrive come “una libreria full stack” che fornisce strumenti dedicati per Supervised Fine-Tuning tramite SFTTrainer, Group Relative Policy Optimization tramite GRPOTrainer, Direct Preference Optimization tramite DPOTrainer, Kahneman-Tversky Optimization tramite KTOTrainer e reward modeling tramite RewardTrainer.
Il repository huggingface/trl su GitHub conta 19,2mila stelle, un numero intermedio tra Axolotl e LLaMA-Factory, ma che sottostima l’adozione reale: gran parte dei team che usano TRL lo fa indirettamente, attraverso Axolotl stesso o altri wrapper che lo includono come dipendenza. Anche TRL è distribuita con licenza Apache 2.0. Un articolo di secondtalent.com pubblicato a maggio 2026 la definisce “la scelta migliore per l’integrazione completa nell’ecosistema”, sottolineando l’ampia libreria di modelli disponibili su Hugging Face Hub e le opzioni di deploy integrate.
Un esempio minimo di script per il fine-tuning supervisionato con TRL:
from trl import SFTTrainer, SFTConfig
from datasets import load_dataset
dataset = load_dataset("json", data_files="dataset_personalizzato.jsonl")
config = SFTConfig(
output_dir="output-modello",
per_device_train_batch_size=2,
gradient_accumulation_steps=4,
num_train_epochs=3,
learning_rate=2e-4,
bf16=True,
)
trainer = SFTTrainer(
model="Qwen/Qwen2.5-7B",
train_dataset=dataset["train"],
args=config,
)
trainer.train()
Il vantaggio di TRL è la flessibilità totale: si può integrare in pipeline personalizzate, testare metriche custom, agganciare logger diversi. Il costo di questa flessibilità è che serve competenza Python solida. Non c’è un file YAML che astrae la complessità, e chi arriva da zero probabilmente troverà la curva di apprendimento più ripida rispetto ad Axolotl o LLaMA-Factory.
LLaMA-Factory: l’interfaccia web per chi non vuole scrivere codice
LLaMA-Factory, sviluppato da hiyouga e presentato in un paper accettato ad ACL 2024, punta su un target diverso: chi vuole fare fine-tuning senza scrivere una riga di Python. Il repository GitHub lo descrive come “Unified Efficient Fine-Tuning of 100+ LLMs & VLMs” e offre sia una CLI zero-code sia una vera interfaccia web. È l’unico dei tre progetti a includere una GUI ufficiale, un dettaglio che lo rende la scelta più accessibile per team misti, dove non tutti i membri sanno programmare.
Sul fronte tecnico, LLaMA-Factory supporta full-tuning, freeze-tuning, LoRA, QLoRA, OFT e QOFT per il training, oltre a PPO, DPO, KTO, ORPO e SimPO per il preference tuning. È distribuito con licenza Apache 2.0 e, al momento della stesura di questo articolo, conta 74,6mila stelle su GitHub: un numero quasi sei volte superiore ad Axolotl e quasi quattro volte superiore a TRL, il segnale più diretto della sua popolarità tra sviluppatori individuali e piccoli team che cercano un punto d’ingresso rapido.
Un avvio tipico via CLI zero-code:
git clone --depth 1 https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
pip install -e ".[torch,metrics]" --no-build-isolation
llamafactory-cli train \
--stage sft \
--model_name_or_path meta-llama/Llama-3.1-8B \
--finetuning_type lora \
--dataset dataset_personalizzato \
--output_dir output-modello \
--per_device_train_batch_size 2 \
--learning_rate 2e-4 \
--num_train_epochs 3.0
Il rovescio della medaglia è che l’astrazione elevata rende più difficile intervenire su dettagli molto fini del training loop rispetto a TRL usata direttamente in Python. Per progetti di ricerca che richiedono modifiche profonde alla funzione di loss o alla logica di campionamento, LLaMA-Factory può risultare limitante.
Tabella comparativa: le specifiche tecniche a confronto
Ecco un confronto diretto delle caratteristiche tecniche verificate sui repository ufficiali e sulla documentazione di ciascun progetto.
| Caratteristica | Axolotl | Hugging Face TRL | LLaMA-Factory |
|---|---|---|---|
| Tipo di progetto | Framework end-to-end YAML-driven | Libreria Python componibile | Framework end-to-end con GUI |
| Interfaccia | CLI + file YAML | Script Python / notebook | CLI zero-code + Web UI |
| LoRA / QLoRA | Sì, con supporto NVFP4/MXFP4 | Sì, tramite integrazione PEFT | Sì, più varianti OFT/QOFT |
| Full fine-tuning | Sì | Sì | Sì |
| Preference tuning | DPO, IPO, KTO, ORPO | DPO, KTO (trainer dedicati) | PPO, DPO, KTO, ORPO, SimPO |
| Reinforcement learning | GRPO, GDPO | GRPO (GRPOTrainer) | PPO integrato nello stage training |
| Multi-GPU / distribuito | DeepSpeed, FSDP nativi | Via Accelerate (DDP/FSDP/DeepSpeed) | DeepSpeed e FSDP via configurazione |
| Modelli supportati | Famiglie recenti (Llama, Qwen, Mistral e altre) | Qualsiasi modello compatibile Transformers | 100+ LLM e VLM dichiarati nel README |
| Licenza | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Stelle GitHub | 12.500 | 19.200 | 74.600 |
| Curva di apprendimento | Media (richiede familiarità con YAML e training) | Alta (richiede Python e ML solidi) | Bassa (adatta anche a non programmatori) |
| Ideale per | Team che scalano da notebook a produzione | Ricercatori e pipeline personalizzate | Team misti e prototipazione rapida |
Il dato che salta più all’occhio è la distanza tra le stelle GitHub di LLaMA-Factory e quelle degli altri due progetti. Non è un indicatore di qualità tecnica in senso stretto, ma riflette quanto la barriera d’ingresso bassa, con CLI zero-code più Web UI, abbia allargato la base di utenti rispetto a strumenti pensati per chi già scrive pipeline di training in Python.
Benchmark e valutazioni indipendenti: cosa dicono le fonti terze
Non esiste, al momento della stesura di questo articolo, un benchmark pubblico che confronti direttamente Axolotl, TRL e LLaMA-Factory sullo stesso hardware misurando token al secondo o tempo per epoca: nessuna delle fonti consultate pubblica un test del genere. Quello che esiste sono valutazioni qualitative indipendenti, che comunque offrono un quadro utile.
La recensione di scored.tools assegna ad Axolotl 9,4 punti su 10, il punteggio più alto tra i framework di fine-tuning open source recensiti nel suo confronto di giugno 2026, motivandolo con la combinazione di default sensati e supporto nativo per scenari multi-GPU complessi. Deploybase.ai, in una guida sui migliori modelli da sottoporre a fine-tuning nel 2026, non valuta i framework ma segnala che Llama 3 8B resta “la scelta migliore per il fine-tuning in produzione” grazie al supporto community più ampio e alla compatibilità eccellente con la quantizzazione a 4 e 8 bit, un fattore che incide direttamente sulla scelta dello strumento di training da abbinare.
SiliconFlow, piattaforma cloud che offre fine-tuning e deployment gestiti, dichiara nei propri materiali di marketing di raggiungere fino a 2,3 volte la velocità di inferenza e il 32% in meno di latenza rispetto ai principali concorrenti cloud AI. È un dato interessante ma va preso per quello che è: una statistica pubblicata dal fornitore stesso, riferita all’inferenza sulla propria infrastruttura, non un benchmark indipendente sui framework di training discussi in questo articolo. SiliconFlow, insieme a Hugging Face, Firework AI, Axolotl e LLaMA-Factory, compare comunque nella classifica delle cinque piattaforme di fine-tuning più citate nelle guide di settore del 2026.
Il segnale più solido, in assenza di benchmark diretti sulla velocità, resta quindi l’adozione misurata su GitHub e la coerenza delle recensioni indipendenti: Axolotl vince sul punteggio qualitativo, LLaMA-Factory vince nettamente sull’adozione di massa, TRL resta il riferimento tecnico per chi lavora dentro l’ecosistema Hugging Face.
Costi reali: GPU cloud e servizi di fine-tuning gestito a confronto
Tutti e tre i framework sono open source e gratuiti da usare. Il costo vero sta nell’hardware necessario per eseguirli. Ecco i prezzi attuali, verificati direttamente sulle pagine ufficiali di tre provider cloud a settembre 2026.
| Servizio | Configurazione | Prezzo | Fonte |
|---|---|---|---|
| RunPod Secure Cloud | A100 80GB (PCIe/SXM) | 1,59 $/ora | RunPod |
| RunPod Secure Cloud | H100 PCIe | 2,89 $/ora | RunPod |
| RunPod Secure Cloud | H100 SXM | 3,49 $/ora | RunPod |
| Lambda Labs | A100 PCIe 40GB (1x) | 1,99 $/ora | Lambda |
| Lambda Labs | H100 SXM 80GB (1x) | 4,29 $/ora | Lambda |
| Lambda Labs | H100 SXM 80GB (8x, per GPU) | 3,99 $/ora | Lambda |
| Together AI | H100 HGX on-demand | 3,99 $/ora | Together AI |
| Together AI | H100 HGX (prenotazione 181+ giorni) | 3,19 $/ora | Together AI |
| Together AI fine-tuning gestito | Modelli fino a 16B, SFT | 0,48 $ / milione di token | Together AI |
| Together AI fine-tuning gestito | Modelli 70-100B, SFT | 2,90 $ / milione di token | Together AI |
Il confronto mostra due strategie di prezzo diverse. RunPod è il provider più economico per l’affitto grezzo di GPU: un A100 80GB a 1,59 dollari l’ora è meno della metà rispetto alla stessa classe di scheda su Lambda Labs. Together AI, invece, offre un modello ibrido: si può affittare l’hardware a ore oppure pagare il fine-tuning gestito a token, senza doversi occupare di infrastruttura. Per un fine-tuning QLoRA di un modello fino a 16 miliardi di parametri su un dataset da 5 milioni di token, il costo con Together AI si aggira sui 2,40 dollari in modalità gestita, contro qualche ora di affitto GPU se si usa Axolotl o LLaMA-Factory in autonomia su RunPod.
La scelta tra self-hosted e gestito dipende quindi dal volume: sotto una manciata di run di training al mese, il servizio gestito spesso costa meno del tempo ingegneristico necessario per configurare un cluster. Sopra quella soglia, affittare GPU grezze e usare Axolotl o LLaMA-Factory diventa più conveniente, soprattutto se si riesce a saturare l’hardware con più esperimenti in parallelo.
I modelli open-weight compatibili nel 2026
La scelta del framework di fine-tuning non può prescindere dal modello di base che si vuole adattare. Il 2026 ha visto un’accelerazione notevole nei rilasci open-weight, e tutti e tre gli strumenti discussi in questo articolo funzionano con la maggior parte di questi modelli, dato che si appoggiano tutti all’ecosistema Transformers di Hugging Face.
- Llama 4 Scout: contesto fino a 10 milioni di token, eseguibile in INT4 su un singolo server, indicato dalla guida di zylos.ai come punto di partenza per infrastrutture self-hosted.
- Qwen 2.5-72B: citato come modello primario alternativo per deployment self-hosted, servito tipicamente tramite vLLM o SGLang.
- DeepSeek V4 Pro: passato a disponibilità generale (GA) il 13 agosto 2026 dopo un’anteprima iniziata ad aprile. La build GA è API-first, ma i pesi della versione preview restano sotto licenza MIT, quindi utilizzabili per fine-tuning locale.
- Nemotron 3.5 Lightning 30B-A3B: rilasciato da NVIDIA l’11 agosto 2026, è un modello Mixture-of-Experts ottimizzato per throughput agentico, distribuito con licenza OpenMDW-1.1 e disponibile in build ufficiale Ollama MLX per ambienti locali.
- OLMo 2 32B: rilasciato dall’Allen Institute for AI (Ai2) il 4 settembre 2026, con pesi, dati di addestramento e codice completamente aperti, una rarità anche nel panorama open source dove spesso solo i pesi vengono pubblicati.
- Inkling: modello multimodale da 975 miliardi di parametri rilasciato il 15 luglio 2026 da Thinking Machines Lab, il laboratorio fondato da Mira Murati, ex CTO di OpenAI, sotto licenza Apache 2.0 completamente permissiva.
Un tracker dedicato ai rilasci open-weight ha contato nove modelli con pesi scaricabili entro il 27 luglio 2026: Leanstral 1.5, Hy3, Bonsai 27B, Inkling, Nanbeige4.2-3B, Laguna S 2.1, Solar Open 2, KAT-Coder-V2.5-Dev e Kimi K3. Per chi lavora con LLaMA-Factory, la promessa di supporto a “100+ LLM e VLM” copre già la maggior parte di questi nomi al momento della pubblicazione, anche se i modelli più recenti richiedono spesso un aggiornamento della libreria Transformers sottostante prima di poter essere caricati correttamente.
Preparare il dataset: differenze pratiche tra i tre framework
Prima ancora di scegliere il framework, la qualità del dataset decide il risultato del fine-tuning. I tre strumenti condividono in gran parte lo stesso formato di base, ma cambiano le convenzioni con cui lo interpretano, ed è un dettaglio che genera molti errori tra chi passa da uno strumento all’altro.
Axolotl accetta dataset in decine di formati diversi tramite il campo type nel file YAML: Alpaca, ShareGPT, ChatML e formati custom definiti tramite un template Jinja. Questa varietà è comoda quando si riusano dataset pubblici trovati online, ma richiede attenzione: un campo type sbagliato non genera sempre un errore esplicito, a volte produce solo un training silenziosamente peggiore, con la loss che scende comunque ma il modello che impara pattern sbagliati.
TRL, essendo una libreria e non un framework end-to-end, lascia il caricamento del dataset interamente alla libreria datasets di Hugging Face. Questo significa massima libertà, ma anche che ogni trasformazione, come il chat template da applicare o la tokenizzazione dei turni di conversazione, va scritta a mano o presa da uno degli esempi ufficiali. È il framework in cui è più facile introdurre bug nella preparazione dei dati, proprio perché non esiste una validazione automatica dello schema come nei due concorrenti.
LLaMA-Factory adotta un approccio intermedio: i dataset vanno registrati in un file dataset_info.json che ne descrive la struttura, dopodiché la Web UI permette di visualizzare un’anteprima delle conversazioni tokenizzate prima di lanciare il training. Questa anteprima visiva è probabilmente la funzionalità più sottovalutata del progetto: permette di individuare a colpo d’occhio dataset malformattati, un controllo che negli altri due framework richiede di scrivere script di debug separati.
Sicurezza e conformità: fine-tuning on-premise per NIS2 e GDPR
Per le aziende italiane ed europee soggette alla direttiva NIS2 o al GDPR, la possibilità di eseguire l’intero ciclo di fine-tuning senza far uscire i dati dal proprio perimetro è spesso il criterio decisivo, più della velocità o della facilità d’uso. Tutti e tre i framework analizzati in questo confronto possono girare interamente offline, su hardware on-premise o su un cloud europeo, senza alcuna dipendenza da servizi esterni durante il training.
La differenza pratica riguarda la superficie di attacco. TRL, essendo una libreria Python leggera, ha meno dipendenze di sistema da mantenere aggiornate rispetto ad Axolotl, che integra DeepSpeed e diversi backend di quantizzazione. LLaMA-Factory, con la sua Web UI, introduce un servizio web aggiuntivo che va isolato correttamente in rete se il training gira su un’infrastruttura condivisa, un accorgimento spesso trascurato dai team che lo adottano proprio per la sua semplicità d’uso.
Un aspetto che vale la pena sottolineare per chi opera in settori regolati è la tracciabilità dei dati di addestramento. Modelli come OLMo 2 32B, che pubblica dati di training e codice insieme ai pesi, semplificano gli audit di conformità rispetto a modelli i cui dati di origine restano opachi. Per un’azienda che deve documentare la provenienza dei dati usati per addestrare un sistema che poi prende decisioni su clienti reali, partire da un modello con questo livello di trasparenza riduce il lavoro di due diligence necessario prima del deployment in produzione.
Cinque esempi reali di utilizzo in produzione
Al di là delle specifiche tecniche, è utile guardare a come questi framework vengono effettivamente usati.
- Chatbot di supporto clienti su Llama 3 8B: una startup che gestisce ticket in italiano usa Axolotl con QLoRA per specializzare Llama 3 8B sul tono e sul vocabolario del proprio settore, sfruttando la compatibilità del modello con la quantizzazione a 4 bit segnalata da deploybase.ai per contenere i costi hardware.
- Riproduzione di pipeline DPO in ambito accademico: gruppi di ricerca universitari usano TRL direttamente in Python per riprodurre esperimenti di Direct Preference Optimization pubblicati in paper, sfruttando la libertà di modificare la funzione di loss che TRL offre rispetto ai framework più astratti.
- Team enterprise misti con LLaMA-Factory: reparti IT aziendali dove analisti di dominio senza background in machine learning collaborano con ingegneri usano la Web UI di LLaMA-Factory per lanciare esperimenti di fine-tuning senza dover scrivere script, riducendo la dipendenza da un singolo ingegnere ML.
- Cattura del traffico di produzione con OpenPipe: alcune startup nel settore agentico usano l’SDK di OpenPipe, compatibile come drop-in replacement con l’SDK OpenAI, per catturare automaticamente le coppie prompt-risposta generate in produzione e trasformarle in dataset di fine-tuning, un approccio che integra la libreria open source Agent Reinforcement Trainer per il reinforcement learning applicato agli agenti.
- Adattamento di OLMo 2 32B su lingue a bassa risorsa: comunità open source hanno iniziato a usare Axolotl per adattare OLMo 2 32B a lingue regionali poco rappresentate nei dataset di addestramento originali, un caso reso possibile proprio dalla trasparenza totale sui dati di training che Ai2 garantisce per questo modello.
Guida alla migrazione tra framework
Passare da un framework all’altro capita più spesso di quanto si pensi, di solito quando un team cresce e ha bisogno di funzionalità che lo strumento iniziale non offre. Ecco i passaggi pratici per una migrazione senza perdere lavoro già fatto.
- Esporta il dataset in formato JSONL standard (struttura tipo Alpaca o ChatML), il formato riconosciuto da tutti e tre i framework senza conversioni complesse.
- Se stai migrando un adapter LoRA già addestrato, usa
peftper unire i pesi dell’adapter al modello base prima di cambiare strumento, così da avere un checkpoint pulito da cui ripartire. - Confronta i default degli iperparametri: Axolotl e LLaMA-Factory impostano valori diversi per
lora_alphaelora_dropoutdi default, quindi copiare una configurazione da un progetto all’altro senza controllare questi valori può cambiare il risultato del training. - Da Axolotl (YAML) a TRL (Python): traduci ogni chiave della configurazione YAML nei parametri corrispondenti di
SFTConfigoDPOConfig, prestando attenzione a batch size effettivo e gradient accumulation, che in Axolotl sono già combinati automaticamente. - Da TRL a LLaMA-Factory: se il tuo script Python usa SFTTrainer con PEFT, la stessa configurazione si traduce quasi 1:1 nei parametri CLI di
llamafactory-cli train --finetuning_type lora. - Esegui sempre un run di validazione breve, poche centinaia di step, sul nuovo framework prima di lanciare il training completo, confrontando loss e perplexity con i log del framework precedente.
- Verifica la compatibilità delle versioni di Transformers e PEFT: è la causa più comune di errori silenziosi durante una migrazione, specialmente con modelli rilasciati di recente come Nemotron 3.5 o OLMo 2.
Quale piattaforma scegliere: cinque casi d’uso concreti
Non esiste una risposta unica. Ecco come orientarsi in base al contesto reale del progetto.
- Startup con un solo ingegnere ML e deadline stretta: LLaMA-Factory riduce il tempo per il primo esperimento funzionante grazie alla CLI zero-code e alla Web UI, senza bisogno di scrivere training loop personalizzati.
- Team che deve scalare da prototipo a produzione multi-GPU: Axolotl è la scelta più naturale, dato il supporto nativo per DeepSpeed ZeRO-3 e FSDP e il punteggio di 9,4/10 assegnato da scored.tools proprio per l’affidabilità in scenari complessi.
- Laboratorio di ricerca che sperimenta nuove tecniche di allineamento: TRL resta la scelta più flessibile, perché permette di modificare la logica interna del training senza combattere contro le astrazioni di un framework end-to-end.
- Azienda con vincoli normativi stringenti (NIS2, GDPR): qualsiasi dei tre framework va bene se eseguito su infrastruttura on-premise o su un provider cloud europeo, dato che nessuno dei tre richiede di inviare dati a servizi esterni durante il training.
- Team che vuole evitare completamente la gestione dell’infrastruttura: il fine-tuning gestito di Together AI, con prezzi a partire da 0,48 dollari per milione di token sui modelli fino a 16 miliardi di parametri, elimina la necessità di scegliere tra i tre framework, che restano comunque disponibili “sotto il cofano” lato provider.
Pro e contro di ciascuna piattaforma
Dopo aver visto specifiche, prezzi e casi d’uso, vale la pena riassumere in forma sintetica i punti di forza e di debolezza di ciascuno strumento, così da avere un riferimento rapido prima di decidere.
Axolotl
Pro: configurazione dichiarativa in YAML, supporto multi-GPU maturo, punteggio più alto tra le recensioni indipendenti consultate, copertura ampia di metodi di preference tuning e RL. Contro: nessuna interfaccia grafica ufficiale, richiede comunque familiarità con i concetti di training per evitare configurazioni sbagliate copiate da esempi online.
Hugging Face TRL
Pro: massima flessibilità per chi scrive codice Python, integrazione diretta con l’intero ecosistema Hugging Face Hub, trainer dedicati e ben documentati per SFT, GRPO, DPO e reward modeling. Contro: curva di apprendimento più ripida, nessuna astrazione che semplifichi la gestione multi-GPU, che va configurata separatamente tramite Accelerate.
LLaMA-Factory
Pro: Web UI ufficiale, CLI zero-code, copertura dichiarata di oltre 100 modelli, community di gran lunga più ampia con 74,6mila stelle su GitHub. Contro: l’astrazione elevata rende più difficile intervenire su dettagli fini del training loop rispetto a TRL usata direttamente.
Errori comuni da evitare nel fine-tuning open source
Il primo errore è scegliere il full fine-tuning senza avere abbastanza dati. Come indicato dalla guida di zylos.ai, sotto i 100.000 esempi di alta qualità il rischio di overfitting supera i vantaggi rispetto a QLoRA, che modifica solo una piccola frazione dei parametri e generalizza meglio su dataset ridotti.
Il secondo errore è ignorare la compatibilità delle versioni. I modelli rilasciati negli ultimi mesi, come Nemotron 3.5 Lightning o OLMo 2 32B, spesso richiedono l’ultima versione di Transformers per essere caricati correttamente: un framework aggiornato a un mese fa può semplicemente non riconoscere l’architettura del modello più recente.
Il terzo errore è sottovalutare il costo della validazione. Molti team lanciano un training completo da diverse ore senza prima verificare su un sottoinsieme ridotto che la loss scenda in modo sensato. Un run di prova da 200-300 step, che costa pochi centesimi su RunPod o Lambda Labs, evita di scoprire un dataset malformattato solo dopo aver speso ore di GPU.
Il quarto errore è confondere popolarità con adeguatezza. LLaMA-Factory ha quasi sei volte le stelle GitHub di Axolotl, ma questo non significa che sia sempre la scelta giusta: per un team che deve integrare il training in una pipeline CI/CD esistente, la maggiore componibilità di TRL o Axolotl spesso conta più della facilità d’uso iniziale.
Verdetto finale: quale piattaforma vince nel 2026
Non c’è un vincitore assoluto, ma i dati raccolti in questo confronto permettono di tracciare una gerarchia per contesto. Per chi parte da zero e vuole risultati rapidi senza scrivere codice, LLaMA-Factory è la scelta più sensata: la combinazione di Web UI, CLI zero-code e 74,6mila stelle su GitHub racconta un progetto che ha abbassato davvero la barriera d’ingresso al fine-tuning open source.
Per team che devono scalare in produzione con training multi-GPU stabile, Axolotl resta la scommessa più solida, sostenuta dal punteggio di 9,4/10 di scored.tools e dalla copertura quasi completa dei metodi di preference tuning e RL più recenti, inclusi DPO, ORPO, KTO e GRPO.
Per chi fa ricerca e ha bisogno di controllo totale sul training loop, Hugging Face TRL resta l’unica opzione che non impone un’astrazione tra lo sviluppatore e il codice di addestramento. Sul fronte costi, la differenza tra affittare hardware grezzo su RunPod, a partire da 1,59 dollari l’ora per un A100 80GB, e usare un servizio gestito come Together AI, a partire da 0,48 dollari per milione di token, dipende dal volume: chi lancia pochi esperimenti al mese risparmia con il servizio gestito, chi itera continuamente risparmia con l’hardware in autonomia.
Domande frequenti
Axolotl, TRL e LLaMA-Factory sono davvero gratuiti?
Sì, tutti e tre i progetti sono distribuiti con licenza Apache 2.0 e possono essere usati e modificati liberamente. L’unico costo reale è quello dell’hardware GPU necessario per eseguire il training, sia esso locale o affittato su un provider cloud.
Quanta VRAM serve per fare fine-tuning di un modello da 7 miliardi di parametri?
Nessuno dei tre progetti pubblica un requisito minimo ufficiale certificato, perché il consumo di memoria dipende da batch size, lunghezza delle sequenze e ottimizzatore scelto. Nella pratica riportata dalla community, un fine-tuning QLoRA di un modello da 7B gira spesso su una singola GPU consumer da 24GB, ma per il full fine-tuning servono GPU professionali con memoria ben superiore, come un A100 o H100 da 80GB.
LLaMA-Factory è adatto anche a chi non sa programmare?
Sì, è l’unico dei tre framework con una Web UI ufficiale che permette di configurare dataset, modello e iperparametri senza scrivere codice. Resta comunque utile una comprensione base dei concetti di fine-tuning per scegliere valori sensati.
Posso usare questi framework con i modelli più recenti come OLMo 2 o DeepSeek V4 Pro?
In generale sì, dato che tutti e tre si appoggiano all’ecosistema Transformers di Hugging Face. Per i modelli rilasciati nelle ultime settimane, come OLMo 2 32B del 4 settembre 2026 o i pesi preview di DeepSeek V4 Pro, potrebbe essere necessario aggiornare le librerie sottostanti prima che il framework riconosca correttamente l’architettura.
Conviene di più il fine-tuning self-hosted o un servizio gestito?
Dipende dal volume di lavoro. Per pochi esperimenti al mese, un servizio gestito come Together AI, con prezzi a partire da 0,48 dollari per milione di token sui modelli fino a 16 miliardi di parametri, spesso costa meno del tempo ingegneristico necessario per configurare un cluster. Sopra una certa soglia di utilizzo, affittare GPU su RunPod o Lambda Labs e gestire il training con Axolotl o LLaMA-Factory diventa più economico.
Qual è la differenza principale tra LoRA e QLoRA?
LoRA (Low-Rank Adaptation) addestra solo un piccolo numero di parametri aggiuntivi mantenendo il modello base in precisione originale, mentre QLoRA applica la stessa tecnica su un modello base quantizzato, tipicamente a 4 bit, riducendo ulteriormente il consumo di memoria a scapito di una leggerissima perdita di precisione numerica durante il training.
Quale framework scegliere per un progetto aziendale con team misto?
LLaMA-Factory è generalmente la scelta più pratica per team dove analisti di dominio senza background tecnico devono collaborare con ingegneri ML, grazie alla Web UI che riduce la dipendenza da un singolo esperto per lanciare ogni esperimento.
È possibile combinare più framework nello stesso progetto?
Sì, ed è una pratica comune. Dato che Axolotl si appoggia internamente a TRL e PEFT, molti team prototipano rapidamente con LLaMA-Factory, poi migrano la configurazione vincente su Axolotl per il training di produzione multi-GPU, sfruttando la compatibilità dei formati di checkpoint tra i tre strumenti.
Serve una GPU dedicata anche solo per iniziare a sperimentare?
No. Per i primi test su modelli piccoli o su sottoinsiemi ridotti del dataset, molti sviluppatori usano notebook gratuiti con GPU condivisa prima di passare a un’istanza a pagamento su RunPod, Lambda Labs o Together AI per il training completo. Questo approccio a due fasi, prototipo gratuito e poi run a pagamento, riduce sensibilmente il rischio di sprecare ore di GPU su una configurazione che poi si rivela sbagliata.




