Estreia da NVIDIA Vera Rubin no MLPerf define o ritmo, mas o status de prévia importa

A NVIDIA entrou no MLPerf Inference v6.1 com o Vera Rubin NVL72, reportando throughput de até 3,7 vezes o de seu antecessor, o GB300 NVL72. A estreia da NVIDIA Vera Rubin no MLPerf oferece aos compradores de infraestrutura a primeira visão revisada por pares da próxima plataforma de IA em escala de rack da empresa. Ela também acrescenta uma limitação importante à manchete: o Vera Rubin continua sendo um sistema em prévia.

Essa distinção define a verdadeira disputa. A NVIDIA não está simplesmente comparando uma geração de GPU com outra. Ela defende que racks altamente integrados podem transformar novo silício, redes e software de serving em uma economia de inferência melhor.

A submissão mais ampla da AMD ao MLPerf até hoje mostra por que esse argumento agora enfrenta pressão. A AMD publicou resultados competitivos em hardware disponível, ampliou a cobertura de workloads e destacou implantações que chegam a 512 aceleradores. A NVIDIA lidera as comparações selecionadas do Vera Rubin, mas os clientes precisam decidir se a liderança de uma prévia se traduz em valor implantável.

Resultados da NVIDIA Vera Rubin no MLPerf estabelecem uma liderança inicial

A estreia estabelece um grande ganho de desempenho geracional em dois modelos exigentes, embora ainda não represente uma plataforma de produção comercializada.

Os resultados foram divulgados em 16 de setembro de 2026, como parte do lançamento do MLPerf v6.1. O MLPerf Inference mede como sistemas atendem modelos de IA treinados sob condições padronizadas de precisão e latência.

A MLCommons reportou um recorde de 30 organizações participantes nesta rodada. Cinco novos processadores ou aceleradores apareceram, incluindo o MI350P disponível da AMD e o Arc Pro B70 da Intel. NVIDIA Rubin e Vera Rubin NVL72 entraram como prévias.

A NVIDIA submeteu resultados do Vera Rubin para DeepSeek-R1 e Qwen3-VL-235B. O DeepSeek-R1 testa o serving de modelos de raciocínio, enquanto o Qwen3-VL combina entradas de linguagem e visuais para tarefas como classificação de produtos.

Os resultados do Vera Rubin da empresa mostram o maior ganho relativo no cenário interativo do Qwen3-VL. Nele, um Vera Rubin NVL72 entregou 1.307 consultas por segundo. Um resultado comparável do GB300 NVL72 alcançou 349 consultas por segundo.

Isso produz o aumento de manchete de aproximadamente 3,7 vezes. O cenário interativo também impõe um limite de latência de 1,5 segundo, tornando o resultado mais relevante para aplicações responsivas do que throughput em lote sem restrições.

A vantagem foi menor, mas ainda substancial, em outros cenários do Qwen3-VL. O Vera Rubin atingiu 2.393 amostras por segundo offline, em comparação com 1.305 para o GB300. Seu resultado de servidor atingiu 2.323 consultas por segundo, contra 1.210.

Esses resultados equivalem a cerca de 1,8 vezes mais throughput offline e 1,9 vezes mais throughput de servidor. A diferença mostra por que um único multiplicador máximo não pode descrever todo o sistema.

No DeepSeek-R1, o Vera Rubin registrou 652.750 tokens por segundo no cenário interativo. Um resultado do GB300 NVL72 com 72 GPUs atingiu 260.098 tokens por segundo sob as mesmas restrições de latência publicadas.

Essa comparação sustenta a afirmação da NVIDIA de throughput do DeepSeek-R1 até 2,5 vezes maior. A NVIDIA usou TensorRT-LLM para esse workload, enquanto sua submissão do Qwen3-VL utilizou vLLM com NVIDIA Dynamo.

A tabela de desempenho publicada também apresenta limites de precisão ao lado de cada resultado. A entrada do Vera Rubin para DeepSeek-R1 tem como meta 99 por cento da precisão FP16, com uma pontuação de correspondência exata de 81,9132 por cento.

Para o Qwen3-VL, a meta foi 99 por cento da qualidade BF16. O benchmark exigia uma pontuação F1 hierárquica por categoria de pelo menos 0,7824 usando um conjunto de dados do catálogo de produtos da Shopify.

Essas barreiras importam porque uma inferência mais rápida tem valor limitado se uma compressão numérica agressiva prejudica a saída do modelo. O MLPerf exige que as submissões atendam a limites de qualidade definidos antes que seus números de desempenho sejam contabilizados.

Ainda assim, a estreia cobre apenas dois modelos de benchmark. Ela não estabelece liderança em todos os workloads de linguagem, recomendação, vídeo, fala ou recuperação no MLPerf Inference v6.1.

Esse escopo mais restrito não é incomum para hardware em prévia. Mas significa que os compradores devem interpretar o resultado como um sinal inicial do sistema, não como um veredito universal.

Por que mais throughput muda a economia da inferência de IA

O desempenho de inferência importa financeiramente quando um throughput adicional atende mais solicitações úteis sem aumentar proporcionalmente hardware, energia ou complexidade operacional.

O treinamento produz um modelo, mas a inferência é executada sempre que esse modelo responde a um usuário. Um assistente para consumidores, agente de programação, serviço de busca ou sistema de documentos pode acionar muitas chamadas de inferência durante uma única tarefa.

Agentes de raciocínio intensificam esse padrão. Eles geram tokens intermediários, chamam ferramentas, analisam resultados e revisam seus planos. Uma resposta visível pode exigir várias passagens pelo modelo por trás da interface.

Esse comportamento torna os tokens por segundo economicamente importantes. Um sistema mais rápido pode atender mais solicitações simultâneas, reduzir filas ou fornecer rastros de raciocínio mais longos na mesma janela de tempo.

No entanto, o throughput máximo é apenas uma parte do cálculo. Os compradores também precisam de latência de resposta aceitável, precisão consistente, alta utilização, demanda de energia gerenciável e software confiável.

O MLPerf separa vários cenários de implantação por esse motivo. O cenário offline enfatiza o processamento em massa. O cenário de servidor modela solicitações recebidas variáveis, enquanto o cenário interativo impõe requisitos de responsividade mais rigorosos.

O desempenho relativo mais forte do Vera Rubin aparece nesse contexto interativo sensível à latência. Isso sugere que suas melhorias arquiteturais se tornam especialmente valiosas quando um sistema não pode ocultar atrasos por trás de grandes lotes.

O resultado importa para produtos que cobram por acesso, consumo ou trabalho concluído. Se um rack processa mais solicitações em um nível de serviço exigido, o operador obtém mais capacidade dessa infraestrutura.

Ainda assim, throughput não equivale automaticamente a receita. A demanda precisa existir, o software precisa manter os aceleradores ocupados e o serviço completo deve evitar gargalos fora do servidor de modelos.

Armazenamento, estruturas de rede, bancos de dados, filtros de segurança e lógica de aplicação podem limitar o desempenho entregue. Um benchmark isola o sistema sob teste de forma mais limpa do que a maioria dos ambientes de produção consegue.

O custo por token também é mais complexo do que dividir o custo do equipamento pelo throughput de pico. Ele inclui eletricidade, refrigeração, redes, manutenção, financiamento, engenharia de software, indisponibilidade e depreciação.

A NVIDIA diz que o Vera Rubin reduz os custos por token, mas a versão v6.1 não publica uma comparação completa de custo total de propriedade em produção. O benchmark oferece evidências de desempenho, não um modelo completo de compra.

Portanto, as equipes de infraestrutura devem traduzir esses resultados para seus próprios perfis de tráfego. Um serviço visual de busca de produtos pode valorizar o throughput de servidor do Qwen3-VL. Uma plataforma de raciocínio pode priorizar a latência e a geração de tokens do DeepSeek-R1.

O resultado se torna mais valioso quando o benchmark se assemelha ao workload do comprador. Torna-se menos decisivo quando a arquitetura do modelo, o tamanho das solicitações, o comportamento de batching ou as restrições de serviço diferem substancialmente.

Essa é a pressão econômica que os concorrentes da NVIDIA enfrentam. Eles não precisam vencer todos os gráficos, mas precisam oferecer desempenho implantável, maturidade de software e flexibilidade suficientes para gerar um caso de negócio geral melhor.

Codesign em escala de rack é o mecanismo de desempenho

A vantagem do Vera Rubin vem de tratar 72 GPUs, CPUs, memória, rede e software de inferência como um único sistema coordenado.

Um rack NVL72 conecta 72 aceleradores dentro de um domínio de scale-up de alta largura de banda. Redes de scale-up permitem que esses aceleradores cooperem como partes de um grande sistema, em vez de se comportarem como servidores isolados.

A NVIDIA afirma que o NVLink de sexta geração e o NVLink Switch oferecem taxas de pacotes 10 vezes maiores do que a Ethernet padrão. A empresa também alega latência três vezes menor na comparação relevante.

Essas alegações sobre interconexão vêm da NVIDIA e não devem ser tratadas como benchmarks de rede independentes. Ainda assim, elas explicam a escolha de design por trás do sistema submetido.

Grandes modelos de raciocínio e de visão-linguagem movimentam quantidades substanciais de dados durante a inferência. Pesos do modelo, ativações, estados de atenção e decisões de roteamento precisam chegar rapidamente aos recursos de computação corretos.

O Vera Rubin usa HBM4, uma geração de memória de alta largura de banda posicionada próxima à GPU. A configuração de rack da NVIDIA inclui 72 GPUs Rubin e 36 CPUs Vera, segundo sua arquitetura publicada.

O software então divide o trabalho entre esses recursos. O serving desagregado separa prefill de decode, permitindo que diferentes recursos se especializem em fases distintas da geração de texto.

O prefill processa a entrada do usuário e constrói o estado interno de atenção do modelo. O decode gera a resposta token a token, frequentemente sob diferentes restrições de memória e latência.

Separar essas fases pode melhorar a utilização quando o software atribui cada uma a recursos adequados. Também pode criar sobrecarga de coordenação, portanto interconexões rápidas e agendamento eficaz se tornam críticos.

As submissões da NVIDIA usaram paralelismo de especialistas em larga escala para modelos mixture-of-experts. Esse design de modelo ativa apenas camadas especializadas selecionadas para cada token, em vez de executar toda a rede a cada vez.

A abordagem pode reduzir a computação, mas cria comunicação irregular. Os tokens precisam ser roteados aos especialistas corretos, processados e devolvidos sem que atrasos na rede consumam os ganhos.

A aritmética de menor precisão constitui outra parte do mecanismo. A NVIDIA usou NVFP4, um formato numérico de quatro bits destinado a reduzir o uso de memória e aumentar o throughput computacional.

O sistema aplicou precisão reduzida a pesos, operações de atenção e ao cache de chave-valor. Um cache de chave-valor armazena informações de atenção anteriores para que o modelo não recompute toda a conversa a cada novo token.

Menor precisão permite que mais dados caibam na memória e reduz a movimentação entre unidades de computação. Os limites de precisão no MLPerf oferecem uma salvaguarda contra perda de qualidade inaceitável.

A cifra final de desempenho, portanto, não é uma medição pura do silício Rubin. Ela reflete processadores, memória, rede, formatos numéricos, kernels, frameworks de serving e ajustes específicos do benchmark.

Isso é central para a estratégia da NVIDIA. A empresa quer que os clientes avaliem toda a plataforma porque sua vantagem competitiva vai além das especificações de aceleradores individuais.

A estratégia pode criar benefícios para operadores que buscam uma pilha única com suporte. Ela também pode aumentar a dependência do ambiente de hardware e software estreitamente conectado da NVIDIA.

Para os compradores, essa dependência não é automaticamente negativa. Uma plataforma coordenada pode reduzir o trabalho de integração e produzir desempenho previsível em sistemas qualificados.

A contrapartida surge quando os clientes desejam maior escolha de hardware, software portátil ou controle independente sobre componentes individuais. É aí que a abordagem concorrente da AMD se torna relevante.

AMD pressiona a narrativa de plataforma com hardware disponível

O desempenho da AMD na v6.1 não elimina as vantagens selecionadas do Vera Rubin, mas impede que a NVIDIA domine sem contestação a narrativa mais ampla da inferência.

A AMD passou de três famílias de modelos no MLPerf Inference v6.0 para seis na v6.1. Seus resultados abrangeram cargas de trabalho de linguagem, raciocínio, recomendação e texto para vídeo nos aceleradores MI355X, MI350X e MI350P.

A submissão da AMD ao MLPerf destaca desempenho competitivo com oito GPUs no GPT-OSS-120B. A AMD afirma que o MI355X superou entradas selecionadas do NVIDIA B200 e B300 em cenários offline e de servidor.

A empresa também relatou ganhos provenientes de trabalho de software em hardware MI355X inalterado. A taxa de transferência em servidor do GPT-OSS-120B com oito GPUs melhorou 38 por cento em relação à rodada anterior.

A taxa de transferência offline aumentou 28 por cento, enquanto o desempenho single-stream do Wan 2.2 melhorou 70 por cento. Essas são comparações da AMD entre seus resultados submetidos nas versões v6.1 e v6.0.

O mesmo padrão reforça um dos principais argumentos da NVIDIA. O hardware, por si só, não determina o valor ao longo da vida útil de um sistema de inferência. Melhorias de software podem liberar mais trabalho útil após a implantação.

A AMD alcançou 95 por cento de eficiência de escalonamento com 72 GPUs MI355X no GPT-OSS-120B. A eficiência de escalonamento mede o quanto o crescimento da taxa de transferência acompanha a adição de aceleradores.

A Crusoe então submeteu um sistema AMD com 512 GPUs. Ele produziu 5,75 milhões de tokens offline por segundo no GPT-OSS-120B e 2,90 milhões no DeepSeek-R1, segundo a AMD.

Esse foi o maior número de aceleradores submetido ao MLPerf Inference até então. Também ilustra uma rota concorrente para escalar, baseada em grandes clusters e um ambiente de software aberto.

A comparação com Vera Rubin não é direta. Diferentes submissões podem usar modelos, tamanhos de sistema, cenários e otimizações aprovadas distintos.

Um resultado agregado de 512 aceleradores não comprova uma economia por rack melhor do que a de um sistema Vera Rubin com 72 GPUs. Da mesma forma, a liderança de Vera Rubin no Qwen3-VL não resolve a competitividade da AMD no GPT-OSS-120B.

Esse é um desafio comum ao interpretar o MLPerf. Cada fornecedor pode enfatizar as cargas de trabalho, os cenários e os tamanhos de sistema que apresentam seu caso mais favorável.

A MLCommons reduz essa liberdade por meio de regras padronizadas, critérios de precisão, revisão de resultados e detalhes de configuração publicados. Ela não pode tornar idênticos sistemas que não são comparáveis.

As comparações mais úteis mantêm constantes o modelo, o cenário, a meta de latência, o requisito de precisão, a quantidade de aceleradores e a divisão. Diferenças fora dessas variáveis devem permanecer visíveis.

A concorrência também vai além da NVIDIA e da AMD. O Google participou da v6.1, a Intel apresentou resultados do Arc Pro B70, e vários provedores de nuvem submeteram sistemas de parceiros.

Os resultados de inferência da Lambda demonstram como integradores de sistemas podem gerar ganhos adicionais usando a mesma geração de aceleradores. Seu sistema Blackwell Ultra com quatro GPUs melhorou quase 9 por cento em relação à v6.0.

A Lambda também usou uma submissão de divisão aberta para executar uma carga de trabalho edge-agentic com Kimi K2.6 em hardware de datacenter. O modelo contém mais de um trilhão de parâmetros, segundo a Lambda.

Essas entradas reforçam um ponto mais amplo. A unidade competitiva está migrando de um processador para uma pilha de serviços configurada, que inclui modelos, frameworks, orquestração e infraestrutura.

A NVIDIA atualmente oferece a versão mais integrada dessa pilha. A AMD tenta enfraquecer a premissa de que a integração exige uma plataforma exclusiva da NVIDIA.

Portanto, a pressão sobre a NVIDIA não é apenas continuar sendo a mais rápida. Ela precisa demonstrar que sua liderança em desempenho gera valor operacional suficiente para justificar o compromisso com sua arquitetura.

O Que os Resultados de Prévia Não Comprovam

A alegação mais sólida é a taxa de transferência de benchmark verificada, enquanto alegações sobre custo, receita, disponibilidade e liderança ampla em cargas de trabalho exigem evidências adicionais.

A MLCommons identifica Vera Rubin e Vera Rubin NVL72 como entradas de prévia. Esse rótulo informa aos leitores que a plataforma não está sendo apresentada como o AMD MI350P disponível nesta rodada de resultados.

O status de prévia não torna um resultado inválido. O MLPerf ainda publica a configuração e aplica seu processo de benchmark. No entanto, ele limita o que compradores podem inferir sobre sistemas comercialmente implantados.

O hardware de produção pode enfrentar restrições que não aparecem em uma submissão de engenharia. Maturidade de firmware, taxas de falha, fornecimento de componentes, refrigeração, tempo de instalação e gestão de frotas afetam a capacidade real.

A submissão de Vera Rubin também veio da NVIDIA e da parceira Nebius. Uma reprodução mais ampla entre integradores independentes forneceria evidências mais fortes de que o desempenho se transfere entre implantações.

O ecossistema de gerações anteriores da NVIDIA oferece um precedente favorável. Dezenove parceiros participaram com plataformas NVIDIA na v6.1, incluindo oito que usaram sistemas Blackwell NVL72 multinó.

Essa abrangência sugere que a NVIDIA sabe como levar projetos otimizados por uma extensa rede de fornecedores. Ela não garante que a configuração de prévia de Vera Rubin chegará inalterada ou dentro do prazo em todos os lugares.

A cobertura de cargas de trabalho cria outra incerteza. A plataforma estreou no DeepSeek-R1 e no Qwen3-VL, duas cargas adequadas ao seu design em escala de rack e à sua pilha de software.

Ela não publicou resultados de Vera Rubin para GPT-OSS-120B, recomendação, fala, geração de imagens, RAG ou Wan 2.2 na divisão fechada. Rodadas futuras devem mostrar se a liderança se generaliza.

A NVIDIA também citou melhorias de desempenho após o prazo no GPT-OSS-120B e no DLRMv3. A empresa declarou explicitamente que a MLCommons não havia verificado esses resultados posteriores.

Esses números devem permanecer fora de conclusões diretas de benchmark até passarem pelo mesmo processo de revisão. Testes do fornecedor podem indicar uma direção, mas não têm o mesmo peso probatório.

Dados de energia são outra peça ausente na comparação principal. A taxa de transferência por rack importa, mas operadores frequentemente enfrentam capacidade elétrica fixa antes de esgotar o espaço físico.

Um rack mais rápido ainda pode complicar implantações se exigir fornecimento de energia mais denso ou refrigeração líquida mais exigente. O desempenho por watt determinará quanto trabalho útil cabe dentro do limite de uma instalação.

A NVIDIA argumenta que maior taxa de transferência reduz o custo por token. Essa conclusão é plausível quando outros fatores permanecem estáveis, mas o resultado publicado não fornece uma contabilidade completa de custos.

Termos de compra, utilização, energia, manutenção, financiamento e trabalho de software podem alterar o número final. Os compradores precisam de dados de produção medidos em suas próprias cargas de trabalho.

O benchmark também não pode garantir a responsividade para o usuário final. O serving do modelo pode ser rápido, enquanto recuperação, chamadas de ferramentas, bancos de dados ou APIs externas criam a maior parte do atraso.

O MLPerf v6.1 começa a abordar essa lacuna com novos testes de geração aumentada por recuperação e edge-agentic. Mais da metade dos participantes usou seu harness centrado em API, que aplica uma arquitetura cliente-servidor.

A MLCommons afirma que esse harness apoiará uma transição para o MLPerf Endpoints em testes de datacenter. A mudança deve aproximar as medições de serviços implantáveis, em vez de motores de modelo isolados.

Essa evolução pode fortalecer ou enfraquecer o argumento da plataforma NVIDIA. Uma pilha rigidamente integrada deve se beneficiar de uma medição de serviço completo, mas dependências externas podem diluir vantagens brutas dos aceleradores.

A interpretação prudente é específica. Vera Rubin apresentou uma estreia de prévia notável e revisada no DeepSeek-R1 e no Qwen3-VL. Ainda não estabeleceu liderança universal nem economia completa de produção.

Três Sinais Determinarão se a Liderança se Mantém

A vantagem inicial de Vera Rubin só se torna estrategicamente importante se sistemas comercializados a reproduzirem em mais cargas de trabalho e sob restrições operacionais mensuráveis.

O primeiro sinal é a ampla disponibilidade em produção. Os clientes devem acompanhar instâncias em nuvem, sistemas de parceiros e racks instalados que exponham detalhes de configuração comparáveis aos da submissão de prévia.

Uma implantação bem-sucedida mostraria que a NVIDIA consegue converter um resultado de engenharia otimizado em infraestrutura reproduzível. Atrasos ou configurações materialmente diferentes enfraqueceriam essa conclusão.

A disponibilidade deve incluir mais do que anúncios de envio. Os compradores precisam de versões estáveis de software, redes qualificadas, procedimentos de serviço e evidências de que os sistemas sustentam desempenho durante longos períodos de operação.

O segundo sinal é a próxima rodada de benchmark independente. Vera Rubin precisa de resultados além de DeepSeek-R1 e Qwen3-VL, especialmente em recuperação, recomendação, vídeo e modelos de linguagem adicionais.

Uma cobertura mais ampla sustentaria a alegação da NVIDIA de que uma plataforma pode lidar com cargas de inferência diversificadas. Uma cobertura restrita deixaria mais espaço para aceleradores especializados e clusters concorrentes.

Os futuros resultados do MLPerf Endpoints serão particularmente reveladores. Eles devem medir sistemas voltados para APIs que se assemelham mais aos serviços adquiridos e operados por empresas.

Observe se a taxa de transferência bruta de Vera Rubin se mantém após a adição de orquestração de solicitações, componentes de recuperação e limites realistas de serviço. Uma liderança menor sugeriria que os gargalos migraram para outro lugar.

O terceiro sinal é o progresso competitivo em software. As melhorias da AMD na v6.1 mostram que aceleradores já instalados podem obter ganhos substanciais de desempenho sem uma nova geração de hardware.

Se ROCm, frameworks abertos de serving e sistemas de parceiros continuarem melhorando rapidamente, os compradores podem aceitar menor desempenho de pico em troca de flexibilidade ou compatibilidade com a infraestrutura existente.

Se o software da NVIDIA melhorar no mesmo ritmo, a liderança inicial de Vera Rubin poderá se ampliar. A empresa já relatou um ganho de 1,6 vez no Qwen3-VL no GB300 entre a v6.0 e a v6.1.

A velocidade de evolução do software importa, portanto, duas vezes. Ela eleva o desempenho atual e altera a forma como os clientes estimam a vida útil de um sistema caro.

As equipes de compras devem solicitar resultados para seus modelos exatos, comprimentos de contexto, padrões de lote e metas de latência. Elas também devem testar falhas, atualizações e mudanças nas cargas de trabalho.

Os desenvolvedores devem acompanhar quais otimizações chegam aos frameworks comuns sem exigir amplo trabalho personalizado. Uma técnica ajustada para benchmark cria valor limitado se equipes comuns não conseguem implantá-la ou mantê-la.

Líderes de produtos de IA devem conectar métricas de infraestrutura a resultados para os usuários. Inferência mais rápida pode possibilitar menor latência, mais etapas de raciocínio, maior concorrência ou solicitações multimodais mais longas.

O resultado da NVIDIA Vera Rubin no MLPerf apresenta um argumento inicial crível para o codesign em escala de rack. Sua comparação de pico de 3,7 vezes é significativa, mas pertence a um cenário definido.

A próxima decisão não é se o benchmark de prévia parece rápido. Ele claramente parece. A decisão é se os sistemas comercializados preservam essa vantagem depois que energia, software, disponibilidade e cargas de trabalho reais entram na equação.

Peça aos fornecedores que reproduzam sua meta de nível de serviço mais exigente antes de escolher uma plataforma. Em seguida, compare conjuntamente taxa de transferência sustentada, latência, precisão, utilização e esforço operacional. Essa avaliação revelará se a liderança de Vera Rubin no benchmark se transforma em uma economia de inferência duradoura ou permanece um resultado de prévia impressionante.