[model] fix: Preserve GLM-5 MTP layers during conversion

[yaoyu-33]

What changed

Preserve the MTP layer count from released GLM-5-family Hugging Face configs during default AutoBridge conversion.

User impact

GLM-5, GLM-5.1, and GLM-5.2 configs declare one next-token-prediction layer, and their checkpoints contain appended MTP tensors. The GLM-5 bridge was overwriting the generic num_nextn_predict_layers -> mtp_num_layers mapping with None. Megatron-Core therefore constructed no MTP destination parameters, leaving the existing MTP mappings unreachable and silently omitting that checkpoint state from non-strict conversion and round trips.

Root cause and fix

The override was introduced before GLM-5 MTP parameter mappings were available and remained after those mappings were added. Remove only that stale override so the generic config bridge supplies the released layer count. Add a focused provider-contract regression test that fails with None before the fix and passes with 1 after it.

Validation

• uv run python -m pytest tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py::test_provider_bridge_preserves_mtp_architecture_from_hf_config -q — fails before (None != 1), passes after
• uv run python -m pytest tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py tests/unit_tests/models/test_autobridge_registration_matrix.py tests/unit_tests/recipes/test_glm5_perf_recipes.py -q — 19 passed
• git diff --check — passed
• uv run pre-commit run --all-files — passed

Scope

This changes only GLM-5-family provider configuration ownership and its unit coverage. It does not change public APIs, dependencies, CI workflows, the Megatron-Core submodule, or main-token inference semantics.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[yaoyu-33]

/ok to test 5e3f8f5

[claude]

LGTM - clean, correctly scoped bug fix.

Verified the fix: removing the stale provider.mtp_num_layers = None override lets the base provider_bridge() supply the value via CONFIG_MAPPING (num_nextn_predict_layers -> mtp_num_layers, model_bridge.py:478). This makes the MTP parameter mappings in mapping_registry() (glm5_bridge.py:215-285) reachable instead of silently unused, so MTP checkpoint state is preserved in conversion and round-trips.

The new regression test correctly captures the bug: the stubbed provider_bridge reads num_nextn_predict_layers to mimic CONFIG_MAPPING, so the assertion mtp_num_layers == 1 fails pre-fix and passes post-fix. The zero-MTP path is already covered by test_mapping_registry_omits_mtp_mappings_without_nextn_layers.

No perf tests impacted.

Suggested test cases:

• tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py::test_provider_bridge_preserves_mtp_architecture_from_hf_config
• tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py::test_provider_bridge_maps_dsa_architecture_from_hf_config
• tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py::test_mapping_registry_omits_mtp_mappings_without_nextn_layers
• tests/unit_tests/models/glm_moe_dsa/test_glm5_bridge.py::test_mapping_registry_includes_mtp_standalone_weights