Reducir a la mitad los costos de la API de LLM: una guía de enrutamiento de modelos para cargas de trabajo de producción en 2026

El problema de costos que se esconde en su factura

Mire el parámetro model en su código de producción. Para la mayoría de equipos que ejecutan una carga de trabajo con LLM que ya pasó de prototipo a tráfico real, ese parámetro se establece una vez (generalmente al modelo más potente al que el equipo tenía acceso cuando lanzó) y nunca se revisita. Cada consulta, sin importar su complejidad, va al mismo modelo. Y ahí es donde habita el sobrecosto silencioso.

En cualquier carga de trabajo de producción no trivial, las consultas no son uniformemente difíciles. Un asistente de soporte al cliente puede ver que el 80% de las consultas son búsquedas simples, clasificaciones o seguimientos breves, y el 20% que realmente requieren razonamiento de vanguardia. Un asistente de codificación puede manejar un flujo constante de pequeños refactors y una cola larga de cambios arquitectónicos multiarchivo. Un pipeline de contenidos puede procesar cientos de tareas de resumen por cada una que requiere escritura creativa estructurada. La forma del trabajo es desigual, pero el enrutamiento al modelo no lo es.

Si hoy está ejecutando 100M de tokens al mes en GPT-5.5 y el 70% de esas consultas serían respondidas igual de bien por un modelo más barato, está pagando aproximadamente $600 al mes por una capacidad que no está usando. A volúmenes más altos, el mismo patrón se compone linealmente: por cada 1B de tokens, la brecha entre una configuración sin enrutamiento y una enrutada es de varios miles de dólares al mes.

El enrutamiento es la respuesta de ingeniería a esa asimetría. El principio es simple: envíe cada consulta al modelo más barato que pueda manejarla y escale a un modelo más capaz solo cuando lo necesite. Las implementaciones son donde viven los trade-offs interesantes, y la mayoría de la guía publicada los maneja mal. Esta pieza cubre los tres patrones que realmente funcionan en producción, las cuentas de costos que sustentan el caso, los modos de falla que lo harán tropezar y una guía de migración para pasar de una configuración de un solo modelo a una enrutada sin reescribir su aplicación.

Los datos de precios en los que se basa este artículo provienen de la pieza complementaria (la comparación de precios de APIs de LLM de 2026), que establece las tarifas por modelo referenciadas en todo el texto. Donde esta guía cita una cifra de costo, está basada en esos datos.

Los tres patrones de enrutamiento que funcionan en producción

Hay tres patrones establecidos para enrutar tráfico de LLM. Difieren en la complejidad de implementación, la sobrecarga de latencia y los tipos de ahorro de costos que desbloquean. La mayoría de los sistemas de producción eventualmente usan una combinación de los tres; entender las fortalezas de cada uno le ayuda a secuenciar el trabajo.

Patrón 1: Reglas estáticas

El patrón más simple. Escribe reglas que enrutan consultas a diferentes modelos según propiedades observables de la solicitud: longitud de la entrada, nivel de usuario, tipo de consulta (si ya tiene un clasificador), endpoint de la API o lógica de negocio. Las consultas cortas van a un modelo barato; las largas van a uno más potente. Los usuarios de la capa gratuita obtienen un modelo más barato que los usuarios de pago. Las solicitudes de generación de código van a un modelo ajustado para código; todo lo demás va a un modelo de propósito general.

El enrutamiento estático es predecible, depurable y prácticamente no agrega sobrecarga de latencia: la decisión de enrutamiento son unas pocas líneas de código que se ejecutan localmente. El techo también es más bajo: está enrutando en función de propiedades que puede observar antes de que el modelo se ejecute, lo que significa que no puede enrutar según “qué tan difícil es realmente la consulta” porque aún no lo sabe. Para cargas de trabajo donde las propiedades de entrada se correlacionan bien con la dificultad (los documentos largos suelen ser más difíciles; el código generalmente difiere de la prosa; los usuarios de pago suelen tener consultas más exigentes), las reglas estáticas pueden capturar el 30–50% del ahorro disponible con muy poco esfuerzo de ingeniería.

Patrón 2: Cascada

El patrón de mayor aplicabilidad. Envía la consulta primero a un modelo barato; si la respuesta cumple un umbral de calidad, la devuelve; si no, escala a un modelo más capaz y utiliza esa respuesta en su lugar. El ahorro de costos proviene de que, para las consultas que el modelo barato puede manejar, solo paga el precio de ese modelo barato.

La característica distintiva del patrón de cascada es que la decisión de enrutamiento está informada por la salida del modelo, no solo por la entrada: deja que el modelo barato intente el trabajo y luego juzga si el intento fue lo suficientemente bueno. El juicio se puede implementar de varias maneras: puntuaciones de confianza del propio modelo, validación de salida estructurada (¿la respuesta se analiza según el esquema esperado?), prompts de autoevaluación (preguntar a un modelo pequeño si la respuesta responde la pregunta) o señales de comportamiento downstream (¿el usuario aceptó la respuesta, o la reformuló e intentó de nuevo?).

La cascada es el patrón que la mayoría de los sistemas de producción adoptan finalmente porque captura ahorros que las reglas estáticas no pueden. El trade-off es que, en las consultas que escalan, se paga tanto la llamada del modelo barato como la llamada del modelo insignia, por lo que el ahorro depende de qué fracción de consultas tiene éxito en el nivel del modelo barato. Este es el patrón que desarrollamos en detalle más adelante en este artículo.

Patrón 3: Enrutamiento basado en un clasificador

El techo más alto y la mayor inversión de ingeniería. Un modelo pequeño y rápido (a menudo una versión ajustada de un modelo sub-frontera, o un clasificador dedicado) mira cada consulta entrante y predice qué modelo downstream debe manejarla. El clasificador puede decidir según el tipo de consulta (“esto parece una tarea de generación de código; enrutar al modelo ajustado para código”), estimación de dificultad (“esto parece una consulta de razonamiento difícil; enrutar a GPT-5.5”) o una política de enrutamiento aprendida entrenada con tráfico histórico y resultados.

El enrutamiento basado en clasificador puede superar a la cascada porque la decisión de enrutamiento ocurre antes de que se ejecute cualquier modelo costoso, así que no paga el “impuesto del modelo barato” en consultas que siempre iban a necesitar el modelo insignia. El costo es el trabajo de ingeniería para construir, entrenar y mantener el clasificador en sí, más la pequeña sobrecarga de latencia de la llamada de enrutamiento. Para cargas de trabajo de muy alto volumen, este trade-off se paga solo; para cargas más pequeñas, generalmente no.

¿Con qué patrón empezar?: Reglas estáticas primero si su carga de trabajo tiene señales de enrutamiento obvias (longitud de entrada, nivel de usuario, endpoint). Cascada si no las tiene, o una vez que haya agotado las reglas estáticas obvias. Basado en clasificador solo después de que tanto estático como cascada estén en su lugar y el volumen de la carga de trabajo justifique la inversión de ingeniería. Saltar directamente al basado en clasificador es una trampa clásica de sobre-ingeniería que la mayoría de equipos lamentan.

Qué medir antes de empezar a enrutar

No puede optimizar lo que no mide. Antes de introducir cualquier lógica de enrutamiento en un sistema de producción, instrumente la carga de trabajo actual de un solo modelo para tener una línea base con la cual comparar. La instrumentación no necesita ser elaborada: un registro básico de cada solicitud con un pequeño conjunto de campos es suficiente para empezar.

La instrumentación mínima útil:

• Por solicitud: modelo usado, conteo de tokens de entrada, conteo de tokens de salida, costo (calculado a partir de conteos de tokens y la tabla de tarifas), latencia de extremo a extremo, estado de respuesta (éxito / error / parcial) y una etiqueta de tipo de consulta si tiene una.
• Por conversación o por usuario: duración de la sesión, conteo de reintentos (señala que el usuario no aceptó la primera respuesta), tasa de seguimiento (señala que la respuesta requirió aclaración).
• Un conjunto de evaluación retenido: 100–500 consultas representativas que pueda volver a ejecutar en cualquier modelo, con salidas de referencia en las que confíe. Así es como mide si un modelo más barato candidato produce calidad aceptable en su carga de trabajo. Sin esto, cada decisión de enrutamiento es una conjetura.

El conjunto de evaluación es donde la mayoría de equipos invierte de menos, y es la pieza de infraestructura de mayor apalancamiento para cualquier proyecto de enrutamiento. Herramientas ligeras como Promptfoo o Helicone evals pueden levantarlo rápidamente; para cargas de trabajo en etapa temprana, un conjunto curado a mano de 50 consultas con salidas calificadas manualmente es suficiente para comenzar.

Una vez instrumentado, ejecute la carga de trabajo tal como está durante al menos una semana para establecer la línea base. La forma de los datos (qué tan sesgada está su distribución de longitud de entrada, qué fracción de consultas son cortas y simples, qué fracción parece difícil) le dice con qué patrón de enrutamiento empezar.

El patrón de cascada en detalle, con cálculo de costos

El patrón de cascada merece más espacio porque es el más aplicable y el que la mayoría de equipos implementará primero o segundo. Las matemáticas también son donde el caso a favor del enrutamiento se vuelve concreto.

Considere una carga de trabajo de producción representativa que hoy corre en Claude Sonnet 4.6: 100 millones de tokens por mes, 80% entrada y 20% salida, $475 de factura mensual a precio de lista. Supongamos que introducimos una cascada delante: las consultas llegan primero a Claude Haiku 4.5 y solo escalan a Sonnet 4.6 si la respuesta de Haiku no supera un control de calidad. Haiku 4.5 lista $1.00 de entrada y $5.00 de salida por millón de tokens, un tercio de la tarifa de Sonnet.

La cuenta de costos depende de dos parámetros: qué porcentaje de consultas tiene éxito en el nivel de Haiku (lo llamamos la tasa de éxito) y cómo difiere la relación entrada/salida entre las consultas exitosas y las escaladas. Para simplificar, suponga que la relación entrada/salida es la misma para ambas, y que la tasa de éxito es del 70%, lo que significa que la respuesta de Haiku es lo suficientemente buena en el 70% de las consultas, y el 30% escala a Sonnet.

Lo que esto le dice. Incluso con una tasa de éxito moderada del 70% (es decir, Haiku acierta 7 de cada 10 veces), la cascada reduce la factura a la mitad. La razón es que la llamada al modelo barato es mucho más barata que la llamada al modelo insignia, por lo que pagar ambas en el 30% de consultas que escalan sigue siendo mucho menos que pagar el insignia en cada consulta. El punto de equilibrio (donde la cascada iguala el costo del modelo único) es aproximadamente una tasa de éxito del 33%. Por debajo de eso, es mejor ir directo; por encima, gana la cascada.

La implementación mínima viable de la cascada

A continuación, la versión más simple del patrón, expresada en Python con el cliente compatible con OpenAI (que funciona contra cualquier proveedor que exponga un endpoint compatible con OpenAI, incluidos Claude a través de la capa de compatibilidad de Anthropic, Gemini y el endpoint unificado de CometAPI). La estructura es deliberadamente básica; las implementaciones de producción agregan observabilidad, manejo de errores y controles de calidad más sofisticados.

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # or your provider of choice
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Run a query through a cascade.
    Returns (response, model_used, escalated).
    """

    # Step 1: try the cheap model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Step 2: judge whether the cheap response is good enough
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Step 3: escalate to the flagship
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Quality gate.
    Returns True if the cheap model's output is good enough.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Structured output: it has to parse against the schema
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # For free-form responses, plug in your own quality signal:
    # - confidence score from the model
    # - self-evaluation prompt to a small model
    # - rules-based checks (length, format, refusal patterns)

    return True

Este es un punto de partida, no una implementación terminada. Tres cosas que agregaría para producción:

• Una compuerta de calidad real. La función is_acceptable anterior es intencionalmente mínima. En la práctica, la compuerta es la pieza más importante de la cascada: demasiado laxa y enviará respuestas de baja calidad; demasiado estricta y escalará con demasiada frecuencia y perderá el ahorro. La mayoría de las cascadas en producción usan una combinación de validación de salida estructurada, detección de negativas (el modelo barato diciendo “No puedo responder esto”) y autoevaluación por un modelo pequeño al que se le pide calificar la respuesta.
• Observabilidad por solicitud. Registre qué modelo se usó, si la solicitud escaló, la latencia en cada nivel y el costo. Esto es lo que le dice, después de una semana ejecutando la cascada, si la tasa de éxito es la que suponía.
• Una ruta canaria para evaluación. Envíe un pequeño porcentaje del tráfico (digamos 5%) a través del modelo insignia incluso cuando la cascada tenga éxito en el nivel barato. Compare las respuestas en una tarea de calificación reservada. Así detecta la degradación silenciosa de la calidad; vea la siguiente sección.

Dónde se rompe el enrutamiento

La matemática de ahorro arriba es real, pero también es el caso optimista. Tres modos de falla sorprenden a los equipos, y nombrarlos honestamente es lo que separa una implementación de enrutamiento que compone valor de una que degrada silenciosamente el producto.

Sobrecarga de latencia en solicitudes escaladas

Cuando una consulta escala, usted paga la llamada del modelo barato antes de que empiece la llamada del modelo insignia. Si el modelo barato tarda 800ms y el insignia 1.5s, la consulta escalada tarda 2.3s de extremo a extremo. Para cargas de trabajo sensibles a la latencia, esto importa. Las mitigaciones son elegir un modelo barato rápido (Haiku 4.5 y Gemini 3 Flash están diseñados para esto), establecer tiempos de espera agresivos en la llamada al modelo barato y considerar llamadas en paralelo para las consultas que sospeche que es más probable que escalen. Algunos equipos aceptan el costo de latencia porque el ahorro en dólares es grande; otros usan reglas estáticas para evitar enviar a través de la cascada las consultas que son obviamente difíciles.

Degradación silenciosa de la calidad

El modo de falla más insidioso. El modelo barato produce respuestas que pasan su compuerta de calidad pero son sutilmente peores que las respuestas del modelo insignia: ligeramente menos precisas, ligeramente menos útiles, ligeramente más propensas a omitir casos extremos. Los usuarios no se quejan de inmediato; la métrica que mira (latencia de respuesta, tasa de error, tasa de aprobación de la compuerta) se ve bien; pero las métricas aguas abajo (retención de usuarios, tasa de conversión, escalaciones de soporte) derivan. Para cuando lo nota, ha enviado semanas de calidad degradada.

La defensa es la ruta canaria mencionada arriba: un porcentaje reservado de tráfico que se ejecuta a través del insignia en paralelo con la cascada, con ambas respuestas calificadas contra una rúbrica de evaluación. La calificación puede hacerla un modelo (LLM como juez) o mediante revisión humana muestreada. El punto es mantener una señal de calidad continua que sea independiente de la compuerta de la cascada, de modo que la degradación aparezca como una deriva en esa señal y no como una sorpresa aguas abajo.

Costo de complejidad en código y observabilidad

Cada modelo adicional en el grafo de enrutamiento es otro modelo que evaluar, monitorizar y actualizar cuando su proveedor lanza una nueva versión. Una cascada de dos niveles es manejable; un enrutador con clasificador y cinco modelos con rutas separadas para código, RAG, chat, agentes y casos límite es significativamente más complejo que la configuración de un solo modelo que reemplazó. La complejidad vale la pena cuando el volumen de la carga justifica el esfuerzo; por debajo de ese volumen, el tiempo de ingeniería dedicado a mantener la capa de enrutamiento puede exceder los ahorros que produce. Sea honesto sobre su umbral de volumen.

Cómo ayudan los agregadores (y dónde no)

Los agregadores de LLM (servicios que exponen múltiples modelos detrás de una única API compatible con OpenAI) interactúan con el enrutamiento de dos maneras distintas. Ambas valen la pena entenderlas porque la respuesta a “¿quiero un agregador en mi capa de enrutamiento?” depende de cuál interacción le importe.

La ayuda genuina: eliminar el impuesto de integración

Construir una cascada o un enrutador basado en clasificador sobre APIs de proveedores directos significa gestionar múltiples SDK, múltiples credenciales de autenticación, múltiples superficies de facturación y múltiples conjuntos de peculiaridades específicas de proveedor (comportamiento de timeouts, formatos de error, semántica de límites de tasa). Para una configuración de enrutamiento multi-modelo, esta sobrecarga es real. Un agregador como CometAPI expone cada modelo detrás de un endpoint compatible con OpenAI, lo que significa que el cambio de código para enrutar es solo cambiar el parámetro model, sin cambiar de proveedor, sin claves separadas, sin una capa de observabilidad separada. Para equipos cuyo obstáculo principal para el enrutamiento es el costo de integración más que el costo de evaluación de calidad, esto es decisivo.

Lo que hay que cuidar: capas de enrutamiento incorporadas

Algunos agregadores ofrecen una función de “enrutamiento inteligente” u “optimizador de modelos” que elige el modelo por usted según la consulta. Esto puede ser útil para prototipos pero generalmente es el enfoque incorrecto para producción. La razón es que la decisión de enrutamiento es una de las cosas más específicas de la carga en su stack: lo que cuenta como “suficientemente difícil para escalar” depende de sus criterios de evaluación, su presupuesto de latencia, su barra de calidad y su techo de costo. Una capa de enrutamiento genérica no puede conocer ninguno de estos. La mayoría de los sistemas de producción se benefician más de un agregador delgado y transparente (uno que expone los mismos modelos a los que accedería directamente, con una credencial y una factura) más su propia lógica de enrutamiento encima, que de una capa de enrutamiento de caja negra que no pueden ajustar.

La guía de migración

Un camino seguro y paso a paso desde una carga de trabajo de producción de un solo modelo a una enrutada. El principio en todo momento es hacer cambios que individualmente sean reversibles y medir el impacto de cada cambio antes de hacer el siguiente.

• Instrumente la carga de trabajo actual. Registre cada solicitud con modelo, tokens de entrada/salida, costo, latencia y una etiqueta de tipo de consulta. Ejecútelo por un mínimo de una semana para establecer una línea base. Sin esto, cada paso subsiguiente es una conjetura.
• Construya el conjunto de evaluación. Cure 100–500 consultas representativas con salidas de referencia en las que confíe. Este es el conjunto reservado que usará para comparar la cascada contra la línea base de un solo modelo en cada paso.
• Identifique el tipo de consulta de mayor volumen. A partir de los datos de instrumentación, encuentre la categoría de consulta que representa la mayor parte del tráfico. Aquí es donde piloteará la cascada. No tiene que ser la categoría más fácil, solo la de mayor volumen, porque ahí es donde se concentran los ahorros.
• Construya un prototipo de cascada para ese único tipo de consulta. Dos niveles: modelo barato primero, insignia si falla la compuerta de calidad. Ejecútelo primero en el conjunto de evaluación. Compare costo y calidad contra la línea base de un solo modelo. Si la calidad se mantiene y el costo baja, proceda; si la calidad cae, endurezca la compuerta y reintente.
• Despliegue detrás de un porcentaje de tráfico. Comience con 5–10% del tráfico de producción para el tipo de consulta elegido. Ejecútelo al menos una semana. Monitoree la tasa de escalamiento de la cascada, el costo por solicitud, la latencia en cada nivel y la comparación de calidad de la ruta canaria. Si las métricas coinciden con la predicción del prototipo, expanda a 25%, luego 50%, luego 100%.
• Repita para el siguiente tipo de consulta. Una vez que el primer tipo de consulta esté completamente migrado y el ahorro se haya materializado, pase a la siguiente categoría de mayor volumen. Cada cascada es una decisión separada; no asuma que un patrón que funcionó para un tipo funcionará para otro.
• Agregue una ruta canaria de calidad continua. Una vez que múltiples tipos de consulta estén ejecutándose con cascadas, configure permanentemente la ruta canaria reservada, con 5% del tráfico pasando por el modelo insignia para calificación. Este es su sistema de alerta temprana para la degradación silenciosa y lo que mantiene confiable la capa de enrutamiento conforme se actualizan los modelos.

Cuándo no vale la pena el enrutamiento

Reconocimiento honesto. Hay cargas de trabajo donde la inversión de ingeniería en enrutamiento no se compensa, y reconocerlas desde el principio ahorra tiempo:

• Cargas de trabajo de un solo modelo donde un modelo realmente es la respuesta correcta para todo. Si su conjunto de evaluación muestra una caída de calidad significativa en el nivel del modelo barato en toda la carga, la cascada no tiene con qué trabajar. Una carga de generación de código limitada por la capacidad de razonamiento es un ejemplo: Haiku fallará la compuerta con demasiada frecuencia como para que la cascada ahorre dinero.
• Cargas de trabajo de muy bajo volumen. Por debajo de aproximadamente $200/mes de gasto en LLM, el tiempo de ingeniería invertido en construir y mantener la capa de enrutamiento suele exceder los ahorros. El umbral es específico de la carga, pero es real. Sea honesto sobre si su gasto es lo suficientemente alto como para justificar el trabajo.
• Entornos regulados donde el proveedor oficial (vendor-of-record) importa. Si su postura de cumplimiento requiere que todo el tráfico de producción fluya a través de una relación específica con un proveedor, el enrutamiento multi-modelo complica esa conversación. Puede haber opciones de enrutamiento dentro del proveedor (Sonnet → Opus en Anthropic; GPT-5 nano → GPT-5.5 en OpenAI), pero el enrutamiento entre proveedores es más difícil de justificar.

El encuadre honesto: el enrutamiento compensa cuando su carga de trabajo es de alto volumen, sus consultas no son uniformemente difíciles y usted tiene la infraestructura de evaluación para saber cuándo la cascada produce calidad aceptable. La mayoría de las cargas de producción a escala significativa encajan esta descripción; algunas no, y envían más rápido quedándose con un solo modelo. Ambas opciones son defendibles.

A dónde ir después: Si aún no ha revisado la tarjeta de tarifas por modelo en la que se basa este artículo, la pieza complementaria, La comparación de precios de APIs de LLM 2026: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash y DeepSeek V4, es la base. Los datos de precios allí son lo que hace concreto el cálculo de costos en esta guía para su carga específica.