TL;DR: Este artigo analisa o NVIDIA Grove, uma API open-source do Kubernetes que abstrai a complexidade do deployment de inferência de LLMs multi-node. Grove organiza papéis (prefill, decode, router) em hierarquias (PodClique, ScalingGroup, PodCliqueSet), permitindo agendamento em grupo (gang scheduling) e escalabilidade controlada por SLO. Para empresas brasileiras, isso reduz o esforço operacional ao rodar modelos grandes no AKS, garantindo que recursos sejam alocados como unidades funcionais completas.
Qual é a lacuna de orquestração do Kubernetes para inferência distribuída?
Cargas de trabalho modernas de inferência de IA são fundamentalmente diferentes das aplicações distribuídas tradicionais baseadas em microsserviços independentes e stateless. Um deployment de LLM em produção pode incluir papéis distintos – serviços de frontend, roteadores cientes de KV-cache, workers de prefill e decode – que são fortemente acoplados em como devem ser agendados, iniciados e escalados. Eles exigem agendamento em grupos, inicialização em uma ordem específica e escalonamento em proporções que preservem um caminho de atendimento de ponta a ponta. Para modelos maiores, uma única instância de prefill ou decode pode abranger vários pods, onde um deployment completo de cada instância é necessário para uma capacidade funcional de serving.
Os primitivos do Kubernetes podem agendar e executar esses componentes de forma independente, mas não entendem nativamente as relações entre componentes necessárias para que o deployment opere como um serviço de inferência:
- Quais pods formam uma instância de modelo utilizável?
- Quais papéis devem ser iniciados antes de outros?
- Quais componentes escalam independentemente e quais devem escalar como um grupo?
Usando primitivos do Kubernetes isoladamente, as equipes de operações são forçadas a distribuir essas considerações entre manifests, labels, scripts ou controladores personalizados. Isso cria desafios de orquestração e piora a observabilidade do deployment.
O LeaderWorkerSet (LWS) é uma API upstream que resolve parte do problema ao gerenciar um pod líder e seus pods workers como uma unidade replicada, o que geralmente mapeia bem para instâncias de modelo multi-node. No entanto, um deployment completo no estilo Dynamo pode conter múltiplas unidades líder-trabalhador em prefill e decode, além de roteamento e outros componentes de serviço. O LWS pode modelar esses grupos líder-trabalhador, mas não é destinado a descrever o serviço de inferência completo entre eles. Além disso, o LWS acopla unidades de escalonamento multi-node a um padrão líder-trabalhador, e nem todos os casos de uso multi-node se mapeiam claramente para isso. No geral, agendamento, inicialização e escalonamento para tais deployments modernos exigem uma abstração de workload do Kubernetes mais flexível.
O que é o NVIDIA Grove e como ele resolve o problema?
NVIDIA Grove é uma API Kubernetes open-source, disponível como um componente modular do NVIDIA Dynamo, para definir workloads de IA simples (single-node) e complexas (multi-node). Enquanto os recursos padrão do Kubernetes descrevem pods e serviços individuais, o Grove permite descrever todo o sistema de inferência e seus requisitos de orquestração como um único objeto: roteamento, prefill, decode, grupos líder-trabalhador/unidades multi-node, dependências de inicialização e limites de escalonamento – tudo expresso em uma especificação de workload.
A partir dessa especificação, o Grove assume a responsabilidade de coordenar os recursos Kubernetes necessários para executar o serviço. Agendamento, inicialização e escalonamento têm uma visão compartilhada da carga de trabalho: quais pods formam uma instância utilizável e quais papéis pertencem ao mesmo grupo. Ações de escalonamento podem mirar um único papel, uma instância completa de modelo multi-node ou uma réplica completa do serviço. Dependências de inicialização entre papéis fazem parte da definição da carga de trabalho, não de scripts externos.
O resultado é uma API de workload que corresponde a como os sistemas de inferência distribuída são realmente construídos: papéis individuais com diferentes perfis de recursos, instâncias de modelo agrupadas que devem escalar juntas e réplicas completas de serviço que representam capacidade de atendimento utilizável de ponta a ponta.
Em um deployment de inferência, o Dynamo fornece o stack de serving: workers de inferência, roteamento, o Planner, gerenciamento de KV-cache e integrações de backend como vLLM, TensorRT-LLM e SGLang. O Grove define a camada de orquestração do Kubernetes ao redor desse stack, ou seja, o contrato entre o sistema de inferência e o cluster. O Grove também pode ser implantado de forma independente ou integrado a outros frameworks de inferência de alto desempenho.
Como o Grove modela a carga de trabalho?
O modelo do Grove é construído em torno de três primitivos hierárquicos que juntos descrevem a forma completa de um deployment de inferência, desde papéis individuais até o serviço completo:
| Primitivo Grove | O que representa | Exemplo em inferência de modelo |
|---|---|---|
| PodClique | Um grupo de pods com o mesmo papel e template de pod. Possui sua própria contagem de réplicas, necessidades de recursos e política de escalonamento opcional. | Pods de router, workers de prefill, workers de decode, pods de frontend |
| PodCliqueScalingGroup | Um grupo de objetos PodClique que devem escalar juntos enquanto preservam as proporções dos papéis. | Uma instância de prefill multi-node com um líder e quatro workers |
| PodCliqueSet | O objeto de workload de nível superior que descreve o sistema de inferência completo. | Router + grupo de prefill + grupo de decode, com ordem de inicialização e política de escalonamento |
Usando essa hierarquia, o Grove gera os recursos Kubernetes de nível inferior que o cluster precisa para agendar, iniciar e escalar a carga de trabalho. Os usuários trabalham no nível do deployment de inferência, enquanto o Grove traduz a intenção em pods gerenciados pelo Grove e outros recursos, incluindo os recursos PodGang voltados para o scheduler que codificam as restrições de agendamento.
Como o Grove coordena agendamento, inicialização e escalabilidade?
Uma vez que o Grove tem a especificação da carga de trabalho, ele usa a mesma hierarquia para guiar como a carga de trabalho é agendada, iniciada e escalada.
Agendamento
Para inferência multi-node, a capacidade de serving chega como uma coleção de instâncias completas. Uma instância de prefill ou decode que abrange vários pods pode servir tráfego apenas quando o conjunto completo puder executar junto. O gang scheduling dá ao Kubernetes um contrato de tudo-ou-nada: ou todos os pods da instância são agendados juntos, ou nenhum. O Grove cria automaticamente os recursos PodGang voltados para o scheduler a partir da especificação da carga de trabalho, de modo que essa garantia seja parte do modelo de workload, não uma regra que as equipes precisam aplicar separadamente.
O gang scheduling garante que cada componente individual do deployment seja alocado como uma unidade completa – por exemplo, uma instância completa de prefill ou uma instância completa de decode. No entanto, isso por si só não garante que o deployment possa realmente atender requisições de ponta a ponta: o scheduler pode alocar várias instâncias completas de prefill sem qualquer capacidade de decode correspondente, ou vice-versa.
O Grove aborda essa limitação com o hierarchical gang scheduling. Em vez de garantir a completude apenas no nível da instância, o Grove também a garante no nível do serviço. A carga de trabalho especifica restrições de viabilidade de nível superior – por exemplo, que pelo menos uma instância completa de prefill e uma instância completa de decode devem ser agendadas juntas antes que o deployment seja considerado pronto. O scheduler, portanto, trata esses componentes interdependentes como um “gang de nível superior”: ele agenda a combinação necessária apenas quando recursos suficientes estão disponíveis. Isso impede que o sistema aloque configurações individualmente completas, mas funcionalmente inutilizáveis, que não podem processar requisições de ponta a ponta.
Em um cluster AKS, os pods de inferência gerenciados pelo Grove podem ser agendados por um scheduler ciente de gang como o KAI Scheduler, um scheduler open-source nativo do Kubernetes construído para workloads de IA com reconhecimento nativo de PodGang. O Grove define a carga de trabalho de inferência – os papéis, grupos, dependências e limites de escalonamento – enquanto o KAI fornece ao Kubernetes o comportamento de agendamento necessário para colocar esses pods como unidades completas. Juntos, eles permitem que essas capacidades sejam expressas e aplicadas de forma limpa dentro da infraestrutura nativa do Kubernetes.
Nota: Ao implantar workloads Dynamo com Grove e KAI scheduler, recomenda-se configurar o cluster com recursos dedicados para o KAI scheduler, a fim de evitar conflitos de agendamento. Workloads de propósito geral podem continuar usando o kube-scheduler padrão em node pools separados, para que os dois schedulers não compitam pela mesma capacidade de nós.
Inicialização
Agendamento é apenas o primeiro passo. Sistemas de serving distribuídos frequentemente têm dependências de inicialização – por exemplo, workers precisam ser descobertos antes que os líderes iniciem, e roteadores ou frontends podem precisar estar prontos antes que os workers de modelo se registrem. O Grove integra a ordem de inicialização à definição da carga de trabalho através de cliqueStartupType e startsAfter, em vez de deixá-la para scripts ou convenções externas.
Escalabilidade
O Grove possui múltiplos limites de escalonamento em um modelo hierárquico: um PodClique para um único papel, um PodCliqueScalingGroup para uma unidade líder-trabalhador completa e um PodCliqueSet para o serviço completo. Isso preserva o escalonamento independente mesmo quando o agendamento é coordenado: prefill e decode podem ser agendados como unidades viáveis enquanto ainda escalam separadamente em resposta a diferentes gargalos.
Diferentes limites de escalonamento também se integram bem com o Dynamo Planner (abordado na Parte 2 desta série). Enquanto o Planner raciocina sobre o formato do tráfego, comprimentos de sequência e metas de TTFT (time-to-first-token) ou ITL (inter-token latency) para decidir quando a capacidade deve mudar, o Grove garante que essa decisão atinja o limite de workload apropriado do Grove: um PodClique para um único papel, um PodCliqueScalingGroup para uma instância líder-trabalhador completa ou o PodCliqueSet para o serviço de inferência de ponta a ponta. Em última análise, o scale-out orientado pelo Planner não apenas adiciona pods; ele adiciona uma instância de inferência completa, agendada em grupo e pronta para servir.
Como modelar deployments de inferência com o Grove?
A API PodCliqueSet do Grove é flexível o suficiente para cobrir uma variedade de formas de deployment de inferência:
- Serving agregado: onde um único PodClique é suficiente; cada worker lida com o ciclo de vida completo da requisição, e escalar significa adicionar mais cópias desse pod worker.
- Serving desagregado: router, prefill e decode tornam-se PodCliques separados, cada um escalando independentemente em resposta a diferentes pressões de tráfego.
- Multi-node: quando uma única instância de modelo abrange vários pods, um PodCliqueScalingGroup vincula os PodCliques líder e worker em uma unidade de escalonamento.
O repositório GitHub do Grove inclui manifests de referência para esses padrões de deployment, fornecendo às equipes pontos de partida concretos para mapear sua própria arquitetura de serving em PodCliques, PodCliqueScalingGroups e PodCliqueSets.
Veja o Grove em ação abaixo enquanto ele orquestra um deployment multi-node Llama 3.1 70B no AKS. A demonstração serve Llama-3.1-70B-Instruct-FP8 em 16x NVIDIA H100 (2 nós de Azure Standard_ND96isr_H100_v5) com tp=16. O walkthrough mostra um DynamoGraphDeployment sendo traduzido em recursos Grove, pods workers sendo alocados nos nós H100 e o scale-out adicionando um segundo worker de dois pods agendado em grupo como uma unidade agrupada.
[Assista à demonstração do Grove em ação] (vídeo disponível no artigo original)
Perspectivas futuras
Ao introduzir essa camada de workload, o Grove fornece ao Kubernetes um contrato estruturado para orquestrar os requisitos de agendamento em grupo e escalonamento de workloads de IA. Isso também fornece a base para lidar com desafios complexos que as cargas de trabalho modernas de inferência enfrentam hoje.
Um desses desafios é o agendamento ciente de topologia. À medida que os deployments abrangem múltiplos nós e domínios de aceleradores, as decisões de agendamento tornam-se críticas para o desempenho. Sem ciência de topologia, instâncias agendadas em grupo podem ser colocadas em nós fisicamente ou topologicamente distantes, introduzindo gargalos de comunicação que prejudicam a eficiência que o stack de inferência foi projetado para entregar.
Atualizações contínuas (rolling updates) introduzem outra camada de complexidade. Em inferência desagregada, componentes de prefill e decode geralmente têm restrições de compatibilidade entre versões de framework, exigindo que o tráfego entre versões seja bloqueado durante upgrades. Isso pode deixar capacidade ociosa entre versões: por exemplo, um rollout pode deixar oito instâncias de prefill em versão antiga, mas apenas duas instâncias de decode em versão antiga, reduzindo a quantidade de capacidade de ponta a ponta que realmente pode atender requisições. Atualizar esses sistemas com segurança requer um comportamento de rollout que preserve capacidade de serving viável em todo o pipeline, em vez de atualizar cada papel como um pool independente de pods.
Na Parte 5, exploraremos como o modelo de workload do Grove apresentado aqui permite orquestração mais avançada, incluindo agendamento ciente de topologia para inferência distribuída e rolling updates mais seguros para pipelines de serving desagregados. Também compartilharemos como estamos colaborando com as comunidades NVIDIA Grove e Dynamo em direção a um objetivo comum: construir uma camada de orquestração nativa do Kubernetes para as demandas da inferência moderna.
Perguntas Frequentes
-
O que diferencia o NVIDIA Grove do LeaderWorkerSet (LWS)?
Enquanto o LWS gerencia um grupo líder-trabalhador como uma unidade replicada, o Grove vai além: modela todo o serviço de inferência, incluindo múltiplos grupos (prefill, decode, router) e suas dependências. O Grove também oferece agendamento hierárquico em grupo (hierarchical gang scheduling) para garantir que componentes interdependentes sejam alocados juntos, evitando configurações inutilizáveis. -
Como o agendamento hierárquico em grupo evita configurações inutilizáveis?
O agendamento em grupo (gang scheduling) garante que todos os pods de uma instância sejam alocados juntos. O Grove estende isso para o nível do serviço: ele exige que pelo menos uma instância completa de prefill e uma de decode sejam agendadas simultaneamente. Assim, o scheduler não aloca prefill sem decode correspondente, evitando que recursos fiquem alocados sem capacidade funcional de atender requisições. -
O Grove funciona apenas com o Dynamo ou pode ser usado com outros frameworks de inferência?
O Grove foi projetado como um componente modular do NVIDIA Dynamo, mas pode ser utilizado de forma independente ou integrado a outros frameworks de inferência de alto desempenho, conforme mencionado no artigo. Ele define a camada de orquestração do Kubernetes ao redor do stack de serving, sendo compatível com diferentes backends como vLLM, TensorRT-LLM e SGLang. -
Como o Grove lida com atualizações contínuas (rolling updates) em pipelines de inferência?
O artigo indica que rolling updates em pipelines com prefill e decode são desafiadores devido a restrições de compatibilidade entre versões. O Grove ainda não resolve esse problema de forma nativa, mas o artigo adianta que a Parte 5 da série abordará como o modelo de workload do Grove permite implementar rolling updates mais seguros, preservando capacidade de serviço durante a atualização.
Artigo originalmente publicado por Sachi Desai e Ralph Squillace em Azure Updates - Latest from Azure Charts.
