GLM-5.3-Flash on Two Sparks: Speed Meets Quality Gates

Four sustained prompts per arm, one boot per arm. No production-readiness score.

A deployment can finish long requests and generate faster while still failing the contract an application needs. Weschera's GLM-5.3-Flash experiment is useful because it preserves that outcome. On two DGX Sparks, a seven-token DFlash2 arm improves the source's median estimated decode rate, but strict output failures remain. A faster three-token diagnostic is rejected before code execution. None of the three arms receives a clean overall quality pass. These are original community observations, not new Run AI Here measurements.

Pin the target, draft and execution environment separately

The target is nvidia/GLM-5.3-Flash-NVFP4 at 423acf37583782c51c142d145aef733d72943d93. The DFlash2 draft is a different artifact at bf582e4eacc1810f76656d1811693ff6c6737d2a. The community vLLM image has a recorded digest ending abe85a6; its complete digest is retained in the adjacent JSON and original manifest. A document pin does not replace any of these identities.

The source manifest and reproduction document describe two 128 GB unified-memory GB10 nodes using TP2 over RoCE. NVIDIA NVFP4 is the storage format, while Marlin uses W4A16 MoE compute. Do not describe the result as a native W4A4 throughput test. The target export lacks an MTP head; DFlash2 is the tested speculation path. The report is text only, with image and video inputs disabled.

The selected setup uses eager execution, an explicit 6 GiB FP8 E4M3 KV allocation, a 131,072-token window, one request slot, a 128-token prefill batch and disabled prefix caching. An overlay supplies Transformers 5.16.1 and tokenizers 0.23.1. These details make a useful reproduction inventory. They do not establish portability to a stock upstream installation or a second GB10 software stack, and this is a community recipe rather than an official NVIDIA production qualification.

Read the speed denominator before the headline

The saved comparison JSON includes four naturally stopping sustained requests per arm: two English technical tutorials and two Korean essays. Prompt counts are 78 or 92 tokens. Outputs vary greatly, rather than holding one identical response length constant. The saved English request uses temperature zero, top-p one and seed 37. Its output cap is the remaining serving window. The source does not accept a context-limit finish as a natural benchmark stop.

Estimated decode divides completion tokens by wall time after subtracting measured TTFT. It is different from end-to-end request throughput. There is one boot per arm and four different prompts, not four independent boot replications of an identical task. No uncertainty interval is supplied. Ratios of those medians describe these outputs under these settings; they do not establish a universal improvement or the same reduction in application completion time.

The selected depth-7 arm passed executed semantic checks but retained two strict output-format failures.

For example, the baseline English outputs contain 4,356 and 10,853 tokens, while the depth-7 English outputs contain 7,396 and 2,292. The amount and shape of generated work differ. Those facts matter when deciding whether a faster token stream improves a particular application. Short ACK latency, sustained prose generation, code correctness and long retrieval should remain separate checks.

Preserve the selected arm's strict failures

The selected depth-7 arm passes the executed semantic checks, including the source's fixed and generated code cases. It nevertheless fails two strict requirements. One probe asks for Python without a Markdown fence and receives fenced code. A separate thinking-on probe requires final content exactly 703 and receives reasoning plus the answer. These are observable response-contract failures. The arithmetic answer being present does not turn the strict final-content requirement into a pass.

All arms have quality_passed=false in the raw comparison. A selected serving candidate is therefore not synonymous with a fully qualified deployment. The distinction matters for JSON consumers, code runners and tools that accept a constrained output format. An editor should not strip unwanted material, run the repaired answer and retrospectively mark the original response compliant. A downstream repair workflow would need its own explicitly defined evaluation.

Why the fastest arm was rejected

The baseline and depth-3 diagnostic fail the early one-code-block contract in the short quality gate. The source stops before later code execution checks in that branch. This means later checks are skipped, not that the underlying algorithm was measured and proven wrong. The failed response structure is enough to reject that arm for the source's contract, but it does not justify a broader claim about every code answer from the model.

Likewise, the comparison's semantic_checks_passed=false must be read with the detailed gate. It is a campaign outcome containing an early contract failure. A single Boolean cannot explain which tests executed. The adjacent JSON retains both the flag and strict-failure descriptions, so people and AI can inspect the actual reason rather than infer it from a speed ranking.

All three arms recovered three markers; this is neither full-window proof nor broad quality equivalence.

The long input is an exact retrieval check

All three arms recover beginning, middle and end markers from 120,124 actual input tokens. The configured window is 131,072. The check demonstrates that particular retrieval under that serving configuration; it does not prove a completed full-window input, arbitrary document reasoning or concurrent long-context admission. These requests run at C1, and no higher-concurrency performance sweep is supplied.

The 6 GiB KV allocation is a configuration value. It is not whole-model peak unified memory. The source does not provide a paired total peak-RAM trace for every sustained or long-context request. Weight-file bytes are another quantity and should not be added to an allocation to invent an observed peak. Peak memory, repeated-boot dispersion and concurrency scaling stay unknown in this interpretation.

Treat the custom thinking template as its own condition

The report's forced-OFF template uses an empty thinking prefix while retaining maximum-effort system wording. Planning can leak into final text. The author therefore does not qualify it as native thinking OFF. The separate thinking-on strict failure should not be attributed to that template without an isolated comparison. Output structure, reasoning controls and draft depth vary across the probes, and the saved failures do not identify one universal cause.

DFlash2 draft revision, target revision and image digest remain separate source fields.

Finally, the selected server's restart is followed by a health probe. That is a service-readiness observation, not a repeated quality suite on the final boot. Anyone reusing this recipe should retain the target revision, draft revision, image digest, template and overlay in their own inventory, then validate the response contracts they actually need. The published experiment gives concrete starting conditions and useful failures; it leaves production readiness, broader quality and workload-specific peak memory to further measured evidence.