Usar un único modelo para cada llamada puede ser innecesariamente costoso, pero el enrutamiento no es automáticamente una mejora.
Un equipo puede descubrir que la clasificación, la extracción de datos, la redacción y el razonamiento complejo tienen diferentes requisitos de calidad y latencia. El enrutamiento puede aprovechar esas diferencias. También puede añadir una llamada al clasificador, modos de fallo del proveedor, comportamientos de seguridad inconsistentes y más trabajo de evaluación. La única afirmación defensible sobre los ahorros es aquella calculada a partir de tus tokens medidos, los precios actuales del proveedor y las puertas de calidad.
Esta es la orquestación de múltiples modelos: seleccionar un modelo o servicio especializado para un tipo de llamada definido bajo restricciones explícitas de calidad, latencia, privacidad y coste.
Este artículo cubre los patrones, la lógica de enrutamiento, los compromisos (trade-offs) y una guía paso a paso para implementarlo.
Por qué un solo modelo no es óptimo
Los catálogos de proveedores cambian con frecuencia, pero una carga de trabajo puede definir aun así niveles funcionales:
Nivel de razonamiento de alta capacidad: modelos candidatos para tareas difíciles de planificación o análisis. Evalúa la precisión, el comportamiento de las herramientas, la latencia de los casos más lentos y el total de tokens de razonamiento generados en tus propios casos.
Nivel general: candidatos para redacción dirigida al usuario y trabajo mixto de conocimiento donde importa la calidad pero puede no ser necesario un razonamiento extendido.
Nivel de baja latencia: candidatos para clasificación, extracción y reescritura acotadas. Que sea más pequeño no garantiza una precisión adecuada ni una menor latencia de extremo a extremo.
Nivel local o de modelos pequeños: candidatos cuando importan la ubicación de los datos, el funcionamiento sin conexión o el coste marginal de servicio. Incluye el hardware, las operaciones, la energía, la concurrencia y los efectos de la cuantización en la comparación.
Servicios especializados (embeddings, reordenamiento, visión y voz): compáralos con modelos generales para la operación concreta; la especialización no demuestra por sí sola una mejor calidad ni un coste total inferior.
Usa las páginas actualizadas de modelos y precios en el momento de la decisión: OpenAI models y pricing, Anthropic models y pricing, y Google models y pricing. No almacenes en caché ni la disponibilidad ni los precios en una decisión de arquitectura de larga duración.
Una aplicación típica de IA realiza muchos tipos diferentes de llamadas a LLM. Cada llamada tiene sus propios requisitos:
- Clasificar la intención del usuario: evalúa un candidato de baja latencia frente a un conjunto etiquetado, incluidos los casos ambiguos y fuera de alcance.
- Extraer datos estructurados: mide la precisión por campo y la validez del esquema, no el tamaño del modelo.
- Producir una respuesta dirigida al usuario: mide la exactitud factual, el cumplimiento de las políticas y la latencia de los casos más lentos.
- Resumir conversaciones anteriores: prueba si se omiten decisiones, nombres, restricciones y negaciones.
- Procesamiento por lotes en segundo plano: mide el rendimiento, el coste de los reintentos y el cumplimiento del plazo.
No asumas que el candidato más barato es suficiente ni que el más caro es el mejor. Establece esto con el mismo conjunto de evaluación para cada ruta.
Calcular ahorros a partir de la telemetría
Para cada tipo de llamada, recopila:
- número mensual de llamadas;
- distribuciones de tokens de entrada, entrada en caché y salida;
- tasa de reintento y cascada;
- cargos por herramientas, búsqueda, lotes o alojamiento;
- percentiles de latencia; y
- tasa de aprobación en la evaluación de lanzamiento de la ruta.
Calcula cada ruta candidata con los precios actuales:
coste mensual de la ruta = llamadas × (
tokens_de_entrada × precio_por_token_de_entrada
+ tokens_en_caché × precio_por_token_en_caché
+ tokens_de_salida × precio_por_token_de_salida
) + cargos_herramientas + alojamiento + costo_esperado_de_reintento
Compara el resultado con la línea base solo para los candidatos que superen los mismos criterios de lanzamiento de calidad y seguridad. Indica los supuestos junto al resultado. Una ruta que reduce el coste de los tokens, pero aumenta las correcciones manuales, los incidentes o la latencia, puede resultar más cara en conjunto.
Si no hay telemetría disponible, ejecuta primero una evaluación paralela que no afecte a los usuarios. No publiques un porcentaje de ahorro a partir de una división genérica del tráfico.
Los patrones básicos de orquestación
Algunos patrones se repiten en sistemas multi-modelo en producción:
Patrón 1: Enrutamiento basado en tareas
Diferentes tipos de tareas van a diferentes modelos. Este es el patrón más simple.
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
Las tareas son clasificadas por el código que llama (sabe lo que está preguntando). El enrutamiento es determinista y fácil de depurar.
Patrón 2: Enrutamiento basado en complejidad
El sistema estima la complejidad de cada solicitud y enruta en consecuencia.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
La estimación de complejidad puede ser heurística (longitud de la solicitud, detección de palabras clave) o basada en modelos (un clasificador barato puntúa la solicitud). Este patrón maneja casos donde el mismo tipo de tarea varía en dificultad.
Patrón 3: Enrutamiento en cascada
Prueba primero un modelo económico. Si la salida es buena, úsala. Si no, escala a un modelo más caro.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Esto funciona cuando “aceptable” es detectable — por puntuaciones de confianza, validadores o un LLM separado para verificar la calidad. Es potente: la mayoría de las solicitudes simples se responden con el modelo barato; solo los casos difíciles llegan al caro.
Patrón 4: Enrutamiento especializado
Usa modelos especializados para tareas especializadas:
- Embeddings: usa un modelo dedicado de embeddings (mucho más barato que usar un modelo de chat para incrustar).
- Reranking: usa un reranker dedicado.
- Visión: usa un modelo especializado en visión para el análisis de imágenes.
- Voz: usa un modelo de voz para transcripción/síntesis.
- Código: usa un modelo especializado en código para tareas de código.
Los modelos especializados o más pequeños pueden ser más rápidos, baratos o mejores en una tarea acotada, pero ninguna de esas ventajas se deduce solo de la etiqueta. Haz pruebas comparativas del modelo, el proveedor, el prompt, el idioma, el percentil de latencia, la tarifa y el conjunto de evaluación exactos.
Patrón 5: Enrutamiento por proveedor
Usa modelos de múltiples proveedores para redundancia y ventaja en los precios.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Esto da resiliencia ante caídas de un solo proveedor y límites de solicitudes. También te permite aprovechar los cambios en los precios; cuando un proveedor reduce sus tarifas, mueve más tráfico allí.
Un ejemplo realista: IA para atención al cliente
Para concretarlo, veamos cómo una IA de atención al cliente podría utilizar la orquestación de varios modelos.
El sistema tiene estos pasos por ticket:
Paso 1: Clasificar intención. ¿Sobre qué está preguntando el cliente?
Candidato para enrutamiento: un modelo de baja latencia que pase el conjunto etiquetado de intenciones.
Paso 2: Determinar urgencia y sentimiento. ¿Está frustrado el cliente? ¿Es esto urgente?
Candidato para enrutamiento: el mismo modelo solo si los falsos negativos de urgencia cumplen con el umbral de seguridad definido por separado; el sentimiento no es un sustituto fiable de la urgencia.
Paso 3: Recuperar conocimiento relevante.
Candidato para enrutamiento: recuperación mediante embeddings más un reranker, evaluado en un conjunto de recuperación específico del ticket.
Paso 4: Determinar si la IA puede responder o debe derivar el caso a una persona.
Candidato para enrutamiento: un modelo evaluado específicamente por su exhaustividad al detectar casos que deben derivarse. Las reglas deben imponer la derivación a una persona en cuestiones de acceso a cuentas, seguridad, asuntos legales o financieros y otros casos definidos por la política.
Paso 5 (si la IA puede responder): Generar la respuesta visible al cliente.
Candidato para enrutamiento: un modelo general de mayor calidad. Mantenlo solo como borrador hasta que la factualidad, las políticas, la privacidad y el tono pasen los criterios de lanzamiento.
Paso 6 (si la IA no puede responder): Generar un resumen para el agente humano.
Candidato para enrutamiento: un modelo de menor coste cuyos resúmenes preserven el problema, las pruebas, los pasos intentados, las restricciones del cliente y la incertidumbre.
Paso 7: Verificación de calidad. ¿Cumplió la respuesta nuestros estándares?
Candidato para enrutamiento: verificaciones deterministas más un juez calibrado. Un modelo juez no es una garantía independiente; muestrea sus decisiones con humanos.
Instrumenta cada paso y completa después la fórmula de coste anterior con las distribuciones de tokens medidas, los precios actuales y los porcentajes de derivación y reintento, además del coste de la revisión humana. Este ejemplo omite deliberadamente cualquier estimación genérica de ahorro: la mezcla de incidencias y los umbrales de aceptación determinan el resultado.
La lógica del enrutamiento
Algunos enfoques para implementar el enrutamiento:
Enfoque 1: Codificado por tipo de tarea
El más simple. Sabes qué tarea estás llamando, eliges el modelo.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Pros: Transparente, fácil de depurar, fácil de cambiar. Contras: No se adapta a la complejidad de la solicitud dentro de un tipo de tarea.
Enfoque 2: Modelo de enrutamiento
Un modelo pequeño clasifica cada solicitud y la enruta.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Pros: Se adapta a la complejidad dentro de una categoría. Contras: Añade latencia por la llamada al modelo de enrutamiento, añade un punto de fallo y requiere ajustes.
Enfoque 3: Enrutador basado en embeddings
Para solicitudes que caen en patrones conocidos, usa similitud de embedding con ejemplos pasados.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Pros: Rápido (solo una búsqueda vectorial), se vuelve más inteligente con más datos. Contras: Requiere construir un conjunto etiquetado de ejemplos.
Enfoque 4: Cascada
Prueba primero lo barato; escala si es necesario.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Pros: Adaptativo, coste medio bajo. Contras: Lento para los casos que requieren derivación (dos llamadas) y exige una validación fiable.
En la práctica, muchos sistemas en producción usan un híbrido: enrutamiento codificado para los tipos de tarea principales, con cascadas para subtipos específicos de alta varianza.
Las trampas comunes
Algunos errores a evitar:
Trampa 1: Optimizar el coste a expensas de la calidad
Es fácil enrutar todo a modelos pequeños y ver cómo baja el coste. Es más difícil advertir que también ha bajado la calidad. Acompaña siempre los cambios de enrutamiento con un seguimiento de la calidad.
Una disciplina útil: somete la ruta más barata a una prueba sombra o A/B hasta que la muestra cubra las clases de entrada y los modos de fallo importantes. Una semana fija no es evidencia por sí misma. No lances el cambio a menos que se mantengan los criterios predeclarados de calidad y seguridad.
Trampa 2: Complicar en exceso el enrutador
Un enrutador con muchos tipos de tareas y una lógica opaca puede ser más difícil de mantener que el sistema al que sustituye. Comienza con el número mínimo de rutas que justifiquen tus mediciones.
Añade una ruta solo cuando cambie una decisión operativa y mejore una restricción medida lo suficiente como para justificar su propiedad, pruebas y ruta de respaldo.
Trampa 3: Ignorar la latencia
Los modelos más baratos no son necesariamente más rápidos. Mide la latencia y la calidad por separado. Una cascada que prueba un modelo y después recurre a una alternativa añade al menos un intento para esos casos y puede aumentar considerablemente la latencia de los casos más lentos en flujos visibles para el usuario.
Para una respuesta visible al usuario y sensible a la latencia, compara una ruta directa con una cascada tanto por la tasa de aprobación como por la latencia de los casos más lentos. Las cascadas suelen ser más tolerables en lotes o trabajos asíncronos, pero la ruta correcta depende de la carga de trabajo.
Trampa 4: No manejar fallos del proveedor
Cuando dependes de varios modelos, también se multiplican las formas de fallar. Un modelo principal deja de estar disponible, se alcanza un límite de solicitudes o caduca una clave API. Tu lógica de enrutamiento necesita mecanismos de respaldo.
Define un comportamiento explícito para los límites de solicitudes, los tiempos de espera y los errores del proveedor. Un mecanismo de respaldo entre proveedores solo es apropiado si resultan aceptables sus condiciones de tratamiento de datos, la ruta regional, el contrato de herramientas y esquemas y los resultados de la evaluación. De lo contrario, detén el proceso de forma segura, ponlo en cola o derívalo a una persona; devolver una respuesta sustancialmente peor no equivale a disponibilidad.
Trampa 5: No medir la calidad por ruta
Necesitas saber qué ruta está funcionando bien y cuál no. Esto significa evaluación, idealmente automatizada.
Una configuración útil: para cada llamada de producción, registra el modelo usado, la solicitud, la respuesta y (donde sea posible) alguna señal de calidad (comentarios del usuario, métricas de los sistemas posteriores, evaluación automática). Agrupa las métricas por ruta. Detecta la deriva de calidad antes de que los usuarios se quejen.
Revalidar dependencias en vivo
Los identificadores de modelo, las fechas de retirada, los límites de contexto, los precios, los límites de solicitudes, el procesamiento regional y la semántica de la salida estructurada y de las herramientas pueden cambiar de forma independiente. Revisa la documentación actualizada del proveedor y vuelve a ejecutar las evaluaciones de ruta antes de cambiar un alias. Un transporte compatible con OpenAI no garantiza esquemas equivalentes, comportamiento de herramientas, contabilidad de tokens, política de seguridad o manejo de datos.
Una lista de verificación inicial
Si estás construyendo un sistema multi-modelo desde cero, o migrando desde uno solo:
-
Mapea tus tareas. ¿Qué tipos de llamadas a LLM hace tu aplicación? ¿Aproximadamente con qué frecuencia? ¿Aproximadamente cuánto cuestan?
-
Categoriza por complejidad. Para cada tipo de tarea, decide: trivial, moderada o compleja. Empareja cada una con un nivel de modelo.
-
Construye un enrutador. Comienza con un enrutamiento determinista basado en tareas. No lo compliques en exceso.
-
Define el comportamiento ante fallos. Usa una alternativa probada, una cola de espera, una detención segura o la derivación a una persona, según las consecuencias y la política de datos.
-
Mide la calidad por ruta. Configura el registro y una evaluación básica. Necesitas saber si se mantiene la calidad.
-
Itera. Mueve tareas a modelos más baratos donde se mantenga la calidad. Mueve tareas de vuelta a modelos caros donde falle la calidad. Ajusta con el tiempo.
-
No dejes de ajustar. Los modelos cambian. Lanzan nuevos. Cambian los precios. Una configuración de enrutamiento que es óptima en mayo de 2026 puede ser subóptima en noviembre de 2026.
Enruta solo donde la evidencia lo respalde
La orquestación multimodelo puede reducir el coste o la latencia cuando los tipos de llamada son realmente distintos y cada ruta se evalúa por separado. También puede aumentar el coste operativo y reducir la coherencia. Publica la línea base medida, el resultado del enrutamiento, los controles de calidad y el periodo de la muestra en lugar de una afirmación universal de ahorro.
El condicional del enrutamiento puede ser corto; el trabajo de producción consiste en controlar la configuración, evaluar, observar, revisar la privacidad y definir la lógica de reintento y los mecanismos de respaldo.
Mapea tus tareas, haz pruebas comparativas de los candidatos viables, enruta solo donde la evidencia lo justifique y sigue midiendo después del lanzamiento.
