Quando la nicchia diventa un abisso di costi, la tentazione di portare i modelli dentro casa si fa forte. Un ricercatore alle prese con il theorem proving automatico basato su LLM ha descritto una situazione emblematica: ha budget per l’hardware ma non per i crediti cloud, e il dominio è talmente specifico — il proof assistant Rocq — che i modelli più piccoli non lo capiscono. La sua idea: distillare un modello più grande per ottenere una versione contenuta ma competente, da eseguire on-premise.

La trappola del cloud per i domini di nicchia

Il theorem proving agentico è un caso estremo di utilizzo di LLM: richiede ragionamento formale, conoscenza di sintassi esoterica e una precisione che i modelli general-purpose spesso non raggiungono. Chi lavora su proof assistant come Rocq (l’ex Coq) si scontra con un paradosso: i modelli cloud sono potenti ma costosi a ogni inference, e quelli piccoli, che costerebbero meno, falliscono sulle sottigliezze del linguaggio.

L’utente, costretto a usare modelli cloud, vede i costi lievitare. La sua domanda è un classico del calcolo del TCO: perché pagare per token quando si può comprare hardware? E se l’hardware è già finanziato, la scelta di portare l’inference in casa diventa quasi obbligata.

Cos’è la distillazione e perché può funzionare

La distillazione (o knowledge distillation) è il processo con cui un modello grande — il teacher — allena uno più piccolo — lo student — trasferendogli non solo le risposte ma anche le distribuzioni di probabilità sulle previsioni. È una tecnica diffusa per creare LLM compatti che mantengano buona parte delle competenze dell’originale, riducendo latenza e consumo di VRAM.

Nel contesto del theorem proving, si tratterebbe di prendere un modello già robusto su linguaggio formale (ad esempio quelli addestrati su Lean) e distillarlo su esempi di Rocq. Il vantaggio è doppio: le dimensioni ridotte permettono di girare su GPU consumer o workstation con VRAM contenuta, e l’esecuzione on-premise taglia i costi operativi ricorrenti.

Lo stack on-premise: questioni di VRAM e TCO

Self-hosted non significa gratuito. Per fare inference con un modello da 7–13 miliardi di parametri, anche dopo quantization a INT8 o FP16, servono GPU con almeno 16–24 GB di VRAM, e per il training o il fine-tuning i requisiti salgono. Un ambiente on-premise adeguato comporta CapEx iniziale, ma nel lungo periodo il TCO può essere inferiore a quello di un’API cloud, specie se l’uso è continuo e i dati sono sensibili o numerosi.

AI-RADAR ha più volte evidenziato come la scelta tra cloud e on-premise per LLM non sia solo economica: dipende dal volume di richieste, dalla latenza tollerabile e dalla necessità di controllo sui dati. Nel caso specifico del ricercatore, il finanziamento hardware già disponibile sposta l’ago della bilancia verso l’on-premise.

Il nodo dei dati: Rocq è un deserto

di modelli
L’edit del post originale pone un problema aggiuntivo: per Rocq esistono pochissimi modelli, mentre per Lean c’è già DeepSeek fine-tuned. Adattare quest’ultimo con un post-training su esempi di Rocq potrebbe essere più rapido che distillare da zero. Servono però dataset di coppie istruzione-risposta nel linguaggio formale di Rocq, e crearli richiede competenze di dominio non comuni.

Qui si apre un fronte diverso da quello puramente tecnico: la costruzione del dataset è spesso il vero collo di bottiglia nei progetti di fine-tuning specialistico. Chi fa theorem proving ha bisogno di dati annotati, magari generati dal modello grande stesso, in un loop che ricorda l’auto-distillazione.

Oltre la nicchia: cosa insegna questa storia

Il caso del ricercatore è un segnale di quanto l’ecosistema open-source e il self-hosting stiano diventando centrali per l’adozione pratica dei LLM. Non è solo una questione di costi: è la possibilità di plasmare il modello su compiti esatti, senza i vincoli di API generiche. La distillazione on-premise, unita a tecniche di fine-tuning come QLoRA, sta democratizzando l’accesso a modelli specializzati.

Per chi valuta il deployment on-premise, AI-RADAR offre framework analitici che aiutano a mappare i trade-off tra hardware, software e competenze necessarie. La storia del theorem proving con Rocq mostra che la sovranità sui modelli comincia da esigenze molto concrete, e spesso la risposta è in uno stack che ci si costruisce da sé.