Tempo de leitura: 4 minutos
Olá, é um prazer inenarrável estar mais uma vez escrevendo este post. Configurar um cluster de GPUs para inteligência artificial parece, à primeira vista, uma questão de instalar Kubernetes, drivers e algumas ferramentas. Na prática, porém, dezenas de componentes precisam funcionar em combinações compatíveis — e uma pequena diferença de versão pode transformar um ambiente aparentemente pronto em uma fonte de erros difíceis de rastrear. É nesse cenário que a NVIDIA apresenta o AICR v1.0, uma versão estável do NVIDIA AI Cluster Runtime voltada a tornar essas configurações mais abertas, reproduzíveis e verificáveis.
O projeto não tenta substituir ferramentas como Helm, Argo CD, Flux ou Helmfile. A proposta é organizar as informações sobre a configuração desejada, gerar artefatos para essas ferramentas e verificar se o cluster em execução realmente corresponde ao que foi planejado. Parece uma distinção sutil, mas ela pode evitar que uma instalação bem-sucedida seja confundida com uma implantação realmente validada.
Como o AICR v1.0 organiza a configuração de clusters de GPUs
Clusters acelerados por GPUs dependem da compatibilidade entre componentes que seguem ciclos de lançamento diferentes. Kernel, driver da GPU, runtime de contêineres, Kubernetes, rede, armazenamento, operadores, plugins, escalonadores e frameworks de trabalho podem estar atualizados individualmente e, ainda assim, não funcionar bem em conjunto.
O AICR v1.0 aborda esse problema por meio de receitas com versões fixadas. Cada receita descreve uma combinação de componentes que foi preparada para determinado contexto, como serviço, geração de GPU, sistema operacional, plataforma e tipo de carga de trabalho. Assim, em vez de montar a configuração peça por peça e torcer para que tudo se encaixe, o operador parte de uma combinação documentada e validada.
Segundo a NVIDIA, a cobertura do projeto inclui 11 serviços de Kubernetes, 10 aceleradores das famílias Rubin, Blackwell, Hopper, Ampere e Ada, além de Ubuntu, COS e Oracle Linux. O AICR também contempla ferramentas de implantação como Helm, Helmfile, Argo CD e Flux, além de plataformas de trabalho como Kubeflow e Slurm para treinamento e Dynamo e NIM para inferência.
O que muda com o AICR v1.0
A principal novidade do AICR v1.0 é a definição de um contrato de compatibilidade para suas interfaces públicas. Isso inclui a CLI, a API REST, o SDK em Go, a estrutura dos bundles e os esquemas dos artefatos gerados.
Na prática, essa estabilidade interessa a três grupos. Operadores podem usar os comandos e artefatos com maior previsibilidade. Integradores conseguem desenvolver ferramentas sobre interfaces públicas sem depender de pacotes internos. Já os contribuidores passam a ter regras mais claras para propor receitas, validar ambientes e enviar evidências.
A versão também estabelece baselines de compatibilidade que são verificados antes da integração de mudanças. Pela política anunciada, alterações incompatíveis em uma interface estável exigirão uma nova versão principal. Para quem constrói automações em torno do AICR, essa previsibilidade é tão importante quanto a própria receita técnica.
As quatro funções do AICR v1.0 em um fluxo de implantação
O funcionamento do AICR v1.0 está dividido em quatro capacidades independentes: Snapshot, Recipe, Bundle e Validation. Separá-las ajuda a deixar claro o que o sistema observa, o que pretende configurar e o que efetivamente verifica.
Snapshot registra o estado observado
O Snapshot reúne informações sobre o cluster existente, como versão do Kubernetes, sistema operacional, kernel, GPUs e topologia. Ele representa o que foi encontrado no ambiente, não uma configuração ideal.
Recipe descreve o estado desejado
A Recipe contém a configuração pretendida, incluindo versões dos componentes, restrições e etapas de validação. Ela funciona como uma referência para definir o que o cluster deveria ter.
Bundle transforma a receita em artefatos
O Bundle renderiza a receita para ferramentas de implantação já utilizadas pelas equipes. O mesmo objetivo pode ser preparado para Helm, Argo CD, Flux ou Helmfile, sem que a configuração desejada precise mudar por causa da ferramenta escolhida.
Validation verifica o resultado
A Validation compara a receita com o estado real do cluster. Quando a receita declara essas etapas, também pode executar verificações de implantação, conformidade e desempenho. Os resultados podem ser registrados como evidências assinadas, criando uma trilha mais confiável sobre o que foi testado, onde e com quais resultados.
Por que a validação torna o AICR v1.0 mais útil
Instalar todos os componentes sem receber mensagens de erro não significa que um cluster esteja pronto para uma carga de IA. Ainda é necessário saber se a descoberta de aceleradores funciona, se os operadores estão saudáveis, se recursos como agendamento de grupos foram configurados e se o comportamento observado atende aos critérios definidos.
O painel de validação do AICR permite procurar receitas por serviço, GPU, sistema operacional, intenção da carga de trabalho e plataforma. O operador pode então consultar o status da receita e as evidências publicadas para a configuração de hardware testada. É uma tentativa de transformar conhecimento que normalmente fica espalhado em scripts, sistemas de validação e documentos internos em algo mais fácil de consultar.
O projeto também já possui integrações externas mencionadas pela NVIDIA. A Pulumi Labs disponibiliza um provedor baseado no AICR, enquanto a integração com o k0rdent, da Mirantis, empacota o projeto para cenários de gerenciamento de múltiplos clusters. A ideia em comum é definir a configuração uma vez e consumi-la por ferramentas diferentes.
O que o AICR v1.0 não faz sozinho
Apesar do nome e da abrangência, o AICR v1.0 não substitui as ferramentas que aplicam ou reconciliam configurações no Kubernetes. Ele não transforma automaticamente qualquer cluster em um ambiente compatível nem elimina a necessidade de validação humana.
Um fluxo possível começa com critérios como serviço, GPU, sistema operacional e carga de trabalho. Esses critérios ajudam a encontrar uma receita fixada, que pode ser convertida em um bundle e aplicada pelo processo GitOps existente. Depois, o cluster pode ser comparado novamente com a mesma receita, com evidências produzidas quando os testes correspondentes estiverem disponíveis.
Essa divisão é importante porque evita atribuir ao AICR responsabilidades que pertencem a outras camadas. A ferramenta descreve, gera e verifica; os mecanismos de implantação continuam responsáveis por aplicar ou reconciliar os artefatos.
Por que o AICR v1.0 interessa ao futuro da infraestrutura de IA
À medida que os clusters de GPUs ficam maiores e mais heterogêneos, a configuração deixa de ser apenas uma tarefa operacional. Ela passa a ser também um problema de reproducibilidade, integração e evidência. Uma receita que funciona em uma combinação específica de GPU, sistema operacional e serviço não deveria ser tratada como universal — e o AICR tenta tornar essa diferença explícita.
A NVIDIA afirma que o projeto já reúne mais de 100 contribuidores, quase metade de fora da empresa. A abertura para que outras equipes proponham receitas e enviem evidências assinadas pode ampliar a cobertura para ambientes que os mantenedores não conseguem testar diretamente.
O lançamento do AICR v1.0, anunciado em 6 de outubro de 2026, representa portanto menos uma nova ferramenta isolada e mais uma tentativa de criar um vocabulário comum para configurações de clusters de IA. O valor do projeto dependerá da qualidade das receitas, da transparência das evidências e da adoção por operadores e integradores, mas a direção é clara: configurar um cluster não deveria terminar quando os contêineres sobem; deveria terminar quando o resultado pode ser conferido.
