I compared Qwen3 8B and GLM 5.3 Flash on DGX Spark across 4 configurations by use case

Introduction

Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.

I wrote articles about running GLM-5.3-Flash on a single DGX Spark with 2-bit quantization, and then running it on two units with NVFP4. Both articles ultimately landed on the question of "where is the value in buying a second unit?" However, what I really wanted to untangle was: what should I load onto my single unit to meet my own needs, and is faster speed alone really the answer?

https://huggingface.co/Qwen/Qwen3.8-Flash-Next

Then Qwen3.8-Flash-Next appeared. It's a 125B MoE, but with an unusual structure where active parameters (the weights actually used when processing one token) are just 6B, along with a 51B n-gram embedding table. Early estimates after release showed the NVFP4 checkpoint at 122 GiB, and I noted it wouldn't fit on a single unit with 128GB. However, about a week after release, a community patch for vLLM that reads the embedding table via mmap from NVMe was committed, and reports of it starting up on a single unit began appearing. GLM-5.3-Flash squeezed down to 3-bit to fit one unit, Qwen3.8-Flash-Next fitting on one unit via the mmap patch, and Qwen3.8-27B which is small to begin with. With three single-unit options now available, I decided to line them up side by side using the same harness, with the two-unit GLM setup as the baseline. The GLM 3-bit was only tested for loading in the single-unit article; this is the first time it's been put through the full benchmark.

To state the conclusion upfront: for a single person writing in Japanese and having long documents read, Flash-Next on a single unit passes all 9 mechanically-judged tasks, achieves 28.0 tok/s single-stream, reaches the first response for 200K tokens in 101 seconds, and is faster than two GLMs. However, because its thinking is longer, completing the 10 Japanese tasks takes 219 seconds compared to 46 seconds for two GLMs. For shared use by several people, Qwen3.8-27B has the most headroom at a combined 136 tok/s across 8 parallel streams, and all 4 configurations completed code-writing-and-fixing tasks.

The GLM two-unit figures from the single-unit article (dated 2026-08-30) and the two-unit article (dated 2026-09-02) are used as-is in the comparison columns. The GLM 3-bit column reflects results measured on the same day as the two Qwen setups, but on a separate DGX Spark.

https://dev.classmethod.jp/articles/dgx-spark-glm-5-3-flash-first-touch/

https://dev.classmethod.jp/articles/dgx-spark-2node-glm-5-3-flash-nvfp4-vllm/

This article measures three configurations that fit on a single DGX Spark against the same tasks as the two-unit GLM, and introduces criteria for choosing which to use based on purpose, drawing from both the numbers and differences that don't appear in the numbers. I hope it resonates with people who own a single DGX Spark and are wondering what to load on it next.

The 4 Configurations and How I Measured Them

I compared the following 4 configurations. The three single-unit options are, respectively: GLM 3-bit, which compresses the same 320B model more aggressively to fit on one unit; Qwen3.8-Flash-Next, which limits active parameters (the weights actually used when processing one token) to 6B through MoE; and Qwen3.8-27B, which is simply a smaller model overall. These represent "reduce by quantization," "reduce weights used per token," and "use a smaller model." The two-unit GLM is the baseline from previous articles.

The tasks use my own harness, the same as in the two GLM articles. Ten Japanese tasks (free-form answers read by eye, remaining 9 tasks evaluated mechanically), 5 code generation problems, fixing a repository with failing tests, tool calls, agent aptitude probes, 10-turn brainstorming and 8 questions on a 12,000-character document, and a haystack at 5 sizes with a passphrase embedded. For speed, greedy decoding with forced 256 tokens, C=1 is the median of 3 runs.

Thinking strength names differ: GLM uses max, high, and low; Qwen uses xhigh, medium, and low. In this article, GLM's max and Qwen's xhigh are treated as "strongest thinking," and both lows as "weakest thinking." Context length is 262,144 for both Qwen configurations and 65,536 for GLM (131,072 and 262,144 only for the long-document section), and KV cache type is fp8 only for the two-unit GLM.

Evaluation criteria are the same as in the GLM articles: not failing harness tasks, wait times appropriate for the use case, following tool call directives like tool_choice=required, and no character corruption. The agent aptitude probes target individual capabilities the harness depends on, not results from running an actual agent.

One note on the GLM 3-bit column upfront: Unsloth's documentation lists 3-bit UD-IQ3_XXS as the recommended quantization for 128GB machines, and it did fit on a single DGX Spark. However, with only 3 GiB free, mid-way through 8,192-token-scale generation, the host memory runs out with llama-server defaults. The figures in the 3-bit column in this article are from runs completed with --cache-ram 0 --ctx-checkpoints 0 added.

How the 122 GiB Flash-Next Fits on One Unit

The Flash-Next checkpoint is 122 GiB, of which 47.7 GiB is the n-gram embedding table. Since only 16 rows of this table are read per token, it doesn't need to be resident in memory. blazux's recipe applies patches to vLLM's official image, keeping this table as a file on NVMe and fetching only the needed rows via the page cache through mmap.

https://github.com/blazux/qwen3.8-Flash-DGX

On startup, model loading uses 79.4 GiB, leaving 645,945 tokens for the KV cache. That's 2.5 simultaneous 262K requests. Startup takes 866 seconds, longer than the 542–608 seconds for two GLMs, with weight loading alone taking 608 seconds. Since prefill is near 2,000 tok/s in the long-document section, the external table access doesn't appear to be dragging down speed.

The NVIDIA official NVFP4 checkpoint lists only B200 and B300 as supported hardware. With the same image, it crashes when reading FP8 block-scale from the MTP head; disabling MTP allows it to start, and speed matches RadixArk's version without MTP at 17.5 tok/s, with Japanese at 8/9 under weakest thinking. The recipe's hybrid mode (converting side layers to fp8) extends to 32.4 tok/s single-stream and 777,742 KV tokens, but dropped 1 Japanese task, so quality judgment is reserved from a single measurement; the main line in this article is NVFP4 without conversion.

Writing and Reading Alone

For single-user usage, what matters most is single-stream speed and wait time for reading long documents.

Comparing without speculative decoding, Flash-Next's 17.5 is above GLM 3-bit's 15.2 and Qwen3.8-27B's 12.4, making it the fastest without speculation. With speculation, Flash-Next reaches 28.0, surpassing two-unit GLM. Qwen3.8-27B gains a 1.7× boost with speculation to reach 20.8, but doesn't catch Flash-Next. GLM 3-bit figures are without speculation, as MTP hasn't been merged into the upstream.

The 10 Japanese tasks show rows for weakest thinking and strongest thinking with a 16K budget:

Only Flash-Next passed all 9 mechanically-judged tasks at both thinking levels. Flash-Next passed the 50-character constraint and specified-word tasks at both levels, which GLM was failing depending on settings. On the other hand, while GLM finishes in 46 and 109 seconds even at weakest thinking, Flash-Next takes 219 seconds and Qwen3.8-27B takes 420 seconds. This is because the two Qwen models think extensively even at low, producing 6,324 and 5,083 output tokens respectively, versus 1,044–1,092 for GLM. Flash-Next wins on pass rates; two-unit GLM wins on wait time.

For long-document reading, I measured TTFT and prefill using a haystack with a passphrase buried at 50% depth:

The two GLM columns are measured values from the two-unit and 3-bit articles; the 3-bit second row uses a 120,000-token prompt. Since TTFT and prefill are unaffected by speculative decoding, configurations with speculation are included as-is.

The passphrase was retrieved correctly at all measured sizes across all 4 configurations. No difference appeared in passphrase extraction for this benchmark; whether the same holds for summarization or multi-location synthesis is unconfirmed. The difference appeared in wait time. Flash-Next read 200K in 101 seconds with prefill at 1,982 tok/s. That's nearly 40 seconds faster than two-unit GLM's 139 seconds; I understand this single-unit result comes from sparse attention mechanisms skipping computations for long contexts. Qwen3.8-27B is fastest up to 32K but slows increasingly with longer contexts, reaching 186 seconds at 200K. GLM 3-bit needs small batches to secure free memory, taking 15 minutes at 120K. For those who regularly read long documents, this is where the single-unit options diverge most.

Writing Code, Fixing It, Connecting to Agents

For code generation with 5 problems, all 4 configurations had rows with 5/5 complete answers and all 49 tests passing. Flash-Next's strongest thinking with an 8,192 budget cuts off one problem's thinking mid-way for 4/5; with a 16,384 budget it reaches 5/5. With sufficient budget there's no difference here. Differences appeared in the task of fixing a repository with failing tests and in following tool call directives.

All configurations complete the fixes, but compared to two-unit GLM's 38 seconds, the three single-unit configurations take 87–119 seconds, 2 to 3 times longer. Flash-Next took 11 turns, and while I won't claim the turn count difference is definitive from a single measurement, the reason fast single-stream speed doesn't translate to faster fixing is that it's offset by the number of turns.

Individual tool call tasks with 5 questions, multi-call in a single message, and the pseudo-filesystem task produced the same results across all 4 configurations. The difference was in tool_choice=required, where only Flash-Next accepted the requirement but returned 0 calls. This was consistent at both strongest and weakest thinking. Since many agent harnesses are built assuming required, if you're connecting Flash-Next to an agent, this is something to verify upfront. The probe of selecting 1 tool from 40 similar ones failed across all 4 configurations. The cause hasn't been isolated, but it's an item that didn't work regardless of model or quantization changes.

Brainstorming consisted of 10-turn project consultation and a scenario of 8 questions on a 12,000-character document, with recall matching giving full correct answers from Qwen3.8-27B and the three GLM configurations. Flash-Next with strongest thinking and an 8,192 budget had 1 out of 8 turns exhaust its budget on thinking with no body text returned; that empty response remained in history and the next 2 turns also ended empty, resulting in 5/10 for recall. I re-ran under the same conditions twice and got all 16 turns returning body text with full correct recall, but even in the brainstorming task with weakest thinking, 1 out of 10 turns returned empty. For long conversations, raising the budget to 16K is a likely fix, but I haven't confirmed it eliminates this. With Qwen3.8-27B and GLM, this never occurred across 36+ turns.

Shared Use

When several people share one unit, what matters is total throughput at 8 parallel streams, speed remaining per stream, and KV pool size.

Qwen3.8-27B's KV pool figure is with speculation; without speculation it's 1.27M tokens. GLM 3-bit uses fixed allocation of 65,536 × 8 slots, and 262K is not supported.

Qwen3.8-27B's 136 tok/s is the highest across all 4 configurations, and 18.4 tok/s remains per stream. Since model loading is just 18.9 GiB, the rest goes to KV, allowing 4 simultaneous 262K contexts. Flash-Next shows a reversal where adding speculation reduces total parallel throughput, which I attribute to MTP drafts consuming computation across all 8 streams. For a shared server, Flash-Next is better without speculation, but still doesn't reach Qwen3.8-27B. Two-unit GLM's 59.4 is from the DFlash2 row in the two-unit article; switching to built-in MTP raises it to 76.2, but even that falls short of single-unit Qwen3.8-27B.

Differences That Don't Show Up in the Numbers

Some differences worth noting that you'd miss by looking only at the table figures.

Startup and operational headroom: Flash-Next takes 14 minutes to start, and with 79 GiB resident plus KV, the host free memory hovers around 10 GiB. Qwen3.8-27B comes up in 7 minutes with model loading at 18.9 GiB. I allocated 85% to KV this time, so free memory was similarly around 10 GiB, but lowering that allocation leaves room to coexist with other resident processes. I haven't verified co-resident behavior. GLM 3-bit has only 3 GiB free, and as described above, operational headroom is absent. Two-unit GLM comes with two power supplies, two sets of cabling, and a procedure for bringing both down.

Whether what you're running is official also differs. Qwen3.8-27B starts by simply passing the checkpoint to vLLM's official image. Flash-Next depends on an image with 9 community patches applied and an mmap PR not yet merged upstream, so the ability to track vLLM updates depends on the recipe's author. GLM 3-bit also relies on Unsloth's branch, a build not merged into upstream. Six months from now, Qwen3.8-27B is the most likely to still work with the same procedure.

Licenses for completeness: Qwen3.8-27B is Apache-2.0, GLM-5.3-Flash is MIT, but Qwen3.8-Flash-Next uses Qwen Community License 1.0, which has conditions on monthly user count and revenue. For internal use only there's rarely an issue, but if you're embedding it in a product, Flash-Next alone requires additional review.

The feel of the output: comparing free-form Japanese text, the impression was similar. In a task asking to list two advantages and two disadvantages of remote work, all 4 configurations returned commute time, location freedom, reduced communication, and work-life boundary blurring, formatted with headings and paragraphs. Flash-Next produced 293 characters, close to GLM's 280–351, and Qwen3.8-27B produced 355 characters. One spot in Qwen3.8-27B's response had an English word mixed in, reading "effective time has increas し," and Qwen3.8-27B at weakest thinking sometimes leaks English into Japanese text. The two GLM configurations sometimes self-report character counts that push over a 50-character constraint, or name a prohibited word and disqualify themselves depending on settings; Flash-Next didn't show that tendency.

Thinking length also shows in feel. Even at weakest thinking, the two Qwen models think for 5–6 times more tokens than GLM before answering, so better pass rates come with longer waits. Flash-Next's empty body text issue is as described in the previous section, and managing the budget becomes an operational prerequisite in long conversations.

Choosing by Use Case

I tabulated which configuration to choose by use case, lining up the three single-unit configurations alongside two-unit GLM. The evaluation criteria are the four from "The 4 Configurations and How I Measured Them."

The line drawn from the current numbers: Flash-Next for a single person on a single unit; Qwen3.8-27B for shared use on a single unit. GLM 3-bit is on par in pass rates, but with only 3 GiB free, prefill an order of magnitude slower, and everything beyond single-user Japanese writing becomes conditional. Two-unit GLM's advantages were the speed of 38.1-second code fixing, required compliance, and enough headroom to coexist with image processing—not a speed multiplier per se.

For images, I restarted Flash-Next and Qwen3.8-27B with vision enabled and ran 3 tasks: reading values from a bar chart, OCR of an inspection record, and listing protective equipment worn by a worker. Both scored 4/4 on charts and 0.0 character error rate on OCR. The protective equipment task failed mechanical judgment for both, but reading the responses they correctly listed a helmet and vest while explicitly stating that gloves and goggles "are not depicted" — these are false positives where the evaluation counted negation as hallucination. Single-unit GLM 2-bit also scored 4/4 on charts and 0.0 OCR in the single-unit article, so any single-unit configuration works for mixed image use, with only GLM 3-bit excluded for having mmproj removed.

For those continuing to use GLM on a single unit, 2-bit appears to be the better choice over 3-bit. Comparing single-unit 2-bit and today's 3-bit side by side, there's no category where 3-bit consistently improved, and code generation at weakest thinking scored 4/5 for 3-bit versus 5/5 for 2-bit. Single-stream speed dropped 14% from 17.7 to 15.2 tok/s, and free memory shrank from 11 GiB to 3 GiB. The 3-point retention gain wasn't visible at this task granularity.

Personally, I was more surprised that Qwen3.8-27B outperformed two-unit GLM as a shared server than that Flash-Next passed all 9 mechanical tasks. After two articles chasing the 320B headline, the numbers told me that for some use cases, running a smaller model on one unit is the right answer.

Summary

I measured three single-unit configurations — GLM-5.3-Flash 3-bit, Qwen3.8-Flash-Next NVFP4, and Qwen3.8-27B NVFP4 — using the same harness as two-unit GLM.

Flash-Next fits its 122 GiB checkpoint on one unit via mmap for the n-gram table, with 79.4 GiB resident, 28.0 tok/s single-stream, 200K TTFT of 101 seconds, and was uniquely the only configuration to pass all 9 mechanical Japanese tasks. Because thinking is longer, time to complete tasks exceeds two-unit GLM, and strongest thinking requires a 16K budget as a prerequisite. Qwen3.8-27B delivers a combined 136 tok/s at 8 parallel streams, can hold 4 simultaneous 262K contexts, and has the most headroom of all 4 configurations as a shared server. Code generation and fixing was completed by all 4 configurations; two-unit GLM distinguished itself with code-fixing time of 38.1 seconds and required compliance.

I'll also note the limitations. Flash-Next's tool_choice=required non-compliance and the empty body text with strongest thinking are new walls discovered in this single-unit article, and cause isolation is still in progress. The hybrid mode and official NVIDIA version quality, and the 3 image tasks were each measured only once. Conditions across the 4 configurations are not uniform; differences in context length, KV type, presence of speculative decoding, and thinking level naming conventions are as noted in each table's footnotes.

Next, I'd like to isolate whether Flash-Next's required non-compliance is a parser issue or a model tendency. llama.cpp v0.4.0 has initial support for Flash-Next, so I'd like to measure a GGUF single-unit path with the same tasks, look into running the official NVIDIA version's MTP with a newer vLLM, and re-run GLM 3-bit benchmarks when MTP support lands there.

Reference Links

• Qwen/Qwen3.8-Flash-Next - Hugging Face
• RadixArk/Qwen3.8-Flash-Next-NVFP4 - Hugging Face — Flash-Next checkpoint used in this article
• nvidia/Qwen3.8-Flash-Next-NVFP4 - Hugging Face — Official version. Supported hardware: B200 / B300
• RadixArk/Qwen3.8-27B-NVFP4 - Hugging Face
• blazux/qwen3.8-Flash-DGX — PLE mmap recipe (Apache-2.0)
• vLLM PR #53896 Support Qwen3.8-Flash-Next
• llama.cpp v0.4.0 — Initial support for Qwen3.8-Flash-Next (qwen4exp). Noted as unoptimized
• Single DGX Spark Success: Qwen3.8-Flash-Next-NVFP4 with vLLM - NVIDIA Developer Forums
• unsloth/GLM-5.3-Flash-GGUF - Hugging Face — GLM 3-bit checkpoint
• GLM-5.3-Flash: How to Run Locally - Unsloth Documentation — Notes 3-bit as recommended for 128GB machines
• unslothai/llama.cpp glm5next/upstream — Build source for GLM 3-bit
• Running 320B GLM-5.3-Flash on a Single DGX Spark and Measuring the Practical Threshold (Published 2026-08-30)
• Running 320B GLM-5.3-Flash on Two DGX Sparks and Measuring the Value of the Second Unit (Published 2026-09-01, revised 2026-09-02)