12 novembre 2026 · Team VRAMfarm

Fine-tuning di un LLM: quanta VRAM e quante GPU per QLoRA, LoRA e completo

Quasi tutti i lavori di fine-tuning chiedono una GPU, non otto. QLoRA addestra un modello da 8B su una scheda da 16 GB, un 32B su una da 48 GB e un 70B su una sola scheda da 80 GB. LoRA a 16 bit chiede da due a tre volte tanto. Solo il fine-tuning completo, che aggiorna ogni peso, ti porta su più schede da 80 GB anche per un modello da 8B, perché costa circa 16 byte per parametro prima delle attivazioni. Un tipico training QLoRA su un modello da 8B con 15 milioni di token di training richiede 2–4 ore su una RTX 4090 e costa 1,65 € di tempo GPU.

Prima di tutto: ti serve davvero il fine-tuning?

Il fine-tuning insegna a un modello un formato, un tono o un compito specifico: rispondere con lo stile del tuo supporto clienti, estrarre campi nel tuo schema JSON, classificare i ticket nelle tue categorie. È un pessimo modo per aggiungere conoscenza. Se il modello deve conoscere la documentazione del tuo prodotto, mettigli davanti i documenti al momento della domanda (retrieval, o semplicemente un prompt lungo) e tienili aggiornati senza riaddestrare. Prova prima un buon prompt con qualche esempio sul modello base; se sbaglia ancora formato o stile una volta su cinque, il fine-tuning vale la pena.

Memoria per metodo: i conti

Tre metodi, tre conti della memoria molto diversi:

• QLoRA carica il modello base a 4 bit (circa 0,6 byte per parametro) e addestra accanto piccole matrici adapter. Il modello base resta congelato, quindi per lui non ci sono gradienti né stati dell’ottimizzatore.
• LoRA fa lo stesso con il modello base a 16 bit: 2 byte per parametro, qualità leggermente migliore, più memoria.
• Il fine-tuning completo aggiorna ogni peso. Con l’ottimizzatore AdamW standard in mixed precision, ogni parametro costa circa 16 byte: pesi e gradienti a 16 bit, una copia master in fp32 e due stati dell’ottimizzatore in fp32. Un ottimizzatore a 8 bit e pesi a 16 bit senza copia master scendono a circa 6–8 byte.

Sopra ci sono le attivazioni, che crescono con la lunghezza delle sequenze e il batch size. I valori qui sotto presuppongono sequenze da 2.000–4.000 token, un batch piccolo e il gradient checkpointing, che ricalcola le attivazioni invece di conservarle.

Sono intervalli perché i trainer sono diversi: i kernel di Unsloth chiedono molto meno del semplice codice Hugging Face, e le sequenze lunghe fanno salire ogni riga. La guida alla VRAM spiega i conti dei byte per parametro, e la guida a CUDA out of memory le leve da toccare quando un training non ci sta: batch size, lunghezza delle sequenze, gradient checkpointing, ottimizzatori a 8 bit.

Raramente un compito ha bisogno del fine-tuning completo. LoRA su tutti i layer lineari con un rank di 16–64 recupera quasi tutto il guadagno per stile, formato e compiti specifici. Il fine-tuning completo vale il suo costo per il pre-training continuato su un grande corpus, una nuova lingua o un forte cambio di dominio.

Una scheda o più schede

Quando aggiungi schede succedono due cose diverse, e solo una delle due fa risparmiare memoria.

Data parallel (DDP): ogni scheda contiene una copia completa del modello ed elabora batch diversi. La memoria per scheda resta la stessa; cresce la velocità, circa 1,8 volte con due schede e 3,5 volte con quattro. Utile quando un training sta su una scheda ma durerebbe tutta la notte.

Sharding (FSDP, DeepSpeed ZeRO-3): pesi, gradienti e stati dell’ottimizzatore vengono divisi tra le schede, così insieme contengono un modello che nessuna potrebbe contenere da sola. È così che funzionano il fine-tuning completo e la LoRA a 16 bit dei modelli grandi. A ogni step le schede si scambiano dati, quindi il collegamento conta: le macchine da data center con NVLink, come 8 × H100, scalano bene; le schede consumer come RTX 4090 e 5090 comunicano via PCIe e scalano molto peggio. QLoRA insieme a FSDP riesce persino a dividere un modello da 70B su due schede da 24 GB, a una velocità modesta.

La regola pratica: se il lavoro sta su una scheda, usa una scheda. È più semplice e tra le schede non può andare storto niente. Una sola H100 spesso finisce prima e spende meno di due schede consumer. Prendi più schede quando il modello non sta su nessuna scheda singola, o quando un training su una scheda durerebbe più di una giornata di lavoro. Nel catalogo le macchine con 2, 4 e 8 schede sono elencate a parte, e le basi del training multi-GPU spiegano la configurazione; una macchina con più schede costa circa il numero di schede per il prezzo di una scheda, quindi 4 × H100 costano circa 15,60 € all’ora.

Strumenti: Unsloth, Axolotl, TRL

Unsloth è la via più rapida per QLoRA o LoRA su una scheda. I suoi kernel personalizzati riducono memoria e tempo, offre versioni a 4 bit già pronte dei modelli più diffusi ed esporta il risultato come adapter, come modello unito a 16 bit per vLLM o come GGUF per Ollama. Il supporto multi-GPU è più recente e più limitato rispetto agli altri due.

pip install unsloth

Se nel frattempo pip sostituisce il PyTorch dell’immagine, controlla che la nuova build corrisponda alla versione CUDA che la macchina mostrava prima dell’avvio; python -c "import torch; print(torch.cuda.is_available())" deve stampare True.

from unsloth import FastLanguageModel
from trl import SFTTrainer, SFTConfig
from datasets import load_dataset

model, tokenizer = FastLanguageModel.from_pretrained(
    "unsloth/Qwen3-8B", max_seq_length=2048, load_in_4bit=True)
model = FastLanguageModel.get_peft_model(model, r=16, lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"],
    use_gradient_checkpointing="unsloth")

data = load_dataset("json", data_files="/workspace/data/train.jsonl", split="train")
trainer = SFTTrainer(model=model, processing_class=tokenizer, train_dataset=data,
    args=SFTConfig(output_dir="/workspace/out", per_device_train_batch_size=2,
        gradient_accumulation_steps=4, num_train_epochs=3, learning_rate=2e-4,
        logging_steps=10, save_steps=200, bf16=True))
trainer.train()
model.save_pretrained("/workspace/out/adapter")

train.jsonl contiene un esempio per riga, ognuno una lista messages in formato chat (system, user, assistant), che il trainer formatta con il chat template del modello.

Axolotl descrive l’intero training in un solo file YAML: modello, dataset, LoRA o completo, lunghezza delle sequenze e come usare più GPU. Così i training sono ripetibili e facili da confrontare. Installalo con pip come spiega la sua documentazione (gli extra per flash-attention e DeepSpeed dipendono dalla tua configurazione), poi axolotl fetch examples scarica configurazioni pronte per i modelli più comuni e axolotl train your-config.yaml avvia il training. Per un modello che non sta su una scheda, aggiungi alla configurazione una sezione DeepSpeed ZeRO-3 o FSDP; è qui che Axolotl è più forte di Unsloth.

TRL di Hugging Face è la libreria che sta sotto gran parte di quanto sopra: trainer per supervised fine-tuning, DPO e GRPO, PEFT per la LoRA. Sceglila quando vuoi scrivere il tuo codice di training. Uno script che funziona su una scheda gira su quattro con accelerate launch --num_processes 4 train.py.

Tempi e costi

Intervalli per pianificare, su un unico dataset: 10.000 esempi da circa 500 token, tre epoche, 15 milioni di token di training. Il throughput viene da calcoli sulla potenza di calcolo e da report pubblici della community, non da benchmark nostri. Il tempo cresce con i token: dati doppi, ore doppie.

Saltano all’occhio due cose. Le schede da data center più veloci spesso costano meno per training concluso, perché le ore calano più in fretta di quanto salga il prezzo: confronta le due righe del 70B. E il fine-tuning completo di un modello da 8B è breve in tempo GPU; a richiedere più tempo sono la preparazione dei dati e la valutazione intorno.

Aggiungi la configurazione: 5–10 minuti per installare il trainer, più il download del modello, che si paga come traffico più minuti. Per QLoRA prendi la versione a 4 bit, dove esiste; per un modello da 70B sono circa 40 GB invece di 141 GB. L’articolo sul costo per milione di token usa lo stesso metodo per far girare i modelli dopo il training.

Farlo girare su un server a noleggio senza perdere lavoro

1. Prima prova in piccolo. Addestra sull’1% dei dati nei primi 15 minuti, che paghi comunque. Annota i token al secondo che stampa il trainer e la memoria in nvidia-smi, poi fai i conti prima di avviare il training completo.
2. Fallo girare senza di te. Avvia il training dentro tmux (apt-get install -y tmux, tmux new -s train) oppure con nohup python train.py > /workspace/train.log 2>&1 &. Chiudere il browser o la sessione SSH a quel punto non lo ferma.
3. Checkpoint e copie fuori dalla macchina. Imposta save_steps in modo che ogni 15–30 minuti arrivi un checkpoint in /workspace/out. L’hardware ogni tanto si guasta; se una macchina sparisce, la fatturazione si ferma da quel momento, ma il suo disco se ne va con lei. Copia i checkpoint fuori man mano: un repository privato su Hugging Face, rsync verso il tuo computer o un tuo bucket. L’articolo sui file dopo lo stop spiega cosa conserva la cartella salvata.
4. Tieni l’adapter, non il modello base. Un adapter LoRA pesa da qualche decina a qualche centinaio di MB, quindi nella cartella salvata a 0,03 € per GB al mese costa quasi niente. Il modello base pubblico si può riscaricare.
5. Ferma quando hai finito. La fatturazione si ferma nel minuto in cui fermi il server. La protezione dall’inattività ti manda un’email dopo 2 ore senza SSH, Jupyter o carico sulla GPU, e un’ora dopo salva la cartella e ferma il server, ma quelle ore di inattività si pagano.

Per usare il risultato, servi il modello base con l’adapter in vLLM: vllm serve Qwen/Qwen3-8B --enable-lora --lora-modules support=/workspace/out/adapter, poi chiama il modello con il nome support tramite la sua API compatibile con OpenAI. Oppure unisci l’adapter al modello base con Unsloth ed esporta un GGUF per Ollama. Il confronto tra i runtime ti aiuta a scegliere.