Prima di toccare il codice: cosa serve davvero per addestrare un LLM
Addestrare un modello linguistico da zero non significa scaricare uno script e premere invio. È un progetto di ingegneria con tre fronti da risolvere prima della prima riga: dati, potenza di calcolo e valutazione. Secondo la documentazione ufficiale di framework come PyTorch e Hugging Face, la maggior parte dei fallimenti nei progetti di addestramento non deriva dal codice, ma da una pianificazione carente del corpus e da un’infrastruttura mal dimensionata.
Questo articolo descrive una configurazione passo dopo passo assumendo che tu voglia costruire un modello piccolo o medio (tra 100M e 1.500M di parametri) per un dominio specifico, non un concorrente dei grandi modelli generalisti. Se il tuo obiettivo è un modello da 70B parametri con dati multilingue massivi, il budget si misura in milioni di dollari e questo tutorial non basta: riconoscilo fin dall’inizio.
Passo 1: definizione dell’ambito e del budget di calcolo
Prima di scrivere il tokenizer, decidi la dimensione del modello in base alle GPU disponibili. La regola pratica usata nel settore mette in relazione i token di addestramento con i parametri: un modello ben addestrato consuma solitamente tra 20 e 100 volte più token che parametri. Per un modello da 125M parametri, un corpus da 2.500M a 10.000M di token è ragionevole.
Stima della VRAM e del tempo
La memoria necessaria durante l’addestramento non dipende solo dalla dimensione del modello. Gli stati dell’ottimizzatore AdamW quadruplicano il peso del modello in precisione mista. Un modello da 125M parametri può consumare tra 2 e 3 GB solo per gli stati dell’ottimizzatore, più attivazioni e gradienti. Su una GPU da 24 GB puoi addestrare modelli fino a 300-400M parametri con batch piccolo e gradient checkpointing.
Un errore comune che ho visto in team alle prime armi: assumere che una RTX 4090 di consumo permetta di addestrare un modello da 1B parametri senza tecniche di risparmio di memoria. La realtà è che l’addestramento si interrompe per OOM (out of memory) dopo pochi passi, e il tempo di debug supera quello di addestramento.
Passo 2: costruzione e pulizia del corpus
Il dataset è l’asset più prezioso e il più trascurato. Per un modello di dominio (legale, medico, tecnico, assistenza clienti), servono tra 1.000 e 10.000 milioni di token di testo di qualità. Se parti da zero, la pipeline di pulizia deve includere:
- Deduplicazione a livello di documento e di paragrafo con MinHash o SimHash. Senza questo, il modello memorizza e va in overfitting su frasi ripetute.
- Filtro della lingua con un classificatore leggero (fastText funziona bene) per scartare contenuti che non siano in italiano se questo è il tuo dominio.
- Eliminazione del boilerplate (menu di navigazione, avvisi sui cookie, footer) che avvelenano il segnale di addestramento.
- Controllo di qualità euristico: rapporto di caratteri alfabetici, lunghezza media della frase, presenza di ripetizioni n-gramma.
Secondo studi del settore su dataset pubblici come C4 e The Pile, tra il 40% e il 60% del testo grezzo viene scartato dopo la pulizia. Pianifica lo spazio di archiviazione di conseguenza: un corpus da 10.000M token in testo semplice occupa circa 40 GB.
Passo 3: tokenizer specifico del dominio
Non riutilizzare il tokenizer di GPT-2 o Llama se il tuo dominio ha un vocabolario proprio. Un tokenizer BPE addestrato sul tuo corpus riduce il numero di token per documento e accelera l’addestramento. La configurazione con la libreria tokenizers di Hugging Face è diretta:
from tokenizers import Tokenizer, models, trainers, pre_tokenizers
tokenizer = Tokenizer(models.BPE(unk_token=»[UNK]»))
tokenizer.pre_tokenizer = pre_tokenizers.ByteLevel(add_prefix_space=False)
trainer = trainers.BpeTrainer(vocab_size=32000, special_tokens=[«[PAD]»,»[UNK]»,»[BOS]»,»[EOS]»])
tokenizer.train_from_iterator(corpus_iter, trainer=trainer)
tokenizer.save(«tokenizer_dominio.json»)
Un vocabolario tra 32.000 e 50.000 token copre bene l’italiano generale. Per domini tecnici con molti acronimi, considera 48.000. Verifica il tasso di compressione: se il tuo tokenizer genera più di 1,4 token per parola in media, probabilmente hai bisogno di più vocabolario o di un corpus di addestramento più rappresentativo.
Passo 4: architettura del modello e configurazione iniziale
Per un modello da zero, un’architettura decoder-only tipo GPT è lo standard. La configurazione deve essere coerente: dimensione nascosta (d_model), numero di layer, teste di attenzione e dimensione del feed-forward. Una regola che funziona: feed-forward = 4 × d_model, e numero di teste tale che la dimensione per testa sia 64 o 128.
Esempio di configurazione per un modello da 125M
{
«vocab_size»: 32000,
«hidden_size»: 768,
«num_hidden_layers»: 12,
«num_attention_heads»: 12,
«intermediate_size»: 3072,
«max_position_embeddings»: 1024,
«hidden_act»: «gelu»,
«dropout»: 0.1
}
Con questa configurazione, il modello ha circa 125M di parametri. Se la tua GPU è da 16 GB, riduci il batch per dispositivo a 8 e usa l’accumulo di gradienti di 4 per un batch effettivo di 32. Il learning rate iniziale tipico è 3e-4 con scheduler coseno e warmup di 2.000 passi.
Passo 5: loop di addestramento con PyTorch e Accelerate
La configurazione minima valida usa transformers con Trainer o un loop manuale con accelerate. Per il controllo totale, il loop manuale è preferibile. I punti critici:
- Precisione mista (fp16 o bf16) con torch.cuda.amp. Su GPU Ampere o superiori, bf16 è più stabile.
- Gradient checkpointing attivato se il modello non entra in memoria.
- Salvataggio dei checkpoint ogni 500 passi, non ogni epoca. Nei modelli grandi, un’epoca può essere impraticabile.
- Valutazione della perplessità su un insieme di validazione del 5% del corpus.
Un dettaglio che si impara solo con la pratica: la loss può sembrare stabile ma la perplessità di validazione può divergere se il corpus di validazione ha una distribuzione diversa. Assicurati che la validazione sia estratta casualmente dallo stesso corpus pulito, non da una fonte diversa.
Passo 6: valutazione e segnali d’allarme
La perplessità non basta. Devi valutare il modello su compiti concreti: generazione di testo, classificazione o risposta a domande. Per un modello piccolo, usa benchmark leggeri come un sottoinsieme del compito di ragionamento o test manuali di generazione con prompt del tuo dominio.
Segnali che qualcosa va male:
- Loss che scende ma generazione incoerente: probabilmente overfitting per duplicati nel corpus.
- Perplessità di validazione che risale dopo un minimo: learning rate troppo alto o corpus troppo piccolo per la dimensione del modello.
- Ripetizioni nella generazione: mancanza di diversità nel corpus o tokenizer addestrato male.
Passo 7: fine-tuning e deployment
Un modello base addestrato da zero non risponde alle istruzioni. Per un uso pratico, serve una fase di istruzione o fine-tuning supervisionato con coppie domanda-risposta del tuo dominio. Questa fase è più leggera: tra 10.000 e 100.000 esempi di qualità sono solitamente sufficienti per un modello piccolo.
Il deployment con vLLM o llama.cpp permette di servire il modello con quantizzazione a 8 o 4 bit, riducendo i requisiti di VRAM. Un modello da 125M quantizzato a 4 bit occupa meno di 100 MB e può girare su CPU, anche se la latenza sarà maggiore.
Limiti che devi assumere
Addestrare da zero non garantisce qualità. Un modello da 125M addestrato con 5.000M di token in italiano avrà una conoscenza fattuale limitata e allucinerà spesso. Non compete con modelli preaddestrati di dimensioni maggiori. Se il tuo obiettivo è un assistente conversazionale generale, il fine-tuning di un modello esistente è più efficiente in termini di costo e tempo. L’addestramento da zero ha senso quando hai bisogno di controllo totale sul vocabolario, sulla licenza o sull’architettura, o quando studi le dinamiche di addestramento.
Secondo la documentazione ufficiale di PyTorch e le guide di Hugging Face, il costo di un addestramento da 125M parametri con 5.000M di token su una singola GPU da 24 GB può variare da diversi giorni a una settimana, a seconda del throughput. Non ci sono scorciatoie: la pipeline dei dati consuma tanto tempo quanto l’addestramento.
Se decidi di procedere, inizia con un corpus da 500M token e un modello da 50M parametri. Valida l’intera pipeline prima di scalare. L’esperienza dimostra che l’80% degli errori compare nelle prime 24 ore di addestramento e sono più facili da correggere con un modello piccolo.