Microsoft presenta una arquitectura de enrutamiento de agentes de IA en AKS que reduce los costos hasta en un 85%

Microsoft ha publicado una arquitectura de referencia para enrutar el tráfico de agentes en Azure Kubernetes Service (AKS), desglosando el problema en tres decisiones clave: qué modelo responde a una llamada, cómo se gestiona la llamada y qué réplica de GPU la maneja. El diseño combina la extensión de inferencia de la API de Gateway de Kubernetes para el balanceo de carga, agentgateway como proxy de IA y RouteLLM para el enrutamiento semántico, todo conectado a un endpoint compatible con OpenAI. Esto está adaptado para cargas de trabajo de agentes en lugar de chat simple, ya que una sola tarea de agente puede desencadenar cientos de llamadas de LLM en un bucle de planificar-actuar-observar, la mayoría de las cuales (rellenar argumentos de herramientas, decisiones de sí/no, resúmenes) no requieren un modelo de frontera. RouteLLM inspecciona el prompt y predice si un modelo más barato puede igualar la calidad de un modelo más fuerte, utilizando un router de factorización de matrices entrenado con datos de preferencias humanas. Agentgateway, un proxy de código abierto compatible con OpenAI, gestiona la autenticación, los límites de tasa por agente, el seguimiento de costos y las salvaguardas sin inspeccionar el contenido del prompt. El selector de endpoints de la extensión de inferencia de la API de Gateway verifica el estado de la GPU en tiempo real, incluido el uso de caché KV de vLLM y la profundidad de la cola, para decidir qué réplica del modelo seleccionado maneja la solicitud. Para rutas autohospedadas, agentgateway llama al selector de endpoints a través de ext-proc, sin pasar por una puerta de enlace de API de Gateway separada. KAITO proporciona grupos de nodos de GPU bajo demanda y ejecuta vLLM, exponiendo métricas como vllm:num_requests_waiting y vllm:kv_cache_usage_perc. La ruta del modelo fuerte pasa por el backend de IA de agentgateway a Azure OpenAI, mientras que la ruta del modelo débil se enruta a través de un backend de servicio a los pods servidos por KAITO. Prometheus y Grafana gestionados por Azure recopilan métricas de enrutamiento, costos y GPU para una vista unificada. Un número clave es el umbral de actualización de RouteLLM: en los pares de modelos probados, el router mf logró aproximadamente el 95% de la calidad de GPT-4 en MT-Bench enviando solo alrededor del 26% de las llamadas a GPT-4, ahorrando hasta un 85% en costos. Microsoft advierte que esta cifra no es automática y depende del par de modelos utilizado para entrenar RouteLLM; los usuarios deben calibrar los umbrales según el tráfico real. El caché de prompts complica los costos de tokens, ya que los aciertos de caché obtienen descuentos, y cambiar de modelos enfría los cachés en ambos lados. El artículo advierte que los componentes son jóvenes; los campos cambian entre versiones: la extensión de inferencia renombró y reestructuró los CRD antes de la v1. Todo se verificó de extremo a extremo a mediados de 2026 en AKS con la extensión de inferencia v1.0.0 y agentgateway v1.3.1. Los equipos pueden adoptar la arquitectura en fases: para modelos gestionados con pocos agentes, la gobernanza de agentgateway es suficiente; para un solo modelo autohospedado, KAITO y la extensión de inferencia son suficientes sin enrutamiento semántico; RouteLLM vale la pena cuando hay una clara diferencia de precio entre modelos fuertes y débiles y un tráfico simple considerable, lo que se aplica a casi todos los agentes en bucle.