Repository navigation
fix(ckpt): auto-generate DSv4 pipeline layout on export when run_config lacks it - #4306
Conversation
…ig lacks it
PP>1 export of a DSv4 checkpoint fails with 'pipeline_model_parallel_layout must be set': the import-time provider finalizes the layout into a PipelineParallelLayerLayout object, and run_config.yaml serializes that as an instantiation stub ({_target_: ...}) — the layout data is lost, so the export-side reader (which expects a list) finds nothing. Fall back to the bridge's generate_pipeline_layout, exactly like the import path already does. Reproduced and verified on a full DeepSeek-V4-Flash TP1/PP4/EP8 checkpoint.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Lingrui Mei <lmei@nvidia.com>
The script-level provider fallback alone is insufficient: load_megatron_model rebuilds the provider from the checkpoint's run_config.yaml, where the layout was serialized as an object stub, so the PP>1 assert still fired inside build_and_load_model. Pass the resolved layout through mp_overrides (captured before finalize converts it to a PipelineParallelLayerLayout) and declare the field in ModelParallelKwargs. Caught by a 32-GPU GB300 end-to-end run on a freshly imported DeepSeek-V4-Flash checkpoint. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Lingrui Mei <lmei@nvidia.com>
|
/ok to test 3acf617 |
|
Validated end-to-end on 32x GB300 (TP1/PP4/EP8) with real DeepSeek-V4-Flash weights. The original script-level fallback turned out to be insufficient on its own: Test flow: fresh HF->Megatron import (run_config carries the stub — confirmed before export), then export with no manual repair. The fallback log line fires ( |
What
PP>1 export falls back to
bridge.generate_pipeline_layout(...)whenrun_config.yamlcannot provide a usable layout — exactly like the import path already does.Why (round-trip bug)
import→exportof a DeepSeek-V4 checkpoint at PP>1 currently fails withAssertionError: pipeline_model_parallel_layout must be set when using hash MoE layers with pipeline parallelism (PP > 1).Root cause: by save time the provider's layout has been finalized into a
PipelineParallelLayerLayoutobject, andrun_config.yamlserializes it as an instantiation stub — the actual layout data is lost:The export-side reader only accepts a list, finds the stub, and the provider then asserts. Reproduced on a full DeepSeek-V4-Flash TP1/PP4/EP8 checkpoint (imported with this same script); with the fallback the export proceeds.
A deeper fix would be serializing the layout in its list form in
run_config.yaml(checkpointing owners' call); this script-level fallback restores the import→export round trip now.Notes
🤖 Generated with Claude Code