El error más caro que observamos en sistemas de IA en producción es utilizar un único modelo para todo.
Un equipo elige un modelo de gama alta —GPT-5.5, Claude Opus 4.8 o similar— y construye toda la aplicación a su alrededor. Las facturas mensuales alcanzan las cinco cifras. Al dirigir cada solicitud a la gama de modelos adecuada, normalmente se reduce gran parte de esa factura —alrededor del 70-75% en el ejemplo calculado más adelante— y, a menudo, también mejora la latencia.
Eso es la orquestación multimodelo: utilizar en un mismo sistema el modelo adecuado para cada tarea. Es una de las diferencias entre experimentar con IA y operar IA en producción.
Este artículo explica los patrones, la lógica de enrutamiento, las ventajas y los inconvenientes, y ofrece una guía paso a paso para implantarla.
Por qué un solo modelo no es la opción óptima
Los modelos disponibles en 2026 se agrupan en niveles aproximados:
Modelos de razonamiento de gama alta (modos de razonamiento de GPT-5.5, Claude Opus 4.8 y Gemini 3.1 Pro; DeepSeek R1): excelentes para razonamiento complejo, caros ($3-30 por millón de tokens de entrada y $15-50 por millón de tokens de salida en los modelos de gama alta habituales; las gamas especializadas cuestan aún más) y más lentos (normalmente 5-30 segundos).
Modelos generalistas de gama alta (GPT-5.5, Claude Sonnet 5 y Gemini 3.1 Pro): excelentes para la mayoría de las tareas de conocimiento, con un coste moderadamente alto ($2-5 por millón de tokens de entrada y $12-30 por millón de tokens de salida) y una velocidad razonable (2-5 segundos).
Modelos de gama media (Claude Haiku 4.5, Gemini 3.5 Flash y la gama media de OpenAI): buenos para tareas sencillas o de dificultad moderada, económicos ($1-2.50 por millón de tokens de entrada y $5-15 por millón de tokens de salida) y rápidos (1-2 segundos).
Modelos pequeños (las gamas más pequeñas que ofrecen actualmente los proveedores, como Gemini 3 Flash Preview, y modelos pequeños de código abierto): buenos para tareas estructuradas sencillas, muy económicos ($0.50-1 por millón de tokens de entrada) y muy rápidos (<1 segundo).
Modelos especializados (modelos de embeddings, reranking, visión o voz): están optimizados para tareas concretas y suelen ser muy económicos precisamente por su especialización.
(Precios verificados el 2026-07-07 contra las páginas de precios de los proveedores; vuelve a verificar antes de citar.)
Una aplicación de IA habitual realiza muchos tipos de llamadas a LLM, cada una con sus propios requisitos:
- Clasificar la intención del usuario: requiere una clasificación sencilla y una respuesta rápida. Un modelo de gama media es perfecto.
- Extraer datos estructurados de documentos: requiere fiabilidad en la salida estructurada y presenta una complejidad moderada. Conviene un modelo de gama media o un generalista de gama alta.
- Generar la respuesta que recibirá el usuario: exige calidad y buena gestión del contexto. Conviene un modelo generalista de gama alta o uno de razonamiento de gama alta.
- Resumir conversaciones anteriores: es una tarea de resumen sencilla. Basta un modelo de gama media o pequeño.
- Procesar lotes en segundo plano: la latencia no es crítica, pero el volumen sí. Conviene un modelo pequeño o de gama media.
Utilizar un modelo de gama alta para todo es un despilfarro. La clasificación no lo necesita; el resumen tampoco; la extracción estructurada, a menudo, tampoco. Solo la respuesta destinada al usuario se beneficia realmente.
El ahorro de costes es real
En una aplicación de IA típica para tareas de conocimiento, las solicitudes podrían distribuirse así:
- 60% de las llamadas a LLM: clasificación sencilla, extracción y resumen. Los modelos pequeños o de gama media son la mejor opción.
- 30% de las llamadas: complejidad moderada. Conviene un modelo de gama media o un generalista de gama alta.
- 10% de las llamadas: razonamiento complejo o respuesta final al usuario. Conviene un modelo de gama alta.
Si utilizas un modelo de gama alta para todo, pagas el 100% del coste de ese modelo. Con un enrutamiento adecuado:
- 60% al coste del modelo pequeño (1/30 del modelo de gama alta): 2% del coste original.
- 30% al coste del modelo de gama media (1/5 del modelo de gama alta): 6% del coste original.
- 10% al coste del modelo de gama alta: 10% del coste original.
Total: 18% del coste original, es decir, una reducción del 82%. En una factura mensual de €10,000, el ahorro asciende a €8,200 al mes.
Estas cifras dependen de la distribución del tráfico, pero el patrón se repite: la mayoría de las aplicaciones combinan solicitudes cuyo coste medio es muy inferior al de la solicitud más exigente. El enrutamiento permite aprovechar esa diferencia.
Los patrones básicos de orquestación
Varios patrones se repiten en los sistemas multimodelo en producción:
Patrón 1: Enrutamiento basado en tareas
Diferentes tipos de tareas van a diferentes modelos. Es el patrón más simple.
# Model IDs verified 2026-07-07; SMALL_TIER is your provider's current
# small model — check the live model list rather than hard-coding blindly.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return "claude-haiku-4-5"
elif task_type == "summarization":
return "claude-haiku-4-5"
elif task_type == "user-facing-response":
return "claude-sonnet-5"
elif task_type == "complex-reasoning":
return "claude-opus-4-8"
El propio código que realiza la llamada clasifica la tarea, porque sabe qué está solicitando. 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 complejidad se puede estimar mediante heurísticas —longitud de la solicitud o detección de palabras clave— o mediante un modelo —un clasificador económico puntúa la solicitud—. Este patrón permite gestionar casos en los que un mismo tipo de tarea presenta distintos grados de dificultad.
Patrón 3: Enrutamiento en cascada
Prueba primero un modelo económico. Si la respuesta es aceptable, utilízala; de lo contrario, 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)
Este enfoque funciona cuando es posible determinar si una respuesta es «aceptable», por ejemplo mediante puntuaciones de confianza, validadores o un LLM independiente que revise la calidad. Es un patrón potente: el modelo económico resuelve la mayoría de las solicitudes sencillas y solo las difíciles llegan al modelo caro.
Patrón 4: Enrutamiento especializado
Usa modelos especializados para tareas especializadas:
- Embeddings: utiliza un modelo de embeddings dedicado, mucho más barato que emplear un modelo de chat para generarlos.
- Reranking: utiliza un modelo de reranking dedicado.
- Visión: usa un modelo especializado en visión para el análisis de imágenes.
- Voz: usa un modelo de voz para la transcripción/síntesis.
- Código: usa un modelo especializado en código para tareas de código.
Los modelos especializados suelen ser más rápidos, económicos y eficaces en su tarea concreta que un modelo generalista que intente hacer lo mismo.
Patrón 5: Enrutamiento entre proveedores
Utiliza modelos de varios proveedores para aportar redundancia y aprovechar las diferencias de precio.
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)
Así obtienes resiliencia ante interrupciones o límites de uso de un proveedor concreto. También puedes aprovechar los cambios de precio: cuando un proveedor abarate sus modelos, dirige hacia él una mayor proporción del tráfico.
Un ejemplo realista: IA de soporte al cliente
Para verlo de forma concreta, veamos cómo podría aplicar la orquestación multimodelo un sistema de IA para atención al cliente.
El sistema ejecuta estos pasos para cada caso:
Paso 1: Clasificar la intención. ¿Sobre qué está preguntando el cliente? (5-10 categorías.)
Enrutamiento: un modelo pequeño. Es una tarea de clasificación sencilla. Coste: ~$0.0005 por caso (≈500 tokens a precios de la gama pequeña).
Paso 2: Determinar urgencia y sentimiento. ¿El cliente está frustrado? ¿Es urgente?
Enrutamiento: el mismo modelo pequeño. Es otra clasificación sencilla. Coste: ~$0.0005 por caso.
Paso 3: Recuperar conocimiento relevante.
Enrutamiento: modelo de embeddings + modelo de reranking. Herramientas especializadas para tareas especializadas. Coste: ~$0.002 por caso (el reranking representa la mayor parte, a ~$2 por 1,000 búsquedas).
Paso 4: Determinar si la IA puede responder o si debe transferir el caso a una persona.
Enrutamiento: Claude Haiku 4.5. Es una clasificación algo más sofisticada porque tiene en cuenta el contexto recuperado. Coste: ~$0.002 por caso (≈2K tokens de contexto).
Paso 5 (si la IA puede responder): Generar la respuesta al cliente.
Enrutamiento: Claude Sonnet 5. Aquí la calidad es importante porque el cliente leerá la respuesta. Coste: ~$0.015 por caso (≈3K de entrada / 400 de salida).
Paso 6 (si la IA no puede responder): Generar un resumen para el agente de atención al cliente.
Enrutamiento: un modelo de gama media. Debe generar un resumen útil, pero no dirigido al cliente. Coste: ~$0.004 por caso.
Paso 7: Revisión de calidad. ¿La respuesta cumplió con nuestros estándares?
Enrutamiento: Claude Haiku 4.5 como evaluador rápido. Coste: ~$0.002 por caso.
Estas cifras proceden de un cálculo teórico. Los volúmenes de tokens supuestos se indican en cada paso para que puedas repetir el cálculo con tu propio tráfico.
Para los casos que responde la IA —supongamos el 70%—: ~$0.022 por caso. Para los casos transferidos a una persona —el 30%—: ~$0.009 por caso. Media ponderada: ~$0.018 por caso.
Si cada paso se ejecutara con un modelo de razonamiento de gama alta —con los mismos volúmenes de tokens, a ~$5/M de entrada y $25/M de salida—, costaría aproximadamente $0.06-0.08 por caso. El enfoque multimodelo reduce la factura alrededor de un 70-75%.
Con 1,000 casos diarios, el ahorro es de ~$50 al día → aproximadamente $18,000 al año. Es una cifra importante, aunque la mayor mejora operativa suele estar en la latencia: el flujo enrutado responde a los casos sencillos en un segundo, en lugar de treinta.
La lógica de enrutamiento
Estos son algunos enfoques para implementar el enrutamiento:
Enfoque 1: Enrutamiento programado por tipo de tarea
Es el más sencillo: sabes qué tarea vas a ejecutar y eliges el modelo correspondiente.
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="claude-sonnet-5", # ID verified 2026-07-07
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Ventajas: es transparente y fácil de depurar y modificar. Desventajas: no se adapta a las diferencias de complejidad entre solicitudes de un mismo tipo.
Enfoque 2: Modelo de enrutamiento
Un modelo pequeño clasifica cada solicitud y determina la ruta.
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]
Ventajas: se adapta a la complejidad dentro de una categoría. Desventajas: añade latencia —la llamada al enrutador—, incorpora un nuevo punto de fallo y requiere ajustes.
Enfoque 3: Enrutador basado en embeddings
Para las solicitudes que responden a patrones conocidos, utiliza la similitud entre embeddings y ejemplos anteriores.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Ventajas: es rápido —solo requiere una búsqueda vectorial— y mejora a medida que acumula datos. Desventajas: exige crear un conjunto de ejemplos etiquetados.
Enfoque 4: En cascada
Prueba primero la opción económica y escala si es necesario.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Ventajas: es adaptativo y ofrece un coste medio bajo. Desventajas: es lento en los casos que requieren escalado —se realizan dos llamadas— y necesita una validación fiable.
En la práctica, muchos sistemas en producción combinan ambos enfoques: enrutamiento programado para los principales tipos de tareas y cascadas para subtipos concretos con mucha variabilidad.
Los puntos críticos
Estos son algunos errores que debes evitar:
Punto crítico 1: Optimizar el coste a expensas de la calidad
Es fácil dirigir todo a modelos pequeños y observar cómo cae el coste. Resulta más difícil advertir que también ha disminuido la calidad. Acompaña siempre los cambios de enrutamiento con una supervisión de la calidad.
Adopta una práctica sencilla: cuando traslades una tarea a un modelo más económico, realiza durante una semana una prueba A/B con métricas de calidad. No implantes el cambio sin pruebas de que la calidad se mantiene.
Punto crítico 2: Sobrediseñar el enrutador
Un enrutador que gestiona 100 tipos de tareas mediante una lógica sofisticada puede ser más difícil de mantener que el sistema al que sustituye. Empieza con una solución sencilla. Si alcanza el 80% del rendimiento de la versión sofisticada, implanta la sencilla.
Un patrón habitual: un enrutador de 50 líneas que gestiona 5-10 tipos de tareas aporta el 90% del beneficio. A partir de ahí, el rendimiento adicional disminuye.
Punto crítico 3: Ignorar la latencia
Los modelos más económicos suelen ser también más rápidos, lo cual es positivo. Sin embargo, una cascada —probar primero el modelo económico y después el de gama alta— puede duplicar la latencia en los casos difíciles. Esto importa en los flujos destinados al usuario.
Una pauta útil: para respuestas dirigidas al usuario y sensibles a la latencia, utiliza de forma predeterminada el modelo de gama alta y asume el coste. Reserva las cascadas para trabajos en segundo plano o asíncronos.
Punto crítico 4: No gestionar los fallos de los proveedores
Cuando dependes de varios modelos, también aumentan las formas de fallar: un modelo de gama alta deja de estar disponible, se alcanza un límite de uso o caduca una clave de API. La lógica de enrutamiento necesita alternativas de respaldo.
Como mínimo, cada modelo «principal» debe contar con un modelo «de respaldo» de otro proveedor. Aunque la calidad disminuya al activar el respaldo, el sistema seguirá funcionando.
Punto crítico 5: No medir la calidad por ruta
Necesitas saber qué rutas funcionan bien y cuáles no. Para ello hace falta evaluación, preferiblemente automatizada.
Una configuración útil: en cada llamada de producción, registra el modelo utilizado, la solicitud, la respuesta y, siempre que sea posible, alguna señal de calidad —comentarios del usuario, métricas posteriores o evaluación automatizada—. Agrupa las métricas por ruta y detecta la degradación de la calidad antes de que se quejen los usuarios.
A dónde se dirige esto
Estas son algunas tendencias previsibles:
Enrutamiento automático como servicio. Herramientas como OpenRouter, Helicone y Portkey ofrecen cada vez más funciones de «enrutamiento inteligente»: eligen el modelo por ti según reglas configurables. Cabe esperar que estas funciones maduren considerablemente.
Mayor especialización de los modelos. Habrá modelos especializados en código, matemáticas y ámbitos concretos. El enrutamiento incorporará cada vez más modelos especializados.
Los costes seguirán disminuyendo. En 2026, los modelos son 10x más baratos que los modelos de calidad equivalente de 2024. Para 2028, cabe esperar otra reducción de 10x. La viabilidad económica de la orquestación multimodelo seguirá mejorando.
Gamas ejecutadas en el dispositivo. Los teléfonos y portátiles con capacidades locales de IA ofrecerán una «gama gratuita» para algunas solicitudes. La lógica de enrutamiento incluirá cada vez más la regla «mantén el procesamiento en el dispositivo siempre que sea posible».
API estandarizadas entre proveedores. Las API compatibles con OpenAI —ya muy extendidas— facilitan cada vez más el cambio de proveedor. Una mayor estandarización simplificará las estrategias con varios proveedores.
Una lista de verificación inicial
Si estás creando desde cero un sistema multimodelo o migrando desde uno que utiliza un único modelo:
-
Traza un mapa de tus tareas. ¿Qué tipos de llamadas a LLM realiza tu aplicación? ¿Con qué frecuencia y coste aproximados?
-
Clasifícalas por complejidad. Decide si cada tipo de tarea es trivial, moderado o complejo y asígnalo a una gama de modelos.
-
Crea un enrutador. Empieza por un enrutamiento programado según el tipo de tarea. No compliques el diseño.
-
Añade alternativas de respaldo. Cada modelo principal debe contar con un modelo de respaldo de otro proveedor.
-
Mide la calidad por ruta. Configura registros y una evaluación básica para comprobar si se mantiene la calidad.
-
Itera. Traslada tareas a modelos más económicos cuando se mantenga la calidad y devuélvelas a modelos más caros cuando se degrade. Sigue ajustando el sistema con el tiempo.
-
No dejes de perfeccionarlo. Los modelos y los precios cambian, y aparecen modelos nuevos. Un enrutamiento óptimo en mayo de 2026 puede dejar de serlo en noviembre de 2026.
Deja de usar un solo modelo para todo
La orquestación multimodelo es uno de los cambios con mayor retorno de la inversión que puedes realizar en un sistema de IA en producción. Bien aplicada, reduce los costes un 60-90% y, a menudo, mejora la calidad, porque cada tarea utiliza un modelo adecuado.
El umbral técnico es bajo: una lógica básica de enrutamiento ocupa unas decenas de líneas de código. El requisito de disciplina es mayor, porque debes medir la calidad de forma continua para comprobar que las decisiones de enrutamiento siguen siendo válidas.
Deja de utilizar un único modelo para todo. Traza un mapa de tus tareas. Elige el modelo adecuado para cada una. Mide el resultado e itera. El ahorro es real y la mejora de la calidad suele ser una ventaja añadida.
