Il team di engineering dovrebbe ospitare da sé un modello di coding open-weight?

David Abitbol, che guida le operazioni AI di Revolut, ha descritto il rollout in un intervento alla conferenza di AI Engineer a New York, alla fine del 2026. Revolut monitora due numeri su un campione di circa 2.000 engineer: il tempo di coding in ore e il lead time in giorni, dalla presa in carico di una feature al merge pronto per il deploy.

Un primo rollout di Gemini di Google con accesso ai dati interni ha migliorato entrambe le metriche in modo modesto, soprattutto sostituendo le ricerche nella documentazione. Claude Code di Anthropic è arrivato dopo, con budget di token rigidi per ogni engineer, dopo che alcuni avevano accumulato bollette elevate con ritorni poco chiari, e secondo Abitbol all'inizio non ha mostrato effetti misurabili significativi.

Ciò che ha cambiato i numeri è stato ospitare in autonomia un modello open-weight, GLM di Z.ai, a partire da circa aprile 2026, senza alcun limite di token. Il tempo di coding è migliorato di circa il 60% e il lead time di circa il 70%. Revolut tratta ora il modello auto-ospitato come impostazione predefinita per il coding quotidiano, con una fatturazione fissa e prevedibile, e mantiene gli strumenti frontier come eccezione per i problemi più difficili.

A circa 2.000 engineer, servire il modello ha richiesto 56 GPU Nvidia B200, con l'obiettivo di un time-to-first-token sotto i tre secondi (i reclami iniziano oltre i cinque). Il costo medio è risultato di circa 0,30 $ per milione di token, intorno a un decimo di quanto Revolut pagava ad Anthropic e OpenAI messi insieme.

La lettura che Abitbol stesso dà ai dati è la parte più utile: il lead time è migliorato più del tempo di coding, il che significa che il coding non è mai stato il vero collo di bottiglia. Quando nessuno deve più risparmiare token per il ticket più difficile del trimestre, gli engineer iniziano a usare l'AI anche per email, Jira, Confluence e tutto il lavoro che circonda una feature, non solo per il codice in sé.

Questa lezione vale indipendentemente dal modello che un team utilizza. Un team che usa un'API frontier e assegna budget di token per engineer, o limita l'uso per controllare i costi, sta ricreando esattamente lo stesso problema di razionamento che Revolut ha risolto eliminando i limiti. La soluzione non è sempre ospitare il modello in autonomia; a volte basta un piano di prezzo più economico o più lineare sullo stesso modello frontier.

L'indicazione pratica per qualsiasi responsabile di engineering è misurare il lead time, non solo il tempo di coding o le righe generate, prima di decidere se gli strumenti AI stanno davvero ripagando, e osservare se gli engineer stanno razionando il proprio utilizzo per motivi di costo o di quota.

Questa pagina si concentra sulla decisione relativa al costo del team e al rollout: se ospitare il modello in autonomia e come farlo una volta deciso. Per la domanda più ampia e indipendente dal modello su cosa significhino davvero pesi open, open source e API chiuse, e perché i laboratori e i governi li trattano in modo diverso, la guida di Nightschool AI Open-Source vs Closed AI Models affronta l'argomento per intero.

I numeri infrastrutturali di Revolut sono un utile avvertimento contro l'idea che ospitare un modello in autonomia sia semplice una volta che si hanno le GPU. Da aprile ad agosto 2026, con il numero di GPU fermo a 56, il carico è salito da circa 3 a oltre 7 richieste al secondo, mentre il time-to-first-token è sceso da circa 14 secondi a meno di 2, un miglioramento di latenza dell'88% senza nuovo hardware.

Abitbol attribuisce circa l'80% di questo guadagno alla configurazione del serving, non alle GPU: limitare la lunghezza del contesto ben sotto il massimo dichiarato dal modello, eseguire una quantizzazione a precisione inferiore su hardware GPU di generazione attuale e ottimizzare come la cache di attenzione del modello viene distribuita tra i dispositivi. La sua sintesi per i team che considerano questa strada è diretta: caricare i pesi sulle GPU e considerarlo fatto porta a prestazioni pessime.

Quel lavoro di ottimizzazione è un costo operativo reale e continuo che la maggior parte dei team sottovaluta quando confronta il prezzo di listino di un modello auto-ospitato con una bolletta API.