Lambda prepara o agendador de código aberto Run:ai para seu serviço Kubernetes

Em 13 de outubro de 2026, a Lambda afirmou que está trabalhando com a NVIDIA para oferecer o agendador de GPU de código aberto Run:ai como uma opção gerenciada de primeira classe no Lambda Kubernetes Service (LKS), como parte de uma biblioteca planejada de agendadores disponibilizados como componentes gerenciados.

O plano foi anunciado em uma publicação de 13 de outubro de 2026 no blog da Lambda. “Saudamos a decisão da NVIDIA de disponibilizar o Run:ai como código aberto e estamos trabalhando para torná-lo uma opção de primeira classe no Lambda Kubernetes Service (LKS)”, declarou a empresa. A Lambda afirmou que oferece suporte ao Run:ai em sua infraestrutura desde 2022 e descreveu seu objetivo como facilitar a adoção e a operação dos recursos do Run:ai por meio do LKS, para que as equipes tenham mais controle sobre a alocação e o compartilhamento da capacidade de GPU.

A NVIDIA disponibilizou o agendador como código aberto em 2025

Em 1º de abril de 2025, a NVIDIA anunciou o lançamento como código aberto do KAI Scheduler, uma solução de agendamento de GPU nativa do Kubernetes originalmente desenvolvida na plataforma Run:ai, sob a licença Apache 2.0, de acordo com o anúncio da NVIDIA. A NVIDIA afirmou que o agendador continua sendo empacotado e distribuído como parte da plataforma NVIDIA Run:ai.

Segundo a NVIDIA, o agendador recalcula continuamente os valores de alocação justa e ajusta cotas e limites em tempo real, combinando agendamento em grupo, compartilhamento de GPU e filas hierárquicas. Além disso, um agrupador de pods integrado conecta automaticamente as cargas de trabalho a frameworks como Kubeflow, Ray, Argo e Training Operator. A NVIDIA descreve um ciclo de agendamento que registra uma captura instantânea do cluster Kubernetes, calcula uma parcela justa para cada fila por meio das etapas de cotas devidas e de recursos acima da cota e, em seguida, aplica ações de alocação, consolidação, recuperação e preempção para alinhar as alocações atuais ao estado calculado.

Compartilhamento de GPU e agendamento por cotas no Run:ai

A Lambda descreveu as diferentes demandas que o desenvolvimento de IA impõe às GPUs: sessões de depuração podem precisar de apenas uma parte de uma GPU, avaliações podem se desdobrar em muitos trabalhos independentes, e o treinamento distribuído pode exigir, ao mesmo tempo, um grande número de GPUs estreitamente conectadas. Os requisitos também mudam à medida que o trabalho avança das ideias iniciais para os experimentos e, depois, para a produção. Quando trabalhos pequenos recebem GPUs inteiras, pesquisadores ficam esperando enquanto a capacidade reservada permanece sem uso, e as equipes podem ver seus experimentos parados atrás de GPUs reservadas por outro grupo, mas ociosas.

Conforme descrito pela Lambda, o Run:ai é um agendador de GPU para Kubernetes que vai além do agendador padrão do Kubernetes de duas maneiras: o compartilhamento de GPU, que permite executar mais de uma carga de trabalho em uma única GPU, e o agendamento baseado em cotas, que garante uma alocação para cada equipe e permite que elas tomem emprestada a capacidade ociosa umas das outras.

A documentação sobre frações de GPU da NVIDIA explica que as frações dividem a memória da GPU em partes menores que podem ser compartilhadas por várias cargas de trabalho. O tamanho de memória solicitado por cada carga é imposto, de modo que ela não possa exceder o valor solicitado nem invadir a memória de outra carga. Cada pod recebe seu próprio espaço de endereçamento de memória virtual, uma configuração que a documentação chama de “GPU lógica”.

Por padrão, as frações usam o compartilhamento temporal da NVIDIA para compartilhar a capacidade de processamento da GPU, segundo a documentação. As frações multi-GPU alocam o mesmo tamanho de fração em várias GPUs de um único nó: por exemplo, um modelo que usa 8 GPUs e exige 40 GB de memória por GPU pode receber 8×40 GB, em vez de toda a memória de cada GPU, deixando 40 GB disponíveis em cada GPU para outras cargas de trabalho naquele nó. A documentação observa que as frações de GPU e o modo Multi-Instance GPU (MIG) não podem ser usados no mesmo nó.

A documentação sobre os conceitos do agendador da NVIDIA afirma que cada pod recém-criado é atribuído a um grupo de pods e que o agendamento em grupo significa que uma carga de trabalho composta por vários pods é totalmente agendada ou permanece inteiramente pendente. É criada uma fila de agendamento para cada projeto e departamento em cada conjunto de nós; as cotas devidas limitam quais cargas de trabalho não preemptíveis podem ser executadas, enquanto os recursos acima da cota ficam disponíveis apenas para cargas de trabalho preemptíveis. O agendador calcula um valor de alocação justa para cada projeto e departamento em cada conjunto de nós. Quando uma fila está abaixo de sua alocação justa e outra a excede, o agendador transfere recursos entre as filas para reequilibrá-las, um processo que pode preemptar cargas de trabalho preemptíveis que estejam acima da cota. Ele também pode recuperar recursos entre projetos e departamentos, e os administradores podem definir estratégias de posicionamento por compactação ou distribuição para cada conjunto de nós.

Remediação automática de nós no LKS

A Lambda observou que tanto o compartilhamento quanto a preempção pressupõem que a GPU subjacente esteja funcionando corretamente, algo que não é garantido em grande escala: os aceleradores apresentam erros XID, as conexões NVLink e PCIe se degradam, as linhas de memória são remapeadas e as portas InfiniBand operam abaixo da taxa esperada. Um agendador não consegue distinguir uma GPU saudável de uma que está falhando e, por isso, continua enviando trabalhos para um nó que os descarta.

A Lambda afirmou que a remediação automática já está sendo disponibilizada no LKS. A empresa disse que monitora todos os nós em busca dessas falhas e expõe cada uma delas como uma condição padrão de nó do Kubernetes. Quando uma condição é acionada, o nó é isolado para impedir a entrada de novos trabalhos, os trabalhos em execução são drenados e a falha é corrigida automaticamente ou encaminhada para reparo de hardware. O nó só volta a operar depois de ser validado novamente.

A documentação do Kubernetes gerenciado da Lambda descreve o serviço como um ambiente Kubernetes com suporte a GPUs e InfiniBand (RDMA), além de armazenamento persistente compartilhado entre todos os nós de um 1-Click Cluster. O NVIDIA GPU Operator e o NVIDIA Network Operator vêm pré-instalados, e o serviço executa validações contínuas para verificar se GPUs, rede e armazenamento estão funcionando corretamente, além de remediar automaticamente os nós para detectar e resolver problemas de hardware.

O roteiro da biblioteca de escalonadores gerenciados

A Lambda descreveu o escalonamento de GPUs como a camada que deliberadamente deixa em aberto e afirmou que o próximo passo do LKS é avançar rumo ao que chama de biblioteca de software de IA: escalonadores executados no Kubernetes, entre eles Slurm e Run:ai, fornecidos como componentes gerenciados que a Lambda valida em seu próprio hardware e mantém atualizados, em vez de os clientes montarem manualmente a partir de gráficos Helm. Run:ai é um dos principais alvos dessa biblioteca, e a Lambda afirmou que está trabalhando com a NVIDIA para concretizar essa integração.

Segundo a Lambda, o lançamento de código aberto é o que viabiliza essa abordagem: a empresa pode empacotar, testar e manter o Run:ai dentro do próprio LKS, em vez de entregar aos clientes um conjunto de instruções de integração. A Lambda afirmou que pretende oferecer uma integração pronta para uso, assumindo o empacotamento, a validação e as operações contínuas.

A Lambda, que também produz pesquisas abertas, afirmou que valoriza poder inspecionar, adaptar e aprimorar as ferramentas das quais depende e descreveu a decisão da NVIDIA como uma extensão dessa liberdade à orquestração.