Enrutado de modelos: no todo merece el modelo grande

Pagar de más por costumbre

Montas un asistente, eliges el modelo más capaz que hay y lo enchufas a todo: resúmenes, clasificaciones, preguntas complejas, un “hola” del usuario. Funciona. La factura, en cambio, no perdona: estás pagando tarifa de cirujano para poner tiritas.

El problema no es el modelo grande. Es usarlo para todo. Una parte enorme del tráfico de un sistema real es trivial —extraer un dato, decidir un sí o un no, reformular una frase— y ese trabajo lo resuelve un modelo pequeño igual de bien y por una fracción del coste y la latencia. Enrutar es, sencillamente, mandar cada petición al modelo más barato que la resuelve bien. Ni más, ni menos.

La intuición: una cola de triaje

Piensa en urgencias de un hospital. No todo el que entra ve al especialista; primero hay un triaje que decide. La mayoría se resuelve en la primera consulta y solo los casos difíciles suben de nivel. Un buen enrutador de modelos hace lo mismo: un paso barato mira la petición y decide dónde va.

Hay tres formas de decidir, de menos a más sofisticada:

• Por reglas: heurísticas sobre la propia petición (longitud, tipo de tarea, si trae adjuntos, si el usuario es de pago). Baratas, transparentes, fáciles de depurar. Cubren más casos de los que uno cree.
• Por clasificador: un modelo pequeño y rápido etiqueta la dificultad de la petición y esa etiqueta elige el destino. Más flexible que las reglas, con un coste marginal mínimo.
• En cascada: empiezas por el modelo barato y solo escalas al caro si la respuesta no supera un control de calidad. Aprovecha al máximo el modelo pequeño, a cambio de una posible segunda llamada.

Ninguna es “la buena”. Se combinan: reglas para lo obvio, clasificador para la zona gris, cascada cuando el coste de equivocarse es alto.

Reglas primero, porque son gratis

Antes de meter un clasificador, exprime las heurísticas. Un enrutador por reglas resuelve una parte sorprendente del tráfico sin ninguna llamada extra al modelo:

from enum import Enum

class Tier(str, Enum):
    SMALL = "modelo-pequeno"   # barato, rápido, tareas acotadas
    LARGE = "modelo-grande"    # razonamiento, contexto largo

def enrutar(peticion: dict) -> Tier:
    texto = peticion["texto"]
    tarea = peticion.get("tarea", "chat")

    # Tareas mecánicas: clasificar, extraer, reformular → pequeño
    if tarea in {"clasificacion", "extraccion", "reformulacion"}:
        return Tier.SMALL

    # Contexto largo o adjuntos → necesita el grande
    if len(texto) > 4000 or peticion.get("adjuntos"):
        return Tier.LARGE

    # Señales de razonamiento en la petición → el grande
    señales = ("compara", "explica por qué", "analiza", "paso a paso")
    if any(s in texto.lower() for s in señales):
        return Tier.LARGE

    # Todo lo demás, corto y directo → empieza por el pequeño
    return Tier.SMALL

Esto no es elegante ni pretende serlo. Es un filtro barato que se escribe en cinco minutos y que puedes ajustar viendo qué peticiones acaban dónde. La clave es que cada regla existe por un motivo medido, no por corazonada.

La cascada: barato primero, caro si hace falta

Cuando equivocarse cuesta, la cascada da lo mejor de ambos mundos. Llamas al modelo pequeño, compruebas si la respuesta vale y solo entonces escalas:

def responder(peticion: dict) -> dict:
    respuesta = llamar(Tier.SMALL, peticion)

    if respuesta_suficiente(respuesta, peticion):
        return {"texto": respuesta, "modelo": Tier.SMALL, "escalado": False}

    # El pequeño no llegó: reintenta con el grande
    respuesta = llamar(Tier.LARGE, peticion)
    return {"texto": respuesta, "modelo": Tier.LARGE, "escalado": True}

Todo el peso recae en respuesta_suficiente. Un control de calidad honesto mira cosas verificables: ¿la salida cumple el esquema pedido?, ¿el modelo dijo “no lo sé” o pidió más contexto?, ¿la puntuación de confianza —si el modelo la expone— supera el umbral? Evita convertir el control en otro problema difícil: si validar la respuesta es tan caro como generarla, has movido el gasto en vez de reducirlo.

Qué ganas y qué arriesgas

El enrutado no es gratis en complejidad. Merece la pena verlo con números aproximados sobre una mezcla de tráfico realista, donde la mayoría de peticiones son sencillas:

La cascada tiene una trampa de latencia: cuando escala, el usuario paga dos llamadas seguidas. Si tu tasa de escalado se dispara, estás pagando el pequeño y el grande, lo peor de los dos mundos. Por eso el número que de verdad importa no es el coste medio, sino la tasa de escalado y el acierto del enrutador: qué porcentaje de peticiones acaba en el modelo grande y cuántas de las que fueron al pequeño deberían haber ido al grande.

Cómo desplegarlo sin llevarte un susto

Un enrutador mal calibrado degrada la calidad de forma silenciosa: manda al modelo pequeño peticiones que no debería y nadie se entera hasta que un usuario se queja. Trátalo como lo que es, una decisión con consecuencias, y despliégalo con red:

Primero, mide antes de tocar nada. Registra, para una muestra de tráfico real, qué modelo habría elegido tu enrutador y compáralo con lo que responde el modelo grande. Así conoces tu tasa de escalado y tus errores antes de que afecten a nadie.

Segundo, ten siempre una vía de escape. Una variable de entorno que fuerce “todo al grande” te salva el día cuando algo va mal y no sabes aún si es culpa del enrutado.

Tercero, vigila la calidad por ruta, no en agregado. Si solo miras la media, un enrutador que arruina el 10 % de las peticiones difíciles puede pasar desapercibido entre un 90 % de triviales que salen perfectas. Mide el modelo pequeño y el grande por separado.

Cierre: empieza por lo aburrido

El enrutado de modelos es de esas optimizaciones que parecen exóticas y resultan mundanas. No hace falta un clasificador entrenado ni una arquitectura de enrutadores en cascada para empezar. Hace falta mirar tu tráfico, aceptar que la mitad no merece el modelo caro y escribir cuatro reglas que lo reflejen.

Haz esto esta semana: coge cien peticiones reales de tu sistema, etiquétalas a mano como “trivial” o “difícil” y calcula qué porcentaje es trivial. Si pasa del 40 %, ya sabes cuánto estás pagando de más. Empieza por reglas, mide la tasa de escalado, y sube a clasificador o cascada solo cuando los números te digan que las reglas se quedan cortas. Optimizar el coste de un LLM no empieza por el modelo: empieza por no llamarlo cuando no toca.