AMD published its HEPA comparison on August 3, 2026, describing testing performed in July. A later Back End News report repeated the figures, but the performance and cost claims originate with AMD’s vendor disclosure. The AMD post does not provide a public corpus download, runnable harness, raw per-run timings, or variance data, and the independent reviews consulted here test different workloads rather than reproducing HEPA.
What AMD actually measured
AMD’s custom HEPA benchmark uses a fixed corpus of synthetic enterprise files. The stated workload begins with 302 local source files, prepared into 801 chunks, and uses local OCR, embedding, routing, and language-model processing. AMD identifies Qwen3.6-35B-A3B running through llama.cpp, FastEmbed ONNX with nomic-embed-text-v1.5, and Tesseract OCR as components of the workflow.
On AMD’s disclosed systems, the Ryzen AI Halo developer box with a Ryzen AI Max+ 395 completed the workflow in 311.6 seconds. NVIDIA DGX Spark took 367.1 seconds. That is a 55.5-second gap, which AMD describes as 15% faster end-to-end completion.
AMD also says both machines completed five valid runs and passed 25 deterministic quality checks. Those details matter. An agent benchmark that only measures speed could reward a machine that produces an incomplete or incorrect result. The reported checks are at least evidence that AMD attempted to compare valid workflow outputs rather than treating raw throughput as sufficient.
The published post identifies the corpus structure and software components, but it does not include a public corpus download, runnable benchmark harness, raw timing from each run, or variance measurements. As a result, outside readers can assess the disclosed design and reported aggregate outcome, but cannot use the post alone to rerun the exact comparison. It also does not demonstrate that the result transfers to real corporate document repositories, different OCR and embedding choices, another agent framework, longer contexts, or multiple simultaneous users.
The result favors the CPU-heavy parts of this workflow
The most useful part of AMD’s disclosure is the stage-level breakdown. It shows why a single “local AI” headline can conceal sharply different hardware strengths.
AMD says seven of HEPA’s eight pipeline stages ran on the CPU. Only token generation ran on the GPU. In the CPU-side preparation portion, Halo recorded 152.1 seconds, compared with 229.9 seconds for DGX Spark. In embedding and routing, AMD reports 71.5 seconds for Halo and 139.6 seconds for Spark.
DGX Spark, conversely, was faster in generation: 137.2 seconds, versus 159.5 seconds for Halo. In other words, the system that won AMD’s total workflow did not win the model-generation stage. Halo’s advantage in the numerous CPU-side steps more than offset its slower generation time in this particular pipeline.
That distinction has practical consequences. A local assistant that spends substantial time extracting text from files, preparing chunks, creating embeddings, selecting material, and orchestrating tool calls may resemble HEPA more closely than a pure chatbot benchmark does. For that use case, CPU performance and the efficiency of supporting software can matter as much as, or more than, the rate at which a model emits tokens.
A user running a long-context assistant, a concurrent inference server, or a workload dominated by generation should not infer the same outcome. AMD’s own stage figures argue against that assumption: DGX Spark led the generation segment in the test that Halo won overall.
This was not a CPU-only comparison
The proposed framing of this story as Ryzen versus NVIDIA’s processor platform needs an important qualification. HEPA compared complete systems with different software and hardware configurations.
AMD used Debian 13 and Vulkan on the Halo system, with LPDDR5-8000 memory. DGX Spark used Ubuntu and CUDA with LPDDR5-8533 memory. The systems also used different drivers and inference backends. These are not incidental variables in local AI. Operating-system scheduling, memory behavior, driver maturity, GPU API selection, and backend implementation can all affect individual stages and the final completion time.
Consequently, the benchmark supports a narrower, defensible conclusion: Halo finished AMD’s HEPA workflow faster in the exact configurations AMD disclosed. It does not establish that the Ryzen CPU alone created the 55.5-second advantage, or that a different operating system and software stack would preserve it.
That is not a trivial criticism of the result. Whole-system testing is often closer to what a buyer deploys than a narrowly isolated component test. The mistake would be treating it as both things at once: a realistic application result when convenient, and definitive evidence of CPU architecture superiority when making broader claims.
For Windows readers, there is an additional limitation. The published comparison ran on Debian and Ubuntu, not Windows. It therefore provides no direct measurement of the same workflow under Windows, its drivers, or a Windows-oriented local-AI stack. The test can inform a hardware shortlist, but it cannot substitute for testing the intended Windows software environment.
Independent results support a workload-specific view
The available third-party testing points toward a more balanced conclusion than either a Halo or DGX Spark victory lap would suggest.
StorageReview found Halo ahead in several CPU-focused workloads: 11% in 7-Zip compression, 38% in 7-Zip decompression, and 14% in LLVM compilation. Those results are directionally consistent with AMD’s HEPA breakdown, where CPU-centric preparation, embeddings, and routing were the major sources of Halo’s end-to-end lead.
The same independent testing also found Spark ahead in several sustained memory-bandwidth tests. In concurrent vLLM inference profiles, Spark was substantially ahead as well. Separately, Tom’s Hardware reported that Halo’s time to first token fell substantially behind GB10 as context length increased, while noting an edge for Halo’s 16-core CPU in Geekbench CPU performance.
These findings do not refute AMD’s HEPA result. Rather, they explain why it should not become a universal local-AI conclusion. A system can be very competitive at CPU-driven document ingestion and orchestration yet trail on concurrent model serving, sustained bandwidth-sensitive work, or long-context response latency. The buyer’s workload mix is the decisive variable.
For a small team building a private research assistant that processes documents in batches, the time spent before generation may be consequential. For a developer serving several users at once or prioritizing responsiveness against expanding context, the independent inference measurements deserve more weight. A lab evaluating either machine should reproduce its own sequence of tasks instead of choosing based on a single aggregate score.
The cost-per-workflow claim is narrower than it looks
AMD also presents Halo as cheaper per completed workflow: $0.0132, versus $0.0182 for DGX Spark. The calculation uses a $3,999 Halo price and a $4,699 Spark price, assumes three years of continuous use, and excludes energy costs.
The $4,699 Spark figure matches NVIDIA’s marketplace listing and reflects the manufacturer’s February 2026 increase of the DGX Spark Founders Edition MSRP from $3,999. NVIDIA attributed that change to memory supply constraints. So the price input is not arbitrary, but it is time-sensitive: any future change in pricing would change the result.
More significantly, the comparison is not storage-equivalent. The reviewed $3,999 Halo configuration is listed with a 2TB M.2 SSD, while the DGX Spark listing specifies a 4TB self-encrypting NVMe M.2 drive. Storage capacity and security features can carry material value in a machine intended to hold local documents and models. Comparing acquisition prices without accounting for that difference makes the cost advantage less clean than the headline suggests.
The calculation also is not a total-cost-of-ownership estimate. It excludes electricity, support, storage expansion, downtime, administrative effort, and the cost of software integration. Assuming continuous operation for three years converts purchase price into a very small amortized amount per workflow, but that mathematical model may not resemble an organization that only uses the machine during business hours or has demand that varies widely.
AMD’s figures are still useful as a transparent acquisition-price-and-time illustration. They are not sufficient evidence that Halo will be 27% cheaper to operate in a real deployment.
What Windows and enterprise buyers should test
A prospective buyer should first classify the intended job. If it is mostly local document ingestion, OCR, embedding, retrieval, and agent orchestration, HEPA’s structure is relevant and Halo’s reported CPU-side advantage warrants investigation. If the priority is multi-user serving, long-context interactivity, or generation-heavy work, the independent results caution against assuming that the same advantage remains.
Second, test the actual software stack on the intended operating system. Windows users in particular should request or run measurements using the chosen local inference engine, model, embedding method, document types, context size, and driver version. A result on Debian with Vulkan cannot predict a Windows deployment with confidence merely because the hardware name is the same.
Third, measure end-to-end latency rather than only tokens per second. A practical workflow should include document import, OCR where applicable, chunking, embeddings, retrieval, prompt assembly, generation, and validation. It should also include a quality check that makes it clear whether faster output is equally usable output.
Finally, compare like-for-like configurations. Match storage capacity where possible, account for energy and support, and test expected concurrency. Buyers should also preserve raw timings and variation between runs. Those steps would turn the useful insight in AMD’s HEPA disclosure into a decision grounded in a specific deployment rather than marketing shorthand.
AMD has made a credible case that Ryzen AI Halo can be faster on its CPU-heavy, local enterprise-agent benchmark. The evidence does not justify the broader claim that it is faster for local AI in general, nor does it isolate the Ryzen CPU as the sole reason for the outcome. For Windows and enterprise users, the central lesson is more valuable than a single percentage: local AI performance is an end-to-end property of the workload, memory, software stack, operating system, and hardware together.
