Best Model for a Dual DGX Spark: DeepSeek-V4-Flash vs Qwen3.8-Flash-Next vs GLM-5.3-Flash

Two NVIDIA GB10 boxes, 121 GB of unified memory each, joined by a 200-gigabit direct-attach cable. Three open-weight flagships that each want the whole thing. They cannot coexist — every one of them sits at roughly 119 GB of the 121 available per node — so choosing between them is not an academic exercise. It is a twelve-minute swap and a decision about what the machine is for.

This is what a month of measuring them produced, including the parts where the measurements were wrong.

The contenders

Three vendors, three entirely different speculative decoders, one shared constraint: none of them fits on one box, and all three arrived with recipes written for hardware that is not quite this hardware.

Two of those speculators we have written about at length — DSpark and MTP live inside their checkpoints, needing nothing downloaded. GLM is the odd one out here: DFlash2 is a separate drafter file, the arrangement the other two vendors abandoned.

Speed: DeepSeek wins, and it is not close

Every figure below is single-stream, from the same harness, thinking off, each model at the best configuration it can actually run here.

DeepSeek leads every row, and the gap widens exactly where it matters most for interactive work. On the agent loop — short bursts of generation between tool calls, which is what a coding assistant actually does — it is twice Qwen's rate and three times GLM's.

The reason is acceptance. All three ship a speculator, and throughput is forward passes multiplied by how many tokens each pass yields. DeepSeek runs 14.9 passes a second and gets 5.94 of a possible 6 tokens accepted on each — 99% of everything available to it. Qwen manages 14.2 passes and 4.99 of 5. Both are at their ceiling; the ceilings differ.

Prose is the great leveller. 41.7 / 31.1 / 30.4 — the field compresses to almost nothing, because prose is where every speculator guesses worst. Qwen accepts 29% of its draft tokens on prose against 97.5% on structured output. When the next word is genuinely unpredictable, a speculative decoder is just an expensive way to run one forward pass.

Quality: the ranking inverts

The slowest-but-one model is the most correct, by six problems out of thirty-three. DeepSeek leads every speed row and comes last here.

Except that "thinking off" is doing work in that table

This is the one methodological choice in the article that deserves to be argued with, so it gets stated rather than buried.

All three models were measured with reasoning disabled, which reads as even-handed and is not. Reasoning makes Qwen and GLM worse — that is the next section. It makes DeepSeek dramatically better: we have already published 54.3% without reasoning against 96.7% with it on LiveCodeBench, our own measurement, on a single flag. So the setting chosen for fairness is the setting that helps two of these models and cripples the third.

Three things keep that from simply inverting the result, and none of them dissolve it. That 54.3/96.7 pair comes from a different run against a different problem set — DeepSeek scores 60.6% here where it scored 54.3% there — so the numbers are not transferable to these thirty-three problems, and 96.7% cannot be pencilled into the table. DeepSeek reaches that mode only through an endpoint we had to build ourselves, because the checkpoint ships no chat template, which is a real cost rather than a footnote. And every speed figure in this article is thinking-off too, so turning reasoning on would move DeepSeek's quality up and its throughput down, in amounts nobody here has measured together.

What that leaves is narrower than the heading above it. DeepSeek is last on correctness among three models configured for throughput. It is not established that it is the least capable of the three, and on the one occasion we measured its reasoning mode it scored higher than anything in this article. A comparison of all three at their best is the measurement this piece is missing.

That single table is why this comparison exists. A throughput benchmark would have picked DeepSeek and stopped. A model that is 10% slower and 30% more often right is a better coding tool, and no amount of tokens per second changes it.

The paired data sharpens it further. Against GLM, Qwen solved six problems GLM missed while GLM solved one Qwen missed. That is not two models with complementary strengths — six against one is one model strictly better. The entire gap sits on hard problems: all three are perfect on easy (12/12), and the spread is 9/13 versus 4/13 at the top end.

Why GLM loses hard problems, and it is not the budget

GLM is four times faster end to end while decoding 37% slower per token, purely because it writes thirteen times less. On easy and medium problems that terseness costs nothing — 12/12 and 5/8, matching Qwen. On hard ones it answers briefly and wrongly, where Qwen wins by working at length.

Zero truncations on both sides, so this is not a token budget running out. It is a difference in willingness to think.

Which makes the reasoning result genuinely strange

Both Qwen and GLM ship switchable reasoning. Both are worse with it on:

Two vendors, two architectures, same direction. And they fail differently. Qwen reasons too much — twelve of thirty-three runs hit a 32,000-token ceiling and never produced an answer at all. GLM reasons too little — 638 median tokens, zero truncations, and three of the four hard problems it previously solved now lost. The obvious hypothesis, that reasoning would cure GLM's terseness, is exactly backwards: it wrote slightly more and got slightly worse.

On this hardware, with these models, thinking off is the default until proven otherwise.

Context: the only place GLM wins

Ten needles out of ten, at 48K, 156K, 200K, 301K and 404K, at depths 0.1, 0.5 and 0.9. Prefill flat at 820–845 tok/s across an eightfold range. Depth costs 1%: 301K took 357.6 s with the needle at halfway and 361.2 s with it at 90%.

That last number is the interesting one. A model that is skimming loses the end of a long context first. This one does not — retrieval cost is prefill, not search, and what that context costs to hold is its own piece of arithmetic.

And GLM is the only model here that can read a long document and look at the pictures in it. DeepSeek has more configured context and no vision whatsoever. Qwen sees, and stops at 262K — 35% short of what GLM has been verified to retrieve. For a scanned contract, an illustrated manual, a long PDF with figures, there is exactly one option on this hardware.

Vision: accuracy and reliability point different ways

The test: three frames of an egg wrapped in a cloth stocking, spun on a drill chuck. Eight repeats. Ground truth verified by looking at the frame.

GLM is the only one that gets it right, every time. That is what 1,381 image tokens per frame buys over Qwen's 631 — it is the densest processor of the three and it sees more of the picture. Which is the same lesson as the image-token trap from the last round, arriving from the other side: token count decides what a vision model can see, and it is invisible in the call.

Then two of the eight runs ran away. 219 seconds and 43,888 characters; 189 seconds and 39,367 characters — against a normal six seconds and 320. The mean is nine times the median. On a 58-keyframe video that is two or three windows turning a one-minute job into eleven, and the failure is silent: it produces plausible description, not an error.

That looked disqualifying. It was not — the runaway turned out to belong to the multi-image call, not to vision. Eight repeats of a single-image read came back 0 for 8, with lengths within 7% of each other (1,369–1,473 characters, 14.8–16.5 s). The obvious fix, capping the output everywhere, would have truncated exactly the case GLM is best at in order to cure a fault that case does not have. Capping only the multi-image path — 1,500 tokens, four times the longest healthy answer — bounded it.

The proof is the real job rather than the synthetic one. The same 58-keyframe clip, described end to end:

Under two minutes, no runaway. And on the frames themselves GLM is simply right where Qwen is wrong — "a cloth-wrapped egg" against "the balloon-covered egg" — while also reading "20V" and "2.0" off the battery and placing the later shot "on a black wire rack inside a dark oven".

So the most accurate reader of the three is also usable, once the cap is put in the one place the fault actually lives.

Operations: what it costs to change your mind

A full round trip between two of them is about twelve minutes of no service.

The load times contain a small puzzle worth stating: the largest checkpoint loads fastest. DeepSeek is 156 GiB in 334 s; Qwen is 126 GiB in 701 s. The answer is shard count, not bytes — 48 fat shards against 206 thin ones. GLM, at 164 GiB and 120 shards, lands in the middle at 490 s exactly as that theory predicts.

Two of the three also need --enforce-eager, and neither vendor's recipe mentions it, because neither vendor was running a GB10. Qwen's torch.compile locks up for twenty minutes; GLM's sparse attention indexer asks for 119 thread blocks where this chip has 48 streaming multiprocessors, and its fallback path wants 128 KB of shared memory per block where GB10 provides 99 KB. Neither is a tuning problem. Both are the hardware being smaller than the code assumes.

The verdict

On raw performance: DeepSeek-V4-Flash. It wins every throughput row, often by a wide margin, and doubles the field on the agent loop. If your work is high-volume generation and you do not need pictures, nothing here competes.

On quality, with every model configured for throughput: Qwen3.8-Flash-Next. 26 of 33 against 20 and 21, with the paired data showing it strictly better rather than differently good against GLM. It is second on speed everywhere, which is the point — it gives up the least. The qualifier matters: DeepSeek's reasoning mode is outside this comparison and scored higher than anything in it when we measured it separately.

On overall usability: Qwen3.8-Flash-Next, comfortably. It is the only model that is good at everything asked of it: second-fastest, most correct, sees, reasons if you want it to, and holds 262K of context. It has no disqualifying weakness. The other two each have one — DeepSeek cannot see at all, and GLM is third on both speed and quality.

But the honest answer is that it depends on the job, and the split is clean enough to state as a rule:

A note on the numbers that were wrong

Half of what this article reports was measured incorrectly at least once, and the corrections are more instructive than the results.

A default is not a measurement. GLM was declared unusable on the strength of crashes at --max-model-len 1000000 — the repository's own default. Its own results file records the profiles they actually run: 435,456 and 499,968. A third-party report on identical hardware says plainly that "512K/1M remain untested". Every real measurement sat between 262K and 500K, and the only source naming 1M was a config file contradicted by its own project's data. At 435,456 the model retrieves exactly at 404K.

A long-context benchmark built from repeated text measures the cache. An early ladder appeared to prefill 94,657 tokens without trouble. The tell was in the data and went unread: that prompt returned faster than a 70,985-token one. Prefix caching meant almost nothing was computed. With unique content the same server died at a third of the length.

Cold servers lie. GLM's decode was recorded at 41.0 tok/s and flagged as an unexplained gap against a published 62.9. It was a Triton kernel compiling during the measurement. Warm, it is 60.6 — the gap never existed.

And the benchmark you tune on decides what you tune toward

This one has a published casualty, so it gets its own heading.

Two days ago we recommended running Qwen's speculator at depth 9, and reported it beating DeepSeek on structured output, JSON and code by 3–15%. That recommendation came from a synthetic decode suite: fixed prompts, fixed output lengths, one shape of work. On that suite k=9 is 31% faster on structured output, and the number is real.

Measuring the actual workloads gave +27% on one narrow shape and losses on three of five others — including −5% on the agent loop, the thing a coding assistant actually does. The table at the top of this article therefore runs Qwen at k=4, and that is why its structured figure reads 71.2 rather than the 93.4 we published.

Nothing about the model changed. What changed is which benchmark was believed. Optimal speculative depth is a property of the workload, not of the model — and a synthetic suite will happily recommend a setting that loses on everything you actually do, while being perfectly accurate about the thing it measures.

The earlier article has been marked accordingly. Its architecture and memory findings stand; its speed recommendation does not.

Related reading

• Three Local Flagships, One Idea: Qwen3.8-Flash-Next vs DeepSeek-V4-Flash vs Qwen3.8-27B — the architecture behind two of these three, read from their config files
• DeepSeek-V4-Flash on Two GB10s: 304B Params, 1M Context, 83 Watts — the months of use behind the DeepSeek column
• Qwen3.8-27B Is 2.3× Faster With One Flag — Do You Need DFlash2? — DFlash2, the separate-drafter arrangement GLM still uses
• AI Workstation Comparison: RTX 5090 vs GB10 (HP ZGX) — what a single GB10 is, and what two of them cost
• 4-Bit Quantization Decoded: INT4 QAT, MXFP4, and NVFP4 — NVFP4 against EXL3, and why the checkpoints differ in size