Now Reading: Model Router en Azure AI Foundry: Optimización Inteligente de Modelos de IA Generativa
-
01
Model Router en Azure AI Foundry: Optimización Inteligente de Modelos de IA Generativa
Model Router en Azure AI Foundry: Optimización Inteligente de Modelos de IA Generativa
Hace unas semanas escribí sobre OpenRouter, un servicio que me llamó la atención por su forma de simplificar el acceso a múltiples modelos de lenguaje y permitir arquitecturas IA multimodelo de manera bastante flexible.
Hace unos días saltó en mi radar: Model Router de Azure AI Foundry, la posible alternativa nativa de Microsoft dentro de su ecosistema, aunque con un enfoque más autónomo ya que es específico para el enrutamiento. Aunque ambos buscan simplificar el acceso y uso de múltiples modelos, su aproximación difiere significativamente, especialmente en la gestión de la resiliencia y el control del usuario sobre las rutas de respaldo. Veremos diferencias en próximos artículos, os mantendré informados.
Model Router me pareció muy interesante y lo que he estado haciendo estos días es revisar documentación oficial, ver demos en detalle, hacer pruebas en entornos propios de Azure y contrastar la experiencia con artículos y casos de otros profesionales. En este post quiero compartirte no solo qué es el Model Router y cómo funciona, sino también qué conclusiones prácticas he sacado tras dedicar tiempo a investigarlo, bueno la palabra investigar me da mucho respeto, digamos dedicar tiempo a jugar y intentar entenderlo.
¿Qué es el Model Router y por qué me interesa tanto?
El Model Router es, en pocas palabras, un “punto único de entrada” para usar IA generativa en Azure. En lugar de que nuestras aplicaciones llamen directamente a modelos individuales, el router actúa como intermediario, analiza cada solicitud y decide en tiempo real qué modelo ejecutar. Es un repartidor de manos de cartas.
Lo que más me convenció en cuanto entendí su concepto fue que te permite abstraerte de algo que en la práctica consume mucho tiempo: decidir qué modelo usar para cada caso. Él mismo hace esa elección de forma completamente automática, evaluando factores como la complejidad de la consulta, la longitud y naturaleza de la entrada (texto o imágenes), el rendimiento disponible y la carga de los modelos, y el coste estimado por inferencia. Aunque el comportamiento es autónomo, para sistemas de IA más complejos, la claridad en las pautas y las descripciones detalladas de las herramientas son cruciales para la precisión en la selección del modelo.
Desde el punto de vista de arquitectura, esto significa que trabajas siempre contra un único endpoint, simplificando integración, permisos, filtros de contenido y monitorización. Y aviso, no siempre decide lo que entiendes que ha decidir, sobre todo cuando buscas al modelo razonador.
Lo que descubrí al investigar y probar el Model Router
Quise ir más allá de la teoría, ya sabéis primero gatear aunque en este caso os reconozco que ni eso, así que me dediqué principalmente a documentarme con videos explicativos y demos oficiales. Además, revisé otras experiencias de colegas como Stefano Demiliani, va un paso por delante siempre en Azure y recomiendo leer su blog.
Todo ese trabajo( más tiempo que trabajo) me llevo varias conclusiones aunque no todas aún las tengo muy claras:
1. El enrutamiento automático funciona mejor de lo que esperaba y ofrece transparencia cuidada.
En las demos y pruebas, las peticiones simples como preguntas rápidas o consultas breves se redirigían en milisegundos a modelos ligeros, mientras que solicitudes complejas activaban modelos de razonamiento avanzado (familia o-series). El comportamiento es completamente automático, sin necesidad de configuración adicional, lo que simplifica la selección manual de modelos.
Una de las cosas que más valoro en un servicio así es saber qué está pasando por debajo. Aquí, cada respuesta incluye el nombre del modelo que se usó, y desde el portal de Azure puedes ver métricas claras: tokens consumidos, latencia, coste, e incluso dividirlas por los modelos subyacentes. Esta transparencia es crucial porque no solo te da trazabilidad, sino que también permite a los equipos de ingeniería de prompts comprender mejor el comportamiento del router y optimizar sus entradas para obtener los resultados deseados o gestionar de manera más efectiva los costes.
2. El soporte multimodal es inmediato, pero con una aclaración importante.
El Model Router acepta entrada de imágenes para chats habilitados para visión, ya que todos los modelos subyacentes son compatibles con esto. Sin embargo, la decisión de enrutamiento se basa únicamente en la entrada de texto y no en las imágenes. Es decir, las imágenes pueden ser procesadas por el modelo seleccionado, pero no influyen en la selección del modelo por parte del router. Además, es fundamental saber que el Model Router no procesa entrada de audio.
3. El ahorro de costes es real y medible.
Las pruebas propias y las referencias que vi (incluyendo el artículo de Demiliani) coinciden en algo: el ahorro es evidente. Delegar consultas rutinarias en modelos mini y dejar los modelos avanzados solo para lo crítico marca la diferencia cuando proyectas costes en escenarios continuos.
4. La auto-actualización aporta agilidad, pero exige control.
El router puede incorporar nuevas versiones de modelos automáticamente, lo que te permite estar siempre al día. Sin embargo, comprobé que es fundamental revisar métricas tras cada actualización porque un cambio de modelo por defecto puede impactar en coste o en resultados.
5. Hay limitaciones prácticas que conviene conocer y estrategias para mitigarlas.
Por ejemplo, el límite de contexto lo define el modelo más pequeño incluido en el router. Es crucial entender que una llamada a la API con un contexto más grande fallará si el prompt no se enruta a un modelo compatible con ese contexto. Para mitigar esto, en lugar de solo ‘diseñar prompts pensando en el límite de contexto del modelo más pequeño’, considera las siguientes estrategias prácticas:
- Resumir el prompt antes de pasarlo al modelo.
- Truncar el prompt en las partes más relevantes.
- Usar embeddings de documentos y hacer que el modelo de chat recupere las secciones relevantes, haciendo referencia a Azure AI Search.
Además, parámetros como Temperature o Top_P (que ajustan la creatividad de las respuestas) se ignoran en modelos de razonamiento (o-series). Lo mismo ocurre con stop, presence_penalty, frequency_penalty, logit_bias y logprobs. Es importante tener claro que el parámetro reasoning_effort tampoco se soporta y el router selecciona automáticamente su valor basado en la complejidad del prompt. Para los desarrolladores que buscan un control fino sobre la creatividad, esto significa que si un prompt es enrutado a un modelo de razonamiento, los parámetros de creatividad serán ignorados. Por lo tanto, deberán diseñar sus prompts de manera que guíen al router hacia modelos que sí soporten estos parámetros si la creatividad es un requisito clave para su tarea, o considerar no usar el Model Router para esos casos específicos y llamar directamente a un modelo compatible.
6. Prepararse para el cambio de facturación y evaluar su impacto.
Actualmente, hasta el 1 de agosto de 2025, solo se factura por el uso de los modelos subyacentes que el router selecciona para responder a los prompts; la función de enrutamiento en sí no genera cargos adicionales. Sin embargo, a partir de esa fecha, el propio Model Router se facturará como un recurso independiente. Esto significa que, si bien el ahorro de costes es actualmente «real y medible» al optimizar el uso de modelos, será fundamental evaluar el impacto de este nuevo cargo en el modelo de costes a largo plazo para confirmar que sigue siendo la solución más coste-efectiva en escenarios de producción continua.
Conclusión
Después de investigar, ver demos, hacer pruebas y revisar experiencias de otros, mi conclusión es clara: el Model Router de Azure AI Foundry no solo simplifica el consumo de IA generativa, también te da las herramientas para gobernarla mejor.
Lo que más me gustó del Model Router es que te permite centrarte en construir y no en gestionar. En vez de perder tiempo decidiendo modelos, ajustando endpoints y haciendo pruebas manuales, simplemente trabajas contra un único recurso y confías en que hará esa optimización por ti. Y en las pruebas que he visto y estoy haciendo, lo hizo bastante bien. Automatiza la selección de modelos, ofrece transparencia total en métricas y reduce la carga operativa. Para quienes trabajamos en proyectos que combinan IA y aplicaciones de negocio (Dynamics 365, Copilot Studio, escenarios multiagente…), es una pieza que tiene mucho sentido incorporar.
Lo que no me gustó, la trasparencia al usuario tiene su lado oscuro. Que dicotomia, ¿verdad?. ¿Que quiero decir? Pues que en peticiones que en principio entendia que seleccionaria el modelo razonador no lo ha hecho y no he visto o entendido el porqué. Bueno si que entre sombras lo entiendo y es, como he comentado en otras ocasiones, la importancia del prompt y la ventana de contexto.
En próximos artículos quiero compararlo directamente con OpenRouter, porque, aunque persiguen un objetivo algo similar , cada uno lo aborda de forma distinta: uno como servicio abierto multi-LLM, otro integrado en Azure y enfocado a entornos corporativos. OpenRouter, por ejemplo, ofrece una funcionalidad explícita de models para definir rutas de respaldo (fallback) en caso de fallos del modelo principal, una capacidad que el Model Router de Azure gestiona internamente y de forma autónoma, sin una configuración directa por parte del usuario para este tipo de escenarios de error. Lo exploraremos en detalle en un próximo artículo.
Referencias
Referencias oficiales:
Referencias de Comunidad tecnica:
Recordad esto porque ayuda mucho
Suscríbete al canal (anima y da ese empujón a todo esto).
Pulsa «like» si te ha gustado.
Si no quieres perderte nada, ya sabes, pulsa la campana.
En los comentarios déjame cualquier idea, duda, corrección o aportación. Todo será bien bienvenido.
Nota: El contenido de este artículo ha sido generado con la ayuda de IA, para más información accede a la pagina sobre responsabilidad AI del blog
