I Almost Sold My DGX Spark — Until Qwen 3.8 Flash-Next Changed Everything

Date: 5 Oct 2026 | Author: Mash | 9 min read

Cover Photo

A month ago, I wrote about the terrifying financial panic of buying an NVIDIA DGX Spark as an independent builder in a developing country. I poured a small fortune into a glowing 128GB unified-memory box with one goal: total local AI sovereignty.

And for the first few weeks?

I almost listed the damn thing on second-hand marketplaces. 😂

Don’t get me wrong: the hardware was gorgeous, but my actual day-to-day workflow was a mess of frustration. I ran through dozens of local models. Some were brilliant reasoning powerhouses that crawled at a painful 6 tokens per second. Others flew at 80 tok/s but hallucinated basic syntax or choked the moment I handed them complex Thai instructions.

I found myself staring at this ultra-dense supercomputer humming quietly on my desk, thinking: “Did I really just burn months of savings on an oversized paperweight?”

Then Qwen 3.8 Flash-Next dropped.

Everything changed.

The Turning Point

Qwen 3.8 Flash-Next was the very first model that made my DGX Spark feel genuinely useful. Not “cool tech demo” useful, but “shut down cloud subscriptions and ship code all day” useful.

Naturally, the open-source community immediately started brewing custom runtime recipes and inference backends to squeeze every ounce of performance out of Spark’s Grace Blackwell architecture.

First, I tried blazux’s setup. Then came Azempati’s high-throughput a5b build. Soon after, MiaAI’s TensorFold and the community’s blistering veloGB10 emerged.

Every time I switched recipes, I fell in love with one aspect and missed another:

  • “Damn, this one is ridiculously fast for single-stream coding!”
  • “Wait, but this other one can handle multiple people hitting it at once without breaking a sweat.”
  • “Ah, but what happened to my Thai language comprehension?”

Unable to decide, I did what any developer with too much curiosity and an obsession with local compute does: I put all four backends through a head-to-head benchmark shootout.

The Testing Ground & Rules of Engagement

To keep the comparison fair and grounded in reality:

  • Hardware: NVIDIA DGX Spark (Unified memory: ~121GB usable).
  • Thermal / Stability Measure: GPU clock capped at 2,200 MHz (essential to prevent power throttling and unexpected thermal shutdowns during sustained runs).
  • Inference Settings: Temperature = 0, Thinking = OFF, identical system prompts, and matching dataset subsets across all backends.
  • The 5-Point Rule: Because small subsets (100–300 samples) have an inherent statistical margin of error (±4-8%), any score difference under ~5 points is treated as a practical tie.

Here are the four contenders:

  1. veloGB10
  2. TensorFold (MiaAI)
  3. a5b (Azempati)
  4. blazux

1. Raw Speed & Throughput: Single Stream vs. Concurrency

Speed isn’t a single metric. A backend optimized to stream code to a single user in an editor feels completely different from a backend designed as a shared office gateway.

Metric veloGB10 TensorFold blazux a5b
Max Concurrent Streams Tested 1 4 8 8
Single-Stream Decode (tok/s) 104 62 32 50
Decode @ ~42k Long Context (tok/s) 82 54 27 54
Prefill Speed (0.7k -> 84k prompt) 1,283–1,377 tok/s 1,343–1,954 tok/s 676–1,459 tok/s 1,168–1,888 tok/s
TTFT @ ~84k prompt 64.7s 47.8s 59.2s 46.1s
Aggregate Throughput (1 stream) 85.6 tok/s 57.8 tok/s 26.3 tok/s 46.9 tok/s
Aggregate Throughput (4 concurrent) (Queued) 115.0 tok/s 66.6 tok/s 118.2 tok/s
Aggregate Throughput (8 concurrent) (Queued) (VRAM limit) 106.0 tok/s 174.1 tok/s
Per-Request Speed @ 4 concurrent — 32.1 tok/s 17.7 tok/s 31.8 tok/s
Per-Request Speed @ 8 concurrent — — 14.4 tok/s 24.5 tok/s

Key Speed Takeaways:

  • veloGB10 is in a league of its own for solo work: Cracking 104 tokens/second on decode is absurdly responsive. Typing latency is virtually non-existent; diffs stream faster than you can blink. Even at 42k context depth, it cruises along at 82 tok/s.
  • a5b is the true multi-tenant brute: When you scale up to 8 concurrent requests, a5b screams past the competition, delivering a massive 174.1 tok/s aggregate throughput and 24.5 tok/s per stream.
  • TensorFold hits the sweet spot for small teams: It holds 4 real concurrent streams solidly at 115 tok/s aggregate (~32 tok/s per stream), matching a5b at 4 streams while maintaining faster prefill.

2. Intelligence, Tool Calling & Multilingual Capabilities

Speed means nothing if the code won’t compile or the model loses its mind when asked a bilingual question.

I evaluated the quartet across instruction-following (IFEval), agent tool calling (BFCL v4), rigorous coding (LiveCodeBench v6), Thai reasoning (MMLU-ProX Thai & ThaiExam), and open-ended writing evaluated via blind scoring by Codex (1–10 scale).

Benchmark veloGB10 TensorFold blazux a5b
IFEval (541 prompts, strict) 85.6% 85.0% 85.2% 83.4%
BFCL v4 Tool Calling (207 tasks) 87.9% 82.6% 87.0% 86.0%
LiveCodeBench v6 (100 problems, pass@1) 92% 87% 93% 96%
MMLU-ProX (Thai) (392 questions) 75.0% 73.0% 70.2% 65.3%
ThaiExam (300 questions) 66.0% 54.7% 60.3% 57.3%
Writing Score (Thai + EN, n=36) 7.33 / 10 7.14 / 10 6.83 / 10 6.58 / 10
— Thai Subscore (n=19) 7.21 / 10 7.05 / 10 6.63 / 10 6.11 / 10
— English Subscore (n=17) 7.47 / 10 7.24 / 10 7.06 / 10 7.12 / 10

(Note: Applying our ~5% statistical threshold: IFEval is a tie across all four; BFCL is a three-way tie between velo, blazux, and a5b; LiveCodeBench sees velo, blazux, and a5b neck-and-neck with a5b taking the edge).

Head-to-Head Thai Knowledge Matchups

When looking at paired question-by-question wins and losses:

  • velo vs. a5b on Thai MMLU-ProX: velo got 52 questions right that a5b missed, while a5b only answered 14 right that velo missed.
  • velo consistently swept Thai language evaluations, while a5b noticeably suffered in nuanced non-English semantics to achieve its throughput and coding gains.

3. The Quirks, VRAM Footprint & Hard Failures

No benchmark is honest without talking about memory limits and weird runtime behaviors:

  • veloGB10’s VRAM Hunger: velo loads up to ~109 GB out of the DGX Spark’s 121 GB available memory. That leaves almost no breathing room. It is strictly single-stream (request #2 queues up), and currently only supports image inputs (no video).
  • TensorFold’s Breathing Room & Video Support: TensorFold loads around ~94 GB, leaving plenty of buffer. It also natively handles both image and video modalities. Its main quirk? In strict, short-answer benchmarks like ThaiExam (capped at 16 tokens), it sometimes attempted to output internal reasoning despite thinking=off, resulting in 34 format validation failures.
  • blazux’s Aging Speed Profile: blazux was the reliable pioneer. Its quality remains solid (93% LiveCodeBench, 87% BFCL), but single-stream decode sits at ~32 tok/s. With newer runtimes offering triple that speed, it has simply been superseded.

Which Backend Should You Pick?

Here is my no-nonsense cheat sheet:

┌────────────────────────────────────────────────────────────────────────┐
│                        WHICH BACKEND TO CHOOSE?                        │
├──────────────────────────────────────┬─────────────────────────────────┤
│ Solo Developer / Coding Agent        │ ➔ veloGB10                      │
│ (Max speed: 104 tok/s, top Thai)     │                                 │
├──────────────────────────────────────┼─────────────────────────────────┤
│ Small Team / Shared Gateway          │ ➔ TensorFold                    │
│ (4 concurrent streams, video, balanced)│                                 │
├──────────────────────────────────────┼─────────────────────────────────┤
│ High-Concurrency Coding Pipeline     │ ➔ a5b                           │
│ (8+ streams, 174 tok/s, 96% LCB)     │                                 │
├──────────────────────────────────────┼─────────────────────────────────┤
│ Legacy Baseline                      │ ➔ blazux                        │
│ (Reliable, but outpaced)             │                                 │
└──────────────────────────────────────┴─────────────────────────────────┘
  • If you are a solo builder working inside an agent loop (like dsh or pi):
    Go with veloGB10. The 104 tok/s decode speed combined with top-tier Thai comprehension makes it the most satisfying daily driver experience by far.
  • If you are setting up your Spark as an AI gateway for your studio or office:
    Pick TensorFold. It gracefully balances concurrent requests, handles vision and video feeds, keeps RAM sane at 94 GB, and retains high bilingual quality.
  • If you are building an automated batch coding pipeline or CI runner:
    Use a5b. It crushes code benchmarks (96% LiveCodeBench) and churns through 8 parallel streams without breaking a sweat. Just don’t ask it to write poetry in Thai.

The Big Realization: Benchmarks Have No Single Answer

Testing these four backends drilled home a critical lesson:

There is no single “best” model setup.
The fastest single-stream runtime is useless when three colleagues ping the API at once. The strongest coding engine can fall flat on regional multilingual tasks. And a 2% benchmark delta is virtually invisible in real life compared to software architecture and prompting.

At the end of the day, it always circles back to one simple question:
“What are you actually trying to build?”

For me, the DGX Spark is no longer an anxiety-inducing box that I regret buying. With Qwen 3.8 Flash-Next humming under the hood, it has officially graduated into a machine I fire up first thing in the morning and rely on late into the night.

Next up, when I get another weekend to tinker: pushing the limits with long context (~84k+ tokens) and throwing heavy multi-step agent workloads (SWE-bench / tau2) at it.

That’s going to be a wild ride. 😆

⚡ Update (October 11, 2026): azampatti released the new b12x stack upgrade for a5b featuring custom GB10 kernels and MTP 5, boosting single-stream decode by +30% up to 77 tok/s and scaling multi-tenant throughput to 217 tok/s. Check out the follow-up post: The a5b b12x Stack Upgrade.

Disclaimer: All tests were performed on my personal DGX Spark setup with GPU clocks locked at 2,200 MHz for thermal stability. Backends were tested on focused subsets without statistical repetition across multiple seeds. Use these numbers as real-world architectural guidelines rather than universal synthetic lab scores.

> GUESTBOOK LOG

> Fetching terminal logs...

< Back to Archives