feat(mlflow): auto log config leaves as mlflow parameters #1
Loading…
Reference in a new issue
No description provided.
Delete branch "v2.4.0-PR-train-params"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adversarial review of this PR found the runtime scalars recording no information: the walker stringifies live objects as type(obj).__name__, so torch.device logged as "device", torch.dtype as "dtype" (its __name__), and WarmupCosineSpec.milestones as "tuple". bf16 vs fp32 runs and cuda vs cpu runs were indistinguishable in the param table, contradicting the ratified feature list. The stub tests hid this by faking classes named "device"/"dtype". - params.py: _visit records str() for torch.device/torch.dtype and repr() for containers of scalars; other live objects keep the class-name fallback. log_params_guarded skips empty values with a warning: some MLflow backends reject them ("Param value cannot be empty"), and a rejected log_params would raise out of run start — the one failure mode the guard does not cover. compile_mode defaults to "". - train.py: the experiment root now logs eval_interval and checkpoint_interval (named in the proposal's feature list, previously unlogged). epochs deliberately stays on the scheduler spec, which derives it from the same constant; a second epochs source would be a differing-value collision the walker raises on. - tests: real torch.device/torch.bfloat16 in the RunContext stub with value assertions ("cpu", "torch.bfloat16"), milestones pinned to "(6,)", the new experiment keys in the emitted key set, walker tests for the device/dtype/container branches, and an empty-value guard test. - docs: training.md no longer lists the deleted log_params.py (it now names params.py/param_keys.py); the release README's 2.2 row links the renamed implementation plan (v2.2.md -> v2.5.0.md). Known limitation, deferred: the renumbering commit left the release README's 2.2/2.5.0 rows inconsistent (2.5.0.md's heading still says "Plan 2.2"; the 2.5.0 row links the CLI-launch implementation plan). That is renumbering intent, not a link fix, and needs the owner's call. Tests not executed in this environment (no torch/mlflow); py_compile plus a stubbed-torch smoke of the walker and guard pass. The venv pytest and the plan's param smoke remain acceptance gates.Replaces the blanket str() on the torch branch with the admission rule we settled on: a type joins the branch only together with its known string form and the transform for it. torch.dtype is always "torch.<name>", so it records the bare name ("bfloat16"); torch.device has no module prefix ("cpu", "cuda:0") and passes through unchanged. Anything not in the branch keeps the class-name fallback, loudly and manually, until someone admits it with its transform. The value logged is the resolved RunContext.dtype, not the --dtype flag: the object is what the model parameters and retriever buffers are built from, and build_run_context is where dtype decisions live (it already warns on fp16), so it is the value that stays true if a fallback is ever added there. Tests updated: dtype pins to "bfloat16", device passthrough ("cuda:0") and the collision guard covered in test_param_walker; test_train_params asserts the shortened form. The corresponding manual dtype logging experiment on the v2.4.1 branch was reverted; this walker is now the only dtype mechanism. py_compile and a stubbed-torch smoke pass; pytest on a torch box remains the gate.