HAMi é incubado na CNCF e impulsiona compartilhamento de GPUs no Kubernetes

A alocação e o compartilhamento de GPUs em Kubernetes sempre foram um desafio técnico. Historicamente, a API de device plugin do Kubernetes contava dispositivos apenas como inteiros, sem granularidade para fatiamento de recursos como memória ou cores da GPU. Isso forçou projetos como o HAMi a desenvolverem suas próprias arquiteturas, com webhooks mutantes e extensores de agendamento, para traduzir requisições de pods em alocações reais, usando anotações customizadas para registrar decisões de agendamento e aplicar limites via bibliotecas no runtime do contêiner.

Com a chegada do Dynamic Resource Allocation (DRA) no Kubernetes, especialmente com a funcionalidade de consumable capacity a partir do v1.36 (beta por padrão), o cenário muda. O DRA introduz um modelo de claims (reivindicações) similar ao de PersistentVolumeClaims (PVCs), permitindo que o Kubernetes entenda e agende fatias de recursos de GPU nativamente. Isso significa que requisições como "8.000 MiB de memória e 10% de cores de GPU" podem ser expressas diretamente e compreendidas pelo agendador do Kubernetes, eliminando a necessidade de grande parte da lógica de agendamento personalizada do HAMi. No entanto, o DRA foca no agendamento e não na imposição dos limites em runtime. É aí que a camada de enforcement do HAMi, via libvgpu.so, continua crucial, garantindo que um contêiner não exceda sua cota, mesmo que o hardware físico ainda tenha recursos.

A cobertura anterior do CEVIU News, em 17 de julho de 2026, já destacava a promoção do HAMi a projeto de incubação da CNCF, um marco para a virtualização de GPU no Kubernetes. Agora, a grande mudança é a adaptação do HAMi ao Dynamic Resource Allocation (DRA) do Kubernetes. O que antes era uma solução de contorno para o agendamento de recursos fracionados de GPU (com webhooks e extensores de agendamento próprios), agora converge para uma integração mais nativa com o Kubernetes.

O HAMi se divide em componentes específicos: o k8s-dra-driver publica a capacidade das GPUs como recursos consumíveis para o DRA, e o HAMi-DRA, um webhook de admissão, traduz as antigas requisições de recursos estendidos em claims nativos do DRA. Essa evolução realinha o HAMi com o core do Kubernetes, mantendo sua camada única de enforcement de runtime via HAMi-core. O que era uma abordagem quase "forkada" do agendamento, agora se torna um complemento ao mecanismo padrão do Kubernetes, entregando uma promessa que o DRA por si só não cumpriria: a garantia de limites de recursos em tempo de execução.

Para engenheiros de plataforma e times de DevOps, a evolução do HAMi e sua integração com o DRA do Kubernetes representam um salto na eficiência e na gestão de custos em cargas de trabalho intensivas em GPU. Conforme já destacamos na cobertura de 27 de março de 2026, sobre a construção de um padrão nativo de Kubernetes para IA, e na notícia de 4 de abril de 2026 sobre o llm-d da CNCF, a capacidade de escalar IA no Kubernetes depende da infraestrutura subjacente.

A união HAMi-DRA permite o compartilhamento granular de GPUs, o que otimiza a utilização de hardware caríssimo e reduz custos operacionais. Isso é especialmente relevante em cenários de Machine Learning (ML) e IA, onde a demanda por GPUs é alta e o subaproveitamento é um problema. Times agora podem oferecer um provisionamento mais flexível e robusto de GPUs, garantindo que os recursos sejam alocados de forma justa e que os limites sejam impostos em runtime, prevenindo a "fome de recursos" e promovendo um uso mais estável do cluster.