Tom’s Hardware descreveu, em 29 de outubro de 2026, um protótipo para medir o desempenho de CPUs em tarefas de IA agêntica. O método reproduz respostas gravadas de um modelo enquanto agentes executam ferramentas e calcula quantas tarefas completas terminam por segundo à medida que aumenta o número de sessões simultâneas. O relato de Jake Roach apresenta a metodologia, sem resultados comparativos entre CPUs.

Neste artigo

O que o teste pretende medir

Uma sessão corresponde a uma tarefa concluída de ponta a ponta. A métrica principal é o número de sessões concluídas por segundo em cada nível de concorrência, isto é, com diferentes quantidades de agentes trabalhando ao mesmo tempo.

O método também define dois pontos de referência. O throughput máximo é a maior taxa de sessões por segundo observada, junto com o número de sessões simultâneas naquele momento. Já o throughput ideal considera o tempo de resposta: os 5% de sessões mais lentas devem levar no máximo 1,5 vez o tempo de uma sessão individual na concorrência inicial.

Essa diferença importa porque a maior quantidade de tarefas concluídas pode vir acompanhada de sessões mais demoradas. A medida ideal proposta acrescenta um limite para essa lentidão na cauda da distribuição.

Como funcionam a gravação e a reprodução

Na etapa de gravação, um proxy encaminha as solicitações dos agentes para um servidor llama.cpp e registra as solicitações e respostas do modelo. As chamadas às ferramentas e os resultados delas são armazenados separadamente.

Na reprodução, o sistema confere cada solicitação pelo identificador da sessão e por um hash. Uma divergência invalida a execução. As chamadas de ferramentas também são comparadas com o registro; os resultados gravados são devolvidos ao agente para manter a tarefa no mesmo percurso.

O protótipo usa agentes personalizados em LangGraph e uma sequência de 30 tarefas. A concorrência começa com um worker e aumenta até o número máximo de threads da CPU, com três repetições em cada nível. Como os workers iniciam em pontos diferentes da sequência, as tarefas se sobrepõem e têm durações distintas.

Reprodução congelada e inferência ao vivo medem coisas diferentes

Demonstração em inglês de Zen van Riel sobre o uso da CPU durante tarefas de agente

Na reprodução congelada, as respostas gravadas substituem as respostas geradas pelo modelo durante a medição. Assim, essa etapa exclui a inferência ao vivo na GPU, mas mantém a execução das ferramentas no sistema avaliado.

Em outra modalidade, o modelo gera a mesma quantidade de tokens registrada anteriormente. A resposta recém-gerada é descartada, e a resposta gravada é devolvida ao agente. Essa execução inclui a inferência, o processamento de entrada e saída do modelo, o comportamento do cache e as filas entre agentes.

ModalidadeRespostas do modeloInferência ao vivo na GPUEfeitos incluídos
Reprodução congeladaGravadas e reproduzidasNãoExecução das ferramentas e trabalho da CPU durante as tarefas
Inferência ao vivoO modelo gera tokens, mas a resposta gravada é devolvida ao agenteSimInferência, comportamento do cache e filas entre agentes, além da execução das ferramentas

A separação ajuda a interpretar o que cada medição representa: a reprodução congelada isola o trabalho do agente e das ferramentas sem o tempo de inferência ao vivo; a outra modalidade incorpora também o processamento do modelo e a espera entre sessões.

Um vídeo em inglês publicado em 28 de maio de 2026 mostra Zen van Riel usando hooks do Claude Code e scripts em Python para observar a atividade da CPU durante tarefas de agente. O próprio apresentador ressalta que a demonstração não é um teste rigoroso.

Tarefas, sistemas e limites do protótipo

As seis personas do teste cobrem análise, programação, documentos, pesquisa, suporte e tarefas na web. As tarefas são de turno único, embora cada uma possa envolver várias chamadas ao modelo e ferramentas. A persona de pesquisa usa um corpus local da Wikipédia em inglês, com cerca de 50 mil artigos; a de programação trabalha com quatro projetos pequenos, dois em C e dois em Python.

Tom’s Hardware descreveu dois tipos de sistema: uma bancada com Threadripper de 64 núcleos e 128 GB de memória DDR5-6000 RDIMM, e um NVIDIA DGX Spark com GB10, 128 GB de memória unificada, GPU Blackwell e CPU Arm Grace. Para a configuração atual, a publicação informou que o isolamento com Docker acrescentava menos de 2% de sobrecarga em relação à execução sem virtualização.

A carga de trabalho do agente pode envolver orquestração, compilação de código, recuperação de informações e execução em sandbox, atividades que usam a CPU. Tom’s Hardware observa que esse trabalho pode representar uma parcela pequena de uma sessão sequencial, enquanto várias sessões simultâneas podem disputar recursos. O relato descreve um teste em desenvolvimento, não uma resposta universal sobre quanta CPU toda aplicação de IA agêntica exige.

Outras alegações de desempenho medem cargas diferentes

Os números divulgados por outras organizações não são resultados do teste de sessões por segundo de Tom’s Hardware. A Signal65, em uma análise encomendada pela Arm, relatou desempenho médio de rack modelado 1,99 vez maior para o Arm AGI CPU do que para o AMD EPYC 9755 em sete cargas de trabalho. A estimativa combina a potência nominal dos servidores com medições por chip.

A AMD relatou um resultado modelado de 2,37 vezes para o EPYC 9965 em relação ao NVIDIA Vera, usando a média geométrica normalizada de um rack de 100 kW e cargas de infraestrutura. A própria AMD afirmou que esse conjunto de testes não modela um fluxo completo de agentes de ponta a ponta. Já a NVIDIA declarou que o Vera teve desempenho mais de 1,8 vez superior ao de arquiteturas x86 tradicionais em um teste de sandbox para agentes sob carga máxima.

Essas medições usam cargas, referências e limites diferentes: desempenho modelado por rack, cargas de infraestrutura, desempenho de sandbox e sessões concluídas por segundo não formam uma classificação única de CPUs. O relato de Tom’s Hardware diz que obter os primeiros números reais do protótipo seria a próxima etapa.