Aquileo | Upgrade vLLM to 0.17.0 by jeffreywang-anyscale · Pull Request #61598 · ray-project/ray

jeffreywang-anyscale · 2026-03-09T18:37:00Z

Description

Upgrade to vLLM 0.17.0 and re-compile dependencies. Here are the primary changes aside from fixing breaking APIs:

1. `no-verify-hashes` at `pip install` time

uv pip compile generates lock files with hashes from PyPI, but uv pip install --index-strategy unsafe-best-match may download the same package (specifically triton) from the PyTorch CUDA index instead, which serves a different wheel build with a different hash. The workaround is --no-verify-hashes, which disables all hash integrity checking.

Alternative approach: Augment hashes after compilation

At lock file compile time, after uv pip compile generates hashes from its resolved index (PyPI), a post-processing step queries every --extra-index-url (e.g. PyTorch CUDA index) for each package and appends any additional SHA-256 hashes to the lock file.
At Docker install time, --verify-hashes works again because the lock file now contains hashes from all indexes that --index-strategy unsafe-best-match might download from.
This is more complicated.

2. libstdc++ / CXXABI / ICU compatibility

In vLLM 0.16.0, XgrammarBackend was imported lazily inside a method (grammar_init), so the diskcache → sqlite3 → ICU → libstdc++ chain was only triggered when actually using structured output.

In vLLM 0.17.0, XgrammarBackend is imported at the top level of __init__.py, meaning import vllm now eagerly loads the entire chain: __init__.py → backend_xgrammar.py → utils.py → diskcache → sqlite3 → _sqlite3.so → libicui18n.so.78 → libstdc++ (CXXABI_1.3.15).

The system libstdc++ only goes up to CXXABI_1.3.13, but conda's copy (libstdc++.so.6.0.34) has CXXABI_1.3.15. Conda installs its own C++ ecosystem (libstdc++, ICU, etc.) but at runtime the dynamic linker finds the system libstdc++ first. The fix is to make sure conda's newer libstdc++ is found first by setting LD_LIBRARY_PATH.

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.

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

aslonnie · 2026-03-09T20:04:11Z

-opentelemetry-proto==1.39.0 \
-    --hash=sha256:1e086552ac79acb501485ff0ce75533f70f3382d43d0a30728eeee594f7bf818 \
-    --hash=sha256:c1fa48678ad1a1624258698e59be73f990b7fc1f39e73e16a9d08eef65dd838c
+opentelemetry-proto==1.34.1 \


why is this downgraded?

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.

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

how is the tracing-reqs.txt get pulled in with this change?

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

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

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

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

aslonnie

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

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

1. Restore `--index https://download.pytorch.org/whl/${CUDA_CODE}` in rayllm.depsets.yaml. This was accidentally dropped, causing cu128 lockfiles to resolve torchaudio from PyPI instead of the CUDA index. 2. Add numexpr>=2.10 to llm-test-requirements.txt. The CI base Docker image has numexpr compiled against NumPy 1.x, but the lockfile installs NumPy 2.x, causing a binary incompatibility crash. Including numexpr in the lockfile ensures a compatible version overwrites the base image's broken one. 3. Regenerate all 16 LLM lockfiles. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

Master also lacks numexpr in lockfiles with the same NumPy 2.2.6. The CPU test numexpr failure is a base image issue, not caused by this branch. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

cursor · 2026-03-16T20:00:38Z

+# exact versions, so integrity is maintained through version pinning.
 uv pip install --system --no-cache-dir --no-deps \
    --index-strategy unsafe-best-match \
+    --no-verify-hashes \


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.

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

cursor

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

There are 3 total unresolved issues (including 2 from previous reviews).

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

cursor · 2026-03-18T16:22:30Z

+# exact versions, so integrity is maintained through version pinning.
 uv pip install --system --no-cache-dir --no-deps \
    --index-strategy unsafe-best-match \
+    --no-verify-hashes \


Missing LD_LIBRARY_PATH fix in production ray-llm Dockerfile

High Severity

The production docker/ray-llm/Dockerfile upgrades to vLLM 0.17.0 but is missing the LD_LIBRARY_PATH=/home/ray/anaconda3/lib environment variable that was added to ci/docker/llm.build.Dockerfile and release/ray_release/byod/byod.Dockerfile. The PR description explains that vLLM 0.17.0 eagerly imports xgrammar, triggering a libstdc++ dependency chain requiring CXXABI_1.3.15 from conda's copy. Without this fix, the production image will fail at runtime on import vllm.

Additional Locations (1)
ci/docker/llm.build.Dockerfile#L24-L28

Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

## Description Upgrade to vLLM 0.17.0 and re-compile dependencies. Here are the primary changes aside from fixing breaking APIs: ### 1. `no-verify-hashes` at `pip install` time `uv pip compile` generates lock files with hashes from PyPI, but `uv pip install --index-strategy unsafe-best-match` may download the same package (specifically `triton`) from the PyTorch CUDA index instead, which serves a different wheel build with a different hash. The workaround is `--no-verify-hashes`, which disables all hash integrity checking. #### Alternative approach: Augment hashes after compilation - At lock file compile time, after uv pip compile generates hashes from its resolved index (PyPI), a post-processing step queries every `--extra-index-url` (e.g. PyTorch CUDA index) for each package and appends any additional SHA-256 hashes to the lock file. - At Docker install time, `--verify-hashes` works again because the lock file now contains hashes from all indexes that `--index-strategy unsafe-best-match` might download from. - This is more complicated. ### 2. libstdc++ / CXXABI / ICU compatibility In vLLM 0.16.0, XgrammarBackend was imported lazily inside a method (grammar_init), so the `diskcache` → `sqlite3` → `ICU` → `libstdc++` chain was only triggered when actually using structured output. In vLLM 0.17.0, XgrammarBackend is imported at the top level of `__init__.py`, meaning import vllm now eagerly loads the entire chain: `__init__.py` → `backend_xgrammar.py` → `utils.py` → diskcache → sqlite3 → `_sqlite3.so` → `libicui18n.so.78` → `libstdc++` (CXXABI_1.3.15). The system `libstdc++` only goes up to CXXABI_1.3.13, but conda's copy (`libstdc++.so.6.0.34`) has CXXABI_1.3.15. Conda installs its own C++ ecosystem (libstdc++, ICU, etc.) but at runtime the dynamic linker finds the system libstdc++ first. The fix is to make sure conda's newer `libstdc++` is found first by setting `LD_LIBRARY_PATH`. ## Related issues > Link related issues: "Fixes ray-project#1234", "Closes ray-project#1234", or "Related to ray-project#1234". ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. --------- Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com> Co-authored-by: Lonnie Liu <95255098+aslonnie@users.noreply.github.com> Co-authored-by: elliot-barn <elliot.barnwell@anyscale.com> Signed-off-by: 熠欣 <limoxuan.lmx@alibaba-inc.com>

## Description Fix stale open-telemetry hashes in llm py312 lock files missed by #61598. ## Related issues Post-merge failures: https://buildkite.com/ray-project/postmerge/builds/16555/steps/canvas?sid=019d047c-934a-44b9-a9bd-89756bcdc297&tab=output. ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. Testing Built locally with wanda: **export PYTHON=3.12 && export BASE_TYPE=build && export BUILD_VARIANT=build && export RAY_CUDA_CODE=cpu && wanda ci/docker/llm.build.wanda.yaml** <details> <summary>Click to see logs</summary> ``` 2026/03/19 18:01:32 building oss-ci-base_test-py3.12 (from ci/docker/base.test.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 cache hit: sha256:5a4947e0886491051e825e5818560be5424df55fb702b0490fd80a9f3df69e42 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 building oss-ci-base_build-py3.12 (from ci/docker/base.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 cache hit: sha256:912c6d3aeabd7af2a8aaaa69ae4fae1b6885be3ba89d324c5fdd9802e90e13e9 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 building llmbuild (from /home/ubuntu/repos/ray/ci/docker/llm.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 2026/03/19 18:01:41 cache hit: sha256:75c255fb274c3b7e373735eb20834391f65a20308b53e26e052c17de7920ed5c 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/llmbuild 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:llmbuild 2026/03/19 18:01:42 tag output as localhost:5000/rayci-work:z-90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 ``` </details> Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

…61929) We shouldn't hijack `LD_LIBRARY_PATH` in general Ray release images introduced by #61598. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

## Description Upgrade to vLLM 0.17.0 and re-compile dependencies. Here are the primary changes aside from fixing breaking APIs: ### 1. `no-verify-hashes` at `pip install` time `uv pip compile` generates lock files with hashes from PyPI, but `uv pip install --index-strategy unsafe-best-match` may download the same package (specifically `triton`) from the PyTorch CUDA index instead, which serves a different wheel build with a different hash. The workaround is `--no-verify-hashes`, which disables all hash integrity checking. #### Alternative approach: Augment hashes after compilation - At lock file compile time, after uv pip compile generates hashes from its resolved index (PyPI), a post-processing step queries every `--extra-index-url` (e.g. PyTorch CUDA index) for each package and appends any additional SHA-256 hashes to the lock file. - At Docker install time, `--verify-hashes` works again because the lock file now contains hashes from all indexes that `--index-strategy unsafe-best-match` might download from. - This is more complicated. ### 2. libstdc++ / CXXABI / ICU compatibility In vLLM 0.16.0, XgrammarBackend was imported lazily inside a method (grammar_init), so the `diskcache` → `sqlite3` → `ICU` → `libstdc++` chain was only triggered when actually using structured output. In vLLM 0.17.0, XgrammarBackend is imported at the top level of `__init__.py`, meaning import vllm now eagerly loads the entire chain: `__init__.py` → `backend_xgrammar.py` → `utils.py` → diskcache → sqlite3 → `_sqlite3.so` → `libicui18n.so.78` → `libstdc++` (CXXABI_1.3.15). The system `libstdc++` only goes up to CXXABI_1.3.13, but conda's copy (`libstdc++.so.6.0.34`) has CXXABI_1.3.15. Conda installs its own C++ ecosystem (libstdc++, ICU, etc.) but at runtime the dynamic linker finds the system libstdc++ first. The fix is to make sure conda's newer `libstdc++` is found first by setting `LD_LIBRARY_PATH`. ## Related issues > Link related issues: "Fixes ray-project#1234", "Closes ray-project#1234", or "Related to ray-project#1234". ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. --------- Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com> Co-authored-by: Lonnie Liu <95255098+aslonnie@users.noreply.github.com> Co-authored-by: elliot-barn <elliot.barnwell@anyscale.com>

…roject#61882) ## Description Fix stale open-telemetry hashes in llm py312 lock files missed by ray-project#61598. ## Related issues Post-merge failures: https://buildkite.com/ray-project/postmerge/builds/16555/steps/canvas?sid=019d047c-934a-44b9-a9bd-89756bcdc297&tab=output. ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. Testing Built locally with wanda: **export PYTHON=3.12 && export BASE_TYPE=build && export BUILD_VARIANT=build && export RAY_CUDA_CODE=cpu && wanda ci/docker/llm.build.wanda.yaml** <details> <summary>Click to see logs</summary> ``` 2026/03/19 18:01:32 building oss-ci-base_test-py3.12 (from ci/docker/base.test.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 cache hit: sha256:5a4947e0886491051e825e5818560be5424df55fb702b0490fd80a9f3df69e42 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 building oss-ci-base_build-py3.12 (from ci/docker/base.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 cache hit: sha256:912c6d3aeabd7af2a8aaaa69ae4fae1b6885be3ba89d324c5fdd9802e90e13e9 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 building llmbuild (from /home/ubuntu/repos/ray/ci/docker/llm.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 2026/03/19 18:01:41 cache hit: sha256:75c255fb274c3b7e373735eb20834391f65a20308b53e26e052c17de7920ed5c 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/llmbuild 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:llmbuild 2026/03/19 18:01:42 tag output as localhost:5000/rayci-work:z-90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 ``` </details> Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

…ay-project#61929) We shouldn't hijack `LD_LIBRARY_PATH` in general Ray release images introduced by ray-project#61598. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

## Description Upgrade to vLLM 0.17.0 and re-compile dependencies. Here are the primary changes aside from fixing breaking APIs: ### 1. `no-verify-hashes` at `pip install` time `uv pip compile` generates lock files with hashes from PyPI, but `uv pip install --index-strategy unsafe-best-match` may download the same package (specifically `triton`) from the PyTorch CUDA index instead, which serves a different wheel build with a different hash. The workaround is `--no-verify-hashes`, which disables all hash integrity checking. #### Alternative approach: Augment hashes after compilation - At lock file compile time, after uv pip compile generates hashes from its resolved index (PyPI), a post-processing step queries every `--extra-index-url` (e.g. PyTorch CUDA index) for each package and appends any additional SHA-256 hashes to the lock file. - At Docker install time, `--verify-hashes` works again because the lock file now contains hashes from all indexes that `--index-strategy unsafe-best-match` might download from. - This is more complicated. ### 2. libstdc++ / CXXABI / ICU compatibility In vLLM 0.16.0, XgrammarBackend was imported lazily inside a method (grammar_init), so the `diskcache` → `sqlite3` → `ICU` → `libstdc++` chain was only triggered when actually using structured output. In vLLM 0.17.0, XgrammarBackend is imported at the top level of `__init__.py`, meaning import vllm now eagerly loads the entire chain: `__init__.py` → `backend_xgrammar.py` → `utils.py` → diskcache → sqlite3 → `_sqlite3.so` → `libicui18n.so.78` → `libstdc++` (CXXABI_1.3.15). The system `libstdc++` only goes up to CXXABI_1.3.13, but conda's copy (`libstdc++.so.6.0.34`) has CXXABI_1.3.15. Conda installs its own C++ ecosystem (libstdc++, ICU, etc.) but at runtime the dynamic linker finds the system libstdc++ first. The fix is to make sure conda's newer `libstdc++` is found first by setting `LD_LIBRARY_PATH`. ## Related issues > Link related issues: "Fixes ray-project#1234", "Closes ray-project#1234", or "Related to ray-project#1234". ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. --------- Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com> Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com> Co-authored-by: Lonnie Liu <95255098+aslonnie@users.noreply.github.com> Co-authored-by: elliot-barn <elliot.barnwell@anyscale.com>

…roject#61882) ## Description Fix stale open-telemetry hashes in llm py312 lock files missed by ray-project#61598. ## Related issues Post-merge failures: https://buildkite.com/ray-project/postmerge/builds/16555/steps/canvas?sid=019d047c-934a-44b9-a9bd-89756bcdc297&tab=output. ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. Testing Built locally with wanda: **export PYTHON=3.12 && export BASE_TYPE=build && export BUILD_VARIANT=build && export RAY_CUDA_CODE=cpu && wanda ci/docker/llm.build.wanda.yaml** <details> <summary>Click to see logs</summary> ``` 2026/03/19 18:01:32 building oss-ci-base_test-py3.12 (from ci/docker/base.test.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 cache hit: sha256:5a4947e0886491051e825e5818560be5424df55fb702b0490fd80a9f3df69e42 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_test-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-18a8af74139d665a6e758968bfbde633d6378f53fc93c9e43f44d5e44079d5dd 2026/03/19 18:01:41 building oss-ci-base_build-py3.12 (from ci/docker/base.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 cache hit: sha256:912c6d3aeabd7af2a8aaaa69ae4fae1b6885be3ba89d324c5fdd9802e90e13e9 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:oss-ci-base_build-py3.12 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:z-350b089d9da1200e6ec5c1ab39401339692fec2edee96f5b1710df664e95830d 2026/03/19 18:01:41 building llmbuild (from /home/ubuntu/repos/ray/ci/docker/llm.build.wanda.yaml) 2026/03/19 18:01:41 build input digest: sha256:90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 2026/03/19 18:01:41 cache hit: sha256:75c255fb274c3b7e373735eb20834391f65a20308b53e26e052c17de7920ed5c 2026/03/19 18:01:41 tag output as cr.ray.io/rayproject/llmbuild 2026/03/19 18:01:41 tag output as localhost:5000/rayci-work:llmbuild 2026/03/19 18:01:42 tag output as localhost:5000/rayci-work:z-90b7bd4eb00b5344b3ff80a3996023a33183a922639b86e91336c95c1aaf11f3 ``` </details> Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

…ay-project#61929) We shouldn't hijack `LD_LIBRARY_PATH` in general Ray release images introduced by ray-project#61598. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

jeffreywang-anyscale requested review from a team, aslonnie, edoakes and richardliaw as code owners March 9, 2026 18:37

cursor Bot reviewed Mar 9, 2026

View reviewed changes

Comment thread python/deplocks/base_deps/ray_base_deps_py3.10.lock Outdated

Comment thread docker/ray-llm/Dockerfile

gemini-code-assist Bot reviewed Mar 9, 2026

View reviewed changes

jeffreywang-anyscale force-pushed the vllm-0.17.0 branch from fb6c09d to 56b154c Compare March 9, 2026 18:52

Upgrade vLLM to 0.17.0

2b1741a

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

jeffreywang-anyscale force-pushed the vllm-0.17.0 branch from 56b154c to 2b1741a Compare March 9, 2026 18:53

jeffreywang-anyscale added the go add ONLY when ready to merge, run all tests label Mar 9, 2026

ray-gardener Bot added serve Ray Serve Related Issue llm labels Mar 9, 2026

aslonnie reviewed Mar 9, 2026

View reviewed changes

jeffreywang-anyscale added 3 commits March 9, 2026 14:40

pytorch 2.10.0 ships CUDA-enabled wheels on PyPI by default

d9f8a11

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

Merge branch 'master' into vllm-0.17.0

8956423

Fix premerge

9f7ad02

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

kouroshHakha approved these changes Mar 9, 2026

View reviewed changes

Fixing premerge

5a8bfb4

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

jeffreywang-anyscale requested a review from a team as a code owner March 9, 2026 23:21

Merge branch 'master' into vllm-0.17.0

b168241

aslonnie reviewed Mar 10, 2026

View reviewed changes

Merge branch 'master' into vllm-0.17.0

97249b4

cursor Bot reviewed Mar 10, 2026

View reviewed changes

Comment thread python/deplocks/base_extra_testdeps/ray-base_extra_testdeps_py3.13.lock Outdated

Fixing premerge

1f5725c

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

cursor Bot reviewed Mar 10, 2026

View reviewed changes

Comment thread ci/raydepsets/configs/rayllm.depsets.yaml

jeffreywang-anyscale added 2 commits March 10, 2026 19:05

Revert numexpr addition - pre-existing issue unrelated to vLLM upgrade

d9d7a78

Master also lacks numexpr in lockfiles with the same NumPy 2.2.6. The CPU test numexpr failure is a base image issue, not caused by this branch. Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

jeffreywang-anyscale force-pushed the vllm-0.17.0 branch from 518bd4c to d9d7a78 Compare March 11, 2026 02:06

jeffreywang-anyscale added 2 commits March 11, 2026 16:14

wip

ad96776

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

fix

35b269f

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

cursor Bot reviewed Mar 14, 2026

View reviewed changes

Comment thread ci/raydepsets/configs/rayimg.depsets.yaml

Restore extra-index-url for cu130

9a06636

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

jeffreywang-anyscale force-pushed the vllm-0.17.0 branch from 68b5b08 to 9a06636 Compare March 16, 2026 17:45

jeffreywang-anyscale added 2 commits March 16, 2026 10:45

Merge branch 'master' into vllm-0.17.0

31f09d8

no-verify-hashes

63fc455

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

cursor Bot reviewed Mar 16, 2026

View reviewed changes

jeffreywang-anyscale added 3 commits March 17, 2026 22:37

Place conda's libstdc++ first

328b5ca

Signed-off-by: Jeffrey Wang <jeffreywang@anyscale.com>

Merge branch 'master' into vllm-0.17.0

ed137fb

Merge branch 'master' into vllm-0.17.0

3683b59

cursor Bot reviewed Mar 18, 2026

View reviewed changes

elliot-barn added 2 commits March 18, 2026 20:37

updating constraints

1652136

Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

updating hashes

278ccee

Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>

elliot-barn approved these changes Mar 19, 2026

View reviewed changes

aslonnie approved these changes Mar 19, 2026

View reviewed changes

aslonnie merged commit 5ef1e5c into master Mar 19, 2026
6 checks passed

aslonnie deleted the vllm-0.17.0 branch March 19, 2026 03:35

jeffreywang-anyscale mentioned this pull request Mar 19, 2026

[deps] Fix stale open-telemetry hashes in llm py312 lock files #61882

Merged

jeffreywang-anyscale mentioned this pull request Mar 20, 2026

[ci] Remove LD_LIBRARY_PATH override from general ray release images #61929

Merged

Conversation

jeffreywang-anyscale commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

1. no-verify-hashes at pip install time

Alternative approach: Augment hashes after compilation

2. libstdc++ / CXXABI / ICU compatibility

Related issues

Additional information

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aslonnie Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

jeffreywang-anyscale Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

aslonnie Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

aslonnie Mar 10, 2026

Choose a reason for hiding this comment

Uh oh!

elliot-barn Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

aslonnie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor Bot Mar 16, 2026

Choose a reason for hiding this comment

Disabling hash verification weakens supply chain security

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot Mar 18, 2026

Choose a reason for hiding this comment

Missing LD_LIBRARY_PATH fix in production ray-llm Dockerfile

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jeffreywang-anyscale commented Mar 9, 2026 •
edited

Loading

1. `no-verify-hashes` at `pip install` time