GLM-5.3-Flash vs DeepSeek V4 Flash on 2× DGX Spark: Real-World DeepSWE Benchmark Results

Last Updated: August 31, 2026

The short answer: in our real-world DeepSWE benchmark on a two-unit NVIDIA DGX Spark cluster, DeepSeek V4 Flash 0731 solved 2 of 5 coding tasks, submitted patches on 4 of 5, and served its full 1,048,576-token context window at 41 to 66 tokens per second. GLM-5.3-Flash NVFP4 solved 0 of 5 tasks, never submitted a patch, decoded at 10 to 15 tokens per second, and could only be served stably at 24,576 tokens of context because of a kernel bug in its serving stack. DeepSeek V4 Flash stays our coding agent on this hardware. The verdict is not close today.

This was not a synthetic or paper-spec comparison. We ran both models on the same cluster, back to back, on the same 5-task DeepSWE subset, and recorded every failure mode we hit along the way. If you are self-hosting coding agents on compact AI hardware, the failure modes matter more than the headline score.

Which model won our DGX Spark coding benchmark?

DeepSeek V4 Flash 0731 won decisively on every metric we tracked. It solved 2 of 5 DeepSWE tasks against 0 of 5 for GLM-5.3-Flash, finished the whole 5-task run in 2 hours 51 minutes against 4 hours 52 minutes, converged to submitting a patch on 4 of 5 tasks while GLM never submitted one, and ran the full benchmark inside a 1M-token context window while GLM was capped at 24,576 tokens by serving-stack bugs. Decode throughput was roughly 4 times higher for DeepSeek on identical hardware. The engine never crashed once under DeepSeek, while the GLM configuration produced one hard node hang and two context-overflow engine deaths.

What we tested and how

We ran a 5-task June subset of the DeepSWE benchmark from datacurve-ai on a two-unit NVIDIA DGX Spark cluster, using the Pier 0.2.1 harness with mini-swe-agent v2.3.0, sequential trials for both models. The baseline was DeepSeek V4 Flash 0731 with tensor parallelism of 2, a 1M-token window, and NVFP4 weights. The challenger was GLM-5.3-Flash NVFP4, a 320B-parameter mixture-of-experts model with 18B active parameters, split across both nodes with tensor parallelism of 2. Both models used quantized weights and the same vLLM serving stack.

According to NVIDIA's DGX Spark specifications, each unit pairs 128GB of unified LPDDR5x memory with 273 GB/s of bandwidth on a GB10 Grace Blackwell Superchip, and two units can be clustered over the built-in 200 Gb/s ConnectX-7 fabric for tensor parallelism. That is exactly the configuration we tested: 256GB of pooled unified memory, which is why these compact clusters are attractive for self-hosting large open models in the first place.

• Benchmark: DeepSWE (datacurve-ai), 5-task June subset, agentic patch-writing tasks on real open-source repositories in Go and Python
• Harness: Pier 0.2.1 with mini-swe-agent v2.3.0, sequential trials, identical prompts and tool access
• Incumbent: DeepSeek V4 Flash 0731, NVFP4 weights, tensor parallelism of 2, 1,048,576-token context, roughly 41 to 66 tok/s decode
• Challenger: GLM-5.3-Flash NVFP4 (320B total parameters, 18B active), tensor parallelism of 2 across both nodes, served from a patched community vLLM build for the GB10 chip

Task-by-task results: where GLM-5.3-Flash fell apart

DeepSeek V4 Flash solved both Python data-handling tasks cleanly (python-statemachine in 37 minutes, numba-stencil in 51 minutes) and submitted patches on 4 of 5 tasks overall. GLM-5.3-Flash scored zero across the board, but the failure modes split into two distinct patterns: endless tool-call looping on two tasks, and hard context-overflow engine deaths on two others. One task, a Go type-labeling fix, defeated both models, but only DeepSeek still managed to submit a patch attempt inside the time limit.

Why GLM-5.3-Flash could not serve long context on 2 DGX Sparks

Context window was the decisive factor of the whole benchmark. GLM-5.3-Flash could not be served at long context on this cluster for three compounding reasons: its NVFP4 KV cache path is rejected outright by the current vLLM build on this architecture, the first 1M-token attempt hard-hung a node during warmup and required a physical power cycle, and a deterministic kernel assertion in the long-context path caps usable context at roughly 24K tokens regardless of how much memory you allocate. We confirmed the last bug at both 64K and 131K token requests, independent of chunk size.

1. NVFP4 KV cache is rejected. The engine hard-fails with the message "nvfp4 KV cache is not supported with MLA backends". DeepSeek's MLA-compatible NVFP4 KV trick does not exist for the GLM architecture, so fp8 was the only compressed KV path available.
2. The 1M attempt hung a node. A profiler-sized fp8 KV allocation of about 7.9 GiB per rank hard-hung one node during warmup and required a physical power cycle. Community testing records the same pattern: KV carveouts above about 5.5 GiB per rank on this chip allocate and then die.
3. A kernel bug caps context at ~24K. The DSA indexer's persistent TopK kernel asserts on any request that enters the long-context path: "total_ctas=78 > num_sms*occupancy=48". It is deterministic, chunk-size independent, and reproducible at 64K and 131K requests.

The workaround that made the benchmark possible at all: we served the model at a 24,576-token maximum length (a community-verified safe setting that yielded a pool of 348,979 KV tokens and 14.2 times headroom) behind a local truncating proxy that counts tokens on every request and drops middle history above a 21.5K threshold. That proxy kept the engine alive through conversations as long as 432K raw tokens across 528 messages, at the cost of the agent forgetting most of its history every turn. DeepSeek V4 Flash, in contrast, used contexts of 96K to 147K tokens freely during the same benchmark with zero intervention.

The looping problem: why GLM-5.3-Flash never submitted a patch

With thinking mode disabled (the default in the community serving recipes), GLM-5.3-Flash did not converge to submitting patches in any task. Four of five tasks ended in hundreds of tool-call rounds: one run reached 500+ messages and 107K raw tokens, another reached 528 messages and 432K raw tokens before we killed it at 85 minutes. DeepSeek V4 Flash converged on 4 of 5 tasks within 19 to 51 minutes each. We attribute this cautiously: the disabled thinking mode, a day-0 tool-call parser, and the history loss from the truncating proxy are all plausible contributors. Even discounting the context handicap entirely, GLM finished no task that DeepSeek could not.

A model you cannot serve at long context is not a coding agent, no matter what the spec sheet says.

What it took to serve GLM-5.3-Flash at all

Serving GLM-5.3-Flash on two DGX Sparks required substantially more engineering than the incumbent. We downloaded 185GB of NVFP4 weights and synced them to both nodes, built a full 8-stage patch chain for the vLLM GB10 image locally because the community prebuilt image is private, and tuned the launch configuration: tensor parallelism of 2 over the RoCE fabric, a 0.90 GPU memory utilization target, a 5.5 GiB per rank KV pin, fp8 KV cache, eager mode, and a 24,576-token maximum length. Cold boot takes about 12 minutes. Along the way we absorbed one node hang requiring a power cycle, two context-overflow engine deaths, and a launcher bug. This is what day-0 software looks like on new silicon.

It is also consistent with how the community positions this model: the reference recipes for GLM-5.3-Flash, including the 1M-context configuration at roughly 36 tok/s, assume a four-unit cluster with tensor parallelism of 4, not two units. Our result does not contradict those recipes. It confirms that two units are simply not the intended serving envelope.

When would GLM-5.3-Flash make sense on DGX Spark?

GLM-5.3-Flash could become competitive on this hardware class, but every path runs through more work: patch the persistent TopK kernel so long-context requests stop asserting (a multi-hour vLLM extension rebuild that would unlock the roughly 900K-token KV pool), enable thinking mode to attack the looping behavior, move to a four-unit cluster where the community recipes deliver 1M context at usable throughput, and add speculative decoding plus CUDA graphs once stable, which addresses the 3 to 4 times decode deficit. Until then, on two units, it is a day-0 curiosity rather than a daily driver.

• Patch the TopK kernel: a fallback loop for the grid assertion would lift the usable context cap toward the ~900K-token KV pool already allocated
• Enable thinking mode: the no-think looping pattern suggests reasoning output may be required for convergence
• Four units, not two: community recipes with tensor parallelism of 4 serve 1M context at ~36 tok/s, which is the configuration this model actually targets
• Speculative decoding and CUDA graphs: current decode is 3 to 4 times slower than the incumbent in eager mode

What this means for businesses self-hosting AI agents

Model choice on self-hosted hardware is a systems decision, not a model-card decision. The spec sheet says GLM-5.3-Flash supports long context, but memory allocation limits and one kernel assertion turned that into 24K usable tokens on our cluster. Agentic coding is the most context-hungry workload in modern AI: our DeepSeek runs consumed 96K to 147K tokens per task, which is 4 to 6 times more than the challenger could physically serve. Benchmark on your own hardware, with your own workload, before committing, and keep the incumbent until the challenger proves itself end to end.

"The headline score is 2 out of 5 versus 0 out of 5, but the real story is the serving stack. A model you cannot serve at long context is not a coding agent, no matter what the spec sheet says," says AJ Awan, founder of Flowtivity and former EY management consultant. "We ran both models on identical hardware back to back, and the failure modes tell you more than the scores do."

For growing businesses evaluating local AI infrastructure, the practical takeaways are: compact clusters like DGX Spark are genuinely capable serving platforms for open models, the maturity of each model's serving stack varies enormously, and context window headroom is the make-or-break resource for agentic workloads. A cheaper or newer model that cannot hold your repository, your logs, and its own tool history in context at once will lose to the model that can.

Frequently asked questions

Is GLM-5.3-Flash faster than DeepSeek V4 Flash on DGX Spark?

No. In our sequential DeepSWE trials on two DGX Spark units, DeepSeek V4 Flash decoded at roughly 41 to 66 tok/s while GLM-5.3-Flash managed 10 to 15 tok/s in eager mode without speculative decoding, a 3 to 4 times gap on identical hardware.

How much context can GLM-5.3-Flash serve on 2 DGX Spark units?

In our testing, 24,576 tokens was the stable maximum. A deterministic kernel assertion in the vLLM long-context path kills larger requests on current GB10 builds. DeepSeek V4 Flash served the full 1,048,576-token window on the same cluster.

Which model should I run for coding agents on DGX Spark?

On a two-unit cluster, our data says DeepSeek V4 Flash: 2 of 5 tasks solved versus 0 of 5, four times the context, four times the decode speed, and no engine instability. Community reference recipes for GLM-5.3-Flash target four-unit clusters.

Why did GLM-5.3-Flash loop without submitting patches?

We cannot prove a single cause. With thinking mode disabled, 4 of 5 tasks ended in hundreds of tool-call rounds without a submission, including one run of 528 messages and 432K raw tokens. Likely contributors: disabled thinking mode, a day-0 tool parser, and history loss from the truncating proxy.

What is the DeepSWE benchmark?

DeepSWE is an agentic coding benchmark from datacurve-ai that evaluates models on real software engineering tasks from open-source repositories, such as Go type-labeling fixes and Python data-encoding changes. We ran a 5-task subset with sequential trials.

Disclosure: this post reports a self-hosted benchmark of publicly available open-weight models on our own hardware. Identifying infrastructure details have been removed. Flowtivity runs GLM-5.3 (the full model via API) as its daily agent brain, which makes this result inconvenient for us and therefore worth sharing.