launcher/specs/tech-architecture/glm53-recipe-state.md

GLM-5.3-Flash NVFP4 — three quant variants measured on 2× DGX Spark (ds4)

Measured 2026-08-27/28 on cluster ds4 (dgx3+dgx4, switched fabric), all three served by sm121 through the launcher, same benchmark invocation:

tool-eval-bench run --base-url http://<head>:30000/v1 --model glm53 \
  --seed 42 --hardmode --perf --concurrency 1,2

All three share served name glm53 — clients never changed between runs.

Results

recipe	quant	quality	points	decode tg t/s (c1)	tg c2	TTFT	deployability	MTP
glm53-flash-nvfp4-lab	local-inference-lab mixed NVFP4/MXFP8-MTP	89	155/174	28.4	43.4	3.9 s	70	✅ k=3, accept len ~2.9–3.5, ~63–83 %
glm53-flash-nvfp4-redhat	RedHatAI W4A4 compressed-tensors	90	159/176	13.9	13.8	2.2 s	67	❌ (no MTP weights in checkpoint)
glm53-flash-nvfp4	LibertAIDAI NVFP4-A16	88	154/176	26.2	22.7	6.3 s	69	✅ k=5

(lab scored /174 — one scenario skipped by the harness that run; quality % is comparable. LibertAIDAI is the only variant whose MTP regresses under c2 (26.2→22.7) — lab's k=3 draft scales, LibertAIDAI's k=5 does not.)

Prefill (pp2048) 0.3–1.7 K t/s depending on depth/concurrency — noisy, all three in the same band (NAS load-influenced); decode is the stable discriminator.

Read of the numbers

• lab is the throughput pick: MTP doubles decode (28–43 t/s vs ~14 baseline) at −1 quality point. Acceptance lengths matched upstream's 2.55–3.5 range.
• redhat is the quality pick (90/100 — best of the three) but is a baseline-decode dead-end on this box: its checkpoint ships zero MTP tensors (verified index: 146,745 tensors, none under layer 45), so it is stuck at ~14 t/s.
• lab = best agent-throughput/day-driver; redhat = eval ceiling; LibertAIDAI = solid fallback (proven first, but k=5 MTP regresses at c2).

Images & patches

image dir	base	patches
glm53-flash-nvfp4	vllm/vllm-openai:glm53-flash-arm64-cu130	kingjones30 NoPE-MLA mod (4-part, anchor-asserted)
glm53-flash-nvfp4-lab	same	+ 4 FujitsuPolycom patches (Apache-2.0, see patches/UPSTREAM.md): model.py naming shim, modelopt MTP namespace fix, persistent_topk CC-12.x guards ×2
redhat recipe reuses glm53-flash-nvfp4:local (mod is quant-independent)

Boot markers [quantprobe] layer=RoutedExperts prefix=model.layers.45.mlp.experts algo=MXFP8 confirm the MTP fix is live; algo=None there = broken load.

Operational notes (measured)

• lab weight load: 92.19 GiB / 700 s sequential from the NAS HF cache; --kv-cache-memory-bytes 10737418240 → KV 1,164,369 tokens / 2.22× @ 512K (matches upstream to the digit — do NOT switch back to GMU sizing).
• First launcher serve of lab died on both ranks at ~54 s (exit 1, logs lost to --rm); re-run was clean twice. Suspected transient (cold imports + simultaneous launch). If it recurs: re-launch without --rm and keep logs.
• sm121 serve immediately after sm121 stop can fail with "cluster has only 1 nodes" — occupancy race, nodes not yet released; wait ~10 s and retry.
• LibertAIDAI/redhat recipes still run FlashInfer autotune (60-min possible boot, VLLM_ENGINE_READY_TIMEOUT_S=3600 set); the lab recipe disables it via --kernel-config per upstream's proven boot.
• Chat-template caveat: reasoning_effort:"low" still emits a reasoning trace (budget ≠ 0); max_tokens:48 can yield content: null, finish: length — use ≥256 for smoke tests.

Follow-ups

• Vendor instanttensor loader into the lab image (~30 s vs 700 s weight load).
• Consider adding --kernel-config autotune-off + pinned KV to the redhat and LibertAIDAI recipes (their boot could be minutes shorter; verify before trusting).
• MTP for redhat is impossible unless someone trains/exports a drafter into the checkpoint — don't chase it.