Quando la latenza di un'API esterna diventa un problema di UX, la risposta non è sempre un modello più grande. È quello che emerge da un'esperienza raccontata su Reddit: un'applicazione interna usava Gemini Flash con il budget di thinking più basso per stabilire se due stringhe fossero correlate in un certo modo. Il responso era accurato al 99%, ma arrivava in 0,9–1,2 secondi. Può sembrare poco, ma chi usa l'app migliaia di volte al giorno clicca senza aspettare il suggerimento. Un'implementazione deterministica in Python o JavaScript risolveva il confronto in pochi millisecondi con un'accuratezza di poco superiore al 66%, mentre Gemini Flash si fermava al 99%. La soluzione è stata addestrare un modello compatto.

L'autore del post è partito da circa 550 casi d'uso reali. Ha poi chiesto a due modelli frontier di generare esempi simili, arrivando a circa 2.500 esempi totali. Il training è stato eseguito su una RTX A6000 da 16 GB e ha richiesto circa 15 minuti. Il risultato è un modello da circa 50 MB che, quando eseguito localmente su una CPU Threadripper più vecchia a 3,1 GHz, risponde in 0,06 secondi e suggerisce la risposta corretta nel 97% dei casi. Il calo dal 99% al 97% è stato considerato accettabile.

La notizia non è il singolo modello, ma il crollo della soglia di accesso al training locale. Qui entrano in gioco implicazioni di secondo e terzo ordine. La prima è che il costo marginale di ogni chiamata scende: una volta addestrato, un artefatto da 50 MB può essere servito dal server interno senza dipendere da latenza di rete, limiti di rate o costi variabili. Non è un dettaglio: per task booleani o di classificazione stretta, un modello specializzato può girare self-hosted su CPU normali, senza richiedere GPU dedicate in inference. La seconda è che la generazione sintetica dei dati non elimina del tutto la dipendenza dai modelli frontier: i 2.500 esempi sono stati creati anche con due modelli esterni. Il modello locale, quindi, eredita parte della qualità di quei modelli, ma la impacchetta in una forma operativa autonoma. Terzo, il caso mostra che il trade-off tra accuratezza e latenza non è lineare: passare da 99% a 97% può essere irrilevante se il sistema viene usato come supporto a una decisione umana rapida, mentre guadagnare un ordine di grandezza sulla latenza cambia il comportamento degli utenti.

L'autore prevede di fare deploy lato server, con una latenza stimata di 0,1–0,2 secondi, e di registrare accuratezza e confronti per valutare il modello e integrare il training. L'interessante è che, in teoria, lo stesso modello potrebbe girare anche lato client nel browser. La scelta di non farlo subito è pragmatica: la complessità dell'inference client-side non è giustificata se il server risponde abbastanza in fretta. Eppure l'opzione resta sul tavolo.

Strutturalmente, questo episodio segnala che i modelli compatti stanno diventando la via naturale per le decisioni ad alta frequenza nei sistemi interni. Chi guadagna? I team che hanno già una GPU per il training e CPU per l'inference: possono internalizzare un task senza cambiare infrastruttura. Chi perde? I fornitori di API per cui ogni chiamata è ricavo: più workload di questo tipo migrano verso artefatti locali, più il loro ruolo si concentra sulla generazione di dati sintetici e sui task complessi. Non significa che Gemini Flash o servizi simili spariscano: restano utili per compiti variabili, per la prototipazione e per generare i dati iniziali. Ma per un problema booleano ripetuto migliaia di volte, il calcolo locale ha vinto su latenza e prevedibilità operativa. Per chi valuta deployment on-premise, questo tipo di esperienza rientra nei trade-off tra TCO, latenza e controllo dei dati documentati da AI-RADAR nella sezione /llm-onpremise.