Skip to content

Conversation

@not-lain
Copy link
Contributor

What does this PR do?

switch from training_args.bin to training_args.json and only capture the parameters that the user passed
I'm using the same approach we are using in huggingface_hub's PyTorchModelHubMixin to store as little parameters as possible.
a minimalistic approach to test this is pr

from transformers import TrainingArguments
args = TrainingArguments(output_dir="folder",eval_strategy="no") # or any other paramters
print(args.to_json_string())
# outputs
"""
{
  "output_dir": "folder",
  "eval_strategy": "no",
  "logging_dir": "folder\\runs\\Nov29_02-44-45_iphone-laptop"
}
"""
# logging_dir is a special parameter that is always captured and added to the training_args because we want to ensure consistency

# stores the parameters into a file
args.to_json_file("training_args.json")

# loads an instance using the class directly
args2  = TrainingArguments.from_json_file("training_args.json") 

using this approach, we ensure that we only store the parameters that the user-defined manually and not the ones that have default values or the ones inferred from the system (ie cpu, cuda, tpu ... ), leaving some room for flexibility.

in a sense the parameters are mutable, meaning the user can physically alter them.

Fixes #34612

Before submitting

  • This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
  • Did you read the contributor guideline,
    Pull Request section?
  • Was this discussed/approved via a Github issue or the forum? Please add a link
    to it if that's the case.
  • Did you make sure to update the documentation with your changes? Here are the
    documentation guidelines, and
    here are tips on formatting docstrings.
  • Did you write any new necessary tests?

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@muellerzr @SunMarc

@not-lain
Copy link
Contributor Author

cc @muellerzr & @SunMarc for review.
failed test is unrelated

@not-lain
Copy link
Contributor Author

not-lain commented Dec 9, 2024

friendly tagging @muellerzr & @SunMarc
failed tests are unrelated

Copy link
Contributor

@muellerzr muellerzr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice! I'm a fan of this change. However, we should be careful about old training resumptions from older versions and likely should do a deprecation until 5.0.0 (warning if a .bin was found but we do the shift to .json now)

How does that sound?

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@not-lain
Copy link
Contributor Author

[don't merge yet I need to fix something fundamental that was not captured by the tests]

@not-lain
Copy link
Contributor Author

not-lain commented Dec 12, 2024

cc @muellerzr for feedback
I implemented a rollback, now default is traing_args.bin and people can switch to training_args.json by setting the TRAINER_SAFE_SERIALIZE environmental variable.

originally there was never a mechanism inside of the trainer API to load any training_args and people used to load the training arguments manually, I added something useful which is TrainingArguments.from_json_file(file_name )
but I think I will integrate this loading mechanism with the trainer api in another pr (optional new feature)

@not-lain
Copy link
Contributor Author

friendly tagging @muellerzr here for a review.

@not-lain
Copy link
Contributor Author

cc @muellerzr for review

Copy link
Member

@SunMarc SunMarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR ! Left a few comments !

if is_accelerate_available() and isinstance(v, AcceleratorConfig):
d[k] = v.to_dict()
d[k] = serialize_parameter(k, v)
self._dict_torch_dtype_to_str(d)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove this and the function since you took care of that in serialize_parameter. Can you add a comment in serialize_parameter to explain what is happening to torch_dtype ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope I did not misunderstand you, let me know if this has been resolved after the new changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine thanks ! SInce we are not using _dict_torch_dtype_to_str method, you can also remove it in this PR

@not-lain
Copy link
Contributor Author

the test_missing_stateful_callback is now failing, any recommendations on how to approach this?

@not-lain
Copy link
Contributor Author

not-lain commented Feb 7, 2025

cc @muellerzr , failing tests are unrelated

@SunMarc SunMarc requested a review from muellerzr February 7, 2025 13:45
@not-lain
Copy link
Contributor Author

friendly tagging @muellerzr for review

@not-lain
Copy link
Contributor Author

cc @muellerzr for review

@not-lain
Copy link
Contributor Author

friendly tagging @muellerzr here for review

@not-lain
Copy link
Contributor Author

not-lain commented Mar 4, 2025

cc @muellerzr to see if you can review this

Copy link
Contributor

@muellerzr muellerzr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a bunch! fstring nit then passing off to @ArthurZucker :)

(Merged myself though so we can get this in without more delay!)

@muellerzr muellerzr requested a review from ArthurZucker March 5, 2025 08:20
@not-lain
Copy link
Contributor Author

cc @ArthurZucker for review 🤗

Copy link
Collaborator

@ArthurZucker ArthurZucker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea where this stands, happy to merge

@not-lain
Copy link
Contributor Author

not-lain commented Apr 8, 2025

this pr is related to https://github.com/huggingface/transformers/pull/35010/files#diff-bfceaff300c851b8e24fc50dc6638482abaec8f7d2a718e877c3828c166bcf79L223 where it said :

TODO: TrainingArguments users rely on it being fully mutable. In the future see if we can narrow this to a few keys: #25903

in short this pr :

do not hesitate if you have any questions or follow-ups 🤗

@SunMarc
Copy link
Member

SunMarc commented Apr 9, 2025

Can you fix the conflicts ? Then, we will finally be able to merge it ;)

@not-lain not-lain force-pushed the switch-training_args-file-format branch from c468866 to 9a8c9d4 Compare April 9, 2025 18:15
@not-lain
Copy link
Contributor Author

not-lain commented Apr 9, 2025

done (≧∇≦)ノ

Comment on lines +1580 to +1592
def __new__(self, *args, **kwargs):
# catch and save only the parameters that the user passed
self.__training_args_params__ = {}
param_names = list(self.__dataclass_fields__.keys())

for i in range(len(args)):
self.__training_args_params__[param_names[i]] = serialize_parameter(param_names[i], args[i])

for k, v in kwargs.items():
self.__training_args_params__[k] = serialize_parameter(k, v)

return super().__new__(self)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a caveat of only storing training params that were passed, if we change the default of any argument in the future, it will impact the training of the model if the user try to resume the training no ? it is a pretty small edge case but still nice to be aware of it.
Also, does this happen with the bin file ?

Copy link
Contributor Author

@not-lain not-lain Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't deny the fact that when we change the default params the default training arguments will change, but still what if we remove some of the default parameters, the approach introduced in this pr is still more flexible (note that the transformers version and some of these parameters are already part of the readme file so that the user can always have a fallback if they want to )

another good example of how this shows more prospects is that if we change the training device, if the second server supports more default cores then that will be default parameter over there (checkout tpu_num_cores for reference)

In full transparency, in bin, everything is static, and i haven't seen anyone report any problems with it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the details, as this might impact heavily 3rd party library relying on trainer, I'll ask them if this is not too breaking ! cc @qgallouedec @winglian @danielhanchen

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @SunMarc, no change required on TRL side 👌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

save training_args in another file format

6 participants