Para começar a executar o NVIDIA Nemotron 3.5 Super VL na AWS com o caminho de EKS padrão, você precisa de acesso a instâncias P5en.48xlarge ou P6-b200.48xlarge, Git e Docker no terminal e credenciais com permissões para EC2, EKS e FSx for Lustre. A AWS também lista EKS Auto Mode e SageMaker HyperPod EKS como opções de orquestração. O exemplo oficial da AWS descreve os pré-requisitos e a sequência inicial; a visão geral técnica da AWS apresenta a arquitetura e os resultados de desempenho.

O modelo tem 120 bilhões de parâmetros no total, com 12 bilhões ativos por token. Ele recebe texto, imagens, documentos e vídeos, e gera texto, segundo a NVIDIA e a AWS.

O que preparar antes de criar o cluster

Para seguir o exemplo da AWS, confira estes requisitos:

  • Uma conta AWS com acesso às instâncias EC2 P5en.48xlarge ou P6-b200.48xlarge. Pode ser necessário solicitar aumento de cota e obter uma reserva de capacidade.
  • Git e Docker instalados em um terminal.
  • Credenciais AWS com permissão para administrar EC2, EKS e FSx for Lustre.

Essas condições são as do exemplo de implantação da AWS. O acesso às instâncias é um pré-requisito para iniciar essa rota com GPUs.

Primeiros passos com EKS padrão

A sequência abaixo cobre a criação inicial do cluster no exemplo aws-do-eks. A AWS informa que essa etapa de criação pode levar até 30 minutos.

  1. Clone o repositório. No terminal, execute git clone https://github.com/aws-samples/aws-do-eks para obter o projeto usado pelo exemplo.
  2. Entre na pasta do projeto. Execute cd aws-do-eks para acessar os scripts de configuração.
  3. Defina a região. Execute ./config.sh e ajuste AWS_DEFAULT_REGION no arquivo .env para a região escolhida para o cluster.
  4. Construa a imagem auxiliar. Execute ./build.sh. O comando cria uma imagem Docker local com ferramentas e scripts para criar e administrar o cluster.
  5. Inicie o contêiner. Execute ./run.sh para iniciar o ambiente auxiliar.
  6. Confira o estado do contêiner. Execute ./status.sh; o exemplo espera que ele esteja em execução.
  7. Abra o shell do contêiner. Execute ./exec.sh para acessar ferramentas como AWS CLI, eksctl e kubectl.
  8. Configure as credenciais AWS. No shell, execute aws configure e informe as credenciais, a região e o formato de saída json.
  9. Selecione o manifesto do cluster. Execute ./env-config.sh para configurar o manifesto usado na criação.
  10. Ajuste as configurações. Execute ./eks-config.sh para editar itens como nome do cluster, região, tipos de instância, tamanho dos volumes e reserva de capacidade.
  11. Crie o cluster. Execute ./eks-create.sh. No caminho padrão descrito pela AWS, o script chama eksctl create cluster com o manifesto configurado.
  12. Confira os nós. Quando a criação terminar, execute kubectl get nodes para listar os nós do cluster.

A AWS apresenta depois outras etapas, como instalar drivers e operadores, validar o cluster, baixar os pesos do modelo, implantar e testar o serviço e remover os recursos criados. A sequência acima termina na conferência dos nós.

Opções de implantação e mínimos de GPU

A AWS lista três opções de orquestração: Amazon EKS padrão, Amazon EKS Auto Mode e SageMaker HyperPod EKS. Segundo a AWS, o Auto Mode administra o escalonamento e oferece suporte a GPU e EFA, o Elastic Fabric Adapter usado na comunicação entre nós. Os manifestos Kubernetes do modelo são usados nas três opções.

O exemplo também oferece armazenamento EBS com FSx ou FSx sozinho, precisão BF16 ou NVFP4 e serving agregado ou desagregado. No modo desagregado, codificação, prefill e decodificação podem ser distribuídos. A arquitetura de serving citada combina NVIDIA Dynamo e vLLM.

Para vLLM, a AWS apresenta estes mínimos de GPUs por acelerador e precisão:

Modelo de GPUMínimo em BF16Mínimo em NVFP4
B200/GB20082
B300/GB30041
H20084
H100168

Esses números são mínimos de GPUs para servir o modelo com vLLM. Eles não descrevem, por si só, toda a configuração do cluster, que também envolve nós, armazenamento e rede. Já o exemplo de EKS citado acima exige acesso a P5en.48xlarge ou P6-b200.48xlarge.

Como interpretar o teste de latência da AWS

A AWS relatou menor TTFT, ou tempo até o primeiro token, e ITL, o intervalo entre tokens, parecido em um teste com serving desagregado de dois nós em comparação com o agregado. As condições do gráfico são importantes: ele identifica Nemotron 3.5 Super VL 120B-A12B em BF16 com H200, entrada de 1.024 tokens, saída de 512 tokens, concorrência de 1 a 128 e um lançamento por ponto. A configuração agregada usou 8 GPUs; a desagregada, 16.

Assim, o resultado relatado pela AWS não compara as duas topologias com o mesmo número de GPUs. Ele descreve aquelas configurações e cargas de trabalho específicas, sem separar o efeito da topologia dos recursos usados.

Validar o cluster e medir o modelo

A AWS descreve o teste all-reduce do NCCL como uma validação de cluster e rede. Acompanhar atividade nas GPUs e nos adaptadores EFA durante esse teste indica que esses componentes estão operando como esperado. Para medir a inferência, a AWS usa o NVIDIA aiperf, que permite observar TTFT, ITL e throughput em diferentes níveis de concorrência.

O exemplo da AWS também verifica a saúde do serviço com ./models-health.sh, que consulta o endpoint /health. Para benchmarking, ./test-aiperf.sh executa medições contra o serviço implantado. Separar as duas verificações ajuda a identificar se o problema está na operação do cluster ou no desempenho da inferência.