feat: make training config fields optional #1861
Open
+29
−21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Today, supervised_fine_tune itself and the
TrainingConfig
class have a bunch of required fields that a provider implementation might not need.for example, if a provider wants to handle hyperparameters in its configuration as well as any type of dataset retrieval, optimizer or LoRA config, a user will still need to pass in a virtually empty
DataConfig
,OptimizerConfig
andAlgorithmConfig
in some cases.Many of these fields are intended to work specifically with llama models and knobs intended for customizing inline.
Adding remote post_training providers will require loosening these arguments, or forcing users to pass in empty objects to satisfy the pydantic models.