Upgrade vLLM to 0.17.0

[jeffreywang-anyscale]

Description

Briefly describe what this PR accomplishes and why it's needed.

Related issues

Link related issues: "Fixes #1234", "Closes #1234", or "Related to #1234".

Additional information

Optional: Add implementation details, API changes, usage examples, screenshots, etc.

[gemini-code-assist]

Code Review

This pull request correctly upgrades vLLM to version 0.17.0 and updates its dependencies accordingly. The code changes are consistent with this upgrade. However, it seems a local configuration for a PyPI index has been accidentally included in many of the dependency lock files. This should be removed to avoid breaking builds.

[aslonnie]

why is this downgraded?

[jeffreywang-anyscale]

I think this is compiled from https://github.com/ray-project/ray/blob/15a473454084a739264ce66290d7d4fc1b3926b4/python/requirements/serve/tracing-reqs.txt + all opentelemetry libraries should have the same version.

[aslonnie]

hmm... that does not really make sense to me.

1. how is the tracing-reqs.txt get pulled in with this change?
2. should that be upgraded to 1.39.0 for consistency?

I think it is that some additional dependency of vllm 0.17 is pulling the version down

[aslonnie]

@elliot-barn could you help investigate? like what will happen if we enforce opentelemetry-proto>=1.39.0 as a constraint?

[elliot-barn]

 opentelemetry-proto 1.40.0 depends on protobuf<7.0 and >=5.0
  opentelemetry-proto 1.39.1 depends on protobuf<7.0 and >=5.0
  opentelemetry-proto 1.39.0 depends on protobuf<7.0 and >=5.0

we are still on 4.25.8 and py313 dependency upgrade initiative will bring us to 5.29.6

[aslonnie]

I would like to understand more on why opentelemetry-proto needs to be downgraded.

[cursor]

Unintended opentelemetry-proto downgrade across non-LLM lock files

Medium Severity

opentelemetry-proto is downgraded from 1.39.0 to 1.34.1 not only in LLM lock files but also in unrelated base, slim, and serve lock files that have no dependency on vLLM. As the PR reviewers noted, a vLLM upgrade should not pull down opentelemetry-proto in non-LLM environments. This broad, unexplained regression may indicate a dependency resolution issue — possibly a transitive constraint leaking through shared constraint files — and risks incompatibilities with components expecting the newer proto version.

Additional Locations (2)

• python/deplocks/base_slim/ray_base_slim_py3.13.lock#L2048-L2051
• python/deplocks/ci/serve_tracing_depset_py3.10.lock#L1940-L1943

 

[cursor]

PyTorch CUDA index removed from LLM build configs

High Severity

The --index https://download.pytorch.org/whl/${CUDA_CODE} flag was removed from LLM depset configs that build for CUDA targets (cu128, cu130_py312). Other GPU configs in the same repo (ray_base_extra_testdeps_gpu, ray_ml_base_extra_testdeps_cuda, release_multimodal_inference_benchmarks_tests) still use --index https://download.pytorch.org/whl/cu128. vLLM 0.17.0 docs still recommend --extra-index-url for the PyTorch CUDA wheel index. Without this index, the uv resolver may not find CUDA-specific PyTorch wheels for cu128/cu130 builds, potentially resolving CPU-only PyTorch when lock files are regenerated.

Additional Locations (2)

• ci/raydepsets/configs/llm_release_tests.depsets.yaml#L11-L16
• ci/raydepsets/configs/rayimg.depsets.yaml#L67-L71

 

[cursor]

Index strategy inconsistency may break Docker image builds

Medium Severity

The --index-strategy was changed from unsafe-best-match to first-index, inconsistent with every other Dockerfile in the project (base-deps, base-extra, base-slim), which all use unsafe-best-match with an explicit comment explaining its necessity. The lock file rayllm_py311_cu128.lock is compiled using the PyTorch index (via rayllm.depsets.yaml which still has --index https://download.pytorch.org/whl/${CUDA_CODE}), so hashes may originate from that index. With first-index, uv stops at PyPI for packages like torch==2.10.0 and torchvision==0.25.0 and never checks the PyTorch index — if any hashes don't match PyPI's wheels, the build will fail.

 

[cursor]

PyTorch CUDA index removed inconsistently from CUDA depsets

Medium Severity

The --index https://download.pytorch.org/whl/${CUDA_CODE} flag was removed from the ray_base_extra_testdeps_llm_cuda depset in rayimg.depsets.yaml and from the common settings in llm_release_tests.depsets.yaml, but similar CUDA depsets like ray_base_extra_testdeps_gpu and ray_ml_base_extra_testdeps_cuda in the same file still retain it. The LLM CUDA depset expands dependencies that include sentence-transformers, which depends on PyTorch — without the CUDA wheel index, the resolver may pull CPU-only PyTorch wheels for what's explicitly a CUDA build.

Additional Locations (1)

• ci/raydepsets/configs/llm_release_tests.depsets.yaml#L12-L16

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Disabling hash verification weakens supply chain security

Medium Severity

Adding --no-verify-hashes disables integrity checking for all packages installed from the lock file. The lock files still contain hashes, but they are completely ignored during installation. This means a compromised or tampered package on the CUDA index (or any alternate index used via unsafe-best-match) could be installed without detection. While version pinning provides some defense, hash verification is the primary protection against supply chain attacks where an index serves a modified binary for a pinned version. A more targeted fix — such as regenerating hashes from the actual CUDA index, or excluding only the mismatched packages — would preserve integrity checking for the majority of dependencies.