Flash o Pro: elegir modelo por tarea

Flash y Pro no son «el barato» y «el bueno»: son dos puntos de un mismo compromiso entre latencia/coste y profundidad de razonamiento. La decisión no se toma una vez por aplicación, se toma una vez por tarea — y una aplicación seria acaba llamando a los dos desde sitios distintos del mismo código.

01 — El eje

Qué se mueve cuando cambias de variante

Las dos variantes comparten familia, API y forma de llamada. Lo único que cambia es dónde caen en este eje. Las barras son cualitativas: marcan la dirección del compromiso, no una medida.

Flash · velocidad

Pro · velocidad

Flash · razonamiento

Pro · razonamiento

// dirección del compromiso, no una medida — las cifras reales las pones tú en «Para hacer»

Cambiar de variante es cambiar una cadena en el constructor. Esa facilidad es una trampa: como el cambio cuesta cero, es tentador dejar Pro «por si acaso» en todas partes y descubrir el coste a fin de mes.

02 — Decisión

El árbol, tarea por tarea

¿La respuesta la está esperando una persona delante de una pantalla?

SÍ → FlashEn un chat, el usuario nota los segundos antes que la calidad. La latencia es parte de la respuesta.

NO → sigue bajandoUn proceso por lotes o nocturno no tiene presión de latencia; puedes gastar tiempo en calidad.

¿La tarea tiene una respuesta única y comprobable, o admite matiz?

COMPROBABLE → FlashClasificar, extraer un campo, etiquetar, reformatear. Si puedes verificar la salida con un assert, Flash suele bastar.

CON MATIZ → ProRazonamiento en varios pasos, redacción larga, decisiones donde dos respuestas distintas pueden ser válidas.

¿Cuántas veces al día se ejecuta esto?

MILES → FlashEl volumen multiplica cualquier diferencia de precio por llamada. Aquí es donde se decide la factura.

DECENAS → ProA poco volumen, la diferencia de coste es ruido y la de calidad no lo es.

Fíjate en que ninguna rama pregunta «¿cuál es mejor?». Las tres preguntan por la tarea. Por eso el árbol se recorre una vez por cada llamada distinta de tu aplicación, no una vez por aplicación.

03 — Enrutado

El patrón que sale de aquí

Si la decisión es por tarea, el código no debería tener el nombre del modelo esparcido por todas partes. El patrón mínimo es una sola tabla y una función que la consulte:

MODELO_POR_TAREA = {
    "clasificar_ticket": "gemini-flash",   # miles/día, salida verificable
    "resumen_chat":      "gemini-flash",   # hay alguien esperando
    "informe_mensual":   "gemini-pro",     # decenas/mes, admite matiz
}

def modelo_para(tarea):
    return genai.GenerativeModel(MODELO_POR_TAREA[tarea])

Los nombres de arriba están abreviados a propósito: el identificador exacto sale del listado de la API, no de un PDF. Lo que importa del patrón es que el día que quieras probar si una tarea aguanta en Flash, cambias una línea de la tabla y mides — en vez de buscar por el repositorio.

Ese experimento, además, casi nunca es binario. Una tarea que falla en Flash con un prompt flojo puede aguantar perfectamente con un prompt mejor. Antes de subir de variante, merece la pena gastar un intento en el prompt: sale más barato y el aprendizaje se queda contigo.

Auditoría La guía sostiene que los modelos de Google «suelen tener una ventana de contexto mucho más grande y costes competitivos», y ahí se detiene: ni una cifra, ni un competidor concreto, ni una fecha. Es exactamente el tipo de afirmación que era cierta el día que se escribió y que nadie vuelve a comprobar. ¿Contra qué modelo concreto es «competitivo», y en qué unidad — por millón de tokens de entrada, de salida, o por llamada? ¿Sigue siendo Google quien tiene la ventana mayor a la fecha en que lees esto? ¿Y cuánto cuesta esa ventana grande cuando la llenas de verdad, en vez de dejarla vacía?

Para hacer

Medir en vez de suponer

Coge un prompt tuyo real y ejecútalo diez veces contra Flash y diez contra Pro. Apunta tres columnas: segundos hasta la respuesta completa, tokens de entrada y salida (usage_metadata de la respuesta) y si la salida te vale o no. Si las diez de Flash te valen, esa tarea ya tiene modelo asignado y no hace falta discutirlo más.