Arm AGI CPU Benchmarks Put AMD Under Pressure, but the 1.99x Lead Is Modeled

Arm says its new processor completes nearly twice as much work per rack as AMD’s EPYC 9755 across seven selected workloads. The Arm AGI CPU benchmarks report a 1.99x average advantage after measured chip results are scaled using server-power assumptions.

That headline sounds like a decisive defeat for AMD. The underlying results tell a more qualified story. Arm averaged a 1.20x lead per chip, while its much larger rack advantage came mainly from fitting more servers inside a fixed power budget.

Signal65 reviewed the tests through an Arm-commissioned analysis. However, it did not independently rerun the entire comparison on separate hardware. The benchmark also evaluates CPU work around AI agents, not model intelligence or accelerator inference.

The result therefore matters for a specific reason. Arm is asking infrastructure buyers to judge agentic AI CPUs by completed work per rack, rather than treating socket performance as the final answer.

Arm AGI CPU Benchmarks Shift the Fight to the Rack

Arm’s central claim is not that every AGI CPU beats every AMD processor by nearly two times at the socket.

The rack-scale analysis compared Arm’s processor with AMD’s fifth-generation EPYC 9755. It covered seven workloads related to tool execution, retrieval, web serving, software engineering, and model-serving support.

Signal65 reported an average 1.99x modeled rack-performance ratio for Arm. Individual rack results ranged from 1.43x to 3.19x, depending on the workload.

The seven tests were MySQL, NGINX, Milvus, Terminal-Bench 2, a SWE-bench replay, fastText, and vLLM CPU overhead. They represent different pieces of the software path surrounding an AI model.

MySQL measures transactional database throughput. NGINX covers web and API request handling, while Milvus represents vector retrieval for agent memory and search.

Terminal-Bench 2 examines work performed inside sandboxed command-line environments. The test used 72 task types and ran 128 copies concurrently.

The SWE-bench replay covered 259 software-engineering tasks. Rather than asking a model to choose different actions during every run, the benchmark replayed a fixed workflow.

That replay approach matters because AI agents are nondeterministic. Two runs can involve different commands, remote-service delays, or model-generated plans, even when the requested task is identical.

fastText measured CPU word-representation training. The vLLM test measured processor overhead around model serving while bypassing the model’s primary compute work.

That last distinction prevents a common misreading. The vLLM result does not show how quickly the AGI CPU runs large-language-model inference compared with a GPU.

Arm’s chip won five of the seven per-chip comparisons. It led AMD by 9% in Terminal-Bench, 13% in the SWE-bench replay, and 97% in fastText.

AMD retained the lead in two established infrastructure workloads. The EPYC 9755 was 12% faster in MySQL and 5% faster in Milvus at the measured chip level.

NGINX produced a 1.20x ratio for Arm. The vLLM CPU-overhead workload gave Arm a 1.16x result.

Across all seven normalized ratios, Arm averaged a 1.20x per-chip advantage. That result is meaningful, but it is far smaller than the 1.99x figure attached to the rack-level claim.

The rack model transformed the comparison by accounting for rated server power. It assumed between 950 and 1,050 watts for a two-socket Arm server, depending on the AGI CPU configuration.

The AMD system received a 1,700-watt rated-power estimate. Both calculations included memory and other server components, not only processor thermal design power.

After reserving about 8% of a 24-kilowatt rack budget for networking and power distribution, the model fit 21 or 23 Arm servers. It fit 13 AMD servers into the same budget.

That produced between 5,712 and 5,888 physical Arm cores per modeled rack. The AMD rack contained 3,328 physical cores.

The resulting density multiplier lifted every Arm workload above AMD at rack level. Even MySQL, which favored AMD per chip, became a 1.43x modeled result for Arm per rack.

Milvus moved from 0.95x per chip to 1.54x per rack. The SWE-bench replay rose from 1.13x to exactly 2.00x under the rack model.

fastText generated the largest ratio. Its 1.97x measured chip result became a 3.19x modeled rack result.

These figures support Arm’s argument that power-constrained data centers should evaluate total useful work. They do not show two operating racks completing those workloads under directly measured wall power.

Why Agentic AI Makes CPU Work More Visible

AI agents shift substantial work outside the accelerator, making CPU capacity part of the user-visible experience.

A conventional generative AI request can appear centered on model inference. A production agent performs a longer sequence involving planning, retrieval, tool calls, validation, and state management.

The GPU or another accelerator still performs the dense neural-network calculations. The CPU coordinates much of the surrounding execution path and runs many tools the agent selects.

A coding agent offers a practical example. It may inspect a repository, launch a sandbox, install dependencies, compile code, run tests, and analyze failures.

Each model call can trigger another round of CPU work. Running thousands of agents concurrently multiplies the demand placed on containers, databases, APIs, storage, and scheduling systems.

Enterprise agents create a different profile. They can query records, call internal services, apply access policies, serialize responses, update workflow state, and write audit logs.

Retrieval adds indexing and vector-search operations. Model serving adds tokenization, request scheduling, batching, streaming, and cache-metadata management around the accelerator.

Arm’s evaluation framework separates this work into agent-framework functions and use-case-specific tools. It also separates component benchmarks from end-to-end task measurements.

Component tests help isolate processor behavior. End-to-end tests show whether a faster component produces a faster or more reliable completed task.

Neither approach is sufficient alone. A processor can lead a database benchmark without shortening an agent’s total workflow, particularly when model latency dominates.

An end-to-end result can also hide the cause of a performance gap. Different models, networks, tools, or agent decisions can overwhelm the underlying processor difference.

Arm proposes replayable agent trajectories as one bridge between those approaches. A trajectory records the operations produced during an agent session and executes the same sequence on each system.

The technique reduces variation from model decisions. It also makes the comparison more repeatable because both processors receive an equivalent stream of work.

However, replay removes part of the live system. It measures how quickly the infrastructure executes a predetermined path, not whether one full agent stack finds a better path.

This boundary explains why the reasoning and planning label requires care. The relevant tests measure CPU support for those workflows rather than the quality of machine reasoning.

The same caution applies to concurrency. A server that starts more agent environments is not automatically better if response times collapse under sustained utilization.

Arm’s methodology emphasizes completed, useful work while maintaining responsiveness. That framing links throughput with the physical limits facing data centers.

Power delivery has become one such limit. Cooling capacity and rack space also constrain how many processors an operator can deploy, regardless of chip availability.

Under those conditions, per-socket leadership does not always produce the best facility-level outcome. A moderately faster processor can lose at rack scale if its supporting server consumes much more power.

Conversely, a more efficient server can create greater total capacity even when it loses selected chip-level tests. Arm’s MySQL and Milvus results illustrate that possibility inside its model.

Arm developed the methodology with support from Fujitsu, Meta, and OpenAI. Their support signals interest in more representative CPU measurements, but it does not make the framework an industry standard.

Meta said production agents require greater visibility into how workloads exercise the infrastructure below them. OpenAI highlighted orchestration and tool execution as areas that need representative benchmarking.

Fujitsu connected the effort with its development of a high-performance Arm-based processor. All three perspectives support better measurement, although each organization also has an interest in Arm-based infrastructure.

The framework itself acknowledges that it is not a finished benchmark suite. It defines workload categories and measurement boundaries while leaving scoring and broader agreement unresolved.

That distinction is essential. Arm has proposed a way to structure the debate, then published favorable results using tests aligned with that proposal.

The 1.99x Result Comes From Density, Not a 2x Chip Win

The Arm AGI CPU performance story depends more on modeled deployment density than overwhelming socket-level performance.

Arm tested two AGI CPU configurations because the same hardware was not available for every workload. Terminal-Bench 2 and SWE-bench used a 128-core chip running at 2.8 GHz with DDR5-7200 memory.

The other five workloads used a 136-core AGI CPU running at 3.2 GHz with DDR5-8000. AMD’s comparison system used one 128-core EPYC 9755 socket with DDR5-6400.

Both platforms ran the same benchmark scripts. They did not run identical software environments.

Most Arm tests used Ubuntu 24.04 with a custom Linux 7.1.3 build. The SWE-bench test used Ubuntu 26.04.

AMD’s main recorded configuration used Ubuntu 24.04 and Linux 6.8. Some settings also varied by test.

Software differences can affect compiler behavior, scheduling, drivers, and application performance. They make it harder to attribute every gap solely to processor architecture.

The server-power model creates another important distinction. Signal65 and Arm used rated figures rather than measuring complete production racks under load.

Rated power remains useful for capacity planning. Operators cannot install equipment that exceeds a rack’s electrical and cooling design, even if typical consumption is lower.

However, rated power can diverge from workload-specific consumption. A system might draw less than its rated maximum during one application and approach it during another.

Actual power also depends on memory population, storage, networking, cooling, power supplies, firmware, and system-management policies. Those variables become consequential when server count drives the headline.

Memory assumptions changed the reported advantage. Arm’s primary model assigned 4 GB per hardware thread.

AMD’s simultaneous multithreading exposes two hardware threads per physical core. Arm’s tested design uses one thread per core.

That choice gave the modeled AMD servers roughly 2 TB of memory and the Arm servers about 1 TB. It allocated 336 watts for AMD memory and 192 watts for Arm memory.

Signal65 also calculated a scenario that assigned memory per physical core. Under that alternative, AMD required less memory power and Arm’s average rack advantage fell from 1.99x to about 1.81x.

Arm still retained a substantial modeled lead. The decrease shows how a reasonable capacity-planning choice can materially change the final number.

Memory capacity is not just a benchmarking detail. Some agent deployments maintain large indexes, caches, state stores, or concurrent execution environments.

A server with more memory can support workloads that a denser but lower-capacity configuration cannot host efficiently. Buyers must therefore compare usable system capacity, not only normalized throughput.

AMD’s EPYC 9755 supports 128 physical cores and 256 threads. It also belongs to a broad server platform used across general-purpose, database, virtualization, and AI-hosting workloads.

Arm’s AGI CPU targets a more specific proposition. It combines dense Arm cores with substantial memory bandwidth and I/O for AI infrastructure.

That specialization does not make either architecture universally superior. It changes which constraints determine the better choice.

A cloud operator facing a fixed power ceiling might prioritize completed jobs per rack. A database buyer might emphasize per-socket performance, software maturity, memory capacity, or licensing behavior.

An AI cluster operator may care about keeping expensive accelerators occupied. Faster CPU-side preparation and orchestration can reduce accelerator idle time, but these tests did not measure a complete accelerator-backed workflow.

That leaves the Arm AGI CPU vs AMD comparison narrower than the headline suggests. It is a comparison of selected CPU-visible tasks and a modeled deployment scenario.

It is not a total-cost study. The published results do not provide a complete comparison of acquisition costs, software migration, operational support, networking, or facility changes.

They also do not compare Arm against every relevant x86 processor. AMD has other EPYC configurations, while Intel competes with Xeon platforms across enterprise and cloud deployments.

Nvidia’s Vera processor adds a second Arm-based route. A separate Vera workload study reported strong per-core results against EPYC 9755 on agent-like tasks.

That study did not measure power or whole-server throughput. Its narrower result reinforces the need to separate per-core, per-socket, per-rack, and end-to-end claims.

AMD is also promoting CPUs as critical parts of agentic AI systems. Its own agentic CPU case emphasizes orchestration, data processing, security, and accelerator support.

The real disagreement is therefore not whether CPUs matter. It is how buyers should define the workload, normalize systems, and turn component measurements into deployment decisions.

What the Arm AGI CPU Performance Claim Does Not Establish

Signal65 validated Arm’s records and calculations, but that process was not equivalent to an independent laboratory rerun.

Signal65 remotely observed Arm’s test runs. It examined original logs, result files, scripts, and configuration records.

A separate review team rebuilt the calculations using its own code. According to the analysis, it reproduced all seven results within 0.5%.

That work provides more scrutiny than an unreviewed vendor chart. It checks whether the reported ratios follow from the captured results and rack model.

Still, Arm commissioned the analysis and supplied the tested systems. Signal65 did not acquire equivalent hardware and independently repeat the full experiment in its own laboratory.

The review also faced configuration gaps. Signal65 could independently confirm BIOS and memory settings only for an EPYC 9965 system used in a separate sandbox comparison.

It could not independently verify every BIOS and memory setting for the AGI CPU and EPYC 9755 systems. That limits certainty about the source of smaller performance differences.

The distinction matters most around close results. A 97% fastText lead is unlikely to disappear through a minor setting change, but a 5% or 9% gap deserves closer scrutiny.

The arithmetic average creates another limitation. Averaging normalized ratios gives each workload equal influence, regardless of how often a real deployment performs that operation.

One company might run database transactions constantly and train fastText models rarely. Another could operate thousands of coding sandboxes and little transactional infrastructure.

The published 1.99x average therefore does not predict every buyer’s capacity gain. Each operator needs a workload-weighted result based on its own execution profile.

The test suite also mixes established applications with emerging agent proxies. MySQL and NGINX have long histories, while replay-based agent benchmarks remain comparatively young.

That combination is useful because agents call familiar infrastructure. It is also debatable because the selected blend determines what receives equal weight.

The original reporting noted that the result does not establish overall leadership for agentic AI. The processors, workloads, configurations, and Arm-developed methodology define its scope.

No full GPU inference was included in the vLLM result. The reasoning and planning category did not test whether a model reasoned more accurately.

The rack calculation did not include a directly measured 24-kilowatt deployment. It modeled server counts from rated system power after reserving capacity for rack infrastructure.

Price was not part of the public comparison. Neither were application licensing, migration work, staff training, or compatibility with existing deployment tooling.

Those omissions do not invalidate the benchmark. They define what the result can support.

Arm can reasonably say its tested systems produced higher modeled rack throughput under the documented assumptions. It cannot convert that statement into universal agentic AI leadership.

AMD can reasonably point to the two per-chip wins and the effect of memory assumptions. Those points do not erase Arm’s density advantage inside the published model.

The most productive interpretation lies between those positions. Arm has presented a credible hypothesis that warrants broader, independent testing on production hardware.

The hypothesis is that rack power and sustained agent-tool throughput should carry more weight than traditional socket comparisons. The 1.99x result is an early case study for that argument.

For buyers, the method may prove as influential as the current winner. A common, transparent suite would let operators compare Arm, AMD, Intel, and Nvidia across identical boundaries.

Such a suite would need measured system power, equivalent software, documented firmware, workload-level weighting, and repeatable end-to-end validation.

It should also report several views rather than compressing everything into one ratio. Per-core, per-socket, per-watt, per-rack, and per-dollar results answer different operational questions.

Task success and latency should remain separate from infrastructure throughput. A system that completes more replayed actions may not deliver better agent outcomes if model or network delays dominate.

Three Signals Will Decide Whether Arm’s Rack Claim Holds

Production hardware, broader competitor testing, and customer deployments will determine whether Arm’s modeled advantage becomes an operational one.

The first signal is independent testing on final production AGI CPU systems. Signal65 said the current results reflect early systems and that broader follow-up work is planned.

A convincing follow-up should measure complete server power during each workload. It should use comparable operating systems, compiler settings, memory capacity, firmware, and cooling conditions.

The strongest test would populate multiple servers and validate the rack calculation experimentally. That would show whether density, networking, thermals, and sustained utilization behave as modeled.

If production testing stays near the 1.99x average, Arm’s position becomes much stronger. A large decline would show that rated-power modeling overstated deployable capacity.

The second signal is comparison against a wider processor field. AMD EPYC 9755 is important, but one x86 processor cannot represent the entire market.

AMD’s newer and higher-core-count options could change the density calculation. Intel may perform differently across web serving, databases, retrieval, and tool execution.

Nvidia Vera also deserves direct comparison because it uses Arm-compatible cores but targets AI infrastructure through a different system design. Its accelerator connectivity creates another deployment path.

Broader testing should use the same workloads and transparent scoring. Vendor-specific benchmark selections would leave buyers comparing incompatible claims.

If Arm retains a rack lead across multiple competitors, its methodology gains credibility beyond one favorable pairing. If leadership varies sharply, workload selection becomes the more important story.

The third signal is real customer adoption with disclosed operating data. Arm has positioned AGI CPU for hyperscalers and other large AI infrastructure operators.

A public deployment should report completed work, latency, power, and utilization before and after migration. It should also explain any software changes needed for Arm architecture.

Operational evidence can reveal issues benchmarks miss. These include dependency compatibility, observability, container-image availability, workload placement, failure recovery, and administrator effort.

Customer results will matter most when they cover sustained production traffic. Short demonstrations cannot reproduce the demand pattern of thousands of persistent agents.

The October 2026 Arm benchmark announcement makes a clear case for evaluating infrastructure at rack scale. It also states that the methodology must evolve as agent architectures change.

That admission is appropriate. Agentic software remains fluid, and today’s representative tool sequence can become tomorrow’s obsolete proxy.

Infrastructure teams should use the Arm AGI CPU benchmarks as a reason to examine their own bottlenecks, not as a universal procurement verdict.

Start by tracing where an agent spends its time. Separate model inference from retrieval, sandbox startup, tool execution, database access, orchestration, and validation.

Then map those stages to the actual constraint. A cluster may face a power ceiling, a memory-capacity limit, accelerator starvation, or unacceptable task latency.

That process can turn a broad vendor claim into a testable local question. It also prevents one benchmark average from replacing workload-specific capacity planning.

Engineering teams evaluating agent infrastructure can keep benchmark notes, configuration records, and deployment findings in a searchable knowledge base. That record becomes valuable when software or hardware changes invalidate an earlier comparison.

Arm has established the opening position: its processor averaged 1.20x per chip and 1.99x per modeled rack in seven selected workloads. AMD still won two chip-level tests, and several assumptions shaped the larger ratio.

The next decision belongs to independent testers and infrastructure buyers. Will measured production racks reproduce Arm’s density advantage, or will real workloads narrow the gap?