Skip to content

fix(args): stop a custom TrainPipelineConfig from clearing the model family - #150

Draft
Rockdu wants to merge 1 commit into
mainfrom
fix/args-family-with-custom-config
Draft

fix(args): stop a custom TrainPipelineConfig from clearing the model family#150
Rockdu wants to merge 1 commit into
mainfrom
fix/args-family-with-custom-config

Conversation

@Rockdu

@Rockdu Rockdu commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

What

Drop two lines from the --train-pipeline-config-path branch of miles_validate_args:
the --diffusion-model-family conflict check, and the args.diffusion_model_family = None
that followed it. Normalization moves ahead of the branch so it applies on either path.

Why

The model family is a separate axis from the config class. It selects the config class when
no path is given, and it independently selects the encoder module —
encoder_hub.get_encoder(args.diffusion_model_family), read by the SFT validation block and
by SftEncodeActor.

The branch cleared it to None on the grounds that "explicit config path IS the identity".
That is the identity of the config class, not of the family, so a custom config could not
run SFT at all: get_encoder got None and raised. #142 then rejected the two flags
together, walling off the only combination that could have supplied the family.

No new validation, on purpose

The obvious-looking alternative is to require --diffusion-model-family whenever a config
path is given, since the family is the key several per-model pieces are looked up by. That
was rejected: the encoder — and other per-family pieces — may become customizable in their
own right, and a check here would then forbid a legitimate run. The family stays optional;
whoever needs it fails at the lookup that needs it. get_encoder's message now names the
flag to pass, so that failure is actionable instead of just reporting None.

For the same reason this does not stamp cfg_cls.model_family. model_backend guards the
FSDP parallel-plan lookup on that attribute, so an undecorated out-of-tree class does not get
a plan — but that is the class author's call to make (declare model_family, or use
@register_train_pipeline_config), not something the CLI should decide for them.

Validation

Captured train_args from all six recipes plus the smoke and debug-alignment variants
(7 total): identical to main. None of them passes --train-pipeline-config-path, so nothing
in-tree changes behaviour. pre-commit and py_compile clean.

Not run: pytest and train.py --help — no torch/sglang/ray in this environment. No test
added: the branch sits in miles_validate_args, reachable only through parse_args, which
has no fixture in the repo.

🤖 Generated with Claude Code

…family

The model family is a separate axis from the config class. It picks the config
class when no path is given, and it independently picks the encoder module --
encoder_hub.get_encoder(args.diffusion_model_family), read by the SFT validation
block and by SftEncodeActor.

The --train-pipeline-config-path branch cleared it to None on the grounds that
"explicit config path IS the identity". That is the identity of the config class,
not of the family, so a custom config could not run SFT at all. #142 then rejected
the two flags together, walling off the only combination that could have supplied
the family.

Drop both: the path names the config class, the family stays whatever was passed.
Normalization moves ahead of the branch so it applies on either path.

No new validation. The family stays optional on purpose -- encoder and other
per-family pieces may become customizable in their own right, and a check here
would then be forbidding a legitimate run. Whoever needs the family fails at the
lookup that needs it; get_encoder's message now names the flag to pass so that
failure is actionable.

The six recipes' command lines are unchanged (7 captured variants identical); none
of them passes --train-pipeline-config-path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

1 participant