Un CTO che ha già letto cosa sono gli LLMOps e perché servono si trova davanti a una domanda più scomoda: con quali strumenti, esattamente, si costruisce questo layer? La letteratura di riferimento, a partire dal lavoro di Databricks sul tema, offre un’ottima mappa concettuale delle sei aree operative coinvolte. Rimane però aperta la parte più difficile: tradurre quella mappa in uno stack che qualcuno debba effettivamente configurare, versionare e far girare ogni notte in produzione.
Indice degli argomenti:
Dove si inserisce LLMOps nello stack esistente
LLMOps non sostituisce l’infrastruttura DevOps e MLOps già in azienda: vi si innesta sopra, aggiungendo tre livelli che un classico pipeline di machine learning non prevede. Il primo è il livello del prompt, che va versionato esattamente come il codice, perché una modifica di tre parole in un template può cambiare il comportamento del modello quanto un nuovo set di pesi.
Il secondo è il livello dell’orchestrazione delle chiamate, che diventa necessario appena un’applicazione smette di fare una singola richiesta al modello e comincia a incatenarne più d’una verso sistemi esterni.
Il terzo è il livello della valutazione qualitativa, dove le metriche automatiche tradizionali smettono di bastare.
Il registry dei modelli resta il punto di raccordo. MLflow, la piattaforma open source citata da Databricks come riferimento, traccia provenienza, versioni e transizioni lungo tutto il ciclo di vita: quale checkpoint è in produzione, quali parametri di fine-tuning lo hanno generato, quali metriche ha ottenuto in fase di valutazione. Senza questo tracciamento, un rollback in caso di regressione diventa un’operazione manuale nel momento peggiore possibile, cioè mentre il sistema sta già rispondendo male agli utenti.
Fine-tuning: le librerie e i compromessi tecnici
La messa a punto di un modello di base si appoggia su un set consolidato di librerie open source: Hugging Face Transformers per l’interfaccia unificata verso i modelli pre-addestrati, DeepSpeed per il training distribuito su più GPU, PyTorch come framework di base, JAX quando serve calcolo differenziabile ad alte prestazioni. La scelta fra fine-tuning completo, PEFT o LoRA non è solo una questione di budget di calcolo: un fine-tuning completo aggiorna tutti i parametri del modello e produce le prestazioni più solide su un dominio specifico, ma richiede infrastruttura paragonabile a quella dell’addestramento originale. LoRA, al contrario, inserisce matrici di basso rango in un numero limitato di livelli e lascia i pesi originali congelati: il risultato è un adattamento più economico, più veloce da iterare, ma con un tetto di prestazioni più basso su compiti che richiedono un cambiamento profondo del comportamento del modello.
Questa scelta si ripercuote direttamente sulla pipeline CI/CD. Un fine-tuning completo comporta cicli di training lunghi, difficili da eseguire a ogni commit; un adattamento LoRA, invece, è abbastanza leggero da poter rientrare in un flusso di integrazione continua, con test automatizzati che girano a ogni modifica del prompt o del dataset di addestramento.
Valutazione: perché Bleu e Rouge non bastano più
Le metriche automatiche tradizionali restano utili quando esiste una risposta di riferimento univoca: Bleu e Rouge confrontano l’output del modello con un testo target e restituiscono un punteggio di sovrapposizione lessicale. Il problema è che gran parte delle applicazioni aziendali con LLM produce output aperti, dove non esiste un’unica risposta corretta da confrontare, e questi punteggi non catturano coerenza, pertinenza o correttezza fattuale.
Lo standard che si è consolidato nel 2026 per colmare questo vuoto è ibrido: metriche automatiche dove esiste un riferimento misurabile, un giudice LLM per i criteri che richiedono ragionamento, come utilità, aderenza al contesto o tono, e revisione umana riservata alla piccola percentuale di casi segnalati come dubbi da entrambi i livelli precedenti. Un giudice LLM ben calibrato raggiunge tipicamente un accordo dell’85-90% con annotatori umani, ma questa calibrazione va verificata e ripetuta ogni volta che cambia il modello giudice o la rubrica di valutazione, perché anche un giudice calibrato deriva nel tempo. Una parte non trascurabile del lavoro di calibrazione consiste nel controllare i bias tipici di questo approccio: un giudice tende a preferire output del proprio stesso modello, e la mitigazione più efficace resta usare un giudice di una famiglia diversa dal modello generatore.
Le pipeline di valutazione più mature seguono quattro stadi distinti. In sviluppo locale, framework come DeepEval o Promptfoo eseguono test simili a unit test contro un dataset di riferimento di 200-500 esempi, costruito a partire da fallimenti reali osservati in produzione, non da esempi sintetici. Alla pull request, un giudice LLM automatizzato gira sull’intero dataset di riferimento e blocca il merge se il punteggio scende sotto una soglia stabilita.
Al momento del rilascio, controlli soglia su accuratezza, sicurezza e aderenza al contesto bloccano il deploy in caso di regressione rispetto alla baseline di produzione. In produzione, un campionamento continuo del traffico live alimenta di nuovo il dataset di riferimento, chiudendo il ciclo.
Governance del modello e pipeline CI/CD
Il versioning di un sistema LLM copre tre oggetti distinti che vanno tracciati separatamente: il modello o il checkpoint di fine-tuning, il template di prompt, e il dataset di valutazione su cui entrambi vengono misurati. Trattare questi tre elementi come un unico artefatto indistinto è uno degli errori più comuni nelle implementazioni aziendali, perché rende impossibile capire se una regressione in produzione dipenda da un cambio di modello, da una modifica al prompt o da una deriva nei dati in ingresso.
Le pipeline CI/CD applicate a questo contesto seguono i principi DevOps già noti, ma con l’aggiunta di gate specifici: repository per il codice e per i prompt, orchestratori per l’automazione pre-produzione, endpoint API con accelerazione GPU per il serving. Il rilascio in produzione beneficia di pratiche di canary release, dove una nuova versione del modello riceve una quota ridotta del traffico reale prima di sostituire completamente la versione precedente, con un rollback automatico se le metriche di qualità o di sicurezza peggiorano oltre soglia.
Le leve tecniche per abbattere il costo dell’inferenza
L’inferenza, non l’addestramento, è la voce di spesa che pesa di più su un sistema LLM in produzione continua, ed è anche quella su cui esiste il margine di intervento tecnico più ampio. La leva più diretta è la quantizzazione: ridurre la precisione numerica dei pesi del modello da 16 bit a 8 o 4 bit riduce l’uso di memoria di 2-4 volte e taglia il costo di inferenza di circa il 50%, mantenendo tipicamente il 95-99% dell’accuratezza originale. Le tecniche più recenti si spingono oltre comprimendo anche la cache KV, la struttura che il modello usa per non ricalcolare l’attenzione a ogni token generato, con perdite di accuratezza ormai trascurabili.
Il caching semantico è la seconda leva, spesso sottoutilizzata: molte applicazioni aziendali ricevono richieste semanticamente simili in modo ripetuto, e servire una risposta dalla cache invece di rieseguire l’inferenza elimina il costo del tutto per quella quota di traffico, con riduzioni di spesa che nei carichi ad alta ripetizione superano il 70%.
Il batching continuo, che inserisce nuove richieste in coda non appena una sequenza precedente si libera invece di aspettare che l’intero batch finisca, porta l’utilizzo della GPU vicino al 100% e può tagliare il costo per token di circa l’85% rispetto a un batching statico.
Quantizzazione, caching e batching continuo si sommano invece di escludersi: applicati insieme, secondo le misurazioni più recenti sull’hardware più diffuso in produzione, riducono il costo di inferenza complessivo di un ordine di grandezza rispetto a una configurazione non ottimizzata. La differenza fra un’inferenza progettata e una lasciata ai valori di default, per un sistema che serve milioni di richieste al giorno, si misura in decine di migliaia di euro al mese.
Gli errori architetturali più comuni
Il primo errore è trattare il prompt come una stringa nel codice applicativo invece che come un artefatto versionato con il proprio ciclo di test. Il secondo è saltare la fase di calibrazione quando si introduce un giudice LLM, fidandosi del punteggio senza aver mai verificato l’accordo con annotatori umani su un campione di riferimento. Il terzo è concentrare l’ottimizzazione dei costi solo sulla scelta del modello, ignorando che quantizzazione, caching e batching intervengono su leve completamente diverse e complementari. Il quarto, forse il più costoso nel tempo, è non separare il versioning di modello, prompt e dataset di valutazione, rendendo ogni regressione in produzione un esercizio di archeologia invece che una diagnosi immediata.
Lo stack per costruirlo esiste già, è documentato, e gli errori più comuni sono stati mappati da chi ci è passato prima. A fare la differenza fra un’implementazione solida e una fragile, il più delle volte, è la costanza nell’applicare tutti questi strumenti insieme, invece di sceglierne solo alcuni.
Partecipa alla community