July 2026
Lucebox (AMD Radeon AI PRO R9700 + Strix Halo) Beats NVIDIA DGX Spark by 3.63x on DeepSeek V4 Flash Decode Speed
51.1 tok/s (Lucebox) vs 14.09 tok/s (single DGX Spark)
- 51.1 tok/s on Lucebox against 14.09 tok/s on one DGX Spark: 3.63× the decode speed.
- Same model, 284B parameters, one request at a time. Each machine runs its own tuned setup.
- Two AMD GPUs split the work. The R9700 takes the hot path, Strix Halo holds the rest of the experts.
- $5,999 against $4,699 for one DGX Spark: 28% more, about 2.8× the decode per dollar.
DeepSeek V4 Flash decode comparison
| System | Tested configuration | Decode throughput |
|---|---|---|
| Lucebox | ROCmFPX compressed model, DSpark draft model, four experts per token | 51.1 tok/s median |
| 1× NVIDIA DGX Spark | Q2 compressed model, average of tests at four context lengths | 14.09 tok/s |
| Measured ratio | 51.1 ÷ 14.09 | 3.63× |
The 3.63× ratio uses the unrounded DGX Spark mean of 14.0875 tok/s. Each platform runs the setup tuned for its own hardware. This is a whole-system comparison, not a GPU-only A/B test.
Decode throughput is the rate at which a system writes new tokens.
DeepSeek V4 Flash has 284 billion parameters. Its 102.3 GB ROCmFPX build does not fit the R9700’s 32 GB.
So the two AMD GPUs take different jobs. The R9700 runs the dense path and the experts picked most often. Strix Halo holds the rest in its 128 GB and runs them in parallel.
The headline is the median of three requests, after two warmups, on a ~2k-token prompt with 128 generated tokens.
An 11.3 GB DSpark draft model proposes several tokens at once. The full model checks them before they are accepted. A separate 53-token prompt measures the upper end.
For the single-device baseline and the ROCmFPX compression details, see our companion report on DeepSeek V4 Flash on AMD Ryzen AI MAX+ 395.
Complete system price
AMD-Powered Lucebox costs $5,999 as a complete system: custom chassis, 2 TB of storage, power delivery, integration, validation and warranty. NVIDIA lists one DGX Spark at $4,699, or $9,398 for two.
| Complete system | Current U.S. price | What is included |
|---|---|---|
| 1× DGX Spark | $4,699 | Complete system with 4 TB storage |
| AMD-Powered Lucebox | $5,999 | Custom chassis, 2 TB storage, power delivery, integration, validation, and warranty |
| 2× DGX Spark | $9,398 | Two complete systems |
At list prices Lucebox costs 28% more than one DGX Spark. In the headline setups it delivers about 2.8× the decode throughput per dollar, and it costs 36% less than two DGX Sparks.
Prices are the U.S. list prices available at publication, before tax and shipping. Sources: Lucebox system configuration and NVIDIA Marketplace. Configurations and prices can change.
One DGX Spark, measured directly
We ran a Q2 compressed version of the full DeepSeek V4 Flash model on one DGX Spark. We then measured Lucebox at the same 2k, 4k, 8k, and 16k context lengths.
| Context | Lucebox | 1× DGX Spark | Speedup |
|---|---|---|---|
| 2k | 51.0 tok/s | 14.18 tok/s | 3.60× |
| 4k | 49.6 tok/s | 14.24 tok/s | 3.48× |
| 8k | 47.5 tok/s | 14.04 tok/s | 3.38× |
| 16k | 42.9 tok/s | 13.89 tok/s | 3.09× |
| Mean | 47.75 tok/s | 14.09 tok/s | 3.39× |
The DGX Spark mean is 14.0875 tok/s, reported as 14.09 tok/s. Lucebox averages 47.75 tok/s over the same four context lengths, a 3.39× speedup. The 3.63× headline comes from the separate 51.1 tok/s serving result above.
DGX Spark ran the Q2 model. Lucebox ran the ROCmFPX model with four experts per token and DSpark speculative decoding. Each system uses the setup designed for its hardware.
For wider context, LocalMaxxing includes two-DGX-Spark results both with the standard target and with a DSpark-specific package. We show both below rather than selecting the more favorable reference.
The public two-Spark results bracket Lucebox. The standard target ties with our longer decode run; the DSpark-specific package is faster. Useful reference points, not a matched benchmark.
How the work is split
Tensor parallelism splits the same calculation evenly between matching GPUs. That fails here: the R9700 and Strix Halo differ in speed and memory, so an even split leaves the R9700 waiting.
Splitting the model into whole layers is slow too. Every token would cross one device, then the other.
DeepSeek V4 Flash is a mixture of experts model. Each layer holds 256 expert blocks, and only a few run per token, four in these tests.
Each expert lives on one GPU. At every layer both GPUs run the experts they hold, then the R9700 combines the results.
- Core layers used for every token
- Most frequently selected experts
- DSpark helper model
- Working cache and final token selection
- Remaining expert blocks
- Runs only experts selected for the current token
- Runs at the same time as the R9700
- No duplicate copy of the working cache
Ownership follows the hardware. The experts picked most often sit beside the dense path on the R9700; the long tail lives in Strix Halo’s larger memory.
One process submits both branches and copies the Strix Halo result straight to the R9700, which combines them. The R9700 alone owns the target cache and the sampler.
How the short test reached 55 tok/s
The largest gain came from checking four DSpark positions in one GPU operation. A generic safety rule had split that work into groups of three and one, although this path handles all four at once.
Removing the split kept the verifier in a single graph. Batched transfers and expert grouping supplied the rest.
The fused four-position verifier made the decisive jump. Batched peer transfers cut synchronization, and grouping Strix Halo routes by expert stopped rereading the same compressed weights.
The final path also joins results and picks the next token on the GPU, reusing state DSpark already computed.
Test Setup: DeepSeek V4 Flash 284B, Asymmetric Expert Parallelism
Asymmetric expert parallelism means the two GPUs are assigned different work rather than equal slices of every operation.
one machine
one process, two GPUs
4 experts per token
temperature 0 for repeatability
128 output tokens
415.52 tok/s prompt processing
128 output tokens
prompt caches disabled
full model: 64.8 to 65.1 ms
510 output tokens
41.8 to 45.7 range
The server reported exactly 2k, 4k, 8k and 16k prompt tokens for the sweep. Every measured request produced the same 128-token response, byte for byte, at a 0.97 draft acceptance rate.
The 16k point ran in a fresh process, same binary and settings.
The short-prompt result is a ceiling test. It uses 53 prompt tokens and 128 generated tokens, with every DSpark proposal accepted.
A harder shape follows. Five measured requests used a ~2k-token prompt and generated 510 tokens.
Decode ranged from 41.8 to 45.7 tok/s, with a 45.5 tok/s median. All five produced the same response, byte for byte.
The target was DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf; the draft was DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf. The build passed all 20 automated tests, including end-to-end coverage for regular and streamed DSpark requests.
Benchmark scope. Throughput was measured with four routed experts per token. Repeated runs were deterministic; comparison with the six-expert reference configuration was outside the scope of this performance benchmark.
Prompt processing: 415.52 tok/s with DSpark loaded
Prompt processing, or prefill, is the work done before the first generated token. The 11.3 GB DSpark draft sits on the R9700.
Three measured requests after two warmups reached a 415.52 tok/s median, inside a narrow 415.46–415.95 tok/s range.
The progression below separates hardware placement from implementation changes. The first two-GPU path joined both outputs on the CPU.
The faster path keeps the R9700 output in device memory, copies only the Strix Halo partial, and joins on the R9700.
Moving the join off the CPU improved the target-only path by 6.8%. With DSpark loaded, the first R9700-join build ran 23.7% faster than the Strix-only baseline. Transfer and kernel work produced the final result above.
Why heterogeneous hardware works here
The architecture is the point. Strix Halo is an active expert engine, not overflow memory, and the R9700 keeps the latency-sensitive path. Sparse routing makes the uneven split work: each processor gives what it has, bandwidth, capacity or compute.