NVIDIA Nemotron 3.5 Super VL: 120 bilhões de parâmetros, 12 bilhões ativos, com implantação na AWS

A NVIDIA lançou o Nemotron 3.5 Super VL, um modelo multimodal, e a equipe da AWS explicou como executá-lo em clusters Kubernetes próprios. O modelo tem 120 bilhões de parâmetros, mas só 12 bilhões trabalham em cada token (pedaço de palavra).

É o esquema mixture-of-experts: dentro da rede há grupos de "especialistas", e um roteador especial escolhe apenas alguns para cada token. O custo de computação fica parecido com o de um modelo pequeno, mas a memória da GPU ainda precisa comportar os 120 bilhões de pesos. O modelo entende texto, imagens, documentos e vídeo, e gera texto como saída.

Ele é aberto: a NVIDIA publica os pesos, os datasets de treinamento e as receitas de ajuste fino. O modelo foi obtido por destilação a partir do Nemotron 3 Ultra, maior, ou seja, foi treinado para reproduzir o comportamento de uma "professora" de grande porte.

Na AWS, a linha Nemotron já conta com Nemotron 3 Nano, Nano Omni, Super, Ultra e Nemotron 3.5 Lightning. O Super VL entra nessa lista.

Arquitetura híbrida e resultados declarados

Por dentro, o modelo alterna três tipos de camada: Mamba-2, atenção convencional (attention) e camadas de especialistas. A visão fica a cargo do encoder RADIO. A vantagem da Mamba-2 é que, durante a geração, ela mantém um estado de tamanho fixo. Na atenção convencional, a memória do KV-cache (que guarda o contexto já lido) cresce junto com o comprimento do texto. Por isso, um contexto de até 1 milhão de tokens sai bem mais barato do que em um transformer puro. O modelo também traz uma cabeça de Multi-Token Prediction, que permite usar decodificação especulativa: o modelo propõe vários tokens à frente de uma vez e depois os verifica.

A NVIDIA apresenta os seguintes resultados (são dados da própria empresa; o material não traz medições independentes):

• 63,44% no Hermes Bench, teste de tarefas de agentes;
• 87,05% nas avaliações de agentes do LangChain, ou seja, em verificações de desempenho no popular framework para agentes;
• 80,8% no CharXiv, conjunto de perguntas sobre gráficos de artigos científicos.

Os cenários de uso declarados são: revisão e depuração de código, conferência de fontes após uma busca na web, leitura de tabelas e diagramas em documentos, análise de vulnerabilidades e ameaças em cibersegurança, e busca e análise de incidentes em vídeo.

Quantas GPUs são necessárias e como é o cluster

As configurações mínimas para o vLLM (servidor de inferência) são estas:

• B200/GB200: 8 GPUs em BF16, 2 GPUs em NVFP4;
• B300/GB300: 4 GPUs em BF16, 1 GPU em NVFP4;
• H200: 8 GPUs em BF16, 4 GPUs em NVFP4;
• H100: 16 GPUs em BF16, 8 GPUs em NVFP4.

NVFP4 é um formato numérico de 4 bits. Ele reduz os pesos em cerca de quatro vezes em relação ao BF16 e, por isso, exige de duas a quatro vezes menos placas. Em H100, o BF16 obriga a usar dois nós de 8 GPUs cada.

A arquitetura de referência da AWS é a seguinte. O plano de controle do Kubernetes (control plane) responde pela API. Os nós de CPU hospedam pods de serviço e de teste, enquanto os nós de GPU executam o modelo.

As imagens de contêiner ficam no Amazon ECR, os pesos são armazenados em um volume compartilhado do Amazon FSx for Lustre, e os nós de GPU se conectam pela rede Elastic Fabric Adapter (EFA). Os manifestos do Kubernetes são os mesmos para as três opções de orquestração: EKS tradicional, EKS Auto Mode (em que a própria AWS gerencia o escalonamento, os drivers de GPU e o EFA) e SageMaker HyperPod EKS. O esquema foi testado em instâncias p6-b200.

48xlarge (8 GPUs B200) e p5en.48xlarge (8 GPUs H200). O passo a passo está no projeto aws-do-eks.

Como planejar a capacidade pelas curvas de latência

O modelo é servido pelo NVIDIA Dynamo, que funciona em dois modos: inteiro em um único nó ou de forma desagregada, com prefill (leitura do prompt) e decode (geração da resposta) em nós diferentes. Para modelos com visão, a codificação de imagens e vídeo também pode ser levada para um nó separado.

Primeiro, o cluster é validado com o microteste NCCL all-reduce. Se, durante o teste, todas as GPUs estiverem carregadas e houver tráfego em todos os adaptadores EFA, a rede está configurada corretamente. Depois, a ferramenta aiperf mede:

• TTFT, o tempo até o primeiro token;
• ITL, a pausa entre tokens;
• TPS, a vazão total em tokens por segundo.

As medições são repetidas com diferentes números de requisições simultâneas (concurrency sweep). A AWS dá um exemplo de planejamento. Definem-se os limites: TTFT de até 600 ms e ITL de até 100 ms por token. Procura-se o ponto mais à direita do gráfico que fique dentro dos dois limites. No exemplo, são 32 requisições simultâneas e cerca de 320 tokens por segundo por réplica, isto é, por par prefill-decode. Dali em diante é só aritmética: divide-se a vazão desejada por esses 320 e obtém-se o número de pares.

Em dois nós, o modo desagregado deu um TTFT menor que o modo combinado, e o ITL ficou quase igual. Se o ITL sobe, é sinal de que falta capacidade de decode; se o TTFT sobe, falta capacidade de prefill.

A conclusão prática para engenheiros: para o modelo quantizado, basta uma única placa B300 moderna, e a escolha entre os modos é melhor feita com base em medições próprias, repetindo o teste após qualquer mudança de precisão, de esquema de paralelismo ou de versão do Dynamo e do vLLM. Os números de qualidade, por ora, são declarados pela própria NVIDIA, e o material em si faz parte da documentação de parceria da AWS. Vale comparar o modelo com os concorrentes nas suas próprias tarefas.