Google ha anunciado el retiro de Gemini 2.5 Flash, y los desarrolladores que han construido sobre él están pidiendo mantener el modelo en línea más tiempo. Una discusión en el foro oficial de Google AI ganó consenso inmediato (120 puntos en Hacker News, 80 comentarios): quienes usan 2.5 Flash en producción reportan que los modelos más recientes de la familia no se sostienen en sus casos de uso.

Los benchmarks internos de los desarrolladores muestran que Gemini 3 Flash no mantiene el mismo rendimiento, ni siquiera después de adaptar los prompts a las nuevas directrices. Para algunos workflows el modelo siguiente es tres veces más caro, para otros llega demasiado tarde (600-700ms contra los 300-400ms de 2.5 Flash en Australia, donde 3.5 Flash no tiene deployment local). La latencia baja no es un capricho: por debajo de 400ms un agente de voz funciona, por encima se quiebra.

Por qué te concierne. Si estás construyendo sobre APIs de terceros, esta historia es el recordatorio que necesitas: los modelos que usas hoy pueden desaparecer mañana, y el sustituto oficial podría no hacer tu trabajo. La comunidad está pidiendo continuidad, pero la decisión no es suya. Si un componente crítico de tu sistema depende de un modelo específico, debes tener listo un plan B probado, no la esperanza de que el proveedor cambie de opinión.

En detalle

Lo que había antes

Gemini 2.5 Flash fue durante meses el modelo de referencia para quien buscaba equilibrio entre calidad, latencia y costo: lo bastante capaz para tareas complejas, lo bastante rápido para agentes de voz, lo bastante económico para volúmenes altos. No el más potente de la familia, pero el más confiable para cargas de trabajo que exigen consistencia en lugar de picos de inteligencia.

Muchos equipos lo eligieron por esto: un modelo que hace bien una cosa y la hace siempre de la misma manera es más fácil de orquestar que uno brillante pero impredecible. Lo pusieron en producción, calibraron los prompts, construyeron pipelines que dependen de su latencia y su costo.

Qué cambia

Google anunció el retiro sin ofrecer un sustituto que mantenga la misma relación calidad/latencia/costo. Gemini 3 Flash no se mantiene a la altura en las pruebas de los usuarios, y 3.5 Flash cuesta tres veces más. Para quien trabaja en regiones donde el deployment local importa (Australia en particular), la latencia se duplica o triplica, haciendo inutilizable el modelo para casos de uso en tiempo real.

La comunidad está pidiendo a Google que extienda la vida del modelo, al menos hasta que un sustituto verdadero esté disponible. La petición es razonable, pero no hay garantía de que se acepte: las roadmaps de los proveedores de modelos siguen lógicas internas que rara vez coinciden con los tiempos de producción de los usuarios.

Implicaciones para quien construye

Esta historia es un caso de manual sobre un riesgo que muchos subestiman: la estabilidad de los modelos no está garantizada. Una API puede desaparecer, un modelo puede retirarse, un precio puede cambiar. Si tu sistema depende de un modelo específico sin alternativas probadas, tienes una dependencia crítica no documentada.

Como contábamos cuando Zuckerberg admitió que los agentes van más lento de lo esperado, el ritmo de desarrollo de los proveedores no siempre coincide con el de quien construye aplicaciones reales. La presión por lanzar modelos nuevos puede llevar a retirar los antiguos antes de que sus sustitutos estén listos para todos los casos de uso.

Qué hacer

Si usas Gemini 2.5 Flash en producción, tienes dos caminos:

1. Probar las alternativas de inmediato. No confíes en los benchmarks públicos: toma tus casos de uso reales, aquellos en los que el modelo debe funcionar cada día, y verifica que el sustituto propuesto los aguante. Si no los aguanta, el problema es tuyo de resolver, no de Google.

2. Tener un plan B con otro proveedor. No por ideología, sino porque si un único modelo es un punto de fallo crítico, debes saber a dónde ir si desaparece. Probar una alternativa en otro proveedor (OpenAI, Anthropic, un modelo open-weight auto-alojado) te da una opción real, no solo pensamiento desiderativo.

La lección más general: si construyes sobre modelos de terceros, evalúa sin benchmarks tus casos de uso específicos, y mantén registro de qué modelos realmente los sostienen. No hay sustituto para las pruebas hechas sobre tus datos.