Torch upper-bound policy (W14.T03)¶
Pin: torch>=2.1,<2.13 in pyproject.toml and
constraints.txt.
Why an upper bound¶
- Portability CI (linux-arm64, macos-arm64, macos-x86_64) must resolve the
same constraints band. macOS x86_64 historically lags newer torch wheels;
an unbounded
torch>=2.1silently picks a version the Intel runner cannot install and turns Scorecard/CI red for unrelated PRs. - NumPy ABI: older macOS torch builds require NumPy 1.x
(
numpy>=1.24,<2in constraints). Jumping torch majors without re-checking that pairing breakstorch.from_numpywith “Numpy is not available”. - Goldens are conclusion-stable, not float-identical. A silent torch major bump can change SDPA / matmul kernels enough to flake soft latency budgets even when thesis gates (32× pack, err=0) still pass.
How to raise the ceiling¶
- Bump
<2.Nin bothpyproject.tomlandconstraints.txt. - Run the portability matrix (or wait for CI
portability+linux-py-matrix). - Spot-check
bnn profile --batch 8 --in-features 256 --out-features 256soft budgets andbnn repro. - Note the bump in
CHANGELOG.md(integrator applies ROADMAP checkbox).
Dependabot must not auto-open unbounded torch major bumps — see
.github/dependabot.yml (torch/numpy ignored).
Related¶
- OS × arch matrix:
COMPATIBILITY_MATRIX.md - Optional HF / torchao probes:
OPTIONAL_EXTRAS_MATRIX.md