Gemini API: Flex y Priority para costo y fiabilidad | Keryc
Google presentó dos nuevas opciones en la Gemini API pensadas para que puedas elegir mejor entre costo y fiabilidad: Flex y Priority. ¿Quieres gastar menos en tareas que no requieren respuesta inmediata, o asegurar que lo crítico no se interrumpa en picos de tráfico? Ahora puedes hacer ambas cosas desde la misma interfaz síncrona.
Qué ofrecen Flex y Priority
Flex y Priority son dos niveles de servicio que se configuran por petición y funcionan con los mismos endpoints que ya conoces. La idea es simple: separar la lógica según la criticidad de la tarea sin romper tu arquitectura.
Flex está pensado para cargas tolerantes a latencia, donde puedes aceptar menos prioridad a cambio de ahorro.
Priority está pensado para tráfico crítico que no puede ser preemptado, con garantías adicionales y manejo de desbordes.
¿Te suena a equilibrio perfecto entre precio y disponibilidad? Eso es justo lo que buscan.
Flex Inference: ahorrar en tareas en segundo plano
Flex es la opción económica. Google dice que ofrece hasta 50% de ahorro frente al nivel Standard al marcar la petición como menos crítica y aceptar mayor latencia.
Ahorro de costo: aproximadamente 50% menos en comparación con Standard.
Síncrono y simple: no necesitas el Batch API ni gestionar archivos o polling; usas los mismos endpoints síncronos.
Casos ideales: actualizaciones en CRM en lote, simulaciones a gran escala, agentes que "piensan" o navegan en segundo plano.
Para activarlo solo debes ajustar el parámetro service_tier en tu solicitud, por ejemplo {'service_tier': 'flex'}. Flex está disponible para proyectos pagos y para las rutas GenerateContent y Interactions.
Priority Inference: proteger lo crítico
Priority es la opción para cuando la fiabilidad es la prioridad absoluta. Está diseñada para que tus solicitudes más importantes no sean interrumpidas incluso en picos de uso.
Mayor criticidad: más posibilidades de que tu petición sea atendida preferentemente.
Downgrade suave: si excedes límites de Priority, el exceso se sirve en Standard en lugar de fallar, manteniendo tu servicio activo.
Transparencia: la respuesta del API indica qué nivel atendió la petición, así tienes visibilidad sobre rendimiento y facturación.
Casos ideales: bots de soporte en tiempo real, pipelines de moderación en vivo, solicitudes sensibles a la latencia.
Priority se activa igual, ajustando service_tier, y está disponible para proyectos con planes pagados Tier 2 y 3 en GenerateContent y Interactions.
Cómo integrarlo sin romper tu sistema
Lo más práctico es mapear internamente cada tipo de trabajo a un service_tier:
Tareas de fondo y procesamiento en lote -> flex.
Interacciones con usuarios en tiempo real -> priority.
¿Y si no quieres reescribir toda tu cola asíncrona? Buena noticia: al ser síncronos, Flex y Priority permiten enviar tanto trabajos interactivos como de fondo a los mismos endpoints que ya usas, evitando la complejidad de gestionar un flujo Batch separado.
También conviene monitorear la respuesta del API para saber cuándo tus solicitudes fueron atendidas en cada nivel y evaluar costos. La documentación y la "cookbook" ofrecen ejemplos listos para correr que te ahorran tiempo en pruebas.
Reflexión breve
Con Flex y Priority Google simplifica un dilema clásico: optimizar costos sin sacrificar la fiabilidad en lo que importa. Si estás escalando agentes, copilotos o pipelines de datos, esto te da una paleta más fina para decidir dónde gastar y dónde ahorrar. ¿Listo para probar cuál conviene más a tu caso?
