Skip to content
Kevin Davila mascotkevindavila.dev> SOFTWARE ENGINEERES
AI•3 min read

Model routing and costs: when to pay for the expensive model

El camino más rápido para bajar la factura de AI no es negociar precios: es dejar de mandar todo al modelo caro. Clasificar un ticket, extraer un campo o resumir un texto no necesitan el mismo modelo que decidir una arquitectura o resolver un bug sutil.

Esta pieza es la economía del routing: los descuentos que ya tienes, el patrón del clasificador y cómo medir que no perdiste calidad. (La mecánica — alias, versionado, canary — está en Servir varios modelos en producción.)

La regla: dos tipos de petición

  • Peticiones de forma: clasificar, extraer, resumir, etiquetar, formatear. Piden cumplir un formato y casi siempre las hace bien un modelo chico.
  • Peticiones de fondo: razonar, planificar, decidir con información incompleta. Aquí el modelo grande se paga solo.

Si tu mezcla es 70% forma y 30% fondo, mandar todo al modelo grande es pagar 100% a precio de fondo.

Los descuentos que ya tienes (antes de rutear)

  1. Prompt caching: leer un prefijo desde caché cuesta una fracción de reprocesarlo. Precios de lectura de caché del mismo proveedor: desde $0.10/MTok (Haiku 4.5) hasta $0.25/MTok (Fable 5.1), contra $1–$10 de entrada normal. - Source: Pricing - Anthropic
  2. Batch processing: 50% de descuento para trabajo asíncrono agrupable. Si tu feature no necesita respuesta inmediata, esto es dinero gratis. - Source: Pricing - Anthropic
  3. Orden del prompt: el prefijo estable primero (system prompt, instrucciones) para maximizar aciertos de caché.

Antes de construir routing, verifica que ya estás aprovechando estos tres.

El patrón del clasificador

Cuando el routing por reglas se queda corto ("¿esta petición es difícil?"), un modelo barato decide. Es un patrón ya documentado por LangChain: su ModelRouterMiddleware usa un clasificador para elegir el modelo según criterios que defines, y devuelve también las probabilidades de esa decisión.

# Fuente: Building a Harness with Jev — Sydney Runkle / LangChain (adaptado)
from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
    ModelChoice, ModelRouterMiddleware,
)

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(model="openai:luna",
                            criteria="Consultas directas, extracción y cambios locales."),
        "powerful": ModelChoice(model="openai:sol",
                                criteria="Arquitectura y decisiones de alto riesgo."),
    },
    instructions="Elige el modelo menos costoso que pueda completar la tarea.",
)

agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

La pieza clave del patrón es el clasificador: modelos "System One" que no generan texto, evalúan el estado y devuelven decisiones tipadas. El caso publicado (Jev, de TypeSafe AI) reporta hasta 200x más rápido y 400x más barato que LLMs comparables en tareas de clasificación — o sea, decidir cuesta una fracción de lo que cuesta generar. - Source: Building a Harness with Jev - Sydney Runkle / LangChain

La aritmética

Con precios de lista por millón de tokens del mismo proveedor:

ModeloEntradaSalida
Haiku 4.5$1$5
Sonnet 5$2$10
Opus 5.5$4$20

Fuente: Pricing - Anthropic

Ejemplo (aritmética, no medida de nadie): un feature que hoy gasta 100 $ al mes con el modelo grande, y que manda el 70% de su volumen al modelo chico, baja su factura de tokens a ~40-50 $ — porque el ahorro no es lineal: el modelo barato cuesta entre 4 y 5 veces menos en esta tabla. Esa diferencia, cada mes, es el presupuesto de otra feature.

Cómo medirlo (para no cambiar calidad por dinero)

  • Costo por request: la métrica que quieres bajar. Sácala por petición, no solo por mes.
  • Calidad por segmento: separa tus evals entre peticiones de forma y de fondo; mejora en costo y regresión en calidad tienen que verse por separado.
  • Canary: manda un porcentaje al modelo barato, compara, y sube solo si gana.
  • Punto de retorno: define cuánto ahorro justifica el riesgo; si es 5%, no vale la complejidad.

5 pasos

  1. Separa tus peticiones en forma y fondo; cuenta cuántas son de cada tipo.
  2. Aprovecha los descuentos existentes (caché, batch, orden del prompt) antes de rutear.
  3. Empieza con routing por reglas: forma → barato, fondo → caro.
  4. Añade un clasificador solo para los casos grises, con un modelo de decisión.
  5. Pilota con canary y decide con costo por request + evals por segmento.

Con esto cierras el circuito: inferencia barata, servida con criterio, medida y ahora enrutada por costo. El marco completo, en la guía AI Engineering.

¿Ya rutas por tipo de petición o mandas todo al mismo modelo? Cuéntame en los comentarios cuánto bajó tu factura (o por qué decidiste no rutear).

Referencias

> More posts