Compartilhar GPU no Kubernetes exige separar memória, computação e falhas

A NVIDIA detalhou uma integração entre CUDA 13.4, GPU Fractioning Operator e KAI Scheduler para compartilhar GPUs com limites de memória por carga de trabalho.[5] A aplicação passa a enxergar uma fração de memória, e alocações acima do limite podem ser rejeitadas.[5] Para quem opera inferência, a oportunidade é melhorar utilização sem tratar disciplina voluntária de cada processo como mecanismo de controle.

O que muda para quem desenvolve

A proposta permite reserva fixa ou garantia mínima com teto de expansão quando há memória livre.[5] O GPU Fractioning Operator supervisiona MPS nos nós, aplica limites e modos de computação e mede uso por fração, enquanto o scheduler registra a decisão em anotações por contêiner.[5] A integração pronta citada é o modo NvFractions do KAI Scheduler a partir da versão 0.18.0.[5]

A distinção central não é só quanto cada serviço recebe. Em time-slicing, as cargas têm domínios de erro próprios; em sm-sharing, compartilham um domínio de erro durante a execução paralela.[5] O texto recomenda sm-sharing para cargas confiáveis entre si.[5] Minha leitura é que essa escolha precisa aparecer na arquitetura do serviço, e não ficar escondida em uma configuração de infraestrutura.

Limite de memória, disponibilidade e confiança são decisões diferentes. Uma equipe pode aceitar interferência entre seus próprios experimentos e rejeitar a mesma possibilidade entre clientes independentes. O contrato oferecido deve refletir essa diferença.

Como aplicar

Proponha um piloto com dois serviços pequenos e uma carga de estresse controlada. Defina reservas mínimas e tetos explícitos; depois observe o comportamento quando ambos pedem memória ao mesmo tempo. Compare com a alternativa de reservar uma GPU inteira para cada serviço.

Meça utilização, latência, falhas de alocação e recuperação. Programe também o caso em que a expansão não está disponível: o serviço deveria reduzir capacidade, enfileirar ou recusar trabalho? Escolha antes de colocar usuários no caminho.

Na configuração descrita, omitir o limite faz com que ele se iguale ao pedido; em solicitações multigpu, o valor vale para cada dispositivo, não para um total repartido.[5] Revise essas duas condições no desenho do piloto para não testar uma reserva diferente da pretendida.

Cuidados e limites

A publicação diferencia essa abordagem de MIG, que divide a GPU em instâncias isoladas por hardware, e do time-slicing tradicional sem imposição de limites de memória.[5] Não venda os mecanismos como intercambiáveis.

O scheduler também não mistura time-slicing e sm-sharing na mesma GPU, embora dispositivos distintos de um nó possam usar modos diferentes.[5] Essa restrição deve entrar no planejamento de capacidade. O objetivo do experimento não é maximizar ocupação a qualquer custo, mas descobrir quanta eficiência adicional cabe dentro do orçamento de latência e do domínio de falha aceitável.

Fonte

[5] Fonte: NVIDIA Technical Blog