Pare de improvisar cargas de teste: AIPerf mede sua inferência sem scripts feitos à mão
Quem opera automações apoiadas em LLMs — seja um chatbot de atendimento, um fluxo de geração de conteúdo em escala ou um sistema de análise de leads — vive um momento específico antes de escalar: o modelo responde, mas responde rápido o bastante? A resposta, na maioria das vezes, vem de um script improvisado, um curl seguido de um cronômetro manual ou um gerador de carga escrito às pressas. O problema é que esses métodos medem a sua paciência, não o desempenho do servidor.
A NVIDIA anunciou em 18 de setembro de 2026 o AIPerf, sucessor direto do GenAI-Perf, com uma arquitetura projetada para eliminar o maior vilão de qualquer benchmark mal feito: o próprio cliente que dispara as requisições. Para quem toma decisão de investimento em infraestrutura de IA, a novidade importa menos pela engenharia e mais pelo que ela evita: custo por token fora de controle e decisões baseadas em números que não se sustentam fora do ambiente de teste.
O problema que o AIPerf ataca: você não consegue medir o que não consegue saturar
A tentação inicial ao testar um modelo recém-implantado é simples: disparar algumas requisições e ver se a resposta vem em segundos. O artigo técnico da NVIDIA descreve exatamente esse cenário — a intuição leva a comandos curl, scripts asyncio feitos à mão ou geradores de carga criados na base do “vibe code”. Todos esses caminhos compartilham o mesmo defeito de origem: limites de desempenho de processo único, o GIL do Python limitando a concorrência e métricas comparadas contra uma referência que você mesmo construiu, sem padrão externo.
A consequência prática é conhecida por quem já escalou uma automação: o teste local funciona, mas o sistema desmorona quando o tráfego real chega. A explicação está no cliente, não no servidor. O GenAI-Perf, antecessor do AIPerf, usava uma arquitetura de processo único que se tornava um gargalo sob concorrência real. O AIPerf foi reescrito do zero com arquitetura multiprocessada — workers geram carga, serviços separados de processamento de registros cuidam dos resultados e tudo é coordenado via ZMQ. O resultado, segundo a NVIDIA, é um cliente de teste que não vira o ponto de estrangulamento durante a medição.
Para o negócio, a tradução é direta: se o seu teste não satura o servidor, você não está medindo o servidor — está medindo o seu laptop. E decisões de capacidade baseadas nesses números falsos levam a dois caminhos igualmente ruins: provisionar hardware caro demais para uma carga que nunca chega, ou escalar automações que travam no primeiro pico de uso real.
Lendo os números que importam antes de escalar
O AIPerf entrega um conjunto de métricas organizadas em quatro sinais principais, cada um com uma leitura direta para operações de marketing e vendas.
TTFT (Time to First Token) — o tempo entre o envio da requisição e o primeiro token recebido. É o sinal primário para casos de uso interativos, como um chat de atendimento ao cliente. Um TTFT alto significa que a automação parece lenta para o usuário final, mesmo que a resposta completa chegue rapidamente depois.
ITL (Inter-Token Latency) — o tempo entre tokens sucessivos durante a geração. Um ITL alto indica que a fase de decodificação está sofrendo, mesmo que o TTFT pareça saudável. Em termos práticos: o atendente começa a digitar a resposta rápido, mas demora para terminar a frase — percepção de lentidão persistente, pior do que uma espera inicial.
Request Latency — o tempo total da resposta completa, combinando prefill e decodificação em um único número. É a métrica de “quanto tempo o usuário esperou, do início ao fim”.
Output Token Throughput — tokens gerados por segundo entre todas as requisições concorrentes. Este é o sinal primário para planejamento de capacidade, ou seja, quantas automações você consegue rodar simultaneamente antes de degradar a experiência.
O artigo da NVIDIA destaca que cada uma dessas métricas vem com percentis — p25, p50, p75, p90, p95 e p99 — além de mínimos, máximos, médias e desvios padrão. Para o operador de automações, o percentil importa mais que a média: um servidor com TTFT médio saudável e p99 como outlier parece ótimo no resumo e falha na produção. O usuário real não experimenta a média — ele experimenta o pior caso.
O AIPerf também integra telemetria de GPU (consumo de energia, utilização e memória) quando DCGM ou pynvml estão disponíveis, correlacionando picos de latência com eventos de pressão de memória sem precisar de uma sessão de profiling separada. Para decisão de orçamento, isso é ouro: saber que o pico de latência coincide com pressão de memória permite decidir entre otimizar o modelo ou adicionar hardware.
Configurando tráfego realista: o teste que não mente
O exemplo prático do artigo usa o Qwen3-0.6B servido via vLLM — pequeno o suficiente para rodar em uma GPU e rápido para iterar sem esperas longas. O objetivo, como o próprio artigo diz, é estabelecer o loop de medição; trocar o modelo depois é uma mudança de uma flag.
No benchmark inicial, o comando aiperf profile usa --synthetic-input-tokens-stddev 0 e --output-tokens-stddev 0 para fixar exatamente 128 tokens de entrada e 128 tokens de saída por requisição. As flags --extra-inputs min_tokens:128 e --extra-inputs ignore_eos:true garantem que o modelo emita os 128 tokens em vez de parar cedo — sem isso, o modelo pode terminar a resposta antes do alvo e os números de throughput ficam menores do que deveriam, além de não serem reproduzíveis entre execuções.
A flag --streaming é obrigatória para medir TTFT e ITL — sem streaming, o servidor agrupa a resposta completa antes de enviar, e não há eventos de primeiro token ou tokens de decodificação para medir.
O segundo cenário substitui o padrão estático por tráfego realista: --arrival-pattern poisson com --request-rate 10 significa requisições chegando a uma média de 10 por segundo, com intervalos sorteados de uma distribuição exponencial. O servidor experimenta rajadas e pausas — que é como tráfego real se comporta — em vez de um fluxo constante. --synthetic-input-tokens-stddev 128 introduz variação no comprimento dos prompts, e --output-tokens-stddev 32 solta a restrição de saída fixa. --random-seed 42 garante reprodutibilidade: rerun do mesmo comando produz a mesma sequência de requisições.
O resultado, segundo a NVIDIA, são distribuições visivelmente mais largas que o baseline estático — o esperado quando mais requisições competem por acesso à GPU e comprimentos de prefill variam por requisição. A comparação entre os dois cenários mostra exatamente o que uma operação de marketing precisa saber antes de escalar: o desempenho sob carga realista difere drasticamente do desempenho sob carga sintética ideal.
O que isso significa para a sua operação
O AIPerf resolve um problema específico que afeta diretamente o custo por token: medir a inferência em escala de forma confiável, sem scripts improvisados que se tornam obsoletos a cada mudança de requisito. Para o empreendedor que usa IA para vender e criar conteúdo, a ferramenta traduz uma pergunta estratégica — “minha automação aguenta mais carga?” — em uma resposta numérica confiável.
O ganho prático é triplo. Primeiro, decisões de investimento em GPU e infraestrutura passam a ser baseadas em dados comparáveis e transparentes, não em achismos de teste manual. Segundo, o custo por token pode ser previsto com precisão antes de escalar automações — o pior momento para descobrir que o custo explodiu é depois do tráfego real chegar. Terceiro, o AIPerf suporta mais de 15 tipos de endpoint, incluindo chat, responses, NIM rankings e geração de imagem, além de datasets públicos como ShareGPT e formatos de replay de trace da Mooncake, Baseten e WEKA AgentX — ou seja, a ferramenta cobre tanto um smoke test rápido quanto a reprodução de tráfego de produção capturado.
A métrica que antes exigia um engenheiro de infraestrutura dedicado — ou um fim de semana inteiro escrevendo scripts que seriam descartados na semana seguinte — agora é configurável em minutos, com o cliente de teste que não vira o gargalo. A pergunta deixa de ser “o que meu script de teste mediu?” e passa a ser “o que meu servidor realmente aguenta?”. E essa é a única pergunta que importa quando o custo da resposta errada é uma automação que trava no pior momento possível.
