A AWS publicou, em 12 de outubro de 2026, um guia técnico que ensina a implantar um único modelo de linguagem de grande porte (LLM) dividido entre dois nós com GPU no Amazon Elastic Kubernetes Service (Amazon EKS), usando os containers multi-nó do Ray LLM Deep Learning Container. A arquitetura coloca as fases de prefill e de decode em nós separados, mas expõe tudo por trás de um único endpoint compatível com a API da OpenAI, de modo que a aplicação cliente não precisa saber onde cada etapa roda.
Prefill de um lado, decode do outro
A inferência de um LLM tem duas fases com perfis de hardware opostos. O prefill processa o prompt inteiro em paralelo e constrói o cache de chave-valor (KV cache).
O decode gera a resposta token a token, lendo e estendendo esse mesmo cache. O primeiro é limitado por capacidade de computação; o segundo, por largura de banda de memória.
Quando os dois compartilham a mesma GPU, disputam os mesmos recursos: o trabalho pesado e em rajadas do prefill atrapalha o decode, que é constante e sensível a latência.
A chamada desagregação de prefill/decode (PD) resolve isso colocando cada fase em um nó próprio. Assim, cada etapa roda sem interferência da outra e pode ser escalada de forma independente.
O preço dessa separação é que o KV cache produzido no prefill precisa ser entregue ao nó de decode, e essa transferência tem de ser rápida o bastante para não consumir todo o ganho. É exatamente por isso que a interconexão entre os nós se torna o ponto crítico do desenho.
Segundo a AWS, configurações multi-nó como essa são comuns em cargas de paralelismo de tensor, de pipeline e de dados, além de cenários de inferência com desagregação. Entre os casos de uso citados estão a geração aumentada por recuperação (RAG), a sumarização de documentos e as aplicações agênticas — situações em que prompts longos e pesados em computação podem travar a geração de tokens de requisições já em andamento.
O que o container já entrega montado
O Ray LLM DLC chega com a pilha completa de inferência: Ray Serve LLM, a NVIDIA Inference Transfer Library (NIXL) e a pilha do Elastic Fabric Adapter (EFA). Ele já expõe uma API compatível com a OpenAI e dispensa código de aplicação, o que na prática significa configurar o deployment em vez de montar o encadeamento de dependências.
O argumento da AWS repete a lógica que sustenta a família de containers de deep learning da empresa há tempos: imagens Docker pré-construídas e otimizadas para desempenho, que reúnem framework, dependências e pilha de GPU em uma combinação testada e corrigida. Todos os componentes são validados juntos antes de cada release, o que elimina o desalinhamento de versões entre runtime CUDA, framework e camada de serving, um tipo de trabalho que a empresa classifica como indiferenciado e que consome tempo das equipes em vez de acelerar a entrega de modelos.
A base para esse passo foi apresentada em um post anterior, no qual a AWS mostrou o Ray Serve DLC subindo um modelo pequeno atrás de um endpoint HTTP em um único nó com GPU. A novidade agora é o salto para múltiplos nós, necessário quando o modelo não cabe em uma só GPU ou quando uma única réplica não entrega a vazão exigida.
O que muda para quem opera modelos
Na prática, a proposta encurta a distância entre escolher um modelo e ter um endpoint no ar. O Ray é um framework de computação distribuída, e deployments do Ray Serve podem se estender por vários nós; o que a AWS oferece é um caminho testado para essa topologia, sem que o time precise escolher bibliotecas compatíveis nem depurar componentes que saem de sincronia a cada atualização.
O código completo do exemplo está disponível em um repositório de amostras.
O efeito mais concreto é de arquitetura: separar prefill e decode permite escolher hardware e propriedades de serving para cada fase separadamente, o que melhora o desempenho geral na medida em que a operação cresce. Para equipes que servem modelos abertos de maior porte, isso significa tratar a inferência como um problema de infraestrutura configurável, e não como um projeto de engenharia de dependências a cada troca de modelo ou de versão de CUDA.
