Match the backend's tie rounding for warmup steps

When a model or imported YAML produces a half-step value, such as warmup_ratio: 0.05 with max_steps: 50, Math.round derives 3 steps, while the referenced backend fallback in worker.py uses Python's int(round(...)) and derives 2 because Python rounds ties to even. Since the frontend submits the derived value as warmup_steps, this silently changes the effective training configuration; use rounding semantics that match the backend.

Useful? React with 👍 / 👎.

Declining this one. The int(round(...)) at studio/backend/core/training/worker.py:2979 runs only when warmup_steps is None and warmup_ratio is not None, and it sits inside _run_mlx_training, which rejects embedding runs outright at worker.py:2612. mappers.ts:121-122 sends warmup_steps: isEmbedding ? null : config.warmupSteps and warmup_ratio: isEmbedding ? 0.03 : null, with config.warmupSteps a non-nullable number defaulting to 5 (src/config/training.ts:83). Every run that can reach that branch therefore arrives with a concrete warmup_steps and a null ratio, so the condition is never satisfied.

The comparison also assumes the alternative outcome is 2 steps. Without this change the field carries the generic default 5, not 2, which is the bug being fixed, so there is no competing derivation to diverge from.

Where the backend does own a ratio, the operative semantics are ceil, not round. Embedding runs send warmup_ratio (mappers.ts:122 into worker.py:5208), and trainer.py:3790 prefers warmup_ratio over warmup_steps when both are present. Both hand it to TrainingArguments.get_warmup_steps, which is math.ceil(num_training_steps * ratio). ceil(2.5) is 3 and agrees with Math.round, while int(round(2.5)) is 2 and is the outlier, so matching it would move the derived value away from what the backend actually applies to a ratio.

No shipped config produces a tie either: 0.1 * 30 is 3.0 and 0.03 * 30 is 0.8999999999999999.

Use ceiling semantics when materializing a warmup ratio

For a non-embedding CUDA config where warmup_ratio * max_steps is below a half-integer (for example, 0.01 * 30), this writes warmupSteps: 0, and mappers.ts then submits that concrete step count instead of the ratio. The CUDA _train_worker passes a ratio to SFTConfig, whose Hugging Face TrainingArguments derives warmup with ceil, so the same config should have one warmup step rather than none. This is fresh evidence beyond the earlier MLX-only rounding example: it affects custom/imported ratios on the generic CUDA training path.

Useful? React with 👍 / 👎.

Correct, and fixed in e18856c. Math.round writes 0 whenever the product is under 0.5, so an imported config such as warmup_ratio: 0.03 with max_steps: 10 asked for warmup and would have trained with none. That is the same outcome the max_steps guard on the branch below already exists to avoid, so the two halves of the derivation disagreed with each other.

Math.ceil is what TrainingArguments.get_warmup_steps uses to materialize a ratio, which is the semantics every backend path applies wherever it owns one, and it produces identical values for all 78 shipped configs (0.1 * 30 is 3 and 0.03 * 30 is 1 under either operator). An explicit warmup_ratio: 0 still maps to 0.

One correction on the route you describe: for a non-embedding run mappers.ts:137 sends warmup_ratio: null, so _train_worker takes the warmup_steps branch at trainer.py:4044 and passes the literal 0 rather than a ratio. The conclusion is unaffected, since 0 is wrong on its own terms.

Regression test added in tests/training-model-defaults-warmup-ratio.test.ts, "a ratio too small to reach one step still gets one". It fails against the previous Math.round with actual: 0, expected: 1.