[ci][deps] Bump torch to 2.10.0 fleet-wide and retire the Windows torch 2.7 special case

[elliot-barn]

Description

Bumps the repo-wide torch pin from 2.9.0 to 2.10.0 (torchvision 0.24.0 → 0.25.0) across CI, the release BYOD images and the compiled constraints, and retires the Windows-only torch 2.7 special case that the 2.9 pin forced.

Why now: torch 2.8/2.9 Windows wheels were built without libuv, so torch.distributed's gloo backend could not initialize on Windows (pytorch/pytorch#150381). The fix (pytorch/gloo#472) ships in torch 2.10, and windows-requirements.txt carried the instruction "Keep Windows CI on 2.7.0 until the repo-wide torch pin reaches >=2.10, then delete this file and the windows torch2.7 depsets." This PR does exactly that.

Pins moved

• python/requirements/ml/dl-cpu-requirements.txt: torch==2.10.0, torchvision==0.25.0, torch-scatter==2.1.2+cpu.torch.2.10 (Astral), torch-sparse==0.6.18+pt210cpu (PyG torch-2.10.0+cpu page). nvidia-nccl-cu12==2.27.5 is unchanged — torch 2.10.0+cu128 still requires exactly that.
• dl-gpu-requirements.txt: torch==2.10.0+cu128, torchvision==0.25.0+cu128, torch-scatter==2.1.2+cu.12.8.torch.2.10, torch-sparse==0.6.18+pt210cu128.
• data-test-requirements.txt: torchvision==0.25.0; torchcodec cap flipped from <0.10 to >=0.10,<0.11 — its libtorchcodec is ABI-bound to a torch minor and declares no torch requirement, so the line has to be pinned by hand: 0.9.x was built for torch 2.9 and would fail to load, 0.10.x is the torch 2.10 line (lerobot 0.5.1 allows <0.11).
• Release BYOD: requirements_ml_byod_3.10.in (torch==2.10.0, triton==3.6.0 — torch 2.10 requires triton 3.6), requirements_ml_byod_3.13.in (torch==2.10.0), requirements_gpu_cu130.in (2.9.1 → 2.10.0).
• requirements_compiled_py3.14.txt: torch==2.10.0, torchvision==0.25.0, PyG find-links → torch-2.10.0+cpu — mirrored by hand as always for this file. Note torch 2.10 is the first line with cp314 wheels, so this snapshot's torch pin is now actually satisfiable on py3.14 (it pinned 2.7.0, which has none); unifying docker/ray-torch/torch-constraints-py3.14.txt onto it is a possible follow-up, not done here.

ray-torch image: py3.14 now shares the compiled constraints (closes the TODO in ray_torch.depsets.yaml)

ray_torch.depsets.yaml carried two copies of the same depset because requirements_compiled_py3.14.txt pinned torch 2.7.0 (no cp314 wheels), so the py3.14 image had to pin torch itself in docker/ray-torch/torch-constraints-py3.14.txt. With the snapshot on 2.10.0 every pin in that side file (torch, torchvision, cupy-cuda12x, llvmlite, numba, dm-tree) is supplied identically by the snapshot, so the two entries collapse into one constrained by /tmp/ray-deps/requirements_compiled_py${PYTHON_VERSION}.txt and the side file is deleted. Two things had to move for that to resolve:

• nvidia-nccl-cu12 in the py3.14 snapshot: 2.26.2 → 2.27.5 — the torch-2.7-era value was never mirrored; torch 2.10.0 requires 2.27.5 exactly (same as requirements_compiled.txt / dl-cpu-requirements.txt).
• Effect on the py3.14 ray-torch lock: it was previously unconstrained apart from the six side-file pins, so ~100 of its packages floated to whatever was newest at compile time; they are now held to the py3.14 compiled snapshot the same way the py3.11 image is held to requirements_compiled.txt. Most of the ~109 moved lines are exactly that (e.g. pytest 9.0.3 → 8.3.3, numpy 2.4.6 → 2.3.3, sentence-transformers 5.5.1 → 3.0.1). Caveat worth knowing: requirements_compiled_py3.14.txt is a hand-maintained snapshot and differs from requirements_compiled.txt in 28 of 607 shared pins (mixed direction — transformers 4.36.2 vs 5.11.0 and datasets 3.6.0 vs 4.8.5 older, numpy/pytest/urllib3/grpcio/pydantic newer) plus 15 py3.14-only pins, so the two ray-torch images are aligned in policy but not yet byte-for-byte in versions. Refreshing that snapshot toward requirements_compiled.txt (now that torch 2.10 makes it possible) is the natural follow-up. The py3.11 lock only gains langchain-text-splitters and its closure plus the jsonpatch bump.
• jsonpatch==1.32 → 1.33 in test-requirements.txt. langchain-text-splitters (in the ray-torch image since [release] Add ray-torch release test image (py3.14, cu12.8) #65114) needs a langchain-core requiring jsonpatch>=1.33; 1.32 was a 2023 tier-split snapshot pin ([requirements] Split requirements into different tiers [build_base] #36808), 1.33 is the last release, and the only other consumer (cfn-lint) takes any version. This also removes the reason langchain-text-splitters was excluded from the py3.11 ray-torch image, so that python_version >= "3.12" marker is dropped and both images match.

Windows special case removed

• python/requirements/windows-requirements.txt deleted.
• ci_windows.depsets.yaml: relaxed_windows_tests_ci_depset and windows_tests_torch27_ci_depset removed; their two locks deleted.
• ci/docker/windows.build.wanda.yaml and ci/ray_ci/windows/build_base.sh now consume windows-tests-ci_depset_py3.10.lock directly (the lock the torch27 one was derived from).

Not moved (deliberately)

• LLM stack (python/requirements/llm, python/deplocks/llm/*): pinned by vllm==0.27.0 to torch 2.13; independent of this pin.
• doc/source/templates/** (torch 2.0.1): legacy template examples, out of scope.
• docker/ray-torch/torch-constraints-py3.14.txt already pins torch 2.10.0 / torchvision 0.25.0.

What moved in the locks

Aggregated across the 38 changed locks — nothing outside torch's own closure: torch 2.9.0→2.10.0 (+cpu/+cu128), torchvision 0.24.0→0.25.0, torch-scatter/torch-sparse to the torch-2.10 builds, triton 3.5.0→3.6.0 (13 GPU locks), torchcodec 0.9.1→0.10.0 (3 data locks), nvidia-nvshmem-cu12 3.3.20→3.4.5 (13 GPU locks), and the cuda-bindings/cuda-python/cuda-pathfinder set that torch 2.10's cu128 wheel pulls in (torch 2.10.0+cu128 declares cuda-bindings==12.9.4 exactly, which brings cuda-pathfinder and moves the five py3.12 GPU locks that previously resolved cuda-bindings/cuda-python 12.9.6 down to 12.9.4). deepspeed stays 0.18.9.

Verified locally

• torch 2.10.0 has cp310/cp312/cp314 wheels on download.pytorch.org/whl/{cpu,cu128,cu130} and win_amd64 on PyPI; torchvision 0.25.0 likewise (and the repo's ray-torch py3.14 constraints already pair 2.10.0 with 0.25.0).
• PyG publishes torch_sparse 0.6.18+pt210{cpu,cu128} for cp310/cp312 (linux + win); Astral publishes torch-scatter 2.1.2+cpu.torch.2.10 / +cu.12.8.torch.2.10.
• No caps in the way: torchtext 0.18.0 requires torch>=2.3.0; pytorch-lightning 1.8.6 requires torch>=1.9.0; torchft-nightly requires torch>=2.7.
• ./ci/ci.sh compile_pip_dependencies → exit 0; diff vs base is exactly the find-links URL, torch==2.10.0, torchvision==0.25.0
• bazel run //ci/raydepsets:raydepsets -- build --all-configs → exit 0, 105 depsets; 38 locks modified, 2 deleted (the Windows torch27 pair); every non-LLM lock now pins torch==2.10.0
• bazel run //ci/raydepsets:raydepsets -- build --all-configs --check → exit 0, all 105 depsets regenerate byte-identically

Follows #65899 (Astral index / PyG cleanup), which has merged; this PR is rebased on top of it.

Related issues

pytorch/pytorch#150381, pytorch/gloo#472. Follows #65899.

Additional information

Not a duplicate: open dependabot PRs (#64868, #64860, #64005) bump torch in single requirement files without the Windows/PyG/torchcodec/lock changes, and each carries a failing check; no open PR bumps the fleet pin coherently.

AI assistance (Claude Code) was used for this change; every changed line was reviewed by the submitter.

🤖 Generated with Claude Code

[gemini-code-assist]

Note

The number of changes in this pull request is too large for Gemini Code Assist to generate a review.