Modelli open weight in azienda: quando il fine-tuning batte le API

Per due anni la scelta è stata semplice: si paga l’API del fornitore più bravo e non si pensa all’infrastruttura. Poi i modelli a pesi aperti hanno chiuso il divario sui benchmark che contano davvero — ragionamento, codice, lingue diverse dall’inglese — e la domanda è tornata sul tavolo dei CTO: conviene ancora pagare a consumo, o è il momento di portarsi il modello in casa?

Il confronto ingenuo guarda solo il prezzo per milione di token. Quello onesto mette in conto le GPU (comprate o noleggiate), l’energia, le persone che tengono in piedi l’inferenza e, dall’altra parte, gli sconti volume che i fornitori di API concedono a chi firma contratti annuali. Sotto una certa soglia di traffico l’API vince sempre; sopra, la curva si inverte prima di quanto si creda.

C’è poi la voce che nei fogli di calcolo non compare: i dati. Per una banca o una ASL, la differenza tra inviare documenti a un endpoint esterno e tenerli su macchine proprie non è un costo, è un vincolo normativo. In questi casi il fine-tuning di un modello aperto non è l’alternativa economica: è l’unica strada percorribile.

L’errore più comune è dimensionare il progetto sul modello più grande disponibile. Nella pratica, un modello medio raffinato sui propri dati batte quasi sempre un gigante generalista sul compito specifico — e gira su hardware che un’azienda media può permettersi. La ricetta che vediamo funzionare: partire da un task chiuso e misurabile, costruire il dataset di valutazione prima del fine-tuning, e confrontare contro l’API migliore, non contro il proprio entusiasmo.

Il rischio vero non è tecnico ma organizzativo: il modello in casa invecchia, e senza un piano di aggiornamento ci si ritrova in dodici mesi con un sistema peggiore dell’API che si era abbandonato. Chi parte oggi deve mettere a budget la seconda iterazione, non solo la prima.