Microsoft AKS en Bare Metal Reduce Latencia de GPU 12–18% en Build 2026

Microsoft lanzó cuatro actualizaciones de AKS en Build 2026: AKS en Bare Metal (vista previa pública), Azure Kubernetes Fleet Manager para clusters habilitados para Arc (GA), Anyscale en Azure con Ray administrado (vista previa pública) y ModelServingRuntime para inferencia nativa de Kubernetes. Cada una apunta a una capa diferente del costo de infraestructura de GPU: sobrecarga de hipervisor, operaciones de múltiples clusters, gestión de Ray e integración de framework de serving.

AKS en Bare Metal elimina el hipervisor, dando a las cargas de trabajo acceso direto a NVLink y RDMA para entrenamiento distribuido e inferencia de baja latencia. Los benchmarks de Microsoft mostraron una mejora de 12–18% en la tasa de mensajes InfiniBand y menor latencia de cola en nodos A100 bare metal frente a hosts dedicados de Azure. El plano de control gestiona tanto nodos físicos como virtuales, habilitando despliegues híbridos. El hardware de lanzamiento incluye modelos Dell y HPE certificados a través de Azure Stack HCI; soporte más amplio se enviará a finales de año. Sin tarifa por cluster.

Fleet Manager GA para clusters habilitados para Arc extiende política centralizada, ubicación de cargas de trabajo, implementaciones por etapas y RBAC en Azure, on-premises y otras nubes. Para equipos distribuidos entre regiones o usando clusters on-premises para residencia de datos, esta consolidación importa más que cualquier característica individual.

Anyscale en Azure trae Ray administrado a AKS sin operaciones de cluster independientes. El servicio maneja asignación heterogénea y fraccional de GPU, escalando por trabajo. Se ejecuta en suscripciones de clientes, se integra con Entra ID y factura por vCPU-segundo con un nivel gratuito de 200 vCPU-horas durante vista previa. Wayve ejecuta esto en producción para vehículos autónomos, usando AKS, Ray y Anyscale en Azure para conectar miles de GPUs. El CEO Alex Kendall describió el despliegue de un nuevo vehículo Nissan en Japón—"un país donde nunca habíamos manejado"—y en cuatro meses demostrando conducción autónoma en todo Tokio. Vinculó el hito directamente a la capacidad elástica de GPU de Azure.

ModelServingRuntime expone vLLM, KServe y runtimes similares como objetos nativos de Kubernetes en lugar de stacks separados. Una carga de trabajo ModelServingRuntime obtiene HTTPS automático, autenticación Entra ID, trazas de OpenTelemetry y un sidecar para versionado, enrutamiento canario y encolamiento. KAITO aprovisiona recursos y lanza runtimes optimizados bajo AI Runway, integrándose con KEDA para autoscaling y Gateway API para gestión de tráfico. Los equipos pasan de la selección de modelo a endpoint de producción sin escribir boilerplate de serving de Kubernetes. Royal Bank of Canada ejecuta KAITO en producción, permitiendo que equipos de desarrollo aprovisionen recursos GPU e implementen a través de su pipeline CI/CD con registros privados, Entra ID, Key Vault y ACR privado.

Bare metal reduce flexibilidad de scheduling: fallos de hardware requieren reemplazos más largos, y la lista Dell/HPE limita opciones de ubicación en el lanzamiento. Fleet Manager GA cubre solo clusters Arc; trabajo de múltiples clusters solo en Azure usa mecanismos separados. Anyscale en Azure permanece en vista previa y precios de producción a escala no han sido validados.

Para arquitectos: si la latencia p99 está limitada por sobrecarga del hipervisor o la utilización de NVLink es baja en nodos virtualizados, bare metal ofrece un camino que mantiene el plano de control de Kubernetes. ModelServingRuntime/KAITO reduce la superficie operacional pero agrega una capa de indirección. Valide que el versionado de vLLM y configuraciones de runtime personalizado sigan siendo accesibles antes de reemplazar stacks de serving hechos a mano.