[yaoyu-33]

Summary

Fixes two model-side config regressions and records the current-main status for the related TokenizerConfig issue:

• Keep Gemma4 dense-provider MoE defaults from being overwritten by base HF CONFIG_MAPPING when enable_moe_block=False, using a reusable mapping-gate hook.
• Construct Qwen3-ASR thinker_config before Transformers validation calls get_text_config() during config initialization.
• Confirm TokenizerConfig already has the MCore tokenizer padding fields on current main via PR [training] fix: support MCore tokenizer padding fields #4075.

NVBug Status

NVBug	Current main status	PR status
6238889	Not fixed. Gemma4Bridge.provider_bridge() still lets base CONFIG_MAPPING map HF MoE fields before the enable_moe_block guard.	Fixed in this PR by adding a base mapping-gate hook and using it to skip Gemma4 conditional MoE fields when HF disables the MoE block. Dense-config coverage was added.
6238113	Already fixed by PR #4075. TokenizerConfig now has make_vocab_size_divisible_by, tensor_model_parallel_size, and rank.	No additional code change needed here; included for batch status tracking.
6234510	Not fixed. Qwen3ASRConfig.__init__() calls PretrainedConfig.__init__() before thinker_config exists, and Transformers validation calls get_text_config() during that window.	Fixed in this PR by constructing thinker_config before the base initializer and adding config construction coverage.

Validation

• ruff format src/megatron/bridge/models/conversion/model_bridge.py src/megatron/bridge/models/gemma/gemma4_bridge.py src/megatron/bridge/models/qwen3_asr/hf_qwen3_asr/configuration_qwen3_asr.py tests/unit_tests/models/gemma/test_gemma4_bridge.py tests/unit_tests/models/qwen3_asr/test_qwen3_asr_config.py
• ruff check --fix src/megatron/bridge/models/conversion/model_bridge.py src/megatron/bridge/models/gemma/gemma4_bridge.py src/megatron/bridge/models/qwen3_asr/hf_qwen3_asr/configuration_qwen3_asr.py tests/unit_tests/models/gemma/test_gemma4_bridge.py tests/unit_tests/models/qwen3_asr/test_qwen3_asr_config.py
• python -m py_compile src/megatron/bridge/models/conversion/model_bridge.py src/megatron/bridge/models/gemma/gemma4_bridge.py src/megatron/bridge/models/qwen3_asr/hf_qwen3_asr/configuration_qwen3_asr.py tests/unit_tests/models/gemma/test_gemma4_bridge.py tests/unit_tests/models/qwen3_asr/test_qwen3_asr_config.py
• Direct Qwen3-ASR config repro: Qwen3ASRConfig(), Qwen3ASRConfig.from_dict(...), and AutoConfig.from_pretrained("Qwen/Qwen3-ASR-1.7B", trust_remote_code=True) now expose thinker_config.
• pre-commit run --all-files

Attempted targeted pytest with uv run python -m pytest ...; local execution was blocked before collection by the platform wheel availability for nvidia-resiliency-ext. uv run pre-commit run --all-files hit the same local resolver blocker, so the installed pre-commit hooks were run directly. No full suite was run.

Notes

• No changes under 3rdparty/Megatron-LM/.
• Public text is sanitized.

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

[claude]

Nit (non-blocking): mock_hf_config uses num_experts=128, top_k_experts=8, moe_intermediate_size=704 — identical to the Gemma4ModelProvider defaults. After the CONFIG_MAPPING exclusion, test_moe_config passes whether or not the enable_moe_block branch reads from HF config, because the provider defaults already match.

Consider using distinct values in the MoE fixture (e.g. num_experts=64, top_k_experts=4) so test_moe_config actually proves the HF values flow through the enable_moe_block branch.

[claude]

Light Code Review - Both fixes are correct and well-scoped. See below for details.

Gemma4 CONFIG_MAPPING exclusion - The base CONFIG_MAPPING entries (num_experts, num_moe_experts) and (moe_intermediate_size, moe_ffn_hidden_size) were overwriting Gemma4ModelProvider defaults for dense models (enable_moe_block=False) since hf_config_to_provider_kwargs runs unconditionally. Filtering these three megatron fields out of Gemma4 CONFIG_MAPPING and relying on the explicit enable_moe_block guard in provider_bridge() is the right fix. Good catch on the tense_dense_config to test_dense_config_keeps_default_moe_fields rename -- the old name meant the test never ran.

Qwen3ASR thinker_config init ordering - Moving thinker_config construction before super().init() is correct -- Transformers PretrainedConfig.init can call get_text_config() during validation, which needs self.thinker_config to exist. The isinstance guard handles the from_dict path where sub_configs may pass an already-constructed Qwen3ASRThinkerConfig.

Minor observation - See inline comment on test_gemma4_bridge.py:73 -- the MoE-enabled test fixture uses values identical to provider defaults, so test_moe_config cannot distinguish read-from-HF-config from fell-through-to-default. Non-blocking.

Suggested test cases - No perf tests impacted.

[yaoyu-33]

/ok to test 483b0d8