-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Config] Enable component overrides #456
Conversation
✅ Deploy Preview for torchtune-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
yaml_args, cli_args = parser.parse_known_args( | ||
[ | ||
"--config", | ||
"test.yaml", | ||
"b.c=4", # Test overriding a flat param in a component | ||
"b=5", # Test overriding component path | ||
"b.b.c=6", # Test nested dotpath | ||
"d=6", # Test overriding a flat param | ||
"e=7", # Test adding a new param | ||
] | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One case that's not covered here is when we only override some of the fields for a given DictConfig
. E.g. with _Config
as you've defined it above I would like to see the case of just b=5
tested (check that the final value of b.c=3
), and the case of just b.c=4
(check that the final value of b._component_=2
). I think (?) these did not work before and we actually needed to override every single field, but if I understand these changes correctly that will no longer be the case. Either way, would be good to explicitly test for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't require overriding every single field, but yes it would be good to test for this explicitly
docs/source/examples/configs.rst
Outdated
|
||
Overriding components | ||
^^^^^^^^^^^^^^^^^^^^^ | ||
If you would like to override a parameter in the config that has a :code:`_component_` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpicking
If you would like to override a parameter in the config that has a :code:`_component_` | |
If you would like to override a class or function in the config that is instantiated via the :code:`_component_` |
torchtune/config/_utils.py
Outdated
# If a cli arg overrides a yaml arg with a _component_ field, update the | ||
# key string to reflect this | ||
if ( | ||
k in yaml_kwargs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the assumption here is that anything in the CLI overrides was already in the YAML file, right? (I think this is fine and don't see a way to avoid it, just wanna confirm that we will not support the cases in Hydra like +my_appended_config_field=value
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only for components, you cannot append a new component (well, you technically could but it would not be pretty and you'll have to explicitly use _component_
). It has to exist in the yaml file. Appending new config values that aren't in the yaml file will still work without needing the +
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good to me and will improve the UX a lot. Really only one main question from me on the testing: just wanna confirm that we can override individual fields of a DictConfig
without overriding all of them -- I think we can but it's not immediately clear from the command in the test plan.
08918f5
to
4ca0a48
Compare
tests/recipes/test_lora_finetune.py
Outdated
|
||
if enable_fsdp: | ||
cmd.append("--enable-fsdp") | ||
cmd.append("enable_fsdp=True") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is an issue with this test, it passes on main because the flag is not parsed correctly before I update it. After the change, this test fails because we don't call init_distributed
when enable_fsdp is true. any advice on how I can quickly patch this? @rohan-varma @ebsmothers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops I actually missed this until now, but I think you, Rohan, and I all discovered this more or less independently. #472 should fix this
One more comment here.. I think #454 is gonna land before this so please just take a pass and make sure all instances of |
3fee2ce
to
ec9ce97
Compare
ec9ce97
to
91fec7a
Compare
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/torchtune/456
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 91fec7a with merge base e570803 (): This comment was automatically generated by Dr. CI and updates every 15 minutes. |
Context
After the config system was updated in #406 with
_component_
fields, the CLI override experience for specifying TorchTune objects became clunky. For example, to change datasets, we now have to specify the component field in CLI:Instead, we update the
parse
utility to enable specifying component path without using_component_
and merge the overrides properly. The above command will now become:Changelog
_component_
and enable component overrides by adding a merge utility,merge_yaml_and_cli_args
--override
flag by popular demandTest plan
Added unit test and ran
pytest tests
tune --nnodes 1 --nproc_per_node 1 full_finetune --config alpaca_llama2_full_finetune dataset=torchtune.datasets.SlimOrcaDataset dataset.train_on_input=False