IBM Research: el routing de modelos no es clasificación, es optimización de todo el sistema
IBM Research mostró el 15 de julio de 2026 por qué elegir un modelo barato para cada tarea no garantiza ahorro. En 417 tareas de AppWorld, el costo real cambió con caché, pasos de razonamiento, latencia, cumplimiento y condiciones del servicio.
Por Marco Lee · Reportar un error
Continúa con un curso prácticoEl routing de modelos suele venderse con una regla sencilla: manda lo fácil a un modelo barato y reserva el modelo grande para lo difícil. IBM Research acaba de explicar por qué esa receta se rompe en cuanto el agente usa herramientas, repite contexto o trabaja bajo restricciones empresariales.
En su artículo del 15 de julio de 2026, el equipo describe el routing como un problema de optimización de sistemas, no de clasificación. La diferencia importa: no basta con predecir la dificultad del prompt. Hay que optimizar costo, calidad, latencia, caché, confiabilidad y políticas al mismo tiempo.

El precio de la ficha no es el costo de la tarea
IBM comparó el mismo agente CodeAct en 417 tareas de AppWorld. Claude Sonnet 4.6 acumuló 79 dólares, o 0,19 dólares por tarea; GPT-4.1 llegó a 155 dólares, o 0,37 dólares por tarea. El resultado parece contraintuitivo porque el precio nominal de GPT-4.1 era menor y Sonnet necesitaba más pasos de razonamiento.
La explicación fue la caché. Un agente reutiliza grandes fragmentos de contexto entre llamadas. Si un proveedor cobra menos por lecturas desde caché, el costo efectivo puede cambiar el orden que sugería la tabla de precios. Un router que solo mira el precio por millón de tokens está optimizando una variable incompleta.
La primera métrica útil, entonces, no es precio_modelo. Es el costo por tarea terminada, separado en tokens nuevos, tokens cacheados, llamadas de herramientas, reintentos y pasos que terminaron en error.
La dificultad se revela durante la ejecución
“Resume este contrato” puede parecer una tarea pequeña y activar recuperación, controles de cumplimiento, varias herramientas y rondas de revisión. Un prompt técnico puede resolverse con un modelo especializado de menor costo. Además, una petición cambia de naturaleza cuando el agente observa el primer resultado.
Por eso el routing por turno puede ser mejor que el routing único por solicitud, pero también más caro y más lento. Elegir el modelo en cada paso abre flexibilidad para escalar cuando aparecen señales de complejidad; al mismo tiempo, añade decisiones, llamadas y puntos de fallo.
| Señal | Pregunta operativa | Riesgo si se ignora |
|---|---|---|
| Caché | ¿Cuánto contexto se reutiliza? | El modelo “caro” puede salir más barato. |
| Trayectoria | ¿Cuántos pasos y reintentos necesita? | El precio nominal oculta el trabajo real. |
| Latencia | ¿Está caliente el endpoint y cuánto tarda el router? | Un modelo rápido puede entregar una experiencia lenta. |
| Gobierno | ¿Qué modelos están permitidos por datos o región? | La ruta óptima puede ser inaceptable. |

IBM propone una frontera, no un ganador único
El enfoque del artículo genera configuraciones que dibujan una frontera entre costo y exactitud. Una configuración orientada a latencia alcanzó 84% de exactitud, 93 dólares y 83 segundos, con una reducción de 21% en costo y 9% en latencia frente a ejecutar todo con Opus, a cambio de una caída de 4% en exactitud. La cifra es de ese experimento; no debe convertirse en una promesa universal.
La idea general sí es reusable: ofrecer varios puntos de operación y elegir según el producto. Un flujo de soporte puede priorizar costo y tiempo. Un agente que modifica datos puede pagar más por confiabilidad. Una organización regulada puede descartar una ruta aunque sea barata por residencia o privacidad.
Cómo probarlo sin construir un monstruo
Empieza con un conjunto de 50 a 100 tareas reales, no con prompts inventados. Ejecuta el mismo harness con dos o tres modelos y registra costo efectivo, tiempo total, pasos, errores, uso de caché y necesidad de intervención. Compara también reintentos y respuestas incompletas: un fallo caro debe pesar más que una victoria barata.
No rutees hasta tener una política de salida. Si el agente excede pasos, pierde una herramienta crítica o devuelve una evidencia insuficiente, debe escalar, detenerse o pedir revisión. Y vuelve a medir cuando cambien precios, caché, modelos o infraestructura.
Si quieres aterrizar esto en operación, continúa con el curso gratis.
De la guía a la práctica
Elige un curso para tu proyecto
Continúa con una ruta paso a paso: instalación, programación o uso de un asistente personal, según tu experiencia.
Explorar cursos gratisContenido gratis, sin registro. Los servicios externos pueden tener costos.
Avisos cuando actualicemos cursos y guías
Recibe actualizaciones por correo. Es opcional: puedes seguir leyendo y abrir cualquier curso sin suscribirte.
Lecturas relacionadas
Sigue explorando Costos y Modelos y otras piezas para builders.

LiteLLM proxy para agentes: un gateway OpenAI frente a 100+ modelos

OpenRouter para agentes IA: una API, fallbacks y créditos

Timeouts y cancelación de llamadas LLM: AbortSignal, no un setTimeout decorativo
