Skip to content

Support GLM-5.2 - #2093

Merged
zhuzilin merged 1 commit into
mainfrom
glm5.2
Jun 16, 2026
Merged

Support GLM-5.2#2093
zhuzilin merged 1 commit into
mainfrom
glm5.2

Conversation

@zhuzilin

Copy link
Copy Markdown
Contributor

No description provided.

@zhuzilin
zhuzilin merged commit 872504c into main Jun 16, 2026
35 checks passed
@zhuzilin
zhuzilin deleted the glm5.2 branch June 16, 2026 23:04
yushengsu-thu added a commit to radixark/Megatron-Bridge that referenced this pull request Jun 21, 2026
…gatron)

megatron-core's DSAIndexer applies RoPE to the LAST qk_pos_emb_head_dim of each index
head (split([D-rope, rope])), but the HF/DeepSeek (glm_moe_dsa) checkpoint stores the rope
dims in the FIRST half. The previous name->name mapping loaded wq_b/wk/k_norm unchanged, so
the indexer rotated the wrong dimensions -- its index scores were structurally decorrelated
from the reference (HF<->bridge pearson ~0.48 vs slime ~0.70), flipping ~50% of the sparse
top-k key selection at long context.

Fix: _IndexerRopeHalfSwapMapping swaps the two halves of each index head's
dsa_indexer_head_dim when loading the indexer wq_b, wk, k_norm.weight and k_norm.bias
(self-inverse on export); weights_proj (per-head scalar) is untouched. k_norm is included
because it is applied to the (swapped) key BEFORE RoPE, so its per-dim scale/bias must be
swapped consistently. Mirrors the slime mbridge reference (THUDM/slime#2093
slime_plugins/mbridge/deepseek_v32.py: "training uses last half for rope while DeepSeek
uses first half").

Covers GLM-5.1 (index_topk_freq=1) and GLM-5.2 (cross-layer). Validated against slime: all 5
indexer weights become bit-identical, indexer score pearson(slime,bridge) -> 0.98-1.0, and a
3-way HF-reference check shows the fixed bridge tracks HF identically to slime.

Signed-off-by: Yusheng Su <yushengsu.thu@gmail.com>
yushengsu-thu added a commit to yushengsu-thu/miles that referenced this pull request Jun 26, 2026
… cuda-graph hang)

Migrated from radixark#1374 (THUDM/slime#2093). DeepEP/NVSHMEM's internal NCCL opens a
second NCCL communicator that collides with miles' NCCL and hangs during SGLang CUDA-graph replay.
Applied to test whether it also resolves the GLM-5.2 dp-attention EVAL-ON deadlock (skeptical: that
hang is in CPU/gloo collectives + GLM-5 LoRA uses triton MoE not DeepEP, so NVSHMEM may be inert here
-- but empirical test pending a devbox). If it does not fix it, fall back to the miles-side eval
grouped-submission fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MuN5ow5hHFxPze36uhgZC4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant