A spec sheet can’t settle AMD vs Intel for AI. The score a CPU earns on an AI workload belongs to the whole executor: the processor, the backend it ran through, and the driver, framework and runtime installed on that machine. The procurement comparison table puts cores and cache in the AMD column, clock speed and ecosystem history in the Intel column, and circles a winner. That table compares capabilities, and capabilities only turn into performance through software. What deserves comparing is measured executors, under conditions that are disclosed and with optimisation effort held equal on both sides.

LynxBenchAI measures at the level of the executor. It binds every result to the device together with its backend, driver, framework and runtime, so no score is credited to the silicon alone. The Personal Edition installs with pip install lynxbench-ai, so you can take the same measurement on the machine you are actually deciding about.

AMD vs Intel for AI in the LynxBenchAI 26Q3 results

In the 26Q3 results, the AMD Ryzen 5 9600X scores higher than both published Intel CPUs overall and in all three categories: 5.2 GT on the LynxBenchAI 26Q3 Index, with 8.6 for training, 2.7 for inference and 6.3 for compute.

Executor (LynxBenchAI 26Q3 score)	Platform	GT	Training	Inference	Compute
AMD Ryzen 5 9600X	native Linux	5.2	8.6	2.7	6.3
Intel Core i7-10850H	WSL2	0.343	0.702	0.339	0.0654
12th Gen Intel Core i7-1270P	WSL2	0.297	0.196	0.17	1.6

That ordering comes from the measurement, and it answers a narrower question than “AMD or Intel”. The three executors differ in more than vendor. The Ryzen ran on native Linux and both Intel parts ran under WSL2. The two Intel chips are also mobile processors, while the 9600X is a desktop part.

The category scores don’t collapse into a single ranking either. The older i7-10850H scores 0.702 for training against 0.196 for the i7-1270P, while the i7-1270P scores 1.6 for compute against 0.0654. Each category score covers one class of work: training, inference or compute. GT is an ordinal aggregate, so a GT difference is never a percentage gap.

The same release shows what happens when the executor changes and the silicon stays put. The NVIDIA GeForce RTX 5090 scores 597.5 GT on native Linux and 545.7 GT under WSL2 in the 26Q3 results, with inference at 985.8 and 891.8 respectively. That is one card, two executors and two published numbers.

Precision changes the score on the same chip too. On the Ryzen 5 9600X, Dense MatMul scores 6.6 at bf16 and 0.00683 at fp16 in the 26Q3 results. No spec-sheet benchmark can show that kind of difference.

These figures come with limits. A 26Q3 score reflects the release’s fixed set of models, not your application. Each test is one timed window after a discarded warm-up, not a median across repeats. A precision that produces no result on an executor scores zero rather than being skipped. The catalogue runs on the public PyTorch stack, so a result is broadly indicative of the out-of-the-box PyTorch experience on that hardware. The 26Q3 release has no datacentre EPYC or Xeon entry, so for a server CPU decision the published results don’t answer the question directly. Running the Personal Edition on the candidate machines measures those executors directly. Each 26Q3 device has its own results page, reachable from the LynxBenchAI device directory.

A CPU label is only half of what produced the number

A spec sheet settles what the silicon can do in principle. It doesn’t settle what a given machine will measure, because a labelled benchmark figure is half device and half the backend, driver, framework and runtime that were present when it was taken. LynxBenchAI binds every result to the backend it ran through: cuda for NVIDIA, cuda via ROCm for AMD GPUs, xpu for Intel GPUs, or CPU. PyTorch’s ROCm build deliberately reuses the existing torch.cuda interfaces. Intel GPUs joined the official PyTorch stack through the xpu backend from PyTorch 2.5.

The MLPerf rules draw the boundary in the same place. MLCommons defines a system under test as the hardware plus the operating system, compilers, libraries and drivers that significantly influence running time. Its submission rules count the ML framework and the accelerator library (cuDNN, MKL) as part of the software stack that substantially determines ML performance. The general argument for treating performance as a property of the whole stack is in how performance emerges from the hardware and software stack. The GPU version, with the same vendor question, is in NVIDIA vs AMD GPU performance and the software stack.

Same CPU, different drivers, frameworks and runtimes: what is being compared?

Two machines with the same CPU and different drivers, frameworks and runtimes are two executors. Put their numbers side by side and you are comparing those executors, including everything the software did differently. MLPerf Inference v6.1 gives a datacentre example. On the same silicon and socket count as v6.0, Llama3.1-8B Server throughput on the Intel Xeon 6980P rose 2.4× and Offline throughput rose 56%, from software alone. A Xeon 6980P result from one round set against an EPYC result from another would credit a software gap to the vendor.

The framework ranking itself changes from one CPU architecture to another. A study of quantised inference on Intel Skylake, Intel Cascade Lake and ARMv8 processors found ONNX and OpenVINO the most optimised frameworks for the Intel CPUs at FP32. TFLite was the slowest there and gained nothing from quantisation, yet it was the fastest on a Raspberry Pi 4B. The same study measured INT8 at 3.3× the performance of FP32 with OpenVINO on the Intel CPU. It also warned that without instruction-set support or optimised kernels such as FBGEMM, quantisation can slow inference down.

The AMD side has its own settings to get right. AMD’s ZenDNN guide for ONNX Runtime says hardware configuration, OS, kernel and BIOS settings play an important role in performance. It tunes EPYC throughput through OpenMP thread count and affinity, and recommends preloading LLVM’s libomp instead of the default GNU OpenMP for better performance. So “same CPU, different stack, which is faster?” does have an answer, but the answer is about the stacks.

Changing the software half on purpose (a different runtime or inference engine on the same hardware) changes the executor, which is engineering work, not measurement. TechnoLynx covers it in how an inference engine shapes the port decision and in porting AI inference across runtime and hardware without a model swap.

Reading AMD’s and Intel’s own AI claims

Vendor comparisons between EPYC and Xeon are comparisons of stacks, and the footnotes are where the conditions live. AMD’s EPYC 9005 datasheet claims up to 1.9× the XGBoost inference throughput for servers with two 192-core EPYC 9965 CPUs versus two 128-core Xeon 6980P CPUs, with a footnote reference attached. The same datasheet claims up to 13% faster time-to-first-token for an 8-GPU server with an EPYC 9575F host than for one with a Xeon 6960P host.

One AMD comparison pits internally tested AMD and Intel systems against an AWS Graviton5 instance. AMD itself notes that its cloud-instance results may not be directly comparable to physical server configurations because of differences in firmware, operating environment, memory configuration and system tuning. One disclosure pairs AOCC 5.1 with AOCL on the EPYC parts against the Intel compiler with MKL on the Xeon. Intel’s MLPerf statement carries the matching caveat that performance varies by use, configuration and other factors.

None of this makes the claims false. It makes each one a vendor’s result for an executor the vendor chose, valid under its stated conditions and silent about yours. We would treat each claim as a hypothesis to measure, and we hold no AMD-or-Intel ordering beyond what a measurement shows.

How do you keep optimisation effort from becoming the hidden variable across vendors?

Optimisation effort stays out of the result only if it is fixed before anyone knows which vendor’s hardware will run the test, and then applied identically to all of them. LynxBenchAI prepares its benchmarked models once, before any target device is known, and ships the same prepared artefacts to every vendor’s hardware. Where two vendors’ kernels disagree about what is permissible, the stricter constraint applies to everyone instead of being set per vendor. Correctness is checked per test type and precision. Generic benchmark logic is kept separate from platform-specific adaptation, and a workload that fails or times out is recorded as a zero, not dropped.

The reason is mechanical. A CPU offers a lot to tune: thread affinity, NUMA placement, memory allocator and OpenMP runtime. If one side of an AMD vs Intel comparison gets tuned and the other doesn’t, the gap measures the tuning.

Established benchmarks constrain optimisation in different ways. SPEC CPU 2017’s base metrics require one common set of optimisations across a suite, to reflect a user who wants performance without tuning each program. MLPerf’s Closed division holds the model mathematically equivalent to the reference. It still allows arbitrary frameworks, runtimes and matrix-multiplication algorithms. That difference matters when MLPerf and LynxBenchAI results sit side by side. MLPerf permits that tuning, while a LynxBenchAI result uses the same prepared artefacts on every vendor’s hardware. Whether SPEC CPU itself says anything about AI inference is a separate question, covered in what the SPEC CPU benchmark measures for AI inference.

What has to be recorded alongside a CPU benchmark number?

A CPU benchmark number stays meaningful to someone else only if the conditions that produced it travel with it. SPEC’s run rules state that a report of observed performance is meaningful only if the conditions of observation are stated. For an AI workload on a CPU, the record we would keep beside every number is:

• The processor’s formal name, precise enough for someone else to order the same part.
• The backend the framework dispatched to: CPU, cuda, cuda via ROCm, or xpu.
• Firmware and BIOS settings, plus every configuration choice that differs from default.
• The memory configuration wherever the buyer has choices, such as DIMM count, size and which sockets are populated.
• OS and runtime tuning: kernel options, environment variables, and OpenMP thread count and affinity.
• The platform, native Linux or WSL2, which the RTX 5090 pair in the 26Q3 results shows is not a detail.
• The framework and its version, plus any performance libraries such as tuned math libraries or allocators.
• The precision each figure was taken at, since one CPU can score very differently across formats.
• For a LynxBenchAI score, the release name, because scores compare only within a release (26Q3 to 26Q3).

Versions matter for more than speed. PyTorch’s documentation states that completely reproducible results are not guaranteed across PyTorch releases, individual commits or platforms, or between CPU and GPU executions, even with identical seeds. You don’t have to collect all of this by hand. MLCommons’ mlperf-sysinfo probes CPU, memory, accelerators, node counts and framework version automatically, and warns when the hardware and software notes are empty.

A LynxBenchAI run records the device, the backend and the software present on the machine alongside the number. Installing the same package makes that record reproducible on ordinary consumer hardware. It does not record thermal state or settled clocks, so note those yourself if they matter to your comparison.

A single number is also a single draw. Pham et al. (ASE 2020) trained the same network 16 times on identical hardware with identical library versions and all algorithmic randomness disabled, and accuracy still ranged from 77.3% to 80.2%. Inference has its own version of this, with BF16 LLM outputs shifting with batch size, GPU count and GPU type. Each LynxBenchAI test is one timed window, so a small gap between two executors deserves repeat runs on your side before it decides a purchase.

Where does the hardware-versus-software framing stop being useful for CPU selection?

The hardware-versus-software split stops being useful the moment you need a number, because no number exists for either half alone. Before that point, the split helps you ask what the silicon offers and what the stack exploits. AMD’s datasheet credits the EPYC 9005’s full 512-bit data paths with running a broad class of AI workloads on CPU-only infrastructure. Whether that width shows up in your result depends on whether the framework’s kernels use it, the same dependence the quantisation study found for INT8 on CPUs without matching instruction support.

Hardware choice still matters. A capable chip under a stack that ignores its capabilities and a weaker chip under a well-matched stack can both mislead you if you read only one half. The split also hides portability cost. The 2023 “Grand Illusion” study found that mainstream ML frameworks can lose more than 40% of their key functions when ported to other hardware, with extreme slowdowns even where functions do port.

For CPU selection, the decision unit is the executor you will deploy: the CPU plus the framework build, runtime and settings your team will run on it for the life of the hardware. If the real question is whether a CPU is the right device class for the workload at all, see CPU versus GPU for AI workloads.

Putting two candidate CPUs on the same footing

For a server purchase, the silicon is fixed the day it arrives, but its software keeps improving. So we would put the deployment stack, not the processor list, at the top of the comparison. Install the Personal Edition (pip install lynxbench-ai) on each candidate, run it under the stack you intend to ship, and compare the two executors within one release. Two things remain for you: the shape of your own model and the tuning of your own deployment. No published score, ours included, can stand in for those.