Benchmarks de CPU AGI da Arm pressionam a AMD, mas a liderança de 1,99x é modelada

A Arm afirma que seu novo processador conclui quase o dobro do trabalho por rack em relação ao EPYC 9755 da AMD em sete cargas de trabalho selecionadas. Os benchmarks de CPU AGI da Arm relatam uma vantagem média de 1,99x após os resultados medidos do chip serem escalados com premissas de consumo energético dos servidores.

Essa manchete soa como uma derrota decisiva para a AMD. Os resultados subjacentes contam uma história mais matizada. A Arm obteve uma liderança média de 1,20x por chip, enquanto sua vantagem muito maior por rack veio principalmente da possibilidade de instalar mais servidores dentro de um orçamento fixo de energia.

A Signal65 analisou os testes por meio de uma avaliação encomendada pela Arm. No entanto, não reexecutou de forma independente toda a comparação em hardware separado. O benchmark também avalia o trabalho da CPU em torno de agentes de IA, e não a inteligência do modelo ou a inferência em aceleradores.

O resultado, portanto, importa por um motivo específico. A Arm está pedindo aos compradores de infraestrutura que avaliem CPUs para IA agêntica pelo trabalho concluído por rack, em vez de tratar o desempenho por soquete como a resposta final.

Benchmarks de CPU AGI da Arm levam a disputa para o rack

A alegação central da Arm não é que toda CPU AGI supera todo processador AMD em quase duas vezes no nível do soquete.

A análise em escala de rack comparou o processador da Arm com o EPYC 9755 de quinta geração da AMD. Ela abrangeu sete cargas de trabalho relacionadas à execução de ferramentas, recuperação, hospedagem web, engenharia de software e suporte à entrega de modelos.

A Signal65 relatou uma proporção média de desempenho de rack modelado de 1,99x para a Arm. Os resultados individuais por rack variaram de 1,43x a 3,19x, dependendo da carga de trabalho.

Os sete testes foram MySQL, NGINX, Milvus, Terminal-Bench 2, uma reprodução do SWE-bench, fastText e overhead de CPU do vLLM. Eles representam diferentes partes do caminho de software que envolve um modelo de IA.

O MySQL mede a taxa de transferência de banco de dados transacional. O NGINX cobre o tratamento de solicitações web e de API, enquanto o Milvus representa a recuperação vetorial para memória e busca de agentes.

O Terminal-Bench 2 examina o trabalho realizado em ambientes de linha de comando isolados. O teste utilizou 72 tipos de tarefa e executou 128 cópias simultaneamente.

A reprodução do SWE-bench abrangeu 259 tarefas de engenharia de software. Em vez de pedir a um modelo que escolhesse ações diferentes a cada execução, o benchmark reproduziu um fluxo de trabalho fixo.

Essa abordagem de reprodução importa porque agentes de IA são não determinísticos. Duas execuções podem envolver comandos, atrasos de serviços remotos ou planos gerados pelo modelo diferentes, mesmo quando a tarefa solicitada é idêntica.

O fastText mediu o treinamento de representações de palavras pela CPU. O teste vLLM mediu a sobrecarga do processador em torno da entrega de modelos, contornando o trabalho computacional principal do modelo.

Essa última distinção evita uma interpretação equivocada comum. O resultado do vLLM não mostra a rapidez com que a CPU AGI executa inferência de grandes modelos de linguagem em comparação com uma GPU.

O chip da Arm venceu cinco das sete comparações por chip. Ele superou a AMD em 9% no Terminal-Bench, 13% na reprodução do SWE-bench e 97% no fastText.

A AMD manteve a liderança em duas cargas de trabalho consolidadas de infraestrutura. O EPYC 9755 foi 12% mais rápido no MySQL e 5% mais rápido no Milvus no nível medido do chip.

O NGINX produziu uma proporção de 1,20x para a Arm. A carga de trabalho de overhead de CPU do vLLM deu à Arm um resultado de 1,16x.

Em todas as sete proporções normalizadas, a Arm alcançou uma vantagem média de 1,20x por chip. Esse resultado é significativo, mas muito menor do que o índice de 1,99x associado à alegação em nível de rack.

O modelo de rack transformou a comparação ao considerar a potência nominal do servidor. Ele presumiu entre 950 e 1.050 watts para um servidor Arm de dois soquetes, dependendo da configuração da CPU AGI.

O sistema AMD recebeu uma estimativa de potência nominal de 1.700 watts. Ambos os cálculos incluíram memória e outros componentes do servidor, não apenas a potência térmica de projeto do processador.

Após reservar cerca de 8% de um orçamento de rack de 24 quilowatts para rede e distribuição de energia, o modelo acomodou 21 ou 23 servidores Arm. Ele acomodou 13 servidores AMD no mesmo orçamento.

Isso produziu entre 5.712 e 5.888 núcleos físicos Arm por rack modelado. O rack AMD continha 3.328 núcleos físicos.

O multiplicador de densidade resultante elevou todas as cargas de trabalho da Arm acima da AMD no nível de rack. Até mesmo o MySQL, que favorecia a AMD por chip, tornou-se um resultado modelado de 1,43x para a Arm por rack.

O Milvus passou de 0,95x por chip para 1,54x por rack. A reprodução do SWE-bench subiu de 1,13x para exatamente 2,00x sob o modelo de rack.

O fastText gerou a maior proporção. Seu resultado medido de 1,97x por chip tornou-se um resultado modelado de 3,19x por rack.

Esses números sustentam o argumento da Arm de que data centers limitados por energia devem avaliar o total de trabalho útil. Eles não mostram dois racks operacionais concluindo essas cargas de trabalho sob potência de tomada medida diretamente.

Por que a IA agêntica torna o trabalho da CPU mais visível

Agentes de IA transferem trabalho substancial para fora do acelerador, tornando a capacidade da CPU parte da experiência visível ao usuário.

Uma solicitação convencional de IA generativa pode parecer centrada na inferência do modelo. Um agente de produção executa uma sequência mais longa que envolve planejamento, recuperação, chamadas de ferramentas, validação e gerenciamento de estado.

A GPU ou outro acelerador ainda realiza os cálculos densos da rede neural. A CPU coordena grande parte do caminho de execução ao redor e executa muitas ferramentas selecionadas pelo agente.

Um agente de programação oferece um exemplo prático. Ele pode inspecionar um repositório, iniciar um ambiente isolado, instalar dependências, compilar código, executar testes e analisar falhas.

Cada chamada ao modelo pode acionar outra rodada de trabalho de CPU. Executar milhares de agentes simultaneamente multiplica a demanda sobre contêineres, bancos de dados, APIs, armazenamento e sistemas de agendamento.

Agentes empresariais criam um perfil diferente. Eles podem consultar registros, chamar serviços internos, aplicar políticas de acesso, serializar respostas, atualizar o estado do fluxo de trabalho e gravar logs de auditoria.

A recuperação adiciona operações de indexação e busca vetorial. A entrega de modelos acrescenta tokenização, agendamento de solicitações, processamento em lote, streaming e gerenciamento de metadados de cache ao redor do acelerador.

A estrutura de avaliação da Arm separa esse trabalho em funções de framework de agentes e ferramentas específicas de cada caso de uso. Ela também separa benchmarks de componentes de medições de tarefas ponta a ponta.

Testes de componentes ajudam a isolar o comportamento do processador. Testes ponta a ponta mostram se um componente mais rápido produz uma tarefa concluída mais rápida ou mais confiável.

Nenhuma das abordagens é suficiente por si só. Um processador pode liderar um benchmark de banco de dados sem encurtar o fluxo de trabalho total de um agente, especialmente quando a latência do modelo predomina.

Um resultado ponta a ponta também pode ocultar a causa de uma diferença de desempenho. Modelos, redes, ferramentas ou decisões de agentes distintos podem superar a diferença subjacente entre processadores.

A Arm propõe trajetórias de agentes reproduzíveis como uma ponte entre essas abordagens. Uma trajetória registra as operações produzidas durante uma sessão de agente e executa a mesma sequência em cada sistema.

A técnica reduz a variação causada pelas decisões do modelo. Ela também torna a comparação mais repetível, porque ambos os processadores recebem um fluxo de trabalho equivalente.

No entanto, a reprodução remove parte do sistema ao vivo. Ela mede a rapidez com que a infraestrutura executa um caminho predeterminado, não se uma pilha completa de agentes encontra um caminho melhor.

Esse limite explica por que o rótulo de raciocínio e planejamento exige cautela. Os testes relevantes medem o suporte da CPU para esses fluxos de trabalho, e não a qualidade do raciocínio de máquina.

A mesma cautela se aplica à concorrência. Um servidor que inicia mais ambientes de agentes não é automaticamente melhor se os tempos de resposta entrarem em colapso sob utilização sustentada.

A metodologia da Arm enfatiza trabalho útil concluído enquanto mantém a capacidade de resposta. Esse enquadramento conecta a taxa de transferência aos limites físicos enfrentados pelos data centers.

A entrega de energia tornou-se um desses limites. A capacidade de resfriamento e o espaço em rack também restringem quantos processadores um operador pode implantar, independentemente da disponibilidade de chips.

Nessas condições, a liderança por soquete nem sempre produz o melhor resultado no nível da instalação. Um processador moderadamente mais rápido pode perder em escala de rack se seu servidor de suporte consumir muito mais energia.

Por outro lado, um servidor mais eficiente pode criar maior capacidade total mesmo quando perde em testes selecionados no nível do chip. Os resultados da Arm em MySQL e Milvus ilustram essa possibilidade dentro de seu modelo.

A Arm desenvolveu a metodologia com apoio da Fujitsu, Meta e OpenAI. Esse apoio sinaliza interesse em medições de CPU mais representativas, mas não torna a estrutura um padrão do setor.

A Meta afirmou que agentes de produção exigem maior visibilidade sobre como as cargas de trabalho utilizam a infraestrutura abaixo deles. A OpenAI destacou a orquestração e a execução de ferramentas como áreas que precisam de benchmarks representativos.

A Fujitsu conectou o esforço ao desenvolvimento de um processador Arm de alto desempenho. As três perspectivas apoiam melhores medições, embora cada organização também tenha interesse em infraestrutura baseada em Arm.

A própria estrutura reconhece que não é uma suíte de benchmarks concluída. Ela define categorias de carga de trabalho e limites de medição, enquanto deixa sem resolução a pontuação e um acordo mais amplo.

Essa distinção é essencial. A Arm propôs uma forma de estruturar o debate e, em seguida, publicou resultados favoráveis usando testes alinhados a essa proposta.

O resultado de 1,99x vem da densidade, não de uma vitória de 2x do chip

A narrativa de desempenho da CPU AGI da Arm depende mais da densidade de implantação modelada do que de um desempenho esmagador no nível do soquete.

A Arm testou duas configurações de CPU AGI porque o mesmo hardware não estava disponível para todas as cargas de trabalho. O Terminal-Bench 2 e o SWE-bench usaram um chip de 128 núcleos operando a 2,8 GHz com memória DDR5-7200.

As outras cinco cargas de trabalho usaram uma CPU AGI de 136 núcleos operando a 3,2 GHz com DDR5-8000. O sistema de comparação da AMD utilizou um soquete EPYC 9755 de 128 núcleos com DDR5-6400.

Ambas as plataformas executaram os mesmos scripts de benchmark. Elas não executaram ambientes de software idênticos.

A maioria dos testes da Arm usou Ubuntu 24.04 com uma compilação personalizada do Linux 7.1.3. O teste SWE-bench usou Ubuntu 26.04.

A principal configuração registrada da AMD usou Ubuntu 24.04 e Linux 6.8. Algumas configurações também variaram conforme o teste.

Diferenças de software podem afetar o comportamento do compilador, o agendamento, os drivers e o desempenho das aplicações. Elas dificultam atribuir cada diferença exclusivamente à arquitetura do processador.

O modelo de potência do servidor cria outra distinção importante. A Signal65 e a Arm utilizaram valores nominais em vez de medir racks completos de produção sob carga.

A potência nominal continua útil para o planejamento de capacidade. Os operadores não podem instalar equipamentos que excedam o projeto elétrico e de resfriamento de um rack, mesmo que o consumo típico seja menor.

No entanto, a potência nominal pode divergir do consumo específico de uma carga de trabalho. Um sistema pode consumir menos que seu máximo nominal durante uma aplicação e se aproximar dele durante outra.

O consumo real também depende da população de memória, armazenamento, rede, resfriamento, fontes de alimentação, firmware e políticas de gerenciamento do sistema. Essas variáveis tornam-se relevantes quando a contagem de servidores determina a manchete.

As premissas de memória mudaram a vantagem relatada. O modelo principal da Arm atribuiu 4 GB por thread de hardware.

O multithreading simultâneo da AMD expõe duas threads de hardware por núcleo físico. O design testado da Arm usa uma thread por núcleo.

Essa escolha deu aos servidores AMD modelados cerca de 2 TB de memória e aos servidores Arm cerca de 1 TB. Ela alocou 336 watts para a memória AMD e 192 watts para a memória Arm.

A Signal65 também calculou um cenário que atribuía memória por núcleo físico. Nessa alternativa, a AMD exigia menos energia de memória e a vantagem média por rack da Arm caiu de 1,99x para cerca de 1,81x.

A Arm ainda manteve uma liderança substancial no modelo. A redução mostra como uma escolha razoável de planejamento de capacidade pode alterar materialmente o número final.

A capacidade de memória não é apenas um detalhe de benchmark. Algumas implantações de agentes mantêm índices grandes, caches, armazenamentos de estado ou ambientes de execução simultânea.

Um servidor com mais memória pode suportar cargas de trabalho que uma configuração mais densa, mas com menor capacidade, não consegue hospedar de forma eficiente. Portanto, os compradores precisam comparar a capacidade útil do sistema, e não apenas o throughput normalizado.

O EPYC 9755 da AMD suporta 128 núcleos físicos e 256 threads. Ele também faz parte de uma ampla plataforma de servidores usada em cargas de trabalho de uso geral, bancos de dados, virtualização e hospedagem de IA.

A CPU AGI da Arm mira uma proposta mais específica. Ela combina núcleos Arm densos com largura de banda de memória e E/S substanciais para infraestrutura de IA.

Essa especialização não torna nenhuma das arquiteturas universalmente superior. Ela altera quais restrições determinam a melhor escolha.

Um operador de nuvem diante de um limite fixo de energia pode priorizar trabalhos concluídos por rack. Um comprador de banco de dados pode enfatizar desempenho por soquete, maturidade de software, capacidade de memória ou comportamento de licenciamento.

Um operador de cluster de IA pode se preocupar em manter aceleradores caros ocupados. Preparação e orquestração mais rápidas no lado da CPU podem reduzir o tempo ocioso dos aceleradores, mas esses testes não mediram um fluxo de trabalho completo apoiado por aceleradores.

Isso torna a comparação entre a CPU AGI da Arm e a AMD mais restrita do que sugere a manchete. Trata-se de uma comparação de tarefas selecionadas visíveis para a CPU e de um cenário de implantação modelado.

Não é um estudo de custo total. Os resultados publicados não oferecem uma comparação completa de custos de aquisição, migração de software, suporte operacional, rede ou mudanças nas instalações.

Eles também não comparam a Arm com todos os processadores x86 relevantes. A AMD tem outras configurações EPYC, enquanto a Intel concorre com plataformas Xeon em implantações empresariais e de nuvem.

O processador Vera da Nvidia acrescenta uma segunda rota baseada em Arm. Um estudo separado de cargas de trabalho do Vera relatou resultados robustos por núcleo contra o EPYC 9755 em tarefas semelhantes às de agentes.

Esse estudo não mediu energia nem throughput do servidor completo. Seu resultado mais restrito reforça a necessidade de separar alegações por núcleo, por soquete, por rack e de ponta a ponta.

A AMD também promove CPUs como partes críticas de sistemas de IA agêntica. Seu próprio caso para CPUs agênticas enfatiza orquestração, processamento de dados, segurança e suporte a aceleradores.

A discordância real, portanto, não é sobre se as CPUs importam. É sobre como os compradores devem definir a carga de trabalho, normalizar sistemas e transformar medições de componentes em decisões de implantação.

O que a alegação de desempenho da CPU AGI da Arm não estabelece

A Signal65 validou os registros e cálculos da Arm, mas esse processo não equivaleu a uma repetição independente em laboratório.

A Signal65 observou remotamente as execuções de teste da Arm. Ela examinou logs originais, arquivos de resultados, scripts e registros de configuração.

Uma equipe de revisão separada refez os cálculos usando seu próprio código. Segundo a análise, ela reproduziu todos os sete resultados com uma margem de 0,5%.

Esse trabalho proporciona mais escrutínio do que um gráfico de fornecedor sem revisão. Ele verifica se as proporções relatadas decorrem dos resultados capturados e do modelo de rack.

Ainda assim, a Arm encomendou a análise e forneceu os sistemas testados. A Signal65 não adquiriu hardware equivalente nem repetiu de forma independente o experimento completo em seu próprio laboratório.

A revisão também enfrentou lacunas de configuração. A Signal65 só pôde confirmar de forma independente as configurações de BIOS e memória de um sistema EPYC 9965 usado em uma comparação sandbox separada.

Ela não pôde verificar de forma independente todas as configurações de BIOS e memória dos sistemas com CPU AGI e EPYC 9755. Isso limita a certeza sobre a origem de diferenças menores de desempenho.

A distinção importa mais em resultados próximos. Uma vantagem de 97% no fastText dificilmente desapareceria com uma pequena alteração de configuração, mas uma diferença de 5% ou 9% merece análise mais cuidadosa.

A média aritmética cria outra limitação. Fazer a média de proporções normalizadas dá a cada carga de trabalho a mesma influência, independentemente de quão frequentemente uma implantação real realiza essa operação.

Uma empresa pode executar transações de banco de dados constantemente e treinar modelos fastText raramente. Outra pode operar milhares de sandboxes de programação e pouca infraestrutura transacional.

Portanto, a média publicada de 1,99x não prevê o ganho de capacidade de todos os compradores. Cada operador precisa de um resultado ponderado por carga de trabalho, baseado em seu próprio perfil de execução.

A suíte de testes também mistura aplicações estabelecidas com proxies emergentes de agentes. MySQL e NGINX têm longas trajetórias, enquanto benchmarks de agentes baseados em reprodução ainda são relativamente recentes.

Essa combinação é útil porque os agentes utilizam infraestrutura conhecida. Ela também é discutível porque a combinação selecionada determina o que recebe o mesmo peso.

A reportagem original observou que o resultado não estabelece liderança geral em IA agêntica. Os processadores, cargas de trabalho, configurações e a metodologia desenvolvida pela Arm definem seu escopo.

Nenhuma inferência completa por GPU foi incluída no resultado do vLLM. A categoria de raciocínio e planejamento não testou se um modelo raciocinava com maior precisão.

O cálculo por rack não incluiu uma implantação de 24 quilowatts medida diretamente. Ele modelou as quantidades de servidores a partir da potência nominal do sistema após reservar capacidade para a infraestrutura do rack.

O preço não fez parte da comparação pública. Tampouco fizeram parte o licenciamento de aplicações, trabalho de migração, treinamento de equipe ou compatibilidade com ferramentas de implantação existentes.

Essas omissões não invalidam o benchmark. Elas definem o que o resultado pode sustentar.

A Arm pode dizer razoavelmente que seus sistemas testados produziram maior throughput por rack modelado sob as premissas documentadas. Ela não pode transformar essa afirmação em liderança universal em IA agêntica.

A AMD pode apontar razoavelmente para as duas vitórias por chip e para o efeito das premissas de memória. Esses pontos não eliminam a vantagem de densidade da Arm dentro do modelo publicado.

A interpretação mais produtiva está entre essas posições. A Arm apresentou uma hipótese crível que justifica testes mais amplos e independentes em hardware de produção.

A hipótese é que a potência do rack e o throughput sustentado de ferramentas de agentes devem ter mais peso do que comparações tradicionais por soquete. O resultado de 1,99x é um estudo de caso inicial para esse argumento.

Para os compradores, o método pode se provar tão influente quanto o vencedor atual. Uma suíte comum e transparente permitiria que operadores comparassem Arm, AMD, Intel e Nvidia dentro de limites idênticos.

Essa suíte precisaria de potência medida do sistema, software equivalente, firmware documentado, ponderação por carga de trabalho e validação repetível de ponta a ponta.

Ela também deveria apresentar várias perspectivas, em vez de comprimir tudo em uma única proporção. Resultados por núcleo, por soquete, por watt, por rack e por dólar respondem a perguntas operacionais diferentes.

O sucesso e a latência das tarefas devem permanecer separados do throughput da infraestrutura. Um sistema que conclui mais ações reproduzidas pode não oferecer melhores resultados de agentes se atrasos de modelo ou rede predominarem.

Três sinais decidirão se a alegação da Arm por rack se sustenta

Hardware de produção, testes mais amplos de concorrentes e implantações de clientes determinarão se a vantagem modelada da Arm se torna operacional.

O primeiro sinal é o teste independente em sistemas finais de produção com CPU AGI. A Signal65 afirmou que os resultados atuais refletem sistemas iniciais e que está planejado um trabalho de acompanhamento mais amplo.

Um acompanhamento convincente deve medir a potência completa do servidor durante cada carga de trabalho. Deve usar sistemas operacionais comparáveis, configurações de compilador, capacidade de memória, firmware e condições de refrigeração.

O teste mais robusto preencheria vários servidores e validaria experimentalmente o cálculo por rack. Isso mostraria se densidade, rede, térmicas e utilização sustentada se comportam conforme o modelo.

Se os testes de produção permanecerem próximos da média de 1,99x, a posição da Arm se fortalece muito. Uma queda significativa mostraria que a modelagem baseada em potência nominal superestimou a capacidade implantável.

O segundo sinal é a comparação com um campo mais amplo de processadores. O AMD EPYC 9755 é importante, mas um processador x86 não pode representar o mercado inteiro.

As opções mais recentes e com maior número de núcleos da AMD podem mudar o cálculo de densidade. A Intel pode ter desempenho diferente em servidores web, bancos de dados, recuperação e execução de ferramentas.

O Nvidia Vera também merece comparação direta porque usa núcleos compatíveis com Arm, mas visa à infraestrutura de IA por meio de um design de sistema diferente. Sua conectividade com aceleradores cria outro caminho de implantação.

Testes mais amplos devem usar as mesmas cargas de trabalho e pontuação transparente. Seleções de benchmarks específicas de fornecedores deixariam os compradores comparando alegações incompatíveis.

Se a Arm mantiver uma liderança por rack contra vários concorrentes, sua metodologia ganhará credibilidade além de um único pareamento favorável. Se a liderança variar acentuadamente, a seleção de cargas de trabalho se tornará a história mais importante.

O terceiro sinal é a adoção real por clientes com dados operacionais divulgados. A Arm posicionou a CPU AGI para hyperscalers e outros grandes operadores de infraestrutura de IA.

Uma implantação pública deve relatar trabalho concluído, latência, energia e utilização antes e depois da migração. Também deve explicar quaisquer mudanças de software necessárias para a arquitetura Arm.

Evidências operacionais podem revelar problemas que benchmarks não detectam. Entre eles estão compatibilidade de dependências, observabilidade, disponibilidade de imagens de contêiner, posicionamento de cargas de trabalho, recuperação de falhas e esforço administrativo.

Os resultados dos clientes terão maior importância quando cobrirem tráfego de produção sustentado. Demonstrações curtas não conseguem reproduzir o padrão de demanda de milhares de agentes persistentes.

O anúncio de benchmark da Arm de outubro de 2026 apresenta um argumento claro para avaliar infraestrutura em escala de rack. Ele também afirma que a metodologia deve evoluir à medida que as arquiteturas de agentes mudam.

Essa admissão é apropriada. O software agêntico continua fluido, e a sequência representativa de ferramentas de hoje pode se tornar o proxy obsoleto de amanhã.

As equipes de infraestrutura devem usar os benchmarks da CPU AGI da Arm como motivo para examinar seus próprios gargalos, e não como um veredito universal de aquisição.

Comece rastreando onde um agente passa seu tempo. Separe a inferência de modelo de recuperação, inicialização de sandbox, execução de ferramentas, acesso a banco de dados, orquestração e validação.

Em seguida, relacione essas etapas à restrição real. Um cluster pode enfrentar um limite de energia, uma limitação de capacidade de memória, escassez de aceleradores ou latência de tarefa inaceitável.

Esse processo pode transformar uma alegação ampla de fornecedor em uma questão local testável. Ele também impede que uma média de benchmark substitua o planejamento de capacidade específico da carga de trabalho.

As equipes de engenharia que avaliam infraestrutura de agentes podem manter anotações de benchmark, registros de configuração e descobertas de implantação em uma base de conhecimento pesquisável. Esse registro se torna valioso quando mudanças de software ou hardware invalidam uma comparação anterior.

A Arm estabeleceu a posição inicial: seu processador teve média de 1,20x por chip e 1,99x por rack modelado em sete cargas de trabalho selecionadas. A AMD ainda venceu dois testes no nível de chip, e várias premissas moldaram a proporção maior.

A próxima decisão cabe a testadores independentes e compradores de infraestrutura. Racks de produção medidos reproduzirão a vantagem de densidade da Arm, ou as cargas de trabalho reais reduzirão essa diferença?