Recorte de precios de Gemini 3.7 Flash: corrige la caché y el enrutamiento
Un menor precio por token desplaza el gasto en inferencia hacia fallos de caché, enrutamiento y sobrecarga de servicio. Rediseña la ruta de solicitud antes de perseguir tokens.
Si gestionas el gasto en inferencia, la decisión es si un recorte de precios del modelo cambia tu arquitectura. El equilibrio está entre el precio por token y la ruta de solicitud: tasa de acierto de caché, mezcla de enrutamiento y sobrecarga de servicio. Recalcula la factura a partir de los cuatro términos siguientes.
- Gasto en tokens = volumen × precio.
- Ahorro de caché = tasa de acierto de caché × descuento de caché.
- Ahorro de enrutamiento = proporción de solicitudes trasladadas a un modelo más barato × diferencia de precio.
- Sobrecarga = costos de servicio, reintentos y latencia.
Google fijó Gemini 3.7 Flash a $0.75 por millón de tokens de entrada y $3.75 por millón de tokens de salida, la mitad de la tarifa que cobraba Gemini 3.6 Flash tres semanas antes. La tarifa reducida termina el 31 de diciembre de 2026, tras lo cual se duplica a $1.50 por millón de tokens de entrada y $7.50 por millón de tokens de salida.
Google lanzó Gemini 3.7 Flash el 13 de agosto de 2026 como un modelo de gama media para asistencia en programación, procesamiento de documentos y flujos de trabajo de agentes. Incluía una ventana de contexto de 1 millón de tokens y soporte multimodal alineado con la línea Gemini 3.
Google convirtió Gemini 3.7 Flash en el modelo de backend predeterminado en su Gemini Enterprise Agent Platform y lo desplegó en Android Studio, la herramienta de desarrollo Antigravity y Gemini Spark, un asistente de productividad con IA utilizado en más de 160 países. Los materiales de lanzamiento afirmaban que superaba a Claude Sonnet 5 de Anthropic y a GPT-5.6 Terra de OpenAI en la finalización de flujos de trabajo empresariales reales.
El recorte de precios cambia el gasto en tokens, no la ruta de solicitud
La objeción obvia es que un menor precio por token debería reducir la factura en la misma proporción. Eso solo es cierto si el gasto en tokens domina y el volumen se mantiene estable. Si el gasto en tokens es pequeño, el cambio de precio baja el suelo, no la factura.
El gasto en tokens es el término sencillo; el volumen es comportamiento del usuario, no arquitectura, y el precio es la variable. La caché, el enrutamiento y la sobrecarga son decisiones de diseño. Un precio más bajo puede hacer que un mal manejo de solicitudes parezca más barato sin que lo sea: los mismos fallos de caché, errores de enrutamiento y reintentos permanecen. El recorte también puede aumentar el volumen, lo que borra los ahorros.
La caché y el enrutamiento sobreviven al reinicio
La caché es donde se esconden los primeros ahorros. Los contextos largos son costosos cuando se reenvían. Durante la ventana promocional, los tokens de entrada en caché de Gemini 3.7 Flash se facturaban a aproximadamente una décima parte de la tarifa estándar de entrada. Eso cambia el costo del contexto repetido. Si los prompts reutilizan el mismo contexto, los ahorros se acumulan con la tasa de acierto. Las claves de caché deben ser lo suficientemente estables para acertar, pero lo suficientemente acotadas para evitar contexto obsoleto.
La fórmula es ahorro de caché = tasa de acierto de caché × descuento de caché. Una tasa de acierto alta convierte el contexto de un cargo recurrente en un costo casi fijo. Una tasa de acierto baja te deja pagando el precio completo por texto repetido.
El enrutamiento es donde se esconde el segundo ahorro. Consiste en enviar una proporción de solicitudes a un modelo más barato cuando la calidad es suficiente. La fórmula es ahorro de enrutamiento = proporción de solicitudes trasladadas a un modelo más barato × diferencia de precio. El enrutamiento de modelos es una política, no una elección de modelo. Necesita un umbral de calidad, un mecanismo de respaldo y una forma de medir el resultado.
La diferencia de precio importa, pero la proporción trasladada importa más. Si solo una pequeña parte del tráfico puede trasladarse, el precio apenas cambia la factura. Si una gran parte puede trasladarse, la arquitectura captura la diferencia de precio.
La sobrecarga de servicio es el costo oculto
La sobrecarga de servicio es el término que se esconde en la factura. El recorte no elimina las colas, los tiempos de espera ni las solicitudes fallidas. Es lo más fácil de pasar por alto porque aparece como latencia en la cola, no como costo de tokens. Si los reintentos aumentan, los ahorros en tokens pueden compensarse con llamadas adicionales. Si la latencia obliga a un contexto mayor o a más sondeos, la sobrecarga crece. Aquí es donde un modelo más barato aún puede generar una factura más alta.
Prioriza la mayor diferencia tras un cambio de precio. Corrige las claves de caché y la reutilización de contexto cuando la tasa de acierto es baja, añade un clasificador o una política cuando la proporción de enrutamiento es baja, y reduce los reintentos y ajusta los tiempos de espera cuando la sobrecarga es alta. Luego vuelve a ejecutar el modelo de cuatro términos.