[EZ] Pass seed to data sampler.

[EugenHotaj]

We currently hardcode zero. I assume this is not intentional.

Context

What is the purpose of this PR? Is it to

• add a new feature
• fix a bug
• update tests and/or documentation
• other (please add here)

Please link to any issues this PR addresses.

Changelog

What are the changes made in this PR?

• As titled

Test plan

Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

• run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
• add unit tests for any new functionality
• update docstrings for any new or updated methods or classes
• run unit tests via pytest tests
• run recipe tests via pytest tests -m integration_test
• manually run any new or modified recipes with sufficient proof of correctness
• include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

UX

If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

• I did not change any public API
• I have added an example to docs or docstrings

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

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

[RdoubleA]

Getting the seed from self.seed is risky, since we are using self.seed = training.set_seed() in our recipes, which will actually return a different seed on every rank. I am not sure if the sampler should have the same seed across ranks, but I imagine to ensure all ranks are not shuffling the data differently we would want the same seed. It would be better to set it from cfg.seed directly to keep the same data seed across all ranks.

Tagging @andrewkho for thoughts on setting the seed in DistributedSampler.

[EugenHotaj]

@RdoubleA I might be misunderstanding the code but I thought set_seed returned the seed you passed it in from the config (or if you don't pass anything, a global seed). I guess my intention here is to just pass in the seed from the config. Lmk if there is a better way to do it (maybe pass in cfg.seed directly?)

[RdoubleA]

Ah my bad, you're right. It's returning the global seed not the local seed. In that case this should be ok

[RdoubleA]

@EugenHotaj actually we might need to do something like this to get the seed directly from the config and maintaining BC with existing configs:
seed=cfg.get("seed", None) or 0

[EugenHotaj]

@RdoubleA done

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 23.97%. Comparing base (779569e) to head (3708bf9).

Files with missing lines	Patch %	Lines
tests/recipes/test_lora_finetune_single_device.py	0.00%	2 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (779569e) and HEAD (3708bf9). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (779569e)	HEAD (3708bf9)
	3	2

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2266       +/-   ##
===========================================
- Coverage   65.34%   23.97%   -41.37%     
===========================================
  Files         358      358               
  Lines       21207    21207               
===========================================
- Hits        13857     5084     -8773     
- Misses       7350    16123     +8773     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[EugenHotaj]

@RdoubleA I'm not sure what's happening with the TestFullFinetuneDistributedRecipe::test_training_state_on_resume_from_distributed_checkpoint_multi_rank test that keeps failing. It keeps deadlocking for some reason:

3|5|Loss: 11.97959041595459:  50%|█████     | 1/2 [00:00<00:00,  1.63it/s][rank0]:[E120 05:15:13.042532067 ProcessGroupNCCL.cpp:616] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=420, OpType=_REDUCE_SCATTER_BASE, NumelIn=8208384, NumelOut=4104192, Timeout(ms)=1800000) ran for 1800059 milliseconds before timing out.
[rank0]:[E120 05:15:13.042708659 ProcessGroupNCCL.cpp:1785] [PG ID 0 PG GUID 0(default_pg) Rank 0] Exception (either an error or timeout) detected by watchdog at work: 420, last enqueued NCCL work: 426, last completed NCCL work: 419.
[rank1]:[E120 05:15:13.091641415 ProcessGroupNCCL.cpp:616] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=423, OpType=_REDUCE_SCATTER_BASE, NumelIn=64, NumelOut=32, Timeout(ms)=1800000) ran for 1800096 milliseconds before timing out.
[rank1]:[E120 05:15:13.091715615 ProcessGroupNCCL.cpp:1785] [PG ID 0 PG GUID 0(default_pg) Rank 1] Exception (either an error or timeout) detected by watchdog at work: 423, last enqueued NCCL work: 424, last completed NCCL work: 422.
[rank1]:[E120 05:15:14.970203483 ProcessGroupNCCL.cpp:1834] [PG ID 0 PG GUID 0(default_pg) Rank 1] Timeout at NCCL work: 423, last enqueued NCCL work: 424, last completed NCCL work: 422.
[rank1]:[E120 05:15:14.970217275 ProcessGroupNCCL.cpp:630] [Rank 1] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
[rank1]:[E120 05:15:14.970222520 ProcessGroupNCCL.cpp:636] [Rank 1] To avoid data inconsistency, we are taking the entire process down.
[rank1]:[E120 05:15:14.971615376 ProcessGroupNCCL.cpp:1595] [PG ID 0 PG GUID 0(default_pg) Rank 1] Process group watchdog thread terminated with exception: [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=423, OpType=_REDUCE_SCATTER_BASE, NumelIn=64, NumelOut=32, Timeout(ms)=1800000) ran for 1800096 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:618 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x96 (0x7f6f92b6c446 in /home/ec2-user/actions-runner/_work/torchtune/torchtune/3/envs/test/lib/python3.10/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x282 (0x7f6f485cc772 in /home/ec2-user/actions-runner/_work/torchtune/torchtune/3/envs/test/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::watchdogHandler() + 0x233 (0x7f6f485d3bb3 in /home/ec2-user/actions-runner/_work/torchtune/torchtune/3/envs/test/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x14d (0x7f6f485d561d in /home/ec2-user/actions-runner/_work/torchtune/torchtune/3/envs/test/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so)
frame #4: <unknown function> + 0x145c0 (0x7f6f9301d5c0 in /home/ec2-user/actions-runner/_work/torchtune/torchtune/3/envs/test/lib/python3.10/site-packages/torch/lib/libtorch.so)
frame #5: <unknown function> + 0x9f832 (0x7f6fa0c9f832 in /lib64/libc.so.6)
frame #6: <unknown function> + 0x3f480 (0x7f6fa0c3f480 in /lib64/libc.so.6)

Doesn't seem like it would be related to these changes (or maybe surfacing some latent bug), but any idea what's going on?

[EugenHotaj]

^ @RdoubleA any thoughts on the failure I mentioned above?

[RdoubleA]

@EugenHotaj Sorry I've been meaning to investigate this more. I do think it's related to changing the seed though, the failing test is using DCP's resume from checkpoint. DCP was only recently added, so my guess is it's not setting the seed correctly when resuming training.

Will update here once I debug more.

[ebsmothers]

Hey @EugenHotaj I just took a look at this. Unfortunately haven't pinpointed the cause of the test failing (yet), but one other wrench for you: cfg.get("seed", 0) isn't doing what we would want here. Many of our configs set seed: null and in that case we will actually pass seed=None here, triggering an error in the sampler. (This just doesn't get caught in our recipe tests because we always explicitly set the seed there for reproducibility.) Hopefully will have an answer on the failing test before long.

[ebsmothers]

Quick update on the deadlock: I noticed it only occurs for the 8B model and not the 7B one, and for the 8B config we shard a couple extra layers by default. So by commenting out this line the test actually passes on your PR. I am not exactly sure why this sharding by itself is OK, but combining it with the seed is not. I've been digging around the DCP code a bit and found that by setting planner=DefaultPlanner(flatten_state_dict=False) in both async_save and load we get by the deadlock (but the outputs incorrect). Admittedly I'm a bit of a DCP noob so will tag experts @saumishr and @ankitageorge for their thoughts here.

[EugenHotaj]

@ebsmothers thanks for taking a look!

Many of our configs set seed: null and in that case we will actually pass seed=None here, triggering an error in the sampler.

Good point, will verify this -- my assumption was that this would return 0 when seed=null (i.e. seed=None) but you might be right.