Update torch version to 2.13.0+cpu - #50412
Merged
Merged
Conversation
Signed-off-by: Ylang Tsou <ylangt@google.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Contributor
|
why is this neccessary? |
Contributor
Author
mgoin
approved these changes
Jul 31, 2026
mgoin
enabled auto-merge (squash)
July 31, 2026 15:34
github-actions
Bot
added
the
ready
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 19, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 20, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 21, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 24, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 25, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 26, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 26, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
atalman
added a commit
to atalman/vllm
that referenced
this pull request
Aug 27, 2026
….0 (test channel) Update the PyTorch ecosystem to the 2.14.0 release candidate, resolving wheels from the PyTorch test channel (download.pytorch.org/whl/test/...). Mirrors the 2.13.0 test PR vllm-project#45731. - torch: 2.13.0 -> 2.14.0 - torchvision: 0.28.0 -> 0.29.0 - triton: 3.7.1 -> 3.8.0 2.14.0 is published on download.pytorch.org/whl/test/ but not yet on the release index or PyPI, so the index URLs point at the test channel. Verified availability on the test channel before pinning: - torch 2.14.0+cu130, torchvision 0.29.0, triton 3.8.0 all present - triton 3.8.0 is exactly what pytorch release/2.14 pins in .ci/docker/triton_version.txt - torchaudio's newest published version is still 2.11.0 on every channel, so that pin is unchanged ROCm: requirements/build/rocm.txt moves from the rocm7.1 index to test/rocm7.2. rocm7.1 has no torch 2.14.0 wheels; 2.14 is built for rocm7.2 and rocm7.14 only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with CMakeLists' TORCH_SUPPORTED_VERSION_ROCM. check-ray-compatibility.sh now offers uv both the stable and test channels (it already runs with --index-strategy unsafe-best-match), so an RC torch pin coming from a transitive dep resolves during the RC window instead of failing against a stable-only index. Same fix as vllm-project#45731. Deliberately not carried over from vllm-project#45731: the xfails and workarounds that were specific to breakages found during 2.12/2.13 CI (pytorch#184431, #187735, reactions to that RC's failures; 2.14 should get whatever it actually needs once CI reports. requirements/build/tpu.txt is also left alone, as TPU torch is bumped separately (vllm-project#50412). Test Plan: full CI (apply the `ready` label to trigger Buildkite). BC-breaking? No - test-channel version bump only. Authored with AI assistance; modeled on vllm-project#45731.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Update the torch version from 2.11.0+cpu to 2.13.0+cpu in requirements/build/tpu.txt to fix the vllm-tpu wheel build failure caused by missing dependency torch==2.13.0
reference PR: #48155
Test Plan
Test Result
vllm-tpu built successfully, and the vLLM server started without issues.
Essential Elements of an Effective PR Description Checklist
supported_models.mdandexamplesfor a new model.