The conflict

Both are open-weight multimodal MoE models for 4-node GB10 clusters:

• DeepSeek-V4.1-Flash — 552B backbone, 8B/16B active, MXFP4 routed experts + two FP8 n-gram “Engram” memory tables (94.6 GiB each, disk-resident in the Spark recipes), DSpark speculative decoding, 1M context.
• GLM-5.3-Flash — 320B total, 18B active, official release is FP8 (zai-org/GLM-5.3-Flash; a BF16 variant exists), hybrid sparse+linear attention, 1M context.

DeepSeek’s model card shows V4.1-Flash beating GLM-5.3-Flash on every shared benchmark: Terminal-Bench 2.1 90.6 vs 84.3, DeepSWE 74.2 vs 63.4, NL2Repo 65.4 vs 56.3, HLE w/ tools 63.9 vs 55.3, GPQA Diamond 90.9 vs ~86.4.

Artificial Analysis (independent, same harness) ranks it the other way: Intelligence Index 39 for DS-V4.1-Flash vs 42 for GLM-5.3-Flash. GLM wins AA-Briefcase (1454 vs 1421), GDPval-AA (1645 vs 1600), Terminal-Bench 4.0 (33% vs 27%), HLE (40% vs 39%), and knowledge recall. DeepSeek wins AutomationBench (69% vs 60%), long-context retrieval (84% vs 80%), and is ~4× faster per output token on the API (209 vs 47 tok/s) — but burns ~35% more reasoning tokens per task (63k vs 47k) to get there.

So the vendor sweep and the independent index genuinely disagree. The likely mechanism: DeepSeek tuned hard for agentic/automation benchmarks (and measures itself on its own harness), while GLM holds the edge on knowledge and workplace-task depth.

What the NVIDIA DGX Spark forum says

From the main threads (DeepSeek v4.1 Flash, GLM 5.3 Flash on TP4, dual-Spark choice thread):

• jwarner: “AA rebased all of the numbers… If true then GLM-5.3-Flash is cleanly above even this new DS 4.1.”
• stu.miller on 4.1 TP4: “Larger model = better, right? Not in my testing… burned way too many tokens on thinking instead of actually doing the work.” Later, after a week on 4.1: GLM “performed worse in all of my tests on those long face-to-face and overnight automations than ds4 flash… while being slower.”
• nvidiaspark: “with jcode, I am not really happy with the quality, especially on the web app work.”
• massoud.mazar: tool-eval-bench hardmode regressed from 94/100 (ds4-flash-0731) to 85/100 on 4.1 at first; later stacks recovered to ~93–94, i.e. parity.
• Snappy_Dev: “they are almost identical in real world tasks… either one… they are both in the same class.”

Net forum verdict: mixed, leaning DeepSeek for always-on agentic grind and speed, GLM for coding depth and knowledge work.

Does GLM-NVFP4 keep the GLM edge?

jnardiello measured it directly (same hardware, token-level KL/perplexity against vendor FP8): the community NVFP4 GLM recipe costs +3% perplexity on short text rising to +12–16% on long conversations, +9% on agentic code, versus zero measurable loss for the FP8 recipe. NVFP4 also showed the known corrupted-token issue (vLLM #54150).

A 3-point Intelligence Index gap is bigger than a 3–9% perplexity drift, so “GLM even in NVFP4 ≥ DS-V4.1-Flash on general intelligence” is consistent with the data — but nobody has run GLM-NVFP4 through the AA index directly. Treat that extension as inference.

Practical summary

Choose DeepSeek for interactive speed, long-context retrieval, and automation throughput; choose GLM when per-response intelligence matters more than latency. Neither is cleanly “smarter” — but if you only trust measurements you didn’t get from the vendor, GLM-5.3-Flash currently leads the intelligence column.