fix(train): dispatch registered learning rate schedules#5776
Conversation
Use the shared BaseLR registry in JAX, TF2, and pt_expt so cosine and WSD schedules are honored consistently with the input schema. Coding-Agent: Codex Codex-Version: codex-cli 0.144.1 Model: gpt-5.6-sol Reasoning-Effort: xhigh
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughA shared ChangesLearning-rate schedule construction
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Trainer
participant make_learning_rate_schedule
participant BaseLR
Trainer->>make_learning_rate_schedule: pass learning-rate parameters and num_steps
make_learning_rate_schedule->>BaseLR: construct registered schedule
BaseLR-->>Trainer: return selected schedule
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5776 +/- ##
==========================================
- Coverage 79.69% 79.57% -0.12%
==========================================
Files 1020 1020
Lines 116359 116356 -3
Branches 4303 4306 +3
==========================================
- Hits 92736 92594 -142
- Misses 22076 22219 +143
+ Partials 1547 1543 -4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
wanghan-iapcm
left a comment
There was a problem hiding this comment.
The fix is correct across all three backends: routing through make_learning_rate_schedule -> BaseLR(**params) dispatches by type (BaseLR.new resolves the registered subclass and init absorbs the extra type key via **kwargs), so cosine/wsd now work where JAX previously raised and TF2/pt_expt silently forced exp. Copying the config into a fresh dict before adding num_steps also fixes the in-place config mutation. The new regression test genuinely locks the fix: it fails on the buggy behavior (an exp-always factory returns the wrong class for cosine/wsd; a mutating factory leaves num_steps in the input).
Non-blocking: the regression test covers the shared factory but not the trainer call sites that were actually broken. A trainer-level test (construct a JAX/TF2/pt_expt trainer with type: cosine/wsd and assert self.lr_schedule is the expected class) would guard against a future re-hardcoding of a backend to exp. The trainers are now one-line delegations to the tested factory, so this is a coverage note rather than a correctness concern.
Approving.
OutisLi
left a comment
There was a problem hiding this comment.
Requesting changes for one pt_expt integration blocker: valid cosine/WSD warmup schedules crash while constructing LambdaLR, before training starts.
| lr_params = config["learning_rate"].copy() | ||
| lr_params["num_steps"] = self.num_steps | ||
| self.lr_schedule = LearningRateExp(**lr_params) | ||
| self.lr_schedule = make_learning_rate_schedule( |
There was a problem hiding this comment.
[P1] Keep the LambdaLR denominator nonzero for warmup schedules
Dispatching cosine and wsd here routes them into the existing scheduler construction below, which sets initial_lr = float(self.lr_schedule.value(self.start_step)) and divides every lambda value by initial_lr. On a fresh run, the common schema's legal warmup default (warmup_steps > 0, warmup_start_factor=0.0) gives value(0) == 0, so LambdaLR evaluates the lambda during its constructor and immediately raises ZeroDivisionError; no training step runs. I reproduced this after strict argcheck normalization for both newly supported schedule types (and the pre-existing exp path has the same latent defect).
Please use the nonzero lr_schedule.start_lr as the LambdaLR base/denominator and set each optimizer param group's initial_lr accordingly, as legacy PT's _create_lr_scheduler already does. Then lambda(0) can correctly be zero and initialize the optimizer at the intended zero warmup LR without division by zero. Add a real pt_expt Trainer regression with cosine and wsd, warmup_steps > 0, and the default start factor; the current factory-only test cannot exercise this backend integration.
OutisLi
left a comment
There was a problem hiding this comment.
One additional compatibility issue in the shared factory: its documented/schema default for an omitted learning-rate type is not implemented.
| """ | ||
| params = dict(lr_params) | ||
| params["num_steps"] = num_steps | ||
| return BaseLR(**params) |
There was a problem hiding this comment.
[P2] Preserve the optional default learning-rate type
Both the common schema and this helper's docstring define type as optional with exp as the default, but BaseLR.__new__ requires an explicit type. Consequently, make_learning_rate_schedule({"start_lr": 1e-3, "stop_lr": 1e-5}, 100) now raises KeyError: the type of the BaseLR should be set by type. This also regresses the previous direct-trainer behavior: JAX explicitly used lr_param.get("type", "exp"), while pt_expt and TF2 directly constructed LearningRateExp and therefore did not require the key.
The standard CLI normalization path inserts type="exp", so this does not block normalized dp train inputs; it affects direct use of this new helper and direct/backend trainer construction with otherwise valid schema-shaped parameters. Please add params.setdefault("type", "exp") before dispatch and cover the omitted-type case in the factory test.
Summary
BaseLRregistrypt_expttraining soexp,cosine, andwsdfollow the common schemaAddresses the learning-rate checklist items in #5755, #5756, and #5757. The remaining checklist items in those issues are intentionally left open.
Tests
venv/bin/pytest source/tests/universal/dpmodel/utils/test_learning_rate.py -qvenv/bin/pytest source/tests/pt_expt/test_training.py::TestTraining::test_training_loop -qDP_TEST_TF2_ONLY=1 venv/bin/pytest source/tests/tf2/test_training.py -qvenv/bin/ruff check .venv/bin/ruff format .JAX integration tests were not run locally because the existing virtual environment does not include JAX/Optax; the shared dispatch regression test covers the schedule factory used by the JAX trainer.
Coding agent: Codex
Codex version: codex-cli 0.144.1
Model: gpt-5.6-sol
Reasoning effort: xhigh
Summary by CodeRabbit
New Features
Bug Fixes
Tests