AWS mostra como rodar uma LLM em dois nós de GPU no EKS com o Ray LLM DLC

A AWS publicou um guia passo a passo para rodar uma única large language model em dois nós de GPU do Amazon EKS. Um nó executa o prefill, o outro executa o decode, e por fora tudo parece um único endpoint compatível com a OpenAI. A base são os Deep Learning Containers multi-node do Ray LLM: imagens prontas, com toda a stack de inferência já empacotada. A equipe deixa de montar componentes e fica apenas com a configuração do deploy.

O que exatamente é implantado

O esquema é simples. Há uma modelo, dois nós de GPU em um cluster Amazon EKS e duas etapas distintas de processamento da requisição, distribuídas em máquinas diferentes. A aplicação cliente não sabe nada sobre a topologia. Ela acessa um único endereço pelo protocolo habitual da OpenAI, e os SDKs e as ferramentas existentes continuam funcionando sem alterações.

O principal nesse lançamento não é a ideia em si, mas o empacotamento. Antes, montar uma inferência multi-node significava escolher por conta própria versões compatíveis do engine, do orquestrador, dos drivers e das bibliotecas de rede. Agora a AWS entrega tudo isso como um contêiner pré-montado, da linha Deep Learning Containers. O suporte ao Ray nessa imagem faz sentido: o Ray já é há bastante tempo uma camada de orquestração de cargas distribuídas, e sua extensão para LLMs foi pensada para servir modelos por meio de uma API única.

Por que separar prefill e decode

A geração de texto tem duas fases, com perfis de carga diferentes. O prefill processa todo o prompt de entrada. É computação densa, limitada pelo desempenho da GPU. O decode gera os tokens um a um e costuma ser limitado pela largura de banda da memória e pelo tamanho do KV-cache.

Se as duas fases rodam nos mesmos aceleradores, uma atrapalha a outra. O prompt longo de um usuário atrasa a entrega de tokens para os demais. Separar por nós permite ajustar cada lado individualmente: escolher o paralelismo, o tamanho do batch e o volume de memória de acordo com a tarefa. O custo dessa abordagem é conhecido. É preciso transferir o KV-cache entre os nós, então a rede e a configuração correta do conector importam. É justamente essa parte que o contêiner assume.

Principais parâmetros do esquema

• Modelo: uma única LLM grande, distribuída entre os nós.
• Topologia: dois nós de GPU, um dedicado ao prefill e o outro ao decode.
• Plataforma: Amazon EKS, ou seja, Kubernetes convencional em versão gerenciada.
• Interface: um único endpoint compatível com a OpenAI para todos os clientes.
• Entrega: Deep Learning Container multi-node do Ray LLM, pré-montado, com a stack de inferência completa.
• Abordagem de configuração: configuração do deploy, sem montagem manual de componentes.

Na prática: o que observar antes de adotar

Essa arquitetura não se justifica em todo caso. Para um modelo pequeno, que cabe em um único nó, a desagregação só acrescenta saltos de rede e pontos de falha. Ela faz sentido quando o modelo não cabe na memória de um nó ou quando o perfil de tráfego é muito heterogêneo. Por exemplo, contextos longos na entrada com respostas curtas na saída, ou o contrário.

Antes de um piloto, vale verificar alguns pontos:

• Conectividade entre os nós. A transferência do KV-cache é sensível à latência e à largura de banda, por isso coloque os nós na mesma zona de disponibilidade e consulte a documentação da AWS sobre os tipos de instância e os adaptadores de rede compatíveis.
• Métricas por fase. Acompanhe o tempo até o primeiro token, que depende do prefill, e a velocidade de geração de tokens, que depende do decode. A latência média geral esconde o desequilíbrio.
• Balanceamento dos nós. Um nó para cada fase é um ponto de partida. Se a fila crescer em um dos lados, será preciso escalá-lo de forma independente.
• Compatibilidade dos clientes. A API compatível com a OpenAI facilita a migração, mas o comportamento de parâmetros de requisição pouco usados deve ser testado nos seus próprios cenários.

Para equipes que já usam o EKS e procuram uma forma de servir modelos grandes sem ter uma plataforma própria de inferência, esse é um caminho rápido até um protótipo funcional. Custo e desempenho real precisam ser medidos por cada um com o próprio tráfego: o guia descreve a implantação, mas não garante um ganho específico.