Model Routing
Seleccionar dónde ejecutar una tarea
Model Routing es el patrón de seleccionar un modelo o una configuración de modelo para una solicitud o tarea de acuerdo con requisitos y condiciones de ejecución. La selección puede considerar capacidad, calidad esperada, latencia, costo, disponibilidad, modalidad, contexto, política o riesgo. Su propósito es asignar la ejecución a una alternativa adecuada; no existe un criterio universal de mejor modelo.
Una aplicación puede tener tareas con necesidades diferentes: clasificar una entrada, interpretar una imagen o producir un resultado estructurado. Utilizar el mismo destino para todas simplifica integración, pero puede no satisfacer sus restricciones. Introducir routing permite diferenciarlas, a cambio de mantener criterios de selección y contratos entre alternativas.
El patrón puede existir en un programa convencional sin agentes. Una regla fija puede asignar una clase de tareas a un modelo; un componente puede decidir por metadatos o por análisis de la entrada. La existencia de una decisión de selección no demuestra autonomía ni necesita un sistema multiagente.
Model Routing y Routing general
Routing, dentro de Agentic Workflow Patterns, selecciona caminos o destinos más amplios: herramientas, workflows, agentes, ramas o modelos. Model Routing especializa esa responsabilidad en el destino de inferencia. No sustituye el concepto general ni convierte toda elección de herramienta en selección de modelo.
Una aplicación puede enrutar primero una solicitud a un workflow y después elegir un modelo para una etapa. También puede seleccionar un modelo sin cambiar el flujo de trabajo. Distinguir niveles evita atribuir a la selección de inferencia decisiones que pertenecen a la orquestación completa.
El router puede ser una regla, un clasificador, otro modelo o código que consulta condiciones operativas. La implementación no define por sí sola el patrón. Utilizar un modelo para seleccionar otro tampoco convierte automáticamente el sistema en agente ni garantiza que esa selección sea mejor que una regla sencilla.
Modelo, configuración y proveedor
Un proveedor puede ofrecer varios modelos, y una aplicación puede disponer de varias configuraciones o despliegues relacionados con un mismo modelo. Elegir proveedor y elegir modelo son dimensiones diferentes. El destino necesita describirse con suficiente precisión para entender qué capacidad y contrato recibirá la solicitud.
La configuración también puede importar: modalidad admitida, límites de contexto, mecanismos de salida o capacidades de interacción pueden modificar la aptitud para una tarea. No basta con que dos destinos acepten texto. La aplicación debe conocer qué propiedades requiere y cuáles son realmente compatibles.
Esta precisión no obliga a fijar nombres comerciales en la definición durable. Un inventario operativo puede registrar destinos actuales, mientras el patrón conserva criterios de selección y expectativas. Cambiar una oferta del proveedor exige revisar ese inventario; no crea una nueva identidad conceptual para Model Routing.
La normalización de una interfaz puede ocultar diferencias de comportamiento. Un wrapper común facilita invocación, pero no demuestra equivalencia de calidad, restricciones de salida o interpretación de herramientas. El consumidor sigue necesitando un contrato sobre lo que acepta como resultado y sobre cómo tratar capacidades ausentes.
Señales de selección
Las señales pueden describir la tarea, la entrada, la política y el estado del servicio. Modalidad, tamaño de contexto y formato requerido pueden descartar alternativas antes de comparar preferencias. Otros criterios, como calidad esperada y latencia, requieren evidencia sobre las tareas reales y no solo etiquetas generales de capacidad.
Una estimación de dificultad puede ayudar, pero puede ser errónea. Una solicitud corta puede requerir conocimiento especializado; una larga puede contener mucho texto irrelevante. Utilizar longitud como sustituto universal de complejidad puede producir rutas equivocadas y un comportamiento difícil de explicar.
Política y riesgo pueden imponer condiciones que no deben intercambiarse por una reducción de costo. Una alternativa más rápida no es válida si carece de una modalidad necesaria o no cumple una restricción aplicable. Primero importa la elegibilidad; después, la elección entre alternativas admisibles.
La disponibilidad también es contextual. Un destino puede estar accesible y no tener capacidad adecuada para la operación actual. Otro puede satisfacerla y estar temporalmente indisponible. La selección debe distinguir aptitud, posibilidad de ejecución y resultado observado en lugar de reducir todo a una lista ordenada de nombres.
Estrategias de routing
Una estrategia estática asigna clases de tareas a destinos conocidos. Puede ser fácil de entender y suficiente cuando las necesidades son estables. Su límite aparece cuando las clases agrupan casos demasiado diferentes o el inventario cambia sin revisar las reglas.
Las reglas pueden utilizar metadatos y condiciones explícitas. Un clasificador o modelo router puede estimar qué destino conviene a partir de la entrada. El trabajo RouteLLM, de 2024, estudia routers entrenados con datos de preferencias. Es un ejemplo de investigación, no evidencia de un ganador universal ni requisito de implementación.
Una selección informada por feedback puede revisar preferencias después de observar resultados. Eso necesita distinguir cambios del router, del modelo y de la población de tareas. Si todo cambia simultáneamente, una mejora o degradación no puede atribuirse con claridad a una sola causa.
Introducir una inferencia adicional para decidir también consume tiempo y recursos. Un router complejo puede costar más que la diferencia que pretendía aprovechar en tareas pequeñas. La estrategia debería justificarse por resultados relevantes y mantener una alternativa simple como referencia, sin convertir sofisticación del selector en un objetivo independiente.
Routing normal y fallback
Routing selecciona el destino normal para una tarea bajo sus criterios. Fallback es una respuesta contingente cuando una alternativa no puede utilizarse o no satisface una condición de continuación. Pueden componerse, pero no son sinónimos. Un sistema con una sola alternativa principal y otra de contingencia no necesariamente distribuye tareas mediante una política de routing detallada.
El fallback puede cambiar capacidad, comportamiento o contrato. Si una alternativa no admite el formato necesario, continuar allí puede producir una respuesta imposible de consumir. La existencia de otro proveedor disponible no demuestra que sea una sustitución válida para la tarea.
También importa cuándo se considera fallida una operación. Un timeout de inferencia puede dejar un resultado pendiente; una llamada que desencadena herramientas puede haber producido efectos antes de perder la confirmación. Elegir otro destino no resuelve automáticamente la incertidumbre sobre esos efectos. Tool Use conserva esa frontera.
El patrón no prescribe un orden universal de contingencia ni reintentos ilimitados. La aplicación necesita decidir qué fallos permiten continuar, con qué restricciones y qué información debe devolver cuando no existe una alternativa admisible. Cambiar de modelo repetidamente hasta obtener una respuesta convincente no demuestra corrección.
Model Routing y AI Gateway
Un AI Gateway pertenece a la capa operativa o de infraestructura que puede mediar acceso, aplicar políticas y organizar tráfico. Puede implementar selección de modelos, pero Model Routing es la conducta lógica de aplicación. El patrón puede implementarse sin gateway y un gateway puede existir sin una política sofisticada de routing.
La ubicación de una decisión no elimina su responsabilidad conceptual. Si el gateway elige un destino, la aplicación necesita conocer las garantías relevantes. Si la aplicación elige y la infraestructura ejecuta, ambas deben mantener coherencia sobre el contrato. Esta frontera no materializa AI Gateway ni su diseño operativo, reservados para otra iteración.
Separar responsabilidades facilita sustituir una implementación. Una política de selección puede expresarse con criterios de tarea sin quedar ligada a una API particular. Eso no exige construir una plataforma genérica: unas pocas reglas explícitas pueden ser la solución adecuada mientras el problema sea pequeño.
Contratos al cambiar de destino
Una ruta válida debe conservar lo que exige el consumidor. Structured Generation puede imponer una representación; Context Management prepara información que debe caber y ser interpretable en el destino elegido. El router no debe descartar silenciosamente restricciones necesarias para hacer posible una llamada.
Si una tarea usa herramientas, importa cómo se expresan las solicitudes y cómo se interpretan resultados. Compatibilidad sintáctica no implica selección equivalente de acciones. Las pruebas y evidencias sobre una combinación concreta no se trasladan automáticamente a otra por compartir una interfaz.
El historial puede contener resultados o instrucciones condicionados por el destino anterior. Cambiar modelo en una etapa posterior puede necesitar revisar qué información se transfiere y qué supuestos siguen siendo válidos. No conviene tratar una conversación serializada como una representación universal independiente de cualquier ejecución.
La selección tampoco garantiza corrección semántica. Un modelo considerado adecuado puede fallar en una instancia concreta. El sistema sigue necesitando comprobar requisitos del resultado por las vías pertinentes. Model Routing distribuye ejecución; no reemplaza verificación ni convierte una preferencia estadística en certeza individual.
Fallos y trade-offs
Un router puede clasificar mal la tarea, usar reglas obsoletas, desconocer una capacidad o favorecer un destino por señales que ya no representan el trabajo. También puede ocultar degradaciones si registra solo que la solicitud terminó, sin conservar qué ruta se eligió y bajo qué condiciones.
Las rutas pueden producir experiencias inconsistentes: dos entradas parecidas pueden terminar en destinos con respuestas diferentes. Esa variación puede ser aceptable o relevante según la aplicación. No toda diferencia es un fallo, pero debe poder relacionarse con criterios de selección y requisitos del producto.
Optimizar una sola dimensión puede trasladar el problema. Reducir llamadas a un modelo puede aumentar errores de formato o la necesidad de repetir. Favorecer disponibilidad puede aumentar latencia; favorecer rapidez puede excluir una capacidad necesaria. Los trade-offs se analizan respecto de tareas reales, sin desarrollar aquí AI Economics.
Human in the Loop puede resolver casos que no tienen una ruta apropiada o requieren una decisión adicional. No es un sustituto automático de routing: una persona necesita contexto y autoridad para intervenir. Tampoco debe agregarse una aprobación a cada selección si no existe una necesidad concreta.
Routing y Semantic Caching
Semantic Caching puede reutilizar un resultado previo para una solicitud elegible y evitar una inferencia nueva. Model Routing elige dónde ejecutar cuando se necesita esa ejecución. Son responsabilidades diferentes y ninguna implica la otra.
Su composición necesita coherencia. Una entrada de caché puede depender de versión de modelo, instrucciones o contrato de salida; cambiar la política de routing puede modificar su elegibilidad. El hecho de que dos destinos pertenezcan al mismo proveedor no demuestra que sus resultados sean intercambiables para cualquier uso.
Ejemplo y límites
Una aplicación procesa solicitudes de análisis de documentos. Una regla identifica modalidad y contrato de salida; después selecciona entre destinos admisibles según las necesidades de la tarea. Si no existe uno que cumpla las condiciones, comunica el límite o toma una alternativa permitida en lugar de eliminar silenciosamente el requisito.
Durante una indisponibilidad puede utilizar una contingencia compatible. Si no lo es, detener esa operación puede ser preferible a producir un objeto que el consumidor no puede interpretar. El resultado final sigue necesitando comprobación: haber tomado la ruta prevista demuestra una decisión del proceso, no que la respuesta sea correcta.
El patrón resulta útil cuando existen diferencias relevantes entre tareas y alternativas. Puede ser innecesario si un único destino satisface el trabajo con menor complejidad. No debe convertirse en una plataforma de selección anticipada ni en una clasificación permanente de proveedores; conserva una decisión local que debe poder revisarse con evidencia.
Fuentes y alcance
Referencia primaria consultada el 2026-10-30: Ong et al., RouteLLM, 2024. Se cita como ejemplo de routing basado en preferencias; las fronteras entre selección, proveedor, contingencia e infraestructura son síntesis del Atlas. No se fijan modelos actuales, precios, umbrales ni rankings, y no se materializan AI Gateway o evaluación general.