Dividir uma GPU entre várias tarefas de inteligência artificial sempre fez sentido no papel, porque nem todo programa precisa de uma placa inteira. O problema começa quando essas tarefas passam a dividir a mesma máquina. Basta uma delas pedir memória demais para espremer as vizinhas. Nesta terça-feira (27), a NVIDIA (abre em nova aba) explicou em seu blog técnico (abre em nova aba) como pretende resolver isso no Kubernetes (abre em nova aba). A novidade central é que o limite de memória agora é aplicado pelo próprio CUDA. O programa não precisa colaborar e nem sequer sabe que está rodando numa fatia da placa.
Parece um ajuste de bastidor, mas não é. É a diferença entre uma regra de convivência e uma parede.
O que mudou
Dois nomes ajudam a entender a notícia. O CUDA é a camada de software que permite aos programas usar as GPUs da NVIDIA. O Kubernetes é o sistema que distribui programas pelas máquinas de um data center e decide o que roda onde.
A versão 13.4 do CUDA saiu em setembro (abre em nova aba) com novidades vistosas, como suporte a Windows em chips Arm e uma prévia da arquitetura Rubin. Para quem administra GPUs, porém, o item mais importante estava no meio da lista: a terceira versão do MPS, o serviço que permite a vários processos usar a mesma placa ao mesmo tempo. Ele ganhou limites de memória integrados aos cgroups, o mecanismo do Linux que define quanto de cada recurso um programa pode consumir.
Os limites antigos funcionavam no nível dos aplicativos. Segundo a documentação da NVIDIA, o novo sistema contabiliza toda a memória da placa e se apoia diretamente no kernel do Linux. O objetivo declarado é impedir que um único cliente monopolize a GPU e permitir que o Kubernetes encaixe as tarefas pela memória que cada uma precisa. Cada tarefa enxerga só a sua fração, como se a placa fosse menor do que realmente é.
Duas formas de pedir espaço
Quem dispara uma tarefa pode escolher entre dois tipos de pedido:
- Quantidade exata: a tarefa pede um tamanho de memória e o CUDA a mantém nesse limite. Qualquer tentativa de ir além falha com erro de falta de memória.
- Faixa: a tarefa recebe um mínimo garantido e pode crescer até um teto quando há memória sobrando. Ao passar do mínimo, ela vira candidata a ser expulsa, mas só é encerrada de fato quando a memória realmente aperta.
A faixa é a parte mais interessante, porque permite aproveitar sobras sem reservar a placa inteira "por via das dúvidas". Como veremos adiante, também é a parte que ainda não está pronta.
Para levar isso ao Kubernetes, a NVIDIA usa duas peças de código aberto. O GPU Fractioning Operator roda ao lado do GPU Operator da empresa. O KAI Scheduler decide em qual placa cada tarefa vai parar. Desde a versão 0.18.0, ele tem um modo de compartilhamento chamado NvFractions, que se ativa com uma única linha de configuração. Pedidos com várias placas funcionam como o bom senso manda: 40 GiB em quatro GPUs significam 40 GiB em cada uma delas.
Revezar ou dividir
O usuário também escolhe um modo de uso, que dá para resumir como revezar ou dividir. No revezamento (time-slicing), o modo padrão, as tarefas se alternam na placa, uma por vez, e cada uma fica isolada: se uma quebra, as outras seguem funcionando. A estreia do CUDA 13.4 está justamente aqui, porque o limite de memória passa a valer também nesse modo. No sm-sharing, que já existia no MPS, as tarefas rodam em paralelo e dividem as unidades de processamento da placa. Em troca, compartilham o mesmo "domínio de erro", e um problema grave em uma pode respingar nas outras. Por isso o KAI Scheduler nunca coloca uma tarefa de cada modo na mesma GPU.
O asterisco
Seria fácil tratar o assunto como resolvido, mas a própria NVIDIA não faz isso. A documentação do Run:ai, plataforma de gestão de GPUs da empresa que também adota essas frações dinâmicas, lista duas limitações conhecidas do CUDA 13.4 com o driver r615:
- a memória é recuperada de uma tarefa por vez;
- em alguns cenários, uma tarefa que pede memória dentro do seu mínimo garantido pode ser encerrada à força (SIGKILL).
As duas têm correção prometida para uma versão futura. Não por acaso, o recurso vem desligado por padrão no Run:ai.
O segundo ponto não é detalhe. A graça de um mínimo garantido é ser garantido. Enquanto uma tarefa bem-comportada puder cair, a faixa flexível serve para testes em ambiente controlado, e não para o serviço mais importante da empresa. Por ora, a quantidade exata, com sua parede firme, parece a aposta mais prudente.
A lista de pré-requisitos também limita quem pode adotar o recurso agora:
- Linux com cgroup v2;
- kernel 6.14 ou mais novo para o controlador de memória principal (versões anteriores contam com um mecanismo alternativo);
- driver r615 ou mais recente;
- GPU Operator 26.7.1 ou superior, que não vem com esse driver por padrão;
- placas fora do modo MIG, outra forma de fatiar GPUs que a NVIDIA declara explicitamente sem suporte.
Mesmo com o asterisco, a direção parece a certa. Com a memória controlada de verdade, a pergunta de quem administra GPUs deixa de ser "cabe mais uma tarefa nesta placa?" e passa a ser "quanto cada uma realmente precisa?". O tema deve ganhar palco na KubeCon norte-americana, de 9 a 12 de novembro, em Salt Lake City, evento citado pela NVIDIA no anúncio. Até lá, a correção prometida merece tanta atenção quanto a novidade em si.