La mayoría de los agentes de AI utilizan un único modelo para todo. El paso de planificación, las llamadas a herramientas (tool calls), el resumen, la recuperación de errores. Esto funciona para demostraciones. En producción, es un desperdicio.
Un paso de planificación que requiere un razonamiento profundo no necesita el mismo modelo que un paso de extracción de JSON. Una tarea de generación de código tiene requisitos diferentes a los de una tarea de clasificación. Usar Claude Opus 4.6 ($25/1M de tokens de salida) para formatear una cadena de fecha es como contratar a un arquitecto senior para pintar una pared.
Aquí te explicamos cómo construir agentes que dirijan cada paso al modelo óptimo.
Si estás trabajando en la capa de API en lugar de la capa de agente, lee Agent-First API Design y Why Teams Switch from Direct Model APIs to a Unified AI API junto con esta página. Los agentes multimodelo funcionan mejor cuando la superficie de la API subyacente es lo suficientemente estable como para intercambiar modelos sin reescribir el código de orquestación.
La arquitectura de un agente multimodelo
Solicitud del usuario
│
▼
┌─────────────┐
│ Router │ ← Clasifica la complejidad de la tarea
│(modelo rápido)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│Modelo│ │Modelo│
│Simple│ │Complejo│
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ Agregador │ ← Combina los resultados
│(modelo rápido)│
└─────────────┘
Tres componentes:
- Un router que clasifica las tareas entrantes por complejidad
- Un conjunto de modelos adaptados a diferentes tipos de tareas
- Un agregador que combina los resultados cuando es necesario
En la práctica, los agentes en producción suelen necesitar dos piezas más:
- Una política de fallback cuando el modelo preferido falla o se ralentiza
- Una capa de telemetría que registra la elección del modelo, la latencia y el costo por paso
Sin esos dos elementos, un agente multimodelo se convierte rápidamente en una caja negra con un comportamiento impredecible.
Implementación con el SDK de OpenAI
Utilizando una única API key a través de un agregador, puedes acceder a todos los modelos sin tener que gestionar múltiples SDKs:
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Conjunto de modelos con niveles de costo/capacidad
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - clasificación rápida
"simple": "gpt-4.1-mini", # $0.40/1M in - extracción, formateo
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - planificación, análisis
"complex": "gpt-4.1", # $2.00/1M in - gen de código, multi-paso
"budget": "deepseek-chat", # $0.28/1M in - procesamiento masivo
}
def route_task(task: str) -> str:
"""Usa un modelo económico para clasificar la complejidad de la tarea."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Classify this task into one category:
- simple: data extraction, formatting, translation
- reasoning: analysis, planning, comparison
- complex: code generation, multi-step problem solving
- budget: bulk processing, non-critical tasks
Reply with just the category name."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""Dirige la tarea al modelo apropiado y ejecútala."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
Agente del mundo real: Pipeline de revisión de código
Aquí tienes un agente multimodelo práctico que revisa pull requests:
def review_pr(diff: str) -> dict:
"""Pipeline de revisión de PR multimodelo."""
# Paso 1: Clasificar cambios (modelo económico)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Classify these code changes: {diff[:2000]}\n"
"Categories: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# Paso 2: Escaneo de seguridad (modelo de razonamiento)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "You are a security reviewer. Check for: "
"SQL injection, XSS, auth bypass, secrets in code, "
"unsafe deserialization. Be specific about line numbers."
}, {
"role": "user",
"content": f"Review this diff for security issues:\n{diff}"
}]
).choices[0].message.content
# Paso 3: Calidad del código (modelo general)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Review code quality: naming, structure, "
f"error handling, test coverage.\n{diff}"
}]
).choices[0].message.content
# Paso 4: Resumen (modelo económico)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Summarize this PR review in 3 bullet points:\n"
f"Type: {classification}\n"
f"Security: {security[:500]}\n"
f"Quality: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
Desglose de costos para una revisión de PR típica (diff de 2K tokens):
| Paso | Modelo | Tokens de entrada | Costo |
|---|---|---|---|
| Clasificar | GPT-4.1-mini | ~2,100 | $0.0008 |
| Seguridad | Claude Sonnet 4.6 | ~2,500 | $0.0075 |
| Calidad | GPT-4.1 | ~2,500 | $0.0050 |
| Resumen | GPT-4.1-mini | ~1,200 | $0.0005 |
| Total | ~$0.014 |
Usar Claude Sonnet 4.6 para los cuatro pasos costaría ~$0.028. El enfoque multimodelo reduce los costos en un 50% mientras utiliza el modelo más fuerte donde más importa (revisión de seguridad).
Enrutamiento por capacidad, no solo por precio
Muchos equipos comienzan el enrutamiento multimodelo con una regla simple: las tareas costosas van a modelos costosos, las tareas económicas van a modelos económicos.
Ese es un buen primer paso, pero no es suficiente.
Una política de enrutamiento más sólida considera cuatro dimensiones:
- profundidad de razonamiento
- longitud del contexto
- confiabilidad en el uso de herramientas (tool-use)
- sensibilidad a la latencia
Eso conduce a mejores reglas:
- la planificación y la descomposición van a un modelo con gran capacidad de razonamiento
- la extracción y el formateo van a un modelo económico y rápido
- la revisión de código va al modelo con el mejor comportamiento para encontrar errores
- el análisis de todo el repositorio va al modelo con la ventana de contexto más grande
Esta es la misma razón por la que la comparación de modelos de programación y la comparación de precios deberían informar a tu router en lugar de quedarse en una carpeta de investigación separada.
Integración con LangChain
from langchain_openai import ChatOpenAI
# Crear instancias de modelos con diferentes configuraciones
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Uso en cadenas de LangChain
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
Cuándo usar agentes multimodelo
El enrutamiento multimodelo añade complejidad. Vale la pena cuando:
- Tu agente maneja diversos tipos de tareas (no solo chat)
- Los costos mensuales de API superan los $100 (los ahorros se vuelven significativos)
- Necesitas fortalezas específicas de modelos (Claude para código, Gemini para contexto largo, GPT para velocidad)
- La latencia importa para algunos pasos pero no para otros
Para chatbots simples o agentes de un solo propósito, un único modelo es suficiente. La sobrecarga del enrutamiento no se justifica cuando cada solicitud necesita la misma capacidad.
El punto de inflexión suele ser uno de estos:
- estás pagando por razonamiento de alta gama en tareas de bajo valor
- las caídas de un proveedor son ahora un riesgo real para el negocio
- las necesidades de contexto varían drásticamente a lo largo del flujo de trabajo
- necesitas etapas de revisión / extracción / resumen más económicas alrededor de una etapa central costosa
Si nada de esto es cierto, un solo modelo sigue siendo la respuesta correcta.
Modos de fallo comunes
Los sistemas multimodelo fallan de maneras predecibles:
1. El router es demasiado ingenioso
Si el prompt del router se convierte en un ejercicio gigante de taxonomía, gastarás demasiado en decidir qué hacer. Mantén el router económico y simple.
2. Los contratos de salida divergen
Un modelo devuelve JSON limpio, otro devuelve prosa con un bloque JSON, y tu parser posterior falla. Utiliza esquemas explícitos y validación en cada entrega.
3. El fallback cambia la calidad de forma silenciosa
Dirigir a un modelo más económico durante una saturación del proveedor puede hacer que el agente parezca inestable si el usuario ve un perfil de calidad totalmente diferente. Por eso, la estrategia de rate limiting debe formar parte del diseño, no ser una idea de último momento.
4. Falta el reporte de costos
Si no registras la elección del modelo por paso, el costo y la latencia, no podrás saber si el diseño multimodelo realmente está ahorrando dinero.
Un bucle de evaluación mínimo
No necesitas una plataforma de evaluación gigante para operar un agente multimodelo de manera responsable.
Comienza con una hoja de cálculo o una tabla de base de datos por ejecución:
- categoría de la tarea del usuario
- decisión del router
- modelo final utilizado por paso
- latencia por paso
- costo total de tokens
- si se activó el fallback
- si el usuario aceptó la respuesta
Eso te da suficiente señal para responder a las preguntas que importan:
- ¿Está el router eligiendo el modelo costoso adecuado con la frecuencia necesaria?
- ¿Qué paso está consumiendo la mayor parte del presupuesto?
- ¿Están los fallbacks rescatando ejecuciones o simplemente ocultando la inestabilidad?
- ¿Es la ruta económica lo suficientemente buena para tareas repetitivas?
Esta es también la razón por la que un gateway unificado ayuda. Cuando el uso de modelos se reparte entre muchos proveedores, es más difícil armar un registro de ejecución comparable. Cuando todo pasa por una sola capa de API, la carga de instrumentación disminuye.
Mantén la arquitectura aburrida
Los mejores agentes multimodelo no se sienten exóticos. Se sienten operacionalmente aburridos.
Eso significa:
- una forma de solicitud estable en tu capa de orquestación
- un lugar para definir las reglas de enrutamiento
- un lugar para inspeccionar el costo y la latencia
- una política de fallback por familia de tareas
- una fuente de verdad para las listas de permitidos (allowlists) de modelos
Si el gráfico de tu agente parece ingenioso pero tus operadores no pueden explicar por qué una solicitud fue a un modelo en lugar de a otro, el diseño no está terminado.
Cuándo no usar un agente multimodelo
También hay casos claros donde el diseño más simple gana.
No añadas enrutamiento solo porque el catálogo de modelos sea grande.
Quédate con un solo modelo cuando:
- el producto realiza una tarea estrecha repetidamente
- las diferencias de calidad entre modelos son irrelevantes para el usuario
- tu tráfico es demasiado bajo para que la optimización de costos importe
- tu superficie de operaciones ya carece de instrumentación
- aún no tienes evaluaciones (evals) lo suficientemente sólidas para saber si el enrutamiento ayudó o perjudicó
Un solo modelo bien elegido con buenos reintentos, higiene de prompts y observabilidad a menudo supera a un gráfico multimodelo llamativo en el que nadie confía.
La pregunta correcta no es "¿podemos enrutar?". Es "¿el enrutamiento produce mejor calidad, menor costo o un comportamiento de fallo más seguro para este flujo de trabajo?".
Si la respuesta es vaga, mantén la arquitectura simple hasta que el flujo de trabajo mismo se vuelva más diverso.
Conclusiones clave
- Usa el modelo más económico que maneje bien cada paso
- Reserva los modelos costosos para tareas que realmente los necesiten
- Los pasos de clasificación/enrutamiento siempre deben usar el modelo más económico disponible
- Mide el costo real por ejecución del agente, no solo el precio por token
- Un agregador de API con una sola clave simplifica significativamente el acceso multimodelo
Los agentes multimodelo no son inherentemente mejores. Son mejores cuando el flujo de trabajo contiene genuinamente diferentes tipos de trabajo.
Accede a todos los modelos a través de una sola API: LemonData ofrece más de 300 modelos con una única API key. Construye agentes multimodelo sin gestionar múltiples cuentas de proveedores ni reinventar el enrutamiento para cada par de proveedores.