July 2026
AMD-Powered Lucebox vs DGX Spark: up to 3.6× speedup for DeepSeek V4 Flash decoding
A Radeon AI PRO R9700 supplies the fast local-memory path. A 128 GB Ryzen AI MAX+ 395 supplies the capacity. Lucebox runs the two unequal GPUs as one system, placing each part of the 284B model where it executes best.
The reason for the pairing is practical. The 32 GB R9700 cannot hold the full model by itself, while Strix Halo alone has more capacity but lower decode throughput. Lucebox keeps the latency-sensitive path and selected hot experts on the R9700, assigns the remaining experts to Strix Halo, and runs both owners concurrently.
A measured fused q=4 profile reached 50.8 tok/s, a 3.6× speedup over our 14.04 tok/s single-DGX Spark reference after rounding. In the full serving configuration, with indexed sparse prefill and the 11.3 GB DSpark drafter resident, decode reached a 50.65 tok/s median. A separate short, perfect-acceptance ceiling test reached up to 55.0 tok/s, with warm runs of 54.7, 54.9, and 55.0 tok/s.
Complete-system price
AMD-Powered Lucebox is priced at $6,499 as a complete local-inference system, including the custom chassis, 2 TB of storage, power delivery, hardware 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 | $6,499 | Custom chassis, 2 TB storage, power delivery, integration, validation, and warranty |
| 2× DGX Spark | $9,398 | Two complete systems |
Against one DGX Spark, Lucebox costs 38% more and delivers 3.6× the measured decode throughput in our tested configurations—about 2.6× the throughput per listed dollar. Against two DGX Sparks, the complete Lucebox costs 31% less. Its 45.5 tok/s deeper-suite median is within 0.4% of the public 45.7 tok/s dual-DGX result using the official target; its integrated serving median reaches 50.65 tok/s. The tuned 65.09 tok/s dual-DGX DSpark result remains faster.
Prices checked July 21, 2026, before tax and shipping. Sources: Lucebox local-inference PC and NVIDIA Marketplace. Product configurations and prices can change. Performance figures use different prompts, runtimes, and quantization formats and are compared as complete configurations as tested.
Three parts of the Lucebox stack make this run possible. ROCmFPX brings the 284B target down to 102.3 GB. The expert scheduler gives the fast discrete GPU and the large-memory GPU different jobs. The boundary-aware DSpark verifier keeps all four verification positions, including the current seed, in one graph instead of splitting them into q=3 and q=1.
The two GPUs are useful precisely because they are different. The R9700 has fast local GDDR6 and strong small-batch compute. Strix Halo has a much larger 128 GB memory pool. Lucebox submits both expert owners at every mixture-of-experts layer. Profiling confirms that they execute concurrently, but not for equal durations: the R9700 branch is already hidden inside the longer Strix cold-expert branch, which remains the critical path.
This is one machine. There is no second node, network fabric, or matched pair of accelerators. The model occupies two separate memory domains, and the engine decides which device owns each piece of work.
The setup also includes an 11.3 GB DSpark drafter. The R9700 and Strix Halo provide enough total capacity, but it is not one flat memory pool and the devices are not equally fast. Lucebox places the target, drafter, and experts explicitly instead of relying on an even split.
One DGX Spark, measured directly
We also ran the full DeepSeek V4 Flash Q2 model on a single DGX Spark. Across 2K, 4K, 8K, and 16K context tests, generation measured 14.18, 14.24, 14.04, and 13.89 tok/s: a 14.04 tok/s average. Prompt processing averaged 385.42 tok/s.
The primary comparison uses the integrated Lucebox serving result, not the short ceiling: 50.65 divided by 14.04 is 3.6×. Both machines run the full model, with the inference path tuned for each platform. DGX Spark uses the Q2 path measured across four context lengths; Lucebox uses ROCmFPX, top-4 routing, and q=4 speculative decoding. This is a comparison of complete inference configurations as tested, not an isolated GPU A/B.
Public LocalMaxxing entries provide the two-machine context. Two DGX Sparks running the official target checkpoint reach 45.7 tok/s. Our deeper-suite median is 45.5 tok/s, effectively the same throughput; the integrated serving run reaches 50.65 tok/s. A newer two-DGX run built around a DSpark-specific checkpoint reaches 65.09 tok/s and remains faster.
So “dual-DGX Spark territory” is the fair claim. The deeper Lucebox suite is within 0.4% of the 45.7 tok/s official-checkpoint dual-Spark entry, while the integrated serving median is 10.8% above it. The tuned 65.09 tok/s dual-Spark DSpark result is still faster. We use these public runs as context, not as a controlled hardware shootout.
Asymmetric parallelism, on purpose
Conventional tensor parallelism starts with identical devices and cuts the same matrix operations across them. That is a poor fit here. If every operation is divided evenly, the R9700 waits for Strix Halo. If the model is split by whole layers, each token moves through the devices serially.
DeepSeek V4 gives us a better place to split the work. It is a mixture-of-experts model with 256 routed experts per layer. In this measured profile, only the top four routes are evaluated. Lucebox assigns each expert to an owner, splits a layer’s selected routes by that ownership, and submits both HIP backends before joining the results on-device.
- Dense target path and hyper-connections
- Selected hot routed experts
- DSpark drafter
- Single target KV/cache owner
- Remaining materialized experts
- Only the routes owned by this device
- Concurrent HIP execution per MoE layer
- No target KV/cache duplication
The hot experts stay beside the dense path on the R9700. The long tail lives in Strix Halo’s larger memory. Because routed experts are independent until their weighted outputs are combined, both devices can work at once without pretending they have the same speed or memory architecture.
The fastest path keeps both HIP backends in one process. We tested an earlier worker design that moved expert work through host IPC, but it added too much overhead. The current runtime joins the results on-device, while the R9700 remains the sole owner of the target cache and sampler.
Where the 55 tok/s ceiling came from
Asymmetric placement makes the model fit and keeps both GPUs active. The largest single jump came from preserving one fused q=4 verification graph; two hardware-specific changes then removed overhead from the Strix expert branch and the peer handoff.
DeepSeek V4 compresses its attention state at learned boundaries. A generic safety rule split any verification batch that crossed one of those boundaries. For a q=4 DSpark verification step, that turned one persistent graph into a q=3 submission followed by q=1. The fused verifier already understands the internal boundary, so this path now keeps all four positions together while retaining the generic split everywhere else.
The q=4 boundary fix moved decode from 37.5 to 50.8 tok/s. Publishing the three forward tensors behind one peer dependency raised it to 52.6 tok/s. Grouping the 16 token-route pairs by expert on Strix reduced repeated compressed-weight traffic and reached 54.9 tok/s. Other supporting changes include q≤4 ROCmFPX/MMVQ kernels, a fused hyper-connection and owner join, GPU argmax, pinned rollback, and reuse of DSpark’s context projection and KV state.
What we actually verified
one host
gfx1201 + gfx1151
target top-k 4
temperature 0
64.8–65.1 ms verify
510 output tokens
41.8–45.7 range
The 55 tok/s result is a deliberately short, deterministic ceiling test: 53 prompt tokens, 128 generated tokens, and 1.00 proposal acceptance. To test a less favorable shape, we also ran one warmup and five measured requests with 1,956 prompt tokens and 510 generated tokens. Server-side decode was 45.6, 45.7, 41.8, 45.5, and 45.4 tok/s: a 45.5 tok/s median. All five produced the same 510-token response hash.
The clean dual-architecture build passed all 20 CTest tests, and real DSpark synchronous and asynchronous integration tests passed.
The “up to 55 tok/s” figure is the peak of three warm single-stream ceiling runs; their median was 54.9 tok/s. It is not the deeper-suite or integrated-serving rate. Context length and proposal acceptance change throughput. The DGX sweep and LocalMaxxing entries use different prompt and context settings, so the chart compares complete configurations as tested rather than identical software stacks.
Prefill: 368.8 tok/s with the drafter resident
Decode is only half of the request. We also integrated the indexed sparse-prefill path with the same asymmetric expert ownership. With the 11.3 GB DSpark drafter resident on the R9700, six already-warmed requests using a 1,956-token prompt measured 367.07, 368.80, 368.91, 368.98, 368.72, and 263.26 tok/s server-side: a 368.76 tok/s median. Five runs formed a tight 367.07–368.98 tok/s cluster; one request hit a 2.18-second routing-kernel stall, and we retain that outlier in the published range.
The same six requests decoded at 50.7, 50.6, 50.6, 50.7, 50.7, and 50.6 tok/s with 0.97 proposal acceptance. All produced the same response hash. A separate prefill-only run without the resident drafter reached a 377.82 tok/s median across six consecutive requests, which is useful as a hardware ceiling but is not our end-to-end serving number.
The important change is the join. The R9700 computes attention, routing, shared experts, and its hot routed experts while Strix Halo computes the remaining routes. Their full hidden-state outputs used to return through the CPU before the next hyper-connection update. The final path leaves the hot output on the R9700, peer-copies the Strix partial once, and adds both owner tensors in the R9700 HC-post graph.
The target-only device join is 6.8% faster than the correct 353.69 tok/s host-join candidate. The more representative 368.76 tok/s resident-drafter median is about 23.7% faster than the matched warmed Strix-only control. The improvement comes from keeping each owner’s output on-device: Strix no longer evaluates R9700-owned dummy routes, its partial crosses the peer link once, and the R9700 performs the final hyper-connection update.
Why this matters for Lucebox
Two DGX Sparks scale DeepSeek V4 by linking two matched 128 GB systems and using tensor parallelism across the nodes. Lucebox takes a different route. It combines a fast discrete card with the large memory already available on Strix Halo, in one chassis, and makes the runtime aware of the imbalance.
The practical point is simple: hardware does not have to be symmetrical to be useful. For a sparse model, the engine can put latency-sensitive dense work on the faster device, use the large-memory device as an active expert owner, and overlap the two. Strix Halo is not reduced to passive storage, and the R9700 is not slowed down by an even split.
AMD-Powered Lucebox reaches up to 55 tok/s in the short ceiling test, 50.65 tok/s in the full serving configuration, and 45.5 tok/s on the deeper decode suite. That places one system in the range of public two-DGX Spark results, while the tuned 65.09 tok/s dual-Spark run remains faster. At $6,499, the complete Lucebox costs 31% less than two DGX Sparks at current listed prices. The result is a hardware-software co-design: neither device delivers it alone.
Measured July 21, 2026 on one Lucebox host with a Radeon AI PRO R9700 (gfx1201) and Ryzen AI MAX+ 395 / Radeon 8060S Strix Halo (gfx1151), using ROCm 7.2.4. Target: DeepSeek-V4-Flash-ROCMFP2-STRIX.gguf. Draft: DeepSeek-V4-Flash-DSpark-draft-Q4RMFP4-denseF16.gguf. Both decode profiles used fixed q=4, top-4 routed experts, temperature zero, and observed acceptance 1.00. The short ceiling used 53 prompt and 128 output tokens; its three warm runs were 54.7, 54.9, and 55.0 tok/s. The deeper suite used 1,956 prompt and 510 output tokens; its five measured runs had a 45.5 tok/s median and identical response hashes. The sparse-prefill suite used a 1,956-token prompt, top-4 routing, disabled prompt caches, R9700 auto, and Strix Halo high. With DSpark resident, six already-warmed requests had a 368.76 tok/s prefill median and a 50.65 tok/s server-side decode median; five prefill samples were 367.07–368.98 tok/s and one routing-stall sample was 263.26 tok/s. A separate target-only six-run suite had a 377.82 tok/s prefill median. Our single-DGX Spark Q2 sweep measured 14.04 tok/s average generation and 385.42 tok/s average prompt processing across 2K, 4K, 8K, and 16K contexts. LocalMaxxing references: dual DGX Spark official target 45.7 tok/s and dual DGX Spark DSpark checkpoint 65.09 tok/s. The runs use different prompts, contexts, runtimes, and quantization formats; they are presented as throughput context, not a controlled A/B. The heterogeneous execution path is public and under final review, but is not yet part of main.