Google ha annunciato il ritiro di Gemini 2.5 Flash, e gli sviluppatori che ci hanno costruito sopra stanno chiedendo di tenere il modello online più a lungo. Una discussione sul forum ufficiale di Google AI ha raccolto consenso immediato (120 punti su Hacker News, 80 commenti): chi usa 2.5 Flash in produzione riporta che i modelli più recenti della famiglia non reggono il confronto sui loro casi d’uso.

I benchmark interni degli sviluppatori mostrano che Gemini 3 Flash non mantiene le stesse prestazioni, nemmeno dopo aver adattato i prompt alle nuove linee guida. Per alcuni workflow il modello successivo è tre volte più costoso, per altri arriva troppo tardi (600-700ms contro i 300-400ms di 2.5 Flash in Australia, dove 3.5 Flash non ha deployment locale). La latenza bassa non è un capriccio: sotto i 400ms un agente vocale funziona, sopra si rompe.

Perché ti riguarda. Se stai costruendo su API di terzi, questa storia è il promemoria che serve: i modelli che usi oggi possono sparire domani, e il sostituto ufficiale può non fare il tuo lavoro. La comunità sta chiedendo continuità, ma la decisione non è loro. Se un pezzo critico del tuo sistema dipende da un modello specifico, devi avere pronto un piano B testato, non una speranza che il fornitore cambi idea.

Nel dettaglio

Cosa c’era prima

Gemini 2.5 Flash è stato per mesi il modello di riferimento per chi cercava un equilibrio fra qualità, latenza e costo: abbastanza capace per task complessi, abbastanza veloce per agenti vocali, abbastanza economico per volumi alti. Non il più potente della famiglia, ma il più affidabile per i carichi di lavoro che chiedono consistenza invece di picchi di intelligenza.

Molti team lo hanno scelto proprio per questo: un modello che fa bene una cosa e la fa sempre allo stesso modo è più facile da orchestrare di un modello geniale ma imprevedibile. Lo hanno messo in produzione, hanno calibrato i prompt, hanno costruito pipeline che dipendono dalla sua latenza e dal suo costo.

Cosa cambia

Google ha annunciato il ritiro senza offrire un sostituto che mantenga lo stesso rapporto qualità/latenza/costo. Gemini 3 Flash non tiene il passo nei test degli utenti, e 3.5 Flash costa tre volte tanto. Per chi lavora in regioni dove il deployment locale conta (Australia in particolare), la latenza raddoppia o triplica, rendendo inutilizzabile il modello per casi d’uso real-time.

La comunità sta chiedendo a Google di estendere la vita del modello, almeno fino a quando un sostituto vero sarà disponibile. La richiesta è ragionevole, ma non c’è garanzia che venga accolta: le roadmap dei fornitori di modelli seguono logiche interne che raramente coincidono con i tempi di produzione degli utenti.

Implicazioni per chi costruisce

Questa storia è un caso di scuola su un rischio che molti sottovalutano: la stabilità dei modelli non è garantita. Un’API può sparire, un modello può essere ritirato, un prezzo può cambiare. Se il tuo sistema dipende da un modello specifico senza alternative testate, hai una dipendenza critica non documentata.

Come raccontavamo quando Zuckerberg ha ammesso che gli agenti vanno più lenti del previsto, il ritmo di sviluppo dei fornitori non sempre coincide con quello di chi costruisce applicazioni reali. La pressione a spedire modelli nuovi può portare a ritirare quelli vecchi prima che i sostituti siano pronti per tutti i casi d’uso.

Cosa fare

Se usi Gemini 2.5 Flash in produzione, hai due strade:

1. Testare subito le alternative. Non fidarti dei benchmark pubblici: prendi i tuoi casi d’uso veri, quelli su cui il modello deve funzionare ogni giorno, e verifica che il sostituto proposto li regga. Se non li regge, il problema è tuo da risolvere, non di Google.

2. Avere un piano B con un altro fornitore. Non per ideologia, ma perché se un singolo modello è un punto di fallimento critico, devi sapere dove andare se sparisce. Testare un’alternativa su un altro provider (OpenAI, Anthropic, un modello open-weight self-hosted) ti dà un’opzione reale, non solo un wishful thinking.

La lezione più generale: se costruisci su modelli di terzi, valuta senza benchmark i tuoi casi d’uso specifici, e tieni traccia di quali modelli li reggono davvero. Non c’è sostituto per i test fatti sui tuoi dati.