Cuando escuchas 'model routing' suena simple: eliges el mejor modelo para la tarea y listo. ¿Y si te digo que eso rara vez es lo que ocurre en sistemas agenticos reales? Lo que parece un problema de clasificación pronto se convierte en un problema de optimización de sistemas, con tres dimensiones que lo complican de forma inesperada.
Por qué clasificar falla
La intuición común es estimar la dificultad de una solicitud y enviar las tareas difíciles a modelos potentes. Suena razonable, ¿no? En la práctica esto choca con dos límites claros.
Primero, la dificultad es muchas veces invisible en el momento del enrutamiento. Un prompt aparentemente simple, como resumir un contrato, puede desencadenar recuperación de documentos, controles de cumplimiento, uso de herramientas y varias rondas de refinamiento. Solo al ejecutar la tarea sabes cuan costosa será.
Segundo, aun con una estimación perfecta de dificultad, ese es solo uno de varios factores. En producción debes equilibrar simultáneamente costo, calidad, latencia y confiabilidad. Además, vienen las restricciones empresariales: reglas de cumplimiento, residencia de datos, privacidad y listas de modelos aprobados. El enrutador debe respetar todo eso sin romper la experiencia.
En la práctica, los routers no resuelven un solo problema. Están constantemente balanceando costo, calidad, latencia, cumplimiento y confiabilidad.
Costos, caché y la sorpresa de los precios
Un hallazgo concreto que rompe la lógica de la tarifa por token: Claude Sonnet 4.6 resultó más barato que GPT-4.1 en un experimento real. Sobre 417 tareas usando el mismo agente CodeAct, Sonnet costó 79 USD total (0.19 USD por tarea) mientras GPT-4.1 costó 155 USD (0.37 USD por tarea). En papel, GPT-4.1 tenía mejor precio por token y menor tarifa de entrada y salida, así que debería ganar por goleada.
La explicación fue la caché. Los agentes tienden a reutilizar grandes porciones de contexto entre pasos. Cuando las tasas de aciertos de caché son altas, el costo efectivo de entrada cae drásticamente. Sonnet tenía un precio de lectura de caché más bajo, lo que le dio una ventaja desproporcionada pese a usar más pasos de razonamiento.
La lección: el costo real surge de la interacción entre modelo, carga de trabajo y la infraestructura de serving. Un enrutador que solo mira las hojas de precio está optimizando contra números equivocados.
Latencia y granularidad: no todo es tamaño de modelo
Es tentador pensar que un modelo más grande siempre será más lento y uno pequeño más rápido. Sin embargo, la experiencia del usuario depende de muchos factores: el overhead del propio enrutamiento, el hardware donde corre el modelo, si la caché está caliente y la carga del endpoint. Un modelo teóricamente más rápido puede dar una experiencia más lenta si las condiciones de servicio no son favorables.
Además la granularidad importa. Enrutar una vez por tarea añade poco overhead. Pero enrutar en cada paso del flujo permite adaptarse sobre la marcha y mejorar eficiencia, aunque cada punto de decisión añade latencia y complejidad operativa.
Un enrutador que ignora el estado del serving está optimizando contra una realidad equivocada.
Enfoque práctico: tratar el routing como optimización
Lo que hicieron los autores fue cambiar la pregunta. En lugar de preguntar 'qué modelo es mejor para esta tarea', formularon un problema de optimización: maximizar calidad y latencia mientras minimizan costo, sin que el propio enrutador se convierta en cuello de botella. El resultado es un mapeo de puntos operativos que puedes elegir según tus prioridades.
En el AppWorld Test Challenge con un agente CodeAct, el enrutador traza una frontera costo-precisión donde cada configuración es un punto operativo. Por ejemplo, la Configuración 1, optimizada por latencia, alcanzó 84% de precisión por 93 USD y 83 segundos de latencia. Eso refleja una reducción de costo del 21% y una reducción de latencia del 9% frente a ejecutar Opus solo, con solo 4% de reducción en precisión. Otras configuraciones bajan aún más el costo.
Un enrutador basado solo en dificultad (punto teal en la figura original) cae en una zona de similar precisión pero mayor costo. La ventaja del enfoque de optimización es explorar el espacio de tradeoffs en vez de quedarse en un único criterio.
Técnicamente, el enrutador diseñado es muy ligero: alrededor de 6 ms y 2 kB de memoria por tarea, lo suficiente para no convertirse en el cuello de botella que tanto temen los equipos.
Recomendaciones prácticas para quienes construyen routing
- Mide la tasa de aciertos de caché y calcula el costo efectivo de entrada, no solo el precio por token.
- Observa la infraestructura: hardware, cola de peticiones y estado de endpoints pueden cambiar la latencia más que el tamaño del modelo.
- Considera la granularidad de enrutamiento: enrutar por paso da flexibilidad, pero añade latencia y complejidad operacional.
- Integra políticas de cumplimiento y residencia de datos en la lógica de enrutamiento, no como un filtro posterior.
- Trata el enrutador como un optimizador ligero que expone distintos puntos operativos para escoger según prioridad (costo vs latencia vs calidad).
Reflexión final
El mensaje central es simple pero poderoso: el enrutamiento no es solo elegir modelos, es diseñar el mejor punto de operación para todo el sistema. Modelos, caché, infraestructura y gobernanza son variables interdependientes. Resolver esto es más difícil que clasificar, pero también es donde aparecen las mayores eficiencias.
Si estás integrando routing en sistemas agenticos, empieza por medir interacciones reales entre caché, carga y endpoints antes de confiar en reglas fijas. El verdadero triunfo no es encontrar el 'mejor modelo' por tarea, sino encontrar la mejor configuración para tu sistema.
Fuente original
https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt