DGX Spark/Guides/CPU performance
Performance · November 2026

DGX Spark CPU performance: GB10 benchmarks against Strix Halo, Apple M5 and desktop x86

By Samuel Seidel · Published November 7, 2026 · Sources checked November 7, 2026

The GB10's 20 Arm cores score 3,123 single-core and 19,708 multi-core in Geekbench 6 on a Dell Pro Max GB10 (Jeff Geerling, November 2025): level with a Ryzen AI Max+ 395 on one core, about 10% behind it and a Core Ultra 7 265K on all cores, and 32% behind an Apple M5 Max (4,267 and 29,197) on all cores. In CPU Linpack it does 675 GFLOPS, 2.2 times the Ryzen AI Max+ 395. For serving a model on the GPU the CPU barely matters; it matters for model loading, source builds and preprocessing.

MachineCPUGeekbench 6 singleGeekbench 6 multiHPL (wall power)SourceDate
Dell Pro Max GB1010x Cortex-X925 + 10x Cortex-A7253,12319,708675.39 GFLOPS (155 W)sbc-reviews #922025-11-21
Framework DesktopRyzen AI Max+ 395, 16 cores3,03021,922307.84 GFLOPS (135.7 W)sbc-reviews #802025-08-07
Custom PCCore Ultra 7 265K, 20 cores3,34021,726741.10 GFLOPS (273 W)sbc-reviews #932025-11-25
Mac miniApple M4, 10 cores3,67814,678299.93 GFLOPS (39.6 W)sbc-reviews #572024-11-11
Mac StudioApple M3 Ultra, 32 cores3,26527,7981,278.6 GFLOPS (213 W)sbc-reviews #952025-12-08
Mac StudioApple M5 Max, 18 cores4,26729,197not publishedGeek Culture2026-09-21

All rows except the M5 Max are Jeff Geerling's runs with one method: Geekbench 6 and his top500-benchmark HPL, which is FP64 Linpack on the CPU cores, with wall power during the run. Geerling notes that Geekbench 6 stalled on the GB10 three times before a run completed, and that an earlier NVIDIA DGX Spark run scored 3,237 and 19,794. The M5 Max figures are from a different reviewer. Phoronix's and OpenBenchmarking.org's GB10 pages did not load for me while writing this, so they are not included.

What CPU is inside the GB10?

Twenty off-the-shelf Arm cores, not Neoverse server cores: 10 Cortex-X925 and 10 Cortex-A725 per NVIDIA's documentation, in a MediaTek-designed complex per Tom's Hardware. They sit in two clusters of five X925 plus five A725 each. Chips and Cheese measured the details:

ItemCortex-X925Cortex-A725
Clockup to 3.9 GHz (cluster 0), 4.0 GHz (cluster 1)2.8 GHz
L2 per core2 MB, 12 cycles512 KB, 9 cycles (3.2 ns)
L3 latencyabout 14 nsover 21 ns
DRAM bandwidth, one core38 GB/s26 GB/s
Shared cachesL3 of 8 MB (cluster 0) and 16 MB (cluster 1); 16 MB system-level cache
DRAM latency113 ns, against over 140 ns for Strix Halo
Core-to-core latency50 to 60 ns in a cluster, up to about 200 ns across clusters (240 ns worst case)

From Chips and Cheese, 31 December 2025, measured over SSH on one DGX Spark.

The cross-cluster latency is the detail that matters for software. A job whose threads share data constantly pays up to four times the in-cluster latency when its threads land on different clusters, so pinning a tightly coupled job to one cluster can help.

How does it score against Ryzen AI Max+ 395, Apple M5 and x86?

On one core it matches the Ryzen AI Max+ 395 and trails Apple's newest chip by about a quarter; on all cores it trails both. By my arithmetic from the table: single-core is 3% above the Ryzen AI Max+ 395, 7% below the Core Ultra 7 265K and 27% below the M5 Max. Multi-core is 9 to 10% below the Ryzen and the 265K, 29% below the M3 Ultra and 32% below the M5 Max, and 34% above the 10-core M4.

The multi-core score is 6.3 times the single-core score with 20 cores, against 7.2 times for the Ryzen's 16 cores and 32 threads. My reading is that the ten A725 cores add less than ten more X925 cores would, which is what an efficiency core is for. If a job only uses a few threads, pin it to X925 cores; lscpu -e shows them by their higher MAXMHZ.

Why does Linpack favour the GB10 so much?

Because HPL is dense FP64 matrix maths, and the GB10's cores do it efficiently: 675.39 GFLOPS at 155 W at the wall, 4.36 GFLOPS per watt, against 307.84 GFLOPS and 2.27 GFLOPS per watt for the Ryzen AI Max+ 395 and 741.10 GFLOPS at 273 W for the Core Ultra 7 265K, in Geerling's runs. Two GB10 systems together reached 1,333.2 GFLOPS at 320 W, per his results table.

One consequence is easy to miss: for FP64, the CPU half of the chip is the faster half. clpeak measured the GB10 GPU at about 485 GFLOPS in FP64 (NVIDIA forum, June 2026), under the CPU's Linpack figure. Scientific code that needs double precision should run on the Arm cores; LLM work at FP4 to BF16 belongs on the GPU, where the planned TFLOPS measured guide picks up.

Does CPU speed affect LLM tokens per second?

Hardly, once the model runs on the GPU. A forum user who capped the performance cores at 2,600 MHz to cure 80 to 88 °C CPU temperatures under vLLM reported running llama-bench from 2,600 to 3,600 MHz in 200 MHz steps and seeing no real difference in prompt or generation speed, with the CPU now under 60 °C (NVIDIA forum, 26 September 2026). The CPU's job during serving is scheduling, tokenizing and HTTP, which a few cores cover.

It can still get in the way. vLLM builds on the forum kept two cores at 100% while idle until VLLM_SLEEP_WHEN_IDLE=1 was set (NVIDIA forum, March 2026), which is heat and power for nothing on a box that shares one cooling system between CPU and GPU.

CPU-only inference is a different matter, and slow. I found no published llama.cpp CPU-only result for GB10. As a labelled estimate: generation reads the whole model once per token, one cluster pulls a little over 100 GB/s per Chips and Cheese, so a 3.83 GB Llama 2 7B Q4_0 file tops out near 26 tok/s per cluster, against the 57 tok/s the GPU measures on the same file. For scale, Strix Halo ran that file at 28.94 tok/s on its CPU and 52.22 on Vulkan (llm-tracker.info). Since a Spark has no separate VRAM to overflow, CPU offload buys no capacity either; the bandwidth side is on the planned memory bandwidth measured page.

Where the CPU side slows you down: loading, builds and preprocessing

Model loading is the biggest CPU-side delay on a Spark, and it is the kernel's memory handling, not core speed. eugr measured it on the NVIDIA forum in November 2025:

LoadKernelWith mmapWithout mmapSourceDate
gpt-oss-120b, llama.cpp6.11 (stock DGX OS)1 min 44 s56 sNVIDIA forum2025-11-02
gpt-oss-120b, llama.cpp6.17.1-nvidia (built from NV-Kernels)1 min 30 s22 sNVIDIA forum2025-11-02
Qwen3-Next-80B-A3B-FP8, vLLM6.11 (stock)9 min 19 s2 min 11 sNVIDIA forum2025-11-05
Qwen3-Next-80B-A3B-FP8, vLLM6.17.1-nvidia8 min 41 s1 min 28 sNVIDIA forum2025-11-02

"Without mmap" is llama.cpp's --no-mmap and vLLM's --safetensors-load-strategy eager. A reply in the thread said the 6.17 kernel would reach DGX OS in January 2026 and advised no-mmap whenever the model fits in free memory.

Hugging Face transformers is worse by default: one owner reported from_pretrained taking over 10 minutes and doubling memory use, and disabling mmap made loading fast but needed two to three times the model's size in memory (NVIDIA forum, June 2026). Load with no-mmap options and move tensors to the GPU yourself.

Source builds come second. Many aarch64 and sm_121 packages have no prebuilt wheel, so pip compiles them, and one user's flash-attn build ran over two hours; a reply in the thread pointed out that long flash-attn builds are common on x86 too (NVIDIA forum, December 2025). With a multi-core score about 10% under a Ryzen AI Max+ 395, expect builds to take about as long as on that class of machine. Which wheels exist is covered in the planned PyTorch on DGX Spark guide, and the llama.cpp build page has the CMake flags.

Preprocessing, tokenizing a corpus or chunking documents, runs on these cores too, and I found no published GB10 tokenizer benchmark. It is a five-minute test:

# find the Cortex-X925 cores (higher MAXMHZ), then compare
lscpu -e
python3 -m pip install tokenizers
taskset -c <x925-cores> python3 -c "
import time; from tokenizers import Tokenizer
t = Tokenizer.from_pretrained('Qwen/Qwen3-Coder-30B-A3B-Instruct')
docs = ['lorem ipsum dolor sit amet ' * 400] * 2000
s = time.time(); enc = t.encode_batch(docs)
n = sum(len(e.ids) for e in enc); print(n / (time.time() - s), 'tokens/s')"

Heat and power under CPU load

A full CPU load draws about 115 to 155 W at the wall and can push the CPU sensor to its limit. Geerling measured the Dell GB10 at 31.5 W idle, 114.8 W during Geekbench multi-core, 127.1 W under stress-ng --matrix 0 and 155 W during HPL. On the NVIDIA forum, one owner saw CPU temperatures up to 100 °C and two crashes under vLLM after the 7.0.0-1019 kernel update, cured with a third-party fan-control tool; another capped the X925 clocks instead. Whole-system draw and fan noise are on the power and noise and cooling pages.

What applies on a rented Spark?

A rented instance is a Docker container on one dedicated Spark, so the 20 cores are the same and are not shared with another tenant. You are root inside it, and pip installs, llama.cpp builds and tokenizer jobs run normally. Host-level changes do not: the kernel and driver come from the host, and without privileged mode you cannot cap CPU clocks or install fan control, as the tenant environment page explains. The mmap advice applies unchanged.

My verdict: the GB10's CPU is a competent desktop-class Arm chip with unusually good FP64 Linpack efficiency and middling multi-core throughput. I would not buy a Spark for CPU work; a Ryzen AI Max+ 395 box has more multi-core for less money and an M5 Max more again, as the Strix Halo comparison covers. Buy it for the GPU, load models without mmap, and the CPU will stay out of the way.

FAQ

How fast is the DGX Spark CPU?

About as fast as a Ryzen AI Max+ 395 on one core and about 10% slower on all cores. Jeff Geerling measured a Dell Pro Max GB10 at 3,123 single-core and 19,708 multi-core in Geekbench 6 (November 2025), against 3,030 and 21,922 for a Framework Desktop with the Ryzen AI Max+ 395. An Apple M5 Max scored 4,267 and 29,197 in Geek Culture's review.

What CPU does the DGX Spark have?

Twenty Arm cores in the GB10: 10 Cortex-X925 performance cores and 10 Cortex-A725 efficiency cores, per NVIDIA, in two clusters of five plus five. Chips and Cheese measured the X925 cores at up to 3.9 to 4.0 GHz and the A725 at 2.8 GHz, with 2 MB of L2 per X925 core, 24 MB of L3 in total and a 16 MB system-level cache.

Does CPU speed matter for LLM inference on a DGX Spark?

Very little when the model runs on the GPU. One NVIDIA forum user capped the Cortex-X925 cores at 2,600 MHz and reported no difference in llama-bench prompt or generation speed between 2,600 and 3,600 MHz, while CPU temperature fell under 60 °C. The CPU matters more for model loading, source builds and data preprocessing.

Why does model loading take so long on a DGX Spark?

Memory-mapped loading is slow on its unified memory. In November 2025 tests by eugr on the NVIDIA forum, gpt-oss-120b loaded in llama.cpp in 1 minute 44 seconds with mmap and 56 seconds without on the stock 6.11 kernel, and in 22 seconds without mmap on a 6.17 kernel. vLLM loaded Qwen3-Next-80B in 8 minutes 41 seconds with mmap against 1 minute 28 seconds without.

Is the DGX Spark good for CPU-heavy work like compiling?

It is adequate, not a reason to buy one. In Jeff Geerling's runs its Geekbench 6 multi-core score of 19,708 trails a Ryzen AI Max+ 395 and a Core Ultra 7 265K by about 10%. Its CPU Linpack result of 675 GFLOPS at 155 W is strong, 2.2 times the Ryzen AI Max+ 395. A flash-attn source build still took over two hours for one forum user.

Sources

Every figure above is attributed to its source in the sentence or table where it appears. Pages were read on 7 November 2026 unless a date says otherwise.

First top-up: pay $20, get $30 in credit

Time your own build and model load.

Rent a Spark at $0.79 per hour, billed per minute, and run your compile, tokenizer or loading step on the same 20 cores before you buy one.

A dedicated DGX Spark in the EU, $0.79/hour, billed per minute. $30 of credit is about 37 hours of compute.

Create account See the full DGX Spark specs