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

Introduction

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

I wrote articles about running GLM-5.3-Flash on 1 DGX Spark in 2-bit, and then running it on 2 units in NVFP4. Both ultimately landed on "where is the value in buying a second unit?" However, what I really wanted to figure out was what to load on my single unit to meet my needs, and whether faster speed alone is 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 1 token) are 6B, and it has a 51B n-gram embedding table. Estimates right after release showed the NVFP4 checkpoint at 122 GiB, and I wrote that it wouldn't fit on a single unit's 128GB. However, about a week after release, a vLLM patch from the community for reading that embedding table via mmap from NVMe was committed, and reports of it starting on a single unit began appearing. GLM-5.3-Flash compressed to 3-bit to fit on one unit, Qwen3.8-Flash-Next that fit on one unit with 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 using the same harness, with GLM's 2-unit configuration as the baseline. GLM's 3-bit was only tested for loading in the single-unit article, and this article runs it through the full benchmark for the first time.

To state the conclusion upfront: for a single person writing Japanese and reading long documents, Flash-Next on 1 unit passes all 9 machine-judged tasks, with 28.0 tok/s single-stream and 101 seconds to first response for 200K tokens, which is faster than 2 GLM units. However, because thinking is longer, completing 10 Japanese tasks takes 219 seconds compared to 46 seconds for 2 GLM units. For sharing among several people, Qwen3.8-27B has the most capacity at 136 tok/s total for 8 parallel streams, and all 4 configurations completed code writing and correction tasks.

The GLM 2-unit numbers from the single-unit article (as of 2026-08-30) and the 2-unit article (as of 2026-09-02) are used directly as comparison columns. The GLM 3-bit column was measured on a different DGX Spark on the same day as the two Qwen runs.

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 single-unit configurations on the same tasks as 2 GLM units, and presents criteria for choosing which one to use for each purpose, from both numbers and differences that don't show up in numbers. I hope this resonates with people who own one DGX Spark and are wondering what to load on it next.

The 4 Configurations and How They Were Measured

The 4 configurations compared are as follows. The three single-unit options are: GLM 3-bit, which compresses the same 320B with deeper quantization; Qwen3.8-Flash-Next, which limits active parameters (weights actually used per token) to 6B via MoE; and Qwen3.8-27B, which has fewer total parameters to begin with — representing "reduce by quantization," "limit weights used per token," and "use a smaller model," respectively. The 2-unit GLM serves as the previous baseline.

The tasks use the same custom harness as the two GLM articles. 10 Japanese tasks (free-form responses are read manually, the remaining 9 tasks are machine-judged), 5 code generation problems, fixing a repository with failing tests, tool calling, agent aptitude probes, 10-turn brainstorming and 8 questions from reading a 12,000-character document, and long-form text with keywords embedded at 5 sizes. Speed uses greedy decoding with forced 256 tokens, with C=1 as the median of 3 runs.

Thinking strength uses 3 levels: GLM has max, high, low, and Qwen has xhigh, medium, low with different names. In this article, GLM's max and Qwen's xhigh are grouped as "strongest thinking," and low-to-low as "weakest thinking." Context is 262,144 for the two Qwen models and 65,536 for GLM (131,072 and 262,144 only for the long-document section), and the KV cache type is fp8 only for the 2-unit GLM.

The evaluation criteria are the same as in the GLM articles: not failing harness tasks, wait times appropriate for the use case, following tool call specifications like tool_choice=required, and no garbled characters. Agent aptitude probes individually test capabilities the harness depends on, and are not results from running an actual agent.

One thing to note in advance about the GLM 3-bit column: Unsloth's documentation lists UD-IQ3_XXS 3-bit as the recommended quantization for 128GB machines, and it did load on a single DGX Spark. However, with only 3 GiB free, running llama-server with default settings causes the host memory to run out mid-generation for 8,192-token-class outputs. The 3-bit numbers 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 this table only reads 16 rows per token, it doesn't need to be resident in memory. blazux's recipe applies patches to vLLM's official image, mmaps this table as a file on NVMe, and fetches only the necessary rows through the page cache.

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

On startup, it uses 79.4 GiB loading the model, leaving 645,945 tokens worth of KV cache. For 262K requests, that's 2.5 simultaneous streams. Startup takes 866 seconds, longer than the 542–608 seconds for 2 GLM units, with weight loading alone taking 608 seconds. Since prefill in the long-document section reaches nearly 2,000 tok/s, the external table read approach doesn't appear to be slowing down performance.

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

Writing and Reading for One Person

For single-user use, what matters most is single-stream speed and wait time until a long document is fully read.

Comparing without speculation, 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 the 2-unit GLM. Qwen3.8-27B improves 1.7× with speculation to 20.8, but doesn't reach Flash-Next. GLM 3-bit doesn't have MTP merged in the parent project, so this article uses its no-speculation number.

For 10 Japanese tasks, I'll show rows with weak thinking and strongest thinking with a 16K budget side by side.

Flash-Next was the only one to pass all 9 machine-judged tasks at both thinking levels. The 50-character constraint and designated words that GLM sometimes failed are passed by Flash-Next at both levels. On the other hand, while GLM finishes in 46 seconds and 109 seconds even with weak thinking, Flash-Next takes 219 seconds and Qwen3.8-27B takes 420 seconds. Both Qwen models think extensively even on low, with 6,324 and 5,083 output tokens compared to GLM's 1,044–1,092. The result is Flash-Next for pass rates, and 2-unit GLM for wait time.

For reading long documents, TTFT and prefill are measured using a haystack with the keyword embedded at 50% depth.

The two GLM columns are actual measurements from the 2-unit article and the 3-bit run, and 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 keyword was answered correctly at all measured sizes across all 4 configurations. This keyword extraction test showed no differences; whether the same holds for summarization or multi-location integration has not been verified. The difference emerged in wait time. Flash-Next read 200K in 101 seconds, with prefill at 1,982 tok/s. That's nearly 40 seconds faster than 2-unit GLM's 139 seconds, and I understand this number being achievable on one unit is because sparse attention mechanisms skip computation for long contexts. Qwen3.8-27B is the fastest up to 32K, but slows progressively as context grows, reaching 186 seconds at 200K. GLM 3-bit has its batch size reduced to secure free memory, taking 15 minutes for 120K. For people who regularly read long documents, this is where the largest gap opens among single-unit options.

Writing Code, Fixing It, Connecting to Agents

For code generation with 5 problems, all 4 configurations had rows where all 5 problems were answered correctly with all 49 tests passing. Flash-Next's strongest thinking with an 8,192 budget truncates 1 problem in thinking, scoring 4/5, but 5/5 with a 16,384 budget. With sufficient budget, there's no difference here. Differences appeared in the task of fixing a repository with failing tests, and whether tool call specifications were followed.

All configurations fix the code completely, but while 2-unit GLM takes 38 seconds, the three single-unit configurations take 87–119 seconds, 2–3× longer. Flash-Next ran 11 turns, and while I won't assert a turn count difference from a single measurement, the reason fast single-stream speed doesn't translate to faster fixing is that it's offset by turn count.

The standalone 5-problem tool call test, the form with multiple calls in one message, and the pseudo-filesystem task showed the same results for all 4 configurations. The difference appeared in tool_choice=required, where only Flash-Next accepted the requirement but returned 0 calls. This occurred with both strong and weak thinking. Since agent harnesses are often built with required as a prerequisite, if connecting Flash-Next to an agent, this is worth checking first. The probe for selecting 1 tool from 40 similar tools was failed by all 4 configurations this run. However, since probes generate each question only once in one run, pass/fail varies by run. When I ran the same tasks for Qwen3.8-27B's weak thinking on a different day, all 6 items passed, so treat the failed items in the table as indicative trends.

Brainstorming consisted of a 10-turn project planning consultation and a scenario of reading a 12,000-character document and stacking 8 questions, where recall verification was answered correctly by all questions for Qwen3.8-27B and the 3 GLM configurations. Flash-Next, with strongest thinking at 8,192 budget, had 1 turn out of 8 exhaust the budget during thinking, leaving the response body empty; the 2 turns following that empty response in history also ended empty, resulting in 5 out of 10 recall questions correct. When I re-ran it with different seeds 10 times after publication, it didn't reproduce, so the frequency is low, but when it occurs it drags subsequent turns down. Details are in the addendum at the end. This has never occurred in 36+ turns with Qwen3.8-27B and GLM.

Sharing Among Multiple Users

When sharing one unit among several people, what matters is the total for 8 parallel streams, the speed remaining per stream, and the KV pool size.

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

Qwen3.8-27B's 136 tok/s is the highest of the 4 configurations, with 18.4 tok/s remaining per stream. Since the model loads in 18.9 GiB, the remainder can be allocated to KV, supporting 4 simultaneous 262K contexts. Flash-Next shows an inversion where adding speculation reduces total parallel throughput, which I attribute to MTP drafts consuming computation for 8 streams. If using as a shared server, Flash-Next should run without speculation, but it still doesn't reach Qwen3.8-27B. The 2-unit GLM's 59.4 is from the DFlash2 row in the 2-unit article, reaching 76.2 when switching to built-in MTP, but single-unit Qwen3.8-27B still comes out ahead.

Differences That Don't Show in Numbers

I'll also note differences that get missed if you only look at the table numbers.

Startup and operational headroom. Flash-Next takes 14 minutes to start, and with 79 GiB resident plus KV, host free memory hovers around 10 GiB. Qwen3.8-27B comes up in 7 minutes with the model loading at 18.9 GiB. In this test, I allocated 85% to KV so free memory was also around 10 GiB, but lowering the allocation creates room to coexist with other resident processes. Co-residence behavior has not been verified. GLM 3-bit has only 3 GiB free, with no operational headroom as described above. The 2-unit GLM comes with power supplies and wiring for two units, plus procedures for bringing both down.

Whether what you're running is official also differs. Qwen3.8-27B starts by simply passing a 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 whether it can track vLLM updates depends on the recipe author. GLM 3-bit also uses an Unsloth branch build not merged into the parent project. Qwen3.8-27B seems most likely to work with the same procedure six months from now.

Licenses are worth noting too. Qwen3.8-27B is Apache-2.0, GLM-5.3-Flash is MIT, but Qwen3.8-Flash-Next is under Qwen Community License 1.0, which has conditions on monthly active users and revenue. There are few concerns for internal use only, but if embedding in a product, Flash-Next alone requires additional verification.

The feel of output, when Japanese free-form responses are compared side by side, gave a similar impression. For the task of listing 2 pros and 2 cons of remote work, all 4 configurations returned 4 points — commute time, location freedom, reduced communication, and work-life boundary — with headings and paragraphs. Flash-Next used 293 characters, similar in length to GLM's 280–351 characters, and Qwen3.8-27B used 355 characters. Qwen3.8-27B's response had one instance of an English word mixed in: effective time "increas shi" (増加し with English stem). This was the only such instance observed this time, and it's unclear whether it's a pattern. The two GLM configurations sometimes, depending on settings, exceeded the 50-character limit by appending self-reported character counts, and failed by explicitly naming a prohibited word — tendencies not seen in Flash-Next.

Thinking length also shows up in how things feel. Even with weak thinking, both Qwen models think for 5–6× the tokens of GLM before answering, so better pass rates come with wait time. With strongest thinking, both Qwen models had tasks where an 8,192 budget wasn't enough, so planning for 16K is advisable.

Choosing by Use Case

I've compiled a table of how to choose among the 3 single-unit configurations and 2-unit GLM for each use case. The evaluation criteria are the same 4 criteria from "The 4 Configurations and How They Were Measured."

For a single user on one unit, Flash-Next; for sharing one unit among many, Qwen3.8-27B — that's the line the current numbers draw. GLM 3-bit matches on pass rates, but with only 3 GiB free and single-digit-slower prefill, everything except single-user Japanese writing becomes conditional. Where 2-unit GLM excels is the 38.1-second fix wait time, required compliance, and headroom to co-host images — not a speed multiplier advantage.

For images, I restarted Flash-Next and Qwen3.8-27B with vision enabled and ran 3 tasks: bar chart value reading, inspection record OCR, and worker safety gear enumeration. Both scored 4/4 on charts and 0.0 OCR character error rate. The harness's machine judgment marked both as failing the safety gear task, but reading the responses shows they enumerated helmet and vest, and stated that gloves and goggles "are not depicted" — a false positive from the judgment side counting negation sentences as hallucinations. Since single-unit GLM 2-bit from the single-unit article also scored charts 4/4 and OCR 0.0, any single-unit option suffices for image use cases, with only GLM 3-bit excluded for having mmproj removed.

If continuing to use GLM on one unit, 2-bit rather than 3-bit seems fine. Comparing the 2-bit from the single-unit article to this 3-bit, there are no items that consistently improved with 3-bit, and code generation with weak thinking was 4/5 for 3-bit versus 5/5 for 2-bit. Single-stream speed drops 14% from 17.7 to 15.2 tok/s, and free memory decreases from 11 GiB to 3 GiB. The 3-point improvement in retention wasn't visible at this task granularity.

Personally, I was more surprised that Qwen3.8-27B outperformed 2-unit GLM as a shared server than that Flash-Next passed all 9 machine-judged tasks. After two articles chasing the 320B flag, 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 2-unit GLM.

Flash-Next loads a 122 GiB checkpoint onto one unit via mmap of the n-gram table, with 79.4 GiB resident, 28.0 tok/s single-stream, and 101-second TTFT for 200K, and was the only one to pass all 9 machine-judged Japanese tasks. Because thinking is longer, completing tasks takes more time than 2-unit GLM, and for using the strongest thinking, both Qwen models need a 16K budget. Qwen3.8-27B delivers 136 tok/s total for 8 parallel streams, can handle 4 simultaneous 262K contexts, and has the most capacity as a shared server among the 4 configurations. All 4 configurations completed code generation and fixing, with 2-unit GLM standing out for 38.1-second fix time and required compliance.

I'll also note limitations. Flash-Next's non-compliance with tool_choice=required is a new wall seen in this single-unit article, and root cause analysis is ongoing. Hybrid mode and official NVIDIA edition quality, and the 3 image tasks, were each measured only once. Conditions across the 4 configurations are not uniform, with differences in context length, KV type, speculative decoding presence, and thinking level names as noted in each table's footnotes.

Next, I'd like to determine whether Flash-Next's required non-compliance is a parser-side issue or a model tendency. Since Flash-Next's initial support (qwen4exp) landed in llama.cpp v0.4.0, I'd like to measure the GGUF path on one unit with the same tasks, try running the official NVIDIA edition's MTP with new vLLM, and re-measure GLM 3-bit when MTP support lands for it.

Addendum (2026-09-07): Empty response body did not reproduce even with 16K budget

After publication, I received a comment asking whether raising max tokens would fix the issue, so I re-measured the same Flash-Next configuration on the 12,000-character document + 8-turn scenario where the response body went empty, using the strongest thinking. I varied seeds from 1 to 10 and ran each seed once with budget 8,192 and once with 16,384, for a total of 20 runs. Since the same seed produces identical output up to the point where the budget is reached, this lets me compare 1-to-1 whether a turn that went empty at 8,192 gets filled at 16K.

The result was that no turn produced an empty response body, whether the budget was 16K or stayed at 8,192. All 10 pairs of outputs were identical character for character, recall verification scored 10/10, and even the longest output was 3,633 tokens — less than half the budget. Re-submitting only the empty turn 10 times using the history from when it originally went empty, thinking stopped at 528 characters at most, and the 12,789-character deep-thinking session described in the main text did not reproduce.

So the empty response is not something confirmed to not occur, but rather an event rare enough to not appear even in 20 runs, which when it does occur leaves an empty response in history and drags subsequent turns down. Since re-submitting the empty turn as-is returned a complete response all 4 times, if using in long conversations, rather than raising the budget to 16K, the more reliable fix is: re-submit responses where the response body is empty and finish_reason is length, or don't add empty responses to history. With weak thinking in the brainstorming session, there was also one instance of an empty response body, but it stopped at 546 tokens, so it wasn't a budget exhaustion.

Note: the original article stated "when re-run twice with the same conditions, all 16 turns returned a response body," but those 2 runs were not independent re-runs because vLLM replays the same random number sequence from startup each time. That description has been removed and replaced with the seed-varied results above.

Reference Links

• Qwen/Qwen3.8-Flash-Next - Hugging Face
• RadixArk/Qwen3.8-Flash-Next-NVFP4 - Hugging Face — The Flash-Next checkpoint used in this article
• nvidia/Qwen3.8-Flash-Next-NVFP4 - Hugging Face — Official edition. 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). Optimization explicitly noted as not yet started
• 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 listing 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: Measuring the Practical Divide (published 2026-08-30)
• Running 320B GLM-5.3-Flash on 2 DGX Sparks: Measuring the Value of a Second Unit (published 2026-09-01, revised 2026-09-02)