Microsoft AKS em Bare Metal Reduz Latência de GPU 12–18% no Build 2026

Microsoft lançou quatro atualizações do AKS no Build 2026: AKS em Bare Metal (visualização pública), Azure Kubernetes Fleet Manager para clusters habilitados para Arc (GA), Anyscale no Azure com Ray gerenciado (visualização pública) e ModelServingRuntime para inferência nativa do Kubernetes. Cada uma visa uma camada diferente de custo de infraestrutura GPU: sobrecarga de hipervisor, operações multi-cluster, gerenciamento de Ray e integração de estrutura de serving.

AKS em Bare Metal remove o hipervisor, dando aos workloads acesso direto a NVLink e RDMA para treinamento distribuído e inferência de baixa latência. Os benchmarks da Microsoft mostraram uma melhoria de 12–18% na taxa de mensagens InfiniBand e menor latência de cauda em nós A100 bare metal versus hosts dedicados do Azure. O plano de controle gerencia tanto nós físicos quanto virtuais, permitindo implantações híbridas. O hardware de lançamento inclui modelos Dell e HPE certificados através do Azure Stack HCI; suporte mais amplo será lançado no final do ano. Sem taxa por cluster.

Fleet Manager GA para clusters habilitados para Arc estende política centralizada, colocação de workload, rollouts em etapas e RBAC em Azure, on-premises e outras nuvens. Para equipes divididas entre regiões ou usando clusters on-premises para residência de dados, essa consolidação importa mais do que qualquer recurso único.

Anyscale no Azure traz Ray gerenciado ao AKS sem operações de cluster independentes. O serviço lida com alocação heterogênea e fracionada de GPU, escalando por job. Ele é executado em subscrições de clientes, integra-se com Entra ID e cobra por vCPU-segundo com um nível gratuito de 200 vCPU-horas durante visualização. Wayve executa isso em produção para veículos autônomos, usando AKS, Ray e Anyscale no Azure para conectar milhares de GPUs. O CEO Alex Kendall descreveu a implantação de um novo veículo Nissan no Japão—"um país onde nunca tínhamos dirigido"—e em quatro meses demonstrando direção autônoma em toda Tóquio. Ele vinculou o marco diretamente à capacidade elástica de GPU do Azure.

ModelServingRuntime expõe vLLM, KServe e runtimes similares como objetos nativos do Kubernetes em vez de stacks separados. Um workload ModelServingRuntime obtém HTTPS automático, autenticação Entra ID, rastreamentos OpenTelemetry e um sidecar para versionamento, roteamento canário e enfileiramento. KAITO provisiona recursos e lança runtimes otimizados sob AI Runway, integrando-se com KEDA para autoscaling e Gateway API para gerenciamento de tráfego. As equipes passam da seleção de modelo para endpoint de produção sem escrever boilerplate de serving do Kubernetes. Royal Bank of Canada executa KAITO em produção, permitindo que equipes de desenvolvimento provisionem recursos GPU e façam deploy através de seu pipeline CI/CD com registros privados, Entra ID, Key Vault e ACR privado.

Bare metal reduz flexibilidade de scheduling: falhas de hardware exigem substituições mais longas e a lista Dell/HPE limita opções de colocação no lançamento. Fleet Manager GA cobre apenas clusters Arc; trabalho multi-cluster apenas em Azure usa mecanismos separados. Anyscale no Azure permanece em visualização e preços de produção em escala não foram validados.

Para arquitetos: se a latência p99 está estrangulada pela sobrecarga do hipervisor ou utilização de NVLink é baixa em nós virtualizados, bare metal oferece um caminho que mantém o plano de controle do Kubernetes. ModelServingRuntime/KAITO reduz a superfície operacional mas adiciona uma camada de indireção. Valide que versionamento de vLLM e configs de runtime customizados permaneçam alcançáveis antes de substituir stacks de serving feitos à mão.