Metodologia do AA-AgentPerf

Visão geral

O AA-AgentPerf é um benchmark de hardware que mede o equilíbrio entre a vazão total de uma implantação de inferência e a velocidade que cada agente recebe sob cargas de trabalho agênticas realistas.

  • Trajetórias agênticas reais: Sessões de programação com vários turnos, raciocínio intercalado, chamadas de ferramentas e extensões de contexto variáveis (não prompts sintéticos uniformes).
  • Carga simultânea sustentada: Cada agente simulado permanece ativo durante toda a fase de teste, levando ao limite o reaproveitamento do cache KV, a decodificação especulativa e o comportamento do escalonador.
  • Ranking ao vivo: Publicamos resultados continuamente, incluindo novos hardwares à medida que ficam disponíveis e medindo novamente os sistemas com novas stacks de software e versões de modelos.
  • Pronto para produção: Testamos os modelos com otimizações realistas habilitadas e topologias de implantação em escala de produção.
agentes concorrentes0/ 9SISTEMA DEINFERÊNCIAAGENTE 1AGENTE 2AGENTE 3AGENTE 4AGENTE 5AGENTE 6AGENTE 7AGENTE 8AGENTE 9throughput do sistemavelocidade de saída por agente

Cada agente simulado percorre sequencialmente trajetórias agênticas de programação (raciocinando, chamando ferramentas e editando código) enquanto o sistema aumenta sua escala para comportar uma simultaneidade cada vez maior.

Conjunto de dados

O conjunto de dados do AA-AgentPerf contém trajetórias agênticas reais que abrangem vários casos de uso, linguagens de programação e modelos. Geramos as trajetórias no ambiente agêntico OpenCode instruindo três dos principais modelos de pesos abertos com raciocínio habilitado (DeepSeek V3.2, GLM 4.7 e Kimi K2.5) a resolver problemas em repositórios públicos de código reais. Todas as trajetórias incluem raciocínio e chamadas de ferramentas intercalados.

  • Extensão da sequência de entrada (ISL): Varia de ~5K a ~131K tokens, com média aproximada de 27K tokens. As trajetórias são truncadas para caber na extensão máxima de contexto recomendada dos modelos em teste.
  • Extensão da sequência de saída (OSL): As extensões de saída variam muito entre os turnos. Alguns produzem saídas curtas, como chamadas simples de ferramentas, enquanto outros envolvem raciocínio prolongado antes de o modelo responder ou agir.
  • Linguagens: Mais de 12 linguagens de programação estão representadas, com base na linguagem principal do repositório de origem. Repositórios Python são a fonte mais frequente, seguidos por TypeScript e Go.
  • Atrasos nas chamadas de ferramentas: Após cada chamada de ferramenta, simulamos o tempo de processamento com um atraso fixo por mensagem, amostrado de uma distribuição de durações de chamadas reais e segmentado pela ferramenta acionada. Os atrasos variam de menos de 0,1 s a 5 s, com mediana de aproximadamente 1 segundo.

Fornecemos aos participantes do teste um subconjunto representativo para ajustes, com 500 trajetórias únicas (18.997 prompts), para validar a configuração e otimizar o desempenho. O conjunto de dados de teste completo é mantido em sigilo para evitar otimizações direcionadas ao benchmark.

Fronteira de Pareto

Para cada sistema, publicamos os resultados como uma fronteira de Pareto da vazão total do servidor em relação à velocidade de saída por solicitação. Cada ponto corresponde a uma configuração de serviço em um nível de simultaneidade, e a fronteira mantém os pontos que nenhuma outra configuração do mesmo sistema supera tanto em vazão quanto em velocidade.

Calculamos a velocidade e a latência por solicitação. Como as cargas de trabalho agênticas têm muitas solicitações com OSL pequena, os gráficos usam por padrão a velocidade de saída P25, com percentis calculados sobre todas as solicitações enviadas durante uma fase.

Execução do teste

Medimos cada implantação em um conjunto fixo de níveis de simultaneidade, com uma fase por nível, e calculamos as métricas com informações de tempo dos tokens em estado estável. Cada fase é executada até que pelo menos 30 trajetórias tenham sido concluídas, cada agente simulado tenha concluído pelo menos 3 trajetórias e tenham transcorrido pelo menos 10 minutos de medição em estado estável. As trajetórias são atribuídas aos agentes de forma determinística entre as fases, com prefixos gerados dinamicamente e adicionados ao início de cada trajetória em cada fase para impedir o armazenamento de prefixos em cache entre fases. Um valor de max_tokens de 16K evita que solicitações individuais em que um modelo entra em um loop de repetição distorçam os resultados.

Testamos cada modelo com os parâmetros de amostragem recomendados pelo criador e o maior esforço de raciocínio disponível (max para DeepSeek V4.1 Flash, DeepSeek V4 Pro 0813, Kimi K3, GLM-5.2 e GLM-5.3; xhigh para Muse Spark Open), com todos os outros parâmetros definidos com os valores padrão.

Métricas e resultados

Calculamos as seguintes métricas em cada fase do teste:

  • Tempo até o primeiro token (TTFT): Latência por solicitação, desde o envio da solicitação até o recebimento do primeiro token de saída.
  • Velocidade de saída: Número de tokens de saída por segundo por solicitação, medido após o recebimento do primeiro token.
  • Vazão total do servidor: Tokens de entrada e de saída por segundo entre todos os agentes simultâneos, conforme informado pelo servidor. A entrada inclui os tokens do prompt servidos a partir do cache KV.

Todas as métricas são filtradas para períodos de estado estável em que todos os agentes estejam ativos por pelo menos 30 segundos no nível de simultaneidade pretendido. As métricas de velocidade usam as contagens de tokens do servidor presentes nos metadados de uso retornados pelo framework de inferência, verificadas em relação à tokenização local com o tokenizador nativo do modelo candidato. Medimos o consumo de energia de cada acelerador durante o teste em execução. Normalizamos o principal resultado, a vazão total do servidor, por MW, por acelerador e por dólar por hora de aluguel de aceleradores. Os valores por MW se baseiam na potência medida do acelerador sob carga (die da GPU + HBM), e não no TDP nominal. Os preços de aluguel vêm da Silicon Data, com estimativas próprias para os chips cujo preço a Silicon Data não informa.

Publicamos os resultados no ranking da Artificial Analysis com a configuração completa do sistema informada por cada provedor. Os provedores podem analisar seus resultados antes da publicação para verificar a exatidão das informações.

Envios

Se você é um fornecedor de hardware interessado em enviar seu sistema para uma avaliação do AA-AgentPerf e ainda não está em contato conosco, escreva para agentperf@artificialanalysis.ai.