feat: make training config fields optional (#1861)

# 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` and `AlgorithmConfig` 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.

Signed-off-by: Charlie Doern <cdoern@redhat.com>
This commit is contained in:
Charlie Doern 2025-04-12 04:13:45 -04:00 committed by GitHub
parent 70a7e4d51e
commit 0751a960a5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 29 additions and 21 deletions

View file

@ -9778,13 +9778,16 @@
"type": "integer"
},
"max_steps_per_epoch": {
"type": "integer"
"type": "integer",
"default": 1
},
"gradient_accumulation_steps": {
"type": "integer"
"type": "integer",
"default": 1
},
"max_validation_steps": {
"type": "integer"
"type": "integer",
"default": 1
},
"data_config": {
"$ref": "#/components/schemas/DataConfig"
@ -9804,10 +9807,7 @@
"required": [
"n_epochs",
"max_steps_per_epoch",
"gradient_accumulation_steps",
"max_validation_steps",
"data_config",
"optimizer_config"
"gradient_accumulation_steps"
],
"title": "TrainingConfig"
},
@ -10983,8 +10983,7 @@
"job_uuid",
"training_config",
"hyperparam_search_config",
"logger_config",
"model"
"logger_config"
],
"title": "SupervisedFineTuneRequest"
},