[peft] fix: support decentralized process groups in adapter export

[yaoyu-33]

What changed

Dense PEFT adapter export now uses the ProcessGroupCollection attached to the Megatron model when decentralized process groups are enabled.

The supported trigger is a PEFT-enabled model constructed with model-owned process groups, followed by adapter task construction through save_hf_adapter() / stream_adapter_weights_megatron_to_hf(). Adapter discovery previously queried the global pipeline group, which is intentionally unset in this mode and causes an assertion. Fresh adapter mappings also retained constructor-time global groups instead of the model topology.

The fix reuses the existing model process-group helpers to:

• discover adapters and select the owning pipeline rank through the model's PP group;
• install the model collection on the temporary mapping registry; and
• install it on both generated adapter mappings before materialization.

When no model-owned collection exists, the existing global-state fallback is unchanged.

Regression evidence

Fail-before on unmodified main:

uv run --no-sync python -m pytest -q --confcutdir=tests/unit_tests/models tests/unit_tests/models/test_model_bridge_lora.py::test_build_adapter_conversion_tasks_uses_model_process_groups
1 failed: global process-group state must not be used

Pass-after:

uv run --no-sync python -m pytest -q --confcutdir=tests/unit_tests/models tests/unit_tests/models/test_model_bridge_lora.py::test_build_adapter_conversion_tasks_uses_model_process_groups
1 passed

Adjacent validation:

uv run --no-sync python -m pytest -q --confcutdir=tests/unit_tests/models tests/unit_tests/models/test_model_bridge_lora.py
57 passed

uv run --no-sync pre-commit run --all-files
Passed

git diff --check also passes.

Scope

This change covers dense adapter task discovery, ownership, and mapping collectives. It does not claim validation of decentralized grouped-expert/MoE adapter export or model-quality/convergence behavior.

[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 4f0039a

[claude]

Light review — LGTM

The change correctly threads the model pg_collection into adapter task construction, replacing global parallel_state lookups in build_adapter_conversion_tasks and _megatron_global_adapters_info_all_pp_ranks. This matches the existing decentralized-PG helper pattern (_get_pp_group / _get_pp_rank / _get_pg_collection_from_model) already used throughout model_bridge.py, and set_process_groups_from_pg_collection no-ops safely when pg_collection is None (verified by the updated test_build_adapter_conversion_tasks). Caching current_pp_rank avoids a redundant lookup per adapter. Nice new test asserting the mapping groups (pp_group / _tp_group / ep_group / _etp_group) come from the model, not global state.

One observation (non-blocking, likely follow-up scope): the materialization helpers still read global parallel_state — _split_gdn_in_proj_linear_out_weight (L385), _split_fused_fc1_linear_out_weight (L499), and _gather_expert_adapter_weight / _select_expert_adapter_weight (L523/L527/L539). In the decentralized-PG path where mpu is never initialized, those get_tensor_model_parallel_world_size() / get_expert_model_parallel_group() calls would return the wrong sizes/groups, so fused-FC1, GDN, and expert-sharded LoRA merges could still compute incorrect shard splits. If those paths are exercised without parallel_state, they would need the same pg_collection threading. If out of scope here, consider a note in the PR description.

Suggested test cases

• No perf tests impacted.
• test_build_adapter_conversion_tasks_uses_model_process_groups (added — validates mapping groups sourced from model pg_collection)
• test_build_adapter_conversion_tasks (updated — validates the pg_collection=None fallback path)