refactor(model): build OLMoE and GLM-4.5 from builder-backed model configs

[kamran-nvidia]

What does this PR do ?

Moves OLMoE and GLM-4.5 onto the builder-backed ModelConfig / ModelBuilder path, for recipes and checkpoint conversion, following Muse Glimmer.

Changelog

• Opt-in after fix(model): default MODEL_CONFIG_CLASS to None and opt in per family #6305: MODEL_CONFIG_CLASS now defaults to None, so each migrated bridge sets MODEL_CONFIG_CLASS = BridgeGPTModelConfig next to USE_MODEL_CONFIG_FOR_CONVERSION = True (as Qwen3 and Llama do), and its tests assert it.
• OlMoEBridge: provider_bridge() is replaced by hf_config_to_model_config_kwargs(), and the provider path reuses the same kwargs. The builder config carries the OLMoE layer spec (transformer_layer_spec=olmoe_layer_spec), so both paths build OLMoESelfAttention with QK layernorm. USE_MODEL_CONFIG_FOR_CONVERSION = True.
• olmoe_layer_spec now also accepts a builder-backed GPT model config, using the builder-side TE layer helper that reads config.transformer. Previously it called the provider's default_layer_spec, which reads provider-only fields (use_transformer_engine_full_layer_spec, dense_grouped_gemm) and fails on a builder config. The provider path is unchanged.
• GLM45Bridge: same kwargs migration. The builder config leaves transformer_layer_spec unset because MCore's builder default for MoE models is already get_gpt_decoder_block_spec, which honors the dense-first moe_layer_freq. The deprecated provider path keeps its explicit decoder block spec in hf_config_to_provider_kwargs(). USE_MODEL_CONFIG_FOR_CONVERSION = True.
• Recipes: all six GLM-4.5 H100 recipes use get_model_config(). OLMoE recipes construct OlMoEModelProvider directly and are unchanged.
• Tests:
  • Builder mapping, provider/builder parity, and an OLMoE layer-spec equivalence check between provider and builder config.
  • GLM-4.5 recipe fakes provide get_model_config().
  • A strict recipe test runs every GLM-4.5 recipe against a real BridgeGPTModelConfig at the real model depth (46/92 layers).

Verification

Each family was validated separately on tiny random-weight checkpoints (single GB200 node, NeMo 26.10 container).

Conversion paths:

• scripts/conversion GPU import at TP2 and export.
• AutoBridge.import_ckpt / export_ckpt.
• Load + forward as in compare.py.
• roundtrip_checkpoint.

Each was run on this branch and on main.

Check	OLMoE (MoE)	GLM-4.5 (dense-first MoE)
Provider fields, main vs this branch	identical	identical (incl. MTP=1 config)
get_model_config() vs provider	0 diffs (18 on main)	0 diffs (24 on main)
Export vs source HF weights (GPU TP2, CPU, and from a main-imported checkpoint)	bit-exact	bit-exact except e_score_correction_bias dtype (see below)
Logits: this branch vs main, and this branch on a main-imported checkpoint	bitwise-identical	bitwise-identical
Logits vs HF	cosine 0.999984	cosine 0.999945
roundtrip_checkpoint TP2	pass	pass
Unit tests (family run)	63 passed	45 passed

Regression: 9 OLMoE/GLM-4.5 recipe factories and 295 tests (1 skipped) across models/olmoe, models/glm, test_auto_bridge.py, test_gpt_model_config.py, the OLMoE/GLM-4.5/GLM-5 recipe tests and doc_consistency.

Lint: ruff check and ruff format --check are clean on the changed code (ruff 0.16.7; pre-commit itself not run).

Known, pre-existing: a bf16 source checkpoint exports e_score_correction_bias as fp32, because Megatron keeps the router expert bias in fp32. The values are identical after a cast, and main exports the same way.

After rebasing onto main with #6305 (Megatron Core a98aed553): 268 passed, 1 skipped, including #6305's all-bridges opt-in check in test_gpt_model_config.py; ruff clean.

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you add or update any necessary documentation?
• Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  • Reviewer: Does the PR have correct import guards for all optional libraries?

Additional Information

• Part of the incremental provider → builder migration (refactor(model): add Qwen3 builder-backed model config with YaRN support #6365 Qwen3, refactor(model): build Qwen2 and MiMo from builder-backed model configs #6379 Qwen2 + MiMo, two families per PR).
• Independent of refactor(model): add Qwen3 builder-backed model config with YaRN support #6365: neither family needs the YaRN config fields, so this targets main directly.

🤖 Generated with Claude Code

[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.

[kamran-nvidia]

/ok to test 64df9ee

[kamran-nvidia]

/ok to test 584dc25

[github-actions]

Automatic Claude reviews have been retired. To request a pull-request review, post a comment containing:

/review

Add model=claude to use a Claude reviewer (the default is model=codex). mode=light|strict selects the review depth; for example, /review model=claude mode=strict. Comment /review help for all options.