vLLM roda no Vera Rubin NVL72 com throughput por GPU 7,8 vezes maior

O vLLM, o motor de código aberto mais popular para inferência de grandes modelos de linguagem, anunciou suporte ao sistema em rack NVIDIA Vera Rubin NVL72. Segundo o blog do projeto, na carga de trabalho AgentX o throughput por GPU é 7,8 vezes maior que o da geração anterior, o GB200 NVL72. O release inclui suporte a modelos desde o dia 0, kernels do FlashInfer ajustados para a arquitetura Rubin e roteamento de MoE com reconhecimento de localidade.

O número impressiona, mas antes é preciso entender o que exatamente foi medido.

O que foi declarado

A comparação é feita por GPU, e não pelo rack inteiro. As duas plataformas pertencem à classe NVL72: são 72 aceleradores reunidos em um único domínio NVLink. Por isso, a comparação é formalmente justa: rack contra rack, acelerador contra acelerador.

A carga escolhida foi o AgentX. Pelo nome e pelo contexto, trata-se de um cenário de inferência agêntica: contextos longos, muitas chamadas sequenciais ao modelo e uso intenso de cache. O anúncio original não traz detalhes, e essa é a principal lacuna. A configuração dos modelos, a precisão numérica (FP8, FP4 ou mista), o tamanho dos batches e os limites de latência determinam diretamente o quanto o número pode ser transposto para a sua produção.

Principais parâmetros do release:

• Plataforma: NVIDIA Vera Rubin NVL72 contra GB200 NVL72.
• Motor: vLLM com suporte ao Rubin desde o primeiro dia.
• Kernels: FlashInfer, ajustados para o Rubin.
• MoE: distribuição de especialistas com reconhecimento de localidade (locality-aware).
• Métrica: throughput por GPU.
• Resultado: 7,8x na carga AgentX.

De onde vem o ganho

Os autores apontam três componentes. O primeiro é o próprio hardware do Rubin. O anúncio não separa quanto do ganho vem dele e quanto vem do software, e isso importa. Se uma parte significativa do avanço vier de otimizações de kernels e de roteamento, parte desse ganho pode chegar também ao Blackwell com o tempo. Nesse caso, a diferença real entre as gerações seria menor que 7,8x.

O segundo é o FlashInfer. A biblioteca implementa atenção e operações relacionadas, e é da qualidade desses kernels que depende quanto da capacidade teórica do chip se converte em tokens. Kernels escritos para uma arquitetura específica costumam render o ganho mais perceptível em hardware novo.

O terceiro é o MoE com reconhecimento de localidade. Em modelos com mistura de especialistas, os tokens se espalham por GPUs diferentes, e a comunicação entre placas muitas vezes vira gargalo. Se os especialistas são posicionados e roteados de modo que a maior parte do tráfego fique entre vizinhos próximos na topologia, a carga sobre a interconexão diminui. Em cenários agênticos, com sessões longas, essa otimização é especialmente visível.

Onde está a letra miúda

A fonte do número é o blog do próprio vLLM, ou seja, o benchmark foi preparado pelos desenvolvedores do motor, e não por um laboratório independente. Não há dados de latência por token nem de custo por milhão de tokens, e são justamente esses indicadores que definem a economia da operação. O aumento de throughput por GPU não significa necessariamente uma redução proporcional de preço: um rack de nova geração custa mais, consome mais energia e exige refrigeração mais complexa.

Ainda assim, o suporte desde o dia 0 é relevante. Antes, o hardware novo esperava meses por software maduro, e nesse período o desempenho real ficava bem abaixo do declarado. Desta vez, a pilha de software está pronta para a chegada dos racks.

O que as equipes devem fazer

Se você planeja comprar ou alugar Rubin, não coloque os 7,8x no plano de negócios. Peça ao provedor um teste com o seu modelo e o seu perfil de requisições, com os mesmos limites de latência da produção. Compare o custo por token, e não tokens por segundo por placa.

Se você roda em Blackwell, atualize o vLLM e o FlashInfer e meça de novo a sua linha de base: parte das melhorias de software pode valer também ali. Para modelos MoE, verifique separadamente como os especialistas são posicionados na sua topologia. Para as demais equipes, a conclusão útil é mais simples: a pilha de inferência alcança o hardware mais rápido do que antes, e esperar meses de amadurecimento após o lançamento dos chips, ao que tudo indica, já não é necessário.