WIP: reconcile GLM-5.2 glm_moe_dsa (spec-decode + #130) - #158
Merged
Conversation
added 7 commits
August 15, 2026 09:58
Salvages #130's unit suite (the only coverage for the new dequant_fp8_state_dict + stack_expert_scales helpers). Two guards reconcile it to dev: skip test_glm_cpp_dequant_matches_python when moe_infinity._store is conftest-stubbed, and skip test_glm_routing_parity_vs_hf on dev's HF-delegating SyncGlmMoeDsaMoEBlock (parity already covered by test_glm_routing.py).
… on dev Move the route_tokens_to_experts capability check ahead of model construction so the test skips cleanly on dev's HF-delegating block without touching global RNG. Also record in the decision log that dev already ships the GLM README row/note and the glmmoedsa registry assertion (Task 4.2), so neither is re-added.
This was referenced Aug 15, 2026
drunkcoding
marked this pull request as ready for review
August 15, 2026 18:23
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Strategy
dev@0e4904f(post-#140/#150) is the canonical baseline: it already registersglm_moe_dsa(type 5), ships its own DSA/MTP-integrated
SyncGlmMoeDsaMoEBlock, the native FP8 e4m3 block-scaledequant-on-copy path, DSA indexer/IndexShare, and MTP spec-decode. PR #130 branched from an older
dev(b33d5fa) and re-implemented an overlapping-but-divergent GLM/FP8 stack. Per the writtenreconciliation plan, we canonicalize on
devand salvage only #130's unique wanted deltas —dropping everything spec-decode already provides.
Full auditable triage (git cherry, range-diff, per-commit verdicts, and every deviation with evidence)
is in
docs/superpowers/plans/2026-08-14-glm-5.2-reconciliation.decision-log.md(in this PR).What landed (net wanted deltas) — 4 files
moe_infinity/utils/fp8.py707cc06(subset)dequant_fp8_state_dict+stack_expert_scales(+re/typing/EXPERT_SCALE_KEY_RE). Byte-identical to #130's tested helpers; dev'sdequant_fp8_blockwiseuntouched.core/model/model_topology.cppb5a015astruct TensorPlacement+posix_fadvise(SEQUENTIAL)); fixes multi-day cold-cache store reloads. clang-format clean.tests/python/unit/test_glm_moe_dsa.py9b49f43docs/superpowers/plans/2026-08-14-glm-5.2-reconciliation.decision-log.mdPer-commit verdicts (9 unique #130 commits)
git cherry -v origin/feat/dflash-spec-decode origin/feat/glm-5.2-fp8-support→ 9+commits:707cc06fp8 utilsdequant_fp8_state_dict+stack_expert_scales; dev ownsdequant_fp8_blockwise(d797138).038c149registerglmmoedsa(constants.py,hf_config.py).98a5a39blockSyncGlmMoeDsaMoEBlock(b02c3bd); #130's is a divergent alternative.c8ae160on-GPU dequant3167500+c16cb46, Option A==B parity).b5a015apartition-read perfmodel_topology.cppuntouched by spec-decode; self-contained.187048coffload wiring5b2c2b6.9b49f43tests+docs3dc4e72NVTXba56518.3444ed9smoke e2etest_glm_smoke.pyalready has theMOE_GLM_SMOKEgate.Divergence summary (spec-decode/dev vs #130)
SyncGlmMoeDsaMoEBlockdelegates routing to HF (_route→_hf_route_tokens)and integrates DSA/MTP; feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130's inlines
route_tokens_to_experts+ nvtx annotations and assumes analways-present executor. Kept dev's.
dispatcher (
c16cb46); feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130 dequantizes on-GPU after fetch in a competing C++ path (touches thesame
expert_dispatcher/expert_module/py_archer_prefetch). Kept dev's; feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130's C++ dropped.glm_dsa.py+ DSA indexer/IndexShare; feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130 has none.Deviations from the plan (dev evolved past plan assumptions — all evidence-backed)
dev. README already hasa GLM-5.2 table row + a more detailed note + a full usage section;
test_model_registry.pylines29-30 already assert
glmmoedsa. Re-adding would duplicate (violates the no-dup rule).README.mdand
test_model_registry.pyleft untouched.test_glm_routing_parity_vs_hf— GUARDED. It callssync.route_tokens_to_experts(...)(feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130'sblock API); dev's canonical block has no such method (
hasattr == False) and this env shipstransformers.glm_moe_dsa, so verbatim would AttributeError. Added a hermetic class-levelhasattrguard that skips cleanly (parity is already covered bytest_glm_routing.py::test_routing_parity, which usesblock._route).3dc4e72) — DROPPED with compile-probe evidence. The partially-vendorednvtx3.hpp(onlynvtx3.hpp, not its#include "nvToolsExt.h"sibling) shadows the workingsystem header (dev already puts
core/includefirst on the include path) and fails to compileon this CUDA-13.1 host:
P1 (vendored wins) → fatal error: nvToolsExt.h: No such file or directory;P2 (dev current) → OK. dev already solves CUDA≥12.9 NVTX header-only viaba56518(does not linklibnvToolsExt); feat(glm): support zai-org/GLM-5.2-FP8 (glm_moe_dsa) with FP8-in-store expert offload #130's setup.py hunk would reverse that and re-add fp4-kernel/CUDA-stub/python_requires>=3.8regressions if blind-applied. Landed neither file. Reviewer options in thedecision log.
Verification
test_glm_moe_dsa.py+test_model_registry.py→ 15 passed, 2 skipped,0 failed (stable ×3). Skips:
_storeconftest-stubbed (cpp parity) and the routing-parity guard.dequant_fp8_blockwisedefined exactly once; ruff check+format clean.git apply --3way(no conflict markers); clang-format 0 violations;a faithful port of the already-compiled
b5a015a.-fsyntax-onlyreached the file's own body withno syntax errors (only a pre-existing env
torch/extension.hresolution issue). Full CUDApip install -e .build deferred to CI (plan-sanctioned;_storeis not built in this env).fp8.pyandtest_glm_moe_dsa.py(no errors/warnings).clangdnotinstalled here → C++ relied on clang-format + clean apply.
SyncGlmMoeDsaMoEBlock, oneglm_moe_dsamodule, one each ofdequant_fp8_blockwise/dequant_fp8_state_dict/stack_expert_scales; all DROP-list files(
glm_moe_dsa.py,model_offload.py,constants.py,hf_config.py, C++parallel/+py_archer_prefetch.cpp,test_glm_smoke.py,setup.py,README.md,test_model_registry.py)unmodified vs
origin/dev.Known pre-existing issue (not introduced here)
tests/python/unit/test_glm_routing.py::test_routing_parity(dev-owned, byte-identical toorigin/dev)is a flaky test: it passes in isolation / the dev-only batch / the required suite, but under one
multi-file ordering it nondeterministically produces all-
NaNrouting (1 failedthen39 passedonidentical re-runs). Our guard is hermetic (skips before constructing any model), so this branch
contributes no RNG/side-effects — the flake is dev-side. Out of scope to fix here; recommend hardening
that test separately.
git diff --stat origin/dev...HEAD