Support for unsharded parameters in state_dict APIs

[RdoubleA]

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)

Credit goes to @ifed-ucsd for the original commit, I've adapted it a bit to our latest APIs. Original summary:

"This diff adds functionality to shard the model separately from the vocabulary pruning, which allows us to run training keeping the model in bf16 and the vocab pruning in fp32"

Changelog

What are the changes made in this PR?
*

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/2023

• 📄 Preview Python docs built from this PR

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:

• [DomainsOnly] Jobs fail with GLIBC version not found

✅ No Failures

As of commit 687e0a0 with merge base d5c54f3 ():
💚 Looks good so far! There are no failures yet. 💚

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

[pbontrager]

Added some questions around edge cases.

[pbontrager]

If the tensor isn't sharded but it still a NF4Tensor, we still need to upcast the datatype as is done on line 271

[RdoubleA]

so maybe another elif in the case that the tensor is unsharded, but still NF4Tensor, and just need to call line 271?

[pbontrager]

I think this would be much cleaner if at the top of the loop we do:

if hasattr(...):
	# get full tensor (NF4 or .full_tensor)
if full_param is NF4:
	# upcast
if is_rank_zero:
	# the rest the same

This code still seems to assume that the unsharded param is on rank0 which isn't guaranteed

[SLR722]

Looks good to me