Update _dedup_save_plans.py

[bigning]

To resolve #125740, save each tensor on the lowest rank.

Fixes #125740

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k @LucasLLC

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/126569

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Upgrade MacOS runner to 14

⏳ 1 Pending, 1 Unrelated Failure

As of commit c102e7f with merge base 64c581a ():

UNSTABLE - The following job failed but was likely due to flakiness present on trunk and has been marked as unstable:

• pull / linux-focal-cuda12.4-py3.10-gcc9-sm86 / test (default, 4, 5, linux.g5.4xlarge.nvidia.gpu, unstable) (gh) ()
  inductor/test_efficient_conv_bn_eval.py::EfficientConvBNEvalCudaTests::test_basic_cuda

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[LucasLLC]

At minimum, we would need this to be optional and it should not replace the current deduplication logic. The current logic is a storage optimization, and this would cause a regression in terms of calling dcp.save on models which are replica heavy.

I think in the originally linked issue, we considered not applying this logic to scalars as a fix for minimizing the number of files which need to be loaded

[bigning]

The current logic is a storage optimization, and this would cause a regression in terms of calling dcp.save on models which are replica heavy.

it's "optimization" only in terms of saving balance. But it hurts the loading performance in multi-node case.

we considered not applying this logic to scalars as a fix

i don't think that works. The root cause is the duplicated tensors are saved in different files, no matter if it's scalar tensor or not.

[bigning]

@LucasLLC , i replied to your comment. Could you please take a look ?

[LucasLLC]

@bigning , I believe this generally this isn't seen as a large issue during loading since files are all expected to live in the same NFS directory. Additionally, I think we would prioritize saving latency over loading at least in this case since users are typically saving much more often. Could we change this PR to make the de-duplication optional (and true by default)?

[Skylion007]

Suggested change

	select_plan_idx = min(plan_indices, key=lambda plan_idx: plan_idx)
	select_plan_idx = min(plan_indices)

[bigning]

@LucasLLC

make the de-duplication optional

If we skip the dedup, it fails here https://github.com/pytorch/pytorch/blob/main/torch/distributed/checkpoint/default_planner.py#L386-L387.

files are all expected to live in the same NFS directory.

For NFS, the issue is not about if the file exists in the NFS. It's that each node needs to download the Nx times more files. If it's using cloud, this introduces:

1. Nx cloud storage money cost for downloading more data
2. Nx more time blocking the training. For saving, it can be async, but for loading, usually loading checkpointing blocks the training.
3. Downloading large files from cloud is not stable, this is really a pain point for using cloud storage. The more files you download, the more chance the checkpointing downloading fails.

Can I just add a save_to_same_rank param to dedup_save_plans and DefaultSavePlanner ?

[LucasLLC]

Can I just add a save_to_same_rank param to dedup_save_plans and DefaultSavePlanner

@bigning I understand the pain points in having to download multiple files. I think we would accept a PR which makes this behavior configurable.

[bigning]

makes this behavior configurable.

@LucasLLC , this makes sense. I added a param to dedup_save_plans and DefaultSavePlanner, could you take a look? Thanks!

[LucasLLC]

Thanks @bigning ! This looks good to me. Will merge if tests pass

[bigning]

thanks @LucasLLC , it seems two lints failed, I can't find useful error message, do you know how to fix or how to re-run?

[bigning]

thanks @LucasLLC , it seems two lints failed, I can't find useful error message, do you know how to fix or how to re-run?

NVM, i just submitted another commit. Looks all tests are green now.

[bigning]

@LucasLLC , can you help merge?

[LucasLLC]

@pytorchbot merge

[pytorch-bot]

Pull workflow has not been scheduled for the PR yet. It could be because author doesn't have permissions to run those or skip-checks keywords were added to PR/commits, aborting merge. Please get/give approval for the workflows and/or remove skip ci decorators before next merge attempt. If you think this is a mistake, please contact PyTorch Dev Infra.

[bigning]

@pytorchbot merge

[pytorch-bot]

Pull workflow has not been scheduled for the PR yet. It could be because author doesn't have permissions to run those or skip-checks keywords were added to PR/commits, aborting merge. Please get/give approval for the workflows and/or remove skip ci decorators before next merge attempt. If you think this is a mistake, please contact PyTorch Dev Infra.

[LucasLLC]

@pytorchbot merge

[pytorchmergebot]

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here

[pytorchmergebot]

Merge failed

Reason: 1 jobs have failed, first few of them are: trunk / macos-13-py3-arm64 / build

Details for Dev Infra team

Raised by workflow job