Por qué el enrutamiento de modelos es un problema de sistemas, no de clasificación

El enrutamiento de modelos es una de esas ideas que se ve limpia en una pizarra. Enrutar consultas simples a modelos más baratos y rápidos. Dejar los modelos pesados para lo difícil. Pero el piso del centro de datos no es una pizarra. En producción, el enrutamiento se convierte en un malabarismo constante, y las variables que dominan el costo y la latencia casi nunca son las que los ingenieros enumeran en una tabla comparativa.

Este artículo recorre tres dimensiones que hicieron que el enrutamiento fuera sorprendentemente difícil para nosotros, basándose en 417 tareas del AppWorld Test Challenge con un agente CodeAct. Cada cifra proviene de una implementación real, no de una simulación.

El costo es más que el precio del modelo

La suposición inicial era simple: GPT-4.1 debería ser más barato que Claude Sonnet 4.6. El precio por token de GPT-4.1 es más bajo tanto en entrada como en salida, y Sonnet requiere aproximadamente tres veces más pasos de razonamiento para completar las mismas tareas de agente. Solo en precio de lista, GPT-4.1 gana.

Los números reales contaron una historia diferente. En 417 tareas con el mismo agente, Sonnet costó $79 en total ($0.19 por tarea) mientras que GPT-4.1 costó $155 en total ($0.37 por tarea), casi el doble.

La explicación es el almacenamiento en caché, un factor que la mayoría de las arquitecturas de enrutamiento ignoran por completo. Las cargas de trabajo de agentes reutilizan grandes fragmentos de contexto en pasos consecutivos. Cuando las tasas de acierto de caché son altas, los costos efectivos de entrada caen drásticamente. El precio de lectura de caché más bajo de Sonnet significó que se benefició desproporcionadamente de este patrón, suficiente para superar tanto su precio base más alto como sus trayectorias más largas. Un enrutador que solo mira la hoja de precios está optimizando contra los números equivocados.

La complejidad es más que la dificultad de la tarea

Una estrategia común de enrutamiento es medir la dificultad de la tarea y enviar el trabajo más difícil a modelos más fuertes. Intuitivo, pero se descompone de dos maneras en producción.

Primero, la dificultad suele ser invisible en el momento del enrutamiento. Una solicitud como "resumir este contrato" parece simple, pero podría desencadenar recuperación, comprobaciones de cumplimiento, uso de herramientas y múltiples rondas de refinamiento antes de completarse. Mientras tanto, un mensaje altamente técnico podría ser manejado eficientemente por un modelo especializado más pequeño. A menudo no se sabe lo difícil que es una tarea hasta que la ejecución revela su estructura interna.

Segundo, incluso si se pudiera estimar la dificultad perfectamente, es solo una señal entre muchas. Los enrutadores empresariales necesitan equilibrar simultáneamente costo, latencia, especialización del modelo y confiabilidad. Las restricciones regulatorias se acumulan: reglas de residencia de datos, listas de modelos aprobados, requisitos de cumplimiento. Una tarea que idealmente iría a un modelo podría necesitar ir a otro lado debido a la gobernanza, y el enrutador debe manejarlo con elegancia en lugar de fallar.

Los enrutadores no resuelven un solo problema. Están constantemente haciendo malabarismos con costo, calidad, latencia, cumplimiento y confiabilidad todo a la vez.

La latencia es más que la velocidad del modelo

Es una sabiduría convencional pensar en la latencia puramente en términos del tamaño del modelo: los modelos más grandes son más lentos, los más pequeños más rápidos. Pero lo que el usuario experimenta depende de mucho más que eso.

El enrutamiento en sí mismo añade sobrecarga. Los factores de infraestructura, en qué hardware se ejecuta un modelo, si la caché está caliente, qué tan ocupado está el punto final, a menudo dominan los tiempos de respuesta de extremo a extremo. Un modelo teóricamente más rápido puede seguir produciendo una experiencia de usuario más lenta si las condiciones de servicio no están alineadas.

Luego está la granularidad del enrutamiento. Enrutar una vez por tarea añade una sobrecarga mínima. Pero enrutar en cada paso, lo que brinda más flexibilidad para adaptarse a mitad de la ejecución, significa que cada punto de decisión adicional introduce latencia y complejidad operativa. Un enrutador que ignora el sistema de servicio está luchando la batalla equivocada.

Un enfoque basado en optimización

Estas lecciones impulsaron un cambio fundamental: dejamos de tratar el enrutamiento como un problema de clasificación y comenzamos a tratarlo como un problema de optimización. En lugar de preguntar "¿qué modelo es mejor para esta tarea?", el algoritmo optimiza simultáneamente costo, calidad y latencia, mientras permanece lo suficientemente liviano para evitar convertirse en un cuello de botella.

En el AppWorld Test Challenge, un enrutador basado en optimización trazó una frontera clara de costo-precisión. La Configuración 1 (optimizada para latencia) alcanzó un 84% de precisión por $93 y 83 segundos. Eso es una reducción del 21% en costo y del 9% en latencia en comparación con ejecutar Opus solo, con solo una caída del 4% en precisión. Un enrutador estándar basado en dificultad aterrizó en un rango de precisión similar pero a un costo más alto; no exploró todo el espacio de compensaciones. La optimización en sí misma se ejecuta en aproximadamente 6 milisegundos y 2 kilobytes de memoria por tarea.

La conclusión clave: el enrutamiento no se trata de elegir modelos. Se trata de optimizar sistemas. Los modelos son una variable, importante, pero solo una entre el comportamiento de caché, el estado de la infraestructura, las restricciones de cumplimiento y los patrones de carga de trabajo.

Si está construyendo enrutamiento en sus propios sistemas de agentes, el autor agradece conocer las compensaciones que está encontrando.