Tokens por segundo
não medem
um agente

O placar trocou de unidade

Uma equipe compra aceleração para seu agente de pesquisa. O fornecedor mostra tokens por segundo. Depois da implantação, o usuário espera por busca, reordenação de documentos, várias chamadas ao modelo, ferramentas e verificação. O número da ficha técnica pode estar correto e, ainda assim, explicar pouco sobre o tempo até uma resposta útil.

Em 16 de setembro, o consórcio MLCommons publicou os resultados do MLPerf Inference 6.1 com duas adições importantes: um teste de RAG de ponta a ponta e outro de inferência agentiva em dispositivo de borda. O primeiro havia sido descrito em agosto; a novidade agora é sua entrada na rodada de resultados. O segundo tenta observar uma conversa com histórico crescente e chamadas de ferramentas num equipamento que serve uma pessoa por vez. Nenhum dos dois transforma qualquer agente real em um benchmark universal.

A mudança de método importa mais que a corrida entre chips. Quando o trabalho atravessa modelos e componentes diferentes, contar apenas a velocidade da geração esconde o tempo de recuperar evidências e a chance de entregar uma resposta errada.

RAG inteiro, em duas contas separadas

O teste RAG começa com 2.515 artigos da Wikipédia congelados para todos os participantes. Uma fase extrai, divide e indexa documentos. Outra responde 824 perguntas do conjunto FRAMES, que exigem ligar fatos encontrados em mais de uma fonte. Embedding, recuperação, reordenação, avaliação dos trechos, decisão de suficiência e geração da resposta podem participar de até cinco ciclos de busca.

Por isso o MLPerf separa duas unidades: documentos por segundo para montar o índice e tarefas por segundo para responder consultas. Esta última é mais informativa que tokens por segundo porque inclui o caminho completo de uma pergunta. Também impede que uma implementação ganhe escondendo o custo do recuperador ou do modelo menor que classifica passagens.

Há um limite decisivo: a primeira versão usa o cenário offline. Todas as requisições estão disponíveis para o escalonador de uma vez. Ainda não é o comportamento de um serviço interativo com usuários chegando em momentos imprevisíveis. No ensaio de desempenho, entradas de referência fixam quantos ciclos ocorrem e quais documentos são recuperados. O pipeline faz o trabalho computacional, mas as saídas produzidas nessa execução são descartadas; a qualidade é aferida separadamente.

O protocolo precisa dessa estabilidade para comparar máquinas. Ela também reduz o quanto o número prevê uma aplicação viva, onde uma resposta ruim pode provocar outra busca, uma intervenção humana ou abandono da tarefa.

Um gate baixo ainda é um gate

Na avaliação de qualidade publicada para a configuração de referência, a resposta final acertou 35% das 824 perguntas. Uma submissão é válida se conservar pelo menos 97% desse resultado de referência. Isso é um critério de comparabilidade de desempenho: impede acelerar o sistema destruindo demais a qualidade já medida. Não transforma aproximadamente um terço de respostas corretas em desempenho suficiente para uma empresa, muito menos para um caso de alto risco.

O próprio MLCommons mostra onde a tarefa pesa. Questões numéricas, temporais e tabulares exigem recuperar o dado exato, preservar sua estrutura e às vezes calcular sobre ele. Um chunk pode partir uma tabela; o recuperador pode trazer o documento certo e o número errado; o gerador pode responder com confiança. O placar agrega tudo isso, mas não explica sozinho qual componente falhou numa consulta particular.

O agente da borda mede outra coisa

O segundo teste de 6.1 não é um agente genérico de datacenter. Ele fixa um Qwen 3.6 de 27 bilhões de parâmetros quantizado, uma janela servida de 32 mil tokens e uma requisição por vez num dispositivo de borda. Para desempenho, reproduz vinte trajetórias de programação, com 1.007 turnos, e mede tempo até o primeiro token, tempo por token e latência do turno, inclusive nas caudas da distribuição.

O gate pontuado de acerto, porém, usa cerca de 995 casos de chamadas de função de um único turno. A reprodução das trajetórias possui uma checagem interna das chamadas de ferramenta, mas o conjunto multiturno não é o gate pontuado de qualidade. Essa separação é importante: reproduzir rapidamente uma trajetória gravada não equivale a terminar uma tarefa inédita de software com teste passando. O benchmark agentivo de datacenter mencionado pela MLCommons ainda é outra iniciativa, não um resultado desta rodada.

Antes de comprar o número

A MLCommons também reporta ganhos expressivos em testes existentes e inclui hardware disponível e plataformas ainda em preview na mesma rodada. Um ganho em DeepSeek R1 ou visão-linguagem não pode ser transferido para o novo RAG, para o agente de borda ou para custo por tarefa sem comparar o mesmo workload, cenário, precisão e configuração. Resultado revisado sob protocolo comum é evidência forte para aquela comparação; não é uma fatura pronta.

Um teste de compra deveria reproduzir a forma da própria aplicação: documentos que mudam, permissões reais, consultas difíceis, concorrência observada, chamadas de ferramenta, correções humanas e custo de infraestrutura. Mediria acerto e latência p95 junto de energia e custo por tarefa aceita, com uma linha de base que use a arquitetura atual. O Korvo não executou esse experimento.

O avanço de 6.1 é mudar a pergunta do benchmark. Ainda cabe ao engenheiro completar a resposta: qual trabalho terminou corretamente, em quanto tempo e a que custo, no sistema que seus usuários realmente usam?