[Deps] Require laya 0.3.9, lock 0.3.20, and drop the local weight-init skip

[cacheline999]

Why

Closes #28. #22 wrapped laya.load in transformers' no_init_weights to skip the throwaway random weight init. Laya does this itself from 0.3.9, so the wrapper and its test stubs are no longer needed.

Moving the lock past 0.3.9 brings one more change. From 0.3.10 Laya answers a request of five or more questions in fp16 on MPS. In s1a only the browser front asks that many at once, on pages that offer all four operations, so one episode would mix fp32 and fp16 steps. On the 30 ticket-router tickets with six questions, fp16 moved multilingual probabilities by up to 0.051 and changed two of 180 decisions, both close to even (records/head-multilingual-mps-override5.json below). Keeping fp32 can cost speed: the one M5 report (NandhaKishorM/laya#109) has fp16 5 ms faster at five questions.

How

LayaModel.from_env no longer wraps laya.load, since laya skips the init itself. After loading, it raises the agent's mps_amp_min_rows so every MPS request stays in fp32, the precision main runs today, unless LAYA_MPS_AMP_MIN_ROWS (Laya's own variable) is set; a value that is not a whole number is a configuration error, because Laya would read it as its default of 5. A laya without the attribute (0.3.9) is left as it is.

Open first: s1a/decision_models/laya.py (from_env), then tests/test_decision_models_laya.py.

What

• The laya extra is laya>=0.3.9. uv lock --upgrade-package laya moves the lock from 0.3.5 to 0.3.20, the release system1-omni's Laya worker runs; only the laya entry changes. 0.3.26 is the latest today; say if you would rather lock that.
• without_weight_init() and its transformers.initialization test stubs are gone.
• --model laya keeps MPS requests in fp32 unless LAYA_MPS_AMP_MIN_ROWS is set. Nothing changes on CPU or CUDA. Callers change nothing; setting LAYA_MPS_AMP_MIN_ROWS=5 restores Laya's default.
• Tests: the fp32 default, the variable taking precedence, a non-numeric value, a laya without the attribute, and a laya without package metadata (the system_one test now pins the version, so it passes with the laya extra installed too).
• CHANGELOG, docs/configuration.md and .env.example describe the variable.
• docs/results/laya-upgrade/: the comparison below, as a README with the steps, run.sh and the recorded outputs.

Verification

Run by me on 82f7f21, M1 Pro, Python 3.14, with the laya extra (0.3.20) unless noted.

• uv run ruff format --check . && uv run ruff check . && uv run ty check: all pass.
• uv run pytest -q and scripts/smoke.sh: 492 passed, 41 skipped; smoke: ok (core install). In a fresh environment whose packages are not byte-compiled yet, Python 3.14 prints SyntaxWarnings from pysbd and openjiuwen on stderr, which fails smoke's one-line check for decide and test_s1a_home_from_the_dotenv_file_places_the_logs_and_the_runtime_root. Main fails the same way there; uv sync --compile-bytecode avoids it on both.
• CHANGELOG.md and the docs say what the code does now.

CI (core install, no laya extra) passes on 82f7f21.

Demo / evidence

Task. --model laya's backend, LayaModel.from_env(), answers the 30 tickets in s1a/agents/_data/ticket_router_eval.jsonl: one choice, one noul and one six-question request each. Success is every choice, probability, confidence and noul value equal between main and this branch.

Actions. docs/results/laya-upgrade/README.md has the steps and run.sh runs them: it checks out 222e656 (main, laya 0.3.5) and c197fe6 (this branch's code, laya 0.3.20; the commits after it only add docs/results/laya-upgrade), installs each lock, and runs both checkpoints on CPU and MPS, three fresh processes per side, alternating. Two controls: this branch with LAYA_MPS_AMP_MIN_ROWS=5 on MPS, and main without its weight-init skip on CPU.

Result. An actual run by me, 2026-10-05, M1 Pro, macOS 26.1, checkpoint revision 7b928d8; the 28 outputs are in records/, each naming its commit, versions, device and Laya variables. python compare.py records/ printed:

• all four checkpoint and device rows identical between main and this branch, 3 + 3 runs each;
• with LAYA_MPS_AMP_MIN_ROWS=5: multilingual changed t_6cb98186dde0 (pick, logistics to returns) and t_f5251390fb88 (cancel, 0.4959 to 0.5074), largest probability change 0.051; english 0.010, no decision changed;
• main without the skip loaded in 36.8 s (english) and 42.5 s (multilingual), against 6 to 10 s on either side with it.

Limits. Load and latency columns compare the two sides of a row only: the machine had other work running (1-min load about 6 to 10), and the first english CPU load of each side read the model files from disk. Not covered: the typed-decisions checkpoint, a local checkpoint path, transformers 4.x, CUDA, and Apple chips other than the M1 Pro.

[hsliuustc0106]

@cacheline999 could you add a Demo / evidence section following the self-review guidance? The CPU/MPS measurements already answer the right questions; the missing piece is a reproducible artifact behind the tables.

Please link the comparison script and sanitized per-run outputs for the same ticket inputs on baseline/head: model loading, one- and six-question answers, and the default MPS setting versus LAYA_MPS_AMP_MIN_ROWS=5. Include the exact source/checkpoint revisions and invocation, and retain the two changed multilingual decisions in the override results. Keep the existing cold-load/background-load notes and untested configurations explicit.

Existing logs or a terminal trace are enough; no video or broader hardware sweep is needed. Please use safe sample data and redact credentials/private paths from anything shared.

[cacheline999]

Added, see the Demo / evidence section.