DGX Spark TFLOPS measured: NVIDIA's 1 PFLOP FP4 figure against matmul, burn and prefill tests

NVIDIA's 1 PFLOP is FP4 with 2:4 sparsity, and a register-resident microbenchmark does reach it: nvfp4bench measured 973 to 1,022 TFLOPS sparse and 486 to 511 TFLOPS dense NVFP4 on Founders Edition, HP, ASUS and Lenovo GB10 units in June 2026. Real matrix multiplies land far lower, at 356 TFLOPS for a CUTLASS 4.4 NVFP4 GEMM, 188 for FP8, and 77 to 99 TFLOPS for a sustained PyTorch BF16 matmul. LLM prefill uses 24 to 166 TFLOPS by my calculation, about a fifth of an RTX 5090 on the same llama.cpp test.

TFLOPS on one GB10. NVIDIA's hardware documentation gives only "up to 1 PFLOP at FP4 precision with sparsity" and 6,144 CUDA cores. The FP8 and BF16 peaks are my derivation from the usual 4:2:1 ratio of FP4 to FP8 to 16-bit tensor rates; the FP32 peak is 6,144 cores x 2 operations x 2.418 GHz, the clock clpeak reports.

Does the DGX Spark really reach 1 PFLOP?

Yes, but only with packed NVFP4, 2:4 structured sparsity and no memory traffic at all. nvfp4bench runs back-to-back warp-level matrix instructions on values held in registers, so it measures the tensor cores alone. Owners posted results from four makers' units within three days:

TFLOPS from nvfp4bench --peak, posted in the NVIDIA forum thread between 17 and 19 June 2026. The author reports the unit ran at about 2.6 GHz under load.

Three details from the thread matter if you write kernels. The headline needs the packed mxf4nvf4 instruction with two FP4 values per byte; the byte-padded mxf8f6f4 path most hand-written code starts from runs at exactly half rate, the same rate as FP8. GB10 has no tcgen05 instructions or tensor memory, so FP4 runs on the warp-level path that consumer Blackwell uses. And the build must pass -gencode=arch=compute_121a,code=sm_121a; the -arch=sm_121a shorthand can silently drop the "a" and lose the FP4 instructions. Tom's Hardware called the sparse figure "mostly marketing"; the silicon does reach it, but no LLM measurement on this site uses 2:4 sparse weights.

Dense, sparse and the precision ladder

Dense FP4 is half the sparse figure, FP8 half of dense FP4, and 16-bit half of FP8, as far as the measurements show. clpeak's Vulkan cooperative-matrix tests read 240.7 TFLOPS in FP8 E4M3 and 120.9 in BF16 on driver 610, and its CUDA FP8 test 237 to 239. That matches the 125 TFLOPS dense BF16 that John Carmack assumed when he reported the Spark delivering about half of it, in a post quoted on the NVIDIA forum.

One outlier: mmapeak, run in a CUDA 13.0.2 container in November 2025, reported 212.9 TFLOPS for BF16 with FP32 accumulate and 427.3 for NVFP4 (NVIDIA forum). On an RTX 5090, main-horse found the same tool reporting 370.6 TFLOPS for that BF16 instruction with zero-filled inputs and 187.4 with random ones (main-horse, April 2025). My inference is that the GB10 BF16 figure is inflated the same way; the run does not say which inputs it used.

Off the tensor cores, clpeak measured 29.7 TFLOPS FP32 on OpenCL and 30.6 on CUDA, and about 485 GFLOPS FP64. The Arm CPU beats that FP64 figure in Linpack, as the planned GB10 CPU performance guide shows.

What do real matrix multiplies reach?

About 70 to 80% of the dense peak in the best tuned kernels, and much less in everyday frameworks. The measured results, by tool:

Shares are my arithmetic against the dense peaks in the first table (500 FP4, 250 FP8, 125 BF16). The training row is model FLOPs utilization as the poster computed it.

The ceiling on real kernels is mostly shared memory. GB10 has 101,376 bytes per SM, the same as an RTX 4090, against 228 KB on datacenter Blackwell, so tiles must be smaller, and SGLang's default MoE configurations that request about 147 KB fail outright until replaced with tuned ones, per the CUTLASS thread. The nvfp4bench author adds that large square GEMMs of 8192 cubed and up throttle thermally, so his tool reports burst and sustained results separately.

Peak or sustained: power, clocks and stuck units

A healthy unit sustains about 80 to 99 BF16 TFLOPS for tens of seconds; a unit stuck in a low-power state delivers a tenth of that with no error. A forum reply that said NVIDIA was updating its documentation to match gave the GPU's power limit as 120 W, with the rest of the system allowed 100 W of the 240 W supply (November 2025). Healthy GX10 units ran the 45-second BF16 test at 89 to 92 W and about 2.3 GHz.

Two failure states are documented. Two of eight GX10 units in one cluster ran at 851 MHz, 20.7 W and 42.5 TFLOPS for days, with no throttle reason reported (October 2026). A DGX Spark reference unit sat at 507 MHz, 35 W board power and 9.4 TFLOPS until a reboot raised its readable power limits from 20 W to 140 W and it measured 98.6 TFLOPS, 10.5 times more (August 2026).

Firmware also moves the burn number. After the September 2026 update, Petronella's eight units fell about 11% on a 15-second FP16 burn while Qwen3.8-27B NVFP4 decode rose 4 to 8%. Compute and decode answer to different limits. Long-run thermals by maker are the topic of the planned sustained performance by OEM guide.

How does measured compute show up in prefill?

Prefill is the compute-bound phase, and engines use between 24 and 166 TFLOPS of it, by my calculation. A forward pass costs about 2 FLOPs per active parameter per token, so effective TFLOPS is 2 x active parameters x prefill tok/s. Attention adds a few percent at these prompt lengths, so these figures slightly understate the work.

Active parameters are the nominal sizes in the model names (A3B = 3B, A12B = 12B, about 5B for gpt-oss-120b per Dendro Logic). My arithmetic, not a measurement of utilization.

The pattern is about the kernel path more than the chip. TensorRT-LLM computing in NVFP4 uses about a third of the 500 TFLOPS dense FP4 peak, and SGLang in FP8 about half of the 250 FP8 peak. AWQ in vLLM typically runs Marlin kernels that dequantize 4-bit weights and multiply in 16-bit, and llama.cpp multiplies its quantized types in 8-bit integers; both land at 34 to 55 TFLOPS-equivalent, under half the 125 TFLOPS 16-bit peak and under a quarter of the 242 TOPS INT8 rate clpeak measured. Mixture-of-experts models land lowest; in my reading, routing splits the work into small grouped GEMMs, the same effect as the 120 to 154 TFLOPS grouped-GEMM row above. Prefill also slows with depth, as the long-context guide shows, and the format-by-format speeds are in the planned quantization speed guide.

How do the RTX 5090 and RTX PRO 6000 compare by the same tests?

The RTX 5090 has two to five times the usable compute, depending on the test, and the RTX PRO 6000 slightly more again on prefill.

Ratios by my arithmetic: 3.45 times on mmapeak NVFP4, 2.2 to 2.9 times on the BF16 matmul, 4.6 times (RTX 5090) and 4.9 times (RTX PRO 6000) on llama.cpp prefill. The two matmul scripts differ in name and in run length, so read the BF16 row as a range. I found no fetchable matmul measurement for the RTX PRO 6000.

The prefill ratio is the one that shows up in daily use: a 4.6 times faster prompt phase on an RTX 5090, provided the model fits in its 32 GB. The comparisons on DGX Spark vs RTX 5090 and DGX Spark vs RTX PRO 6000 weigh that against the Spark's 128 GB.

My verdict: plan with about 100 TFLOPS BF16 and 350 TFLOPS NVFP4 for well-tuned kernels, not 1 PFLOP. For prefill-heavy work such as long-document extraction, pick a model with an NVFP4 checkpoint and an engine that computes in FP4, because the format path moves effective compute by three to four times on this chip. If prompt processing dominates and the model fits in 32 GB, an RTX 5090 is the faster tool.

FAQ

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.

• DGX Spark hardware overview, NVIDIA documentation
• GB10 really does hit ~1 PFLOP NVFP4 (2:4 sparse), measured, with an open-source tool, NVIDIA Developer Forums, 2026-06-17
• Detailed Compute Performance Metrics for DGX Spark (mmapeak output), NVIDIA Developer Forums, 2025-11-23
• SM121 CUTLASS Kernel Optimization Results: NVFP4 356 TFLOPS, MoE Grouped GEMM on DGX Spark, NVIDIA Developer Forums, 2026-02-07
• Ubuntu 26.04 + drivers 610 + cuda-toolkit 13.3 + ZFS on GX10 (clpeak results), NVIDIA Developer Forums, 2026-06-25
• Is your GB10 stuck in low-power mode? A free 45-second check, NVIDIA Developer Forums, 2026-10-26
• Investigating 513MHz cap for GPU, NVIDIA Developer Forums, 2026-08-21
• Only getting half the advertised performance and capping at 100W?, NVIDIA Developer Forums, 2025-11-22
• Is Megatron training with Nemo/Megatron connector unsupported on GB10?, NVIDIA Developer Forums, 2026-05-07
• DGX Spark firmware update: what we learned on 8 GB10 units, Petronella Technology Group, 2026-09-26
• 5090 mm perf, main-horse, 2025-04-12
• How NVIDIA DGX Spark's Performance Enables Intensive AI Tasks, NVIDIA Technical Blog, 2025-10-24
• NVIDIA DGX Spark In-Depth Review, LMSYS, 2025-10-13
• vLLM on the DGX Spark: Architecture, Configuration, and Local Evaluation, vLLM blog, 2026-06-01
• Performance of llama.cpp on Nvidia CUDA, ggml-org/llama.cpp discussions, 2026-10-16
• DGX Spark benchmark results (llama-bench), ggml-org/llama.cpp on GitHub, 2026-02-05
• Benchmark Dell Pro Max with GB10, ai-benchmarks issue 34, Jeff Geerling on GitHub, 2025-11-22
• GeForce RTX 5090, NVIDIA
• NVIDIA RTX PRO 6000 Blackwell Workstation Edition, NVIDIA
• Nvidia DGX Spark review, page 2: Going deep on the GB10 Superchip, Tom's Hardware, 2026-01-27