chore(xpu): upgrade vLLM and Omni to 0.29.0 - #15033
Conversation
Signed-off-by: wenxin.zhang <wenxin.zhang@intel.com>
github-actions
Bot
added
chore
external-contribution
|
/ok to test 26a1361 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe vLLM XPU configuration now uses version ChangesvLLM XPU version and SBOM alignment
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The supported XPU build path keeps the updated vLLM and AMD64 SBOM references aligned, with no identified merge-blocking issue. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Signed-off-by: Wenxin Zhang <wenxin.zhang@intel.com>
|
/ok to test f2f0941 |
Signed-off-by: VincyZhang <wenxin.zhang@intel.com>
|
/ok to test 01dbe36 |
dmitry-tokarev-nv
left a comment
dmitry-tokarev-nv
left a comment
There was a problem hiding this comment.
Review
Approved. This closes the last vLLM lane that still resolved below 0.29, and the four values in the xpu block move together. One P3, on a comment that the bump makes false.
I rendered every device lane at the merge base and at the head and compared the resolved build arguments, rather than reading the YAML. Only vllm/xpu moved. Every other lane is byte-identical.
Resolved build arguments per lane, merge base vs head
Merge base 0dc991c, head 01dbe36. Produced by container/render.py --show-result on both trees, then diffed.
| lane | argument | merge base | head |
|---|---|---|---|
| vllm/cuda | RUNTIME_IMAGE_TAG | v0.29.0-ubuntu2404 | v0.29.0-ubuntu2404 |
| vllm/cuda | VLLM_OMNI_REF | v0.29.0rc1 | v0.29.0rc1 |
| vllm/xpu | BASE_IMAGE_TAG | v0.27.1 | v0.29.0 |
| vllm/xpu | RUNTIME_IMAGE_TAG | v0.27.1 | v0.29.0 |
| vllm/xpu | VLLM_OMNI_REF | v0.27.0rc1 | v0.29.0rc1 |
| vllm/xpu | BASELINE_SBOM_FILE | vllm-openai-xpu@3309c2e1 | vllm-openai-xpu@96db42e2 |
| vllm/cpu | RUNTIME_IMAGE_TAG | v0.29.0 | v0.29.0 |
| vllm/cpu | VLLM_OMNI_REF | v0.29.0rc1 | v0.29.0rc1 |
| sglang/cuda, sglang/xpu, trtllm/cuda | all | unchanged | unchanged |
No lane resolves below 0.29 after this change. vllm/xpu was the only one that did, and it was the only lane carrying a vllm_omni_ref override.
The lane keeps inheriting transformers_version: "5.14.1" and tokenizers_version: "0.22.2" from the framework level. That matters, because the new base image ships transformers 5.15.0 while container/context.yaml:105 states the constraint "Omni requires Transformers <5.15". container/templates/vllm_runtime.Dockerfile:191-194 force-installs the pinned pair for every device, and container/templates/vllm_runtime.Dockerfile:530-538 fails the build if a later layer changes them. So the constraint holds by construction. No finding.
Test selection on the xpu lane, measured in a CI image, not read off the markers
The PR changes no test file and no Python file, so selection cannot move. Measured anyway, on both trees, in a vLLM runtime-test CI image:
| marker expression | merge base | head |
|---|---|---|
vllm and pre_merge and not multimodal and xpu_1 |
219 | 219 |
vllm and pre_merge and not multimodal and xpu_2 |
3 | 3 |
Controls, on the head tree. The denominator was 4513 collected items in every run:
| expression | selected |
|---|---|
vllm and pre_merge and xpu_1 (drop not multimodal) |
332 |
vllm and pre_merge and multimodal and xpu_1 |
113 |
xpu_1 |
367 |
(pre_merge or post_merge) and vllm and xpu_1 |
349 |
One point for your awareness, not a finding. The pre-merge xpu gate is vllm and pre_merge and not multimodal (.github/workflows/pr-xpu.yaml:80), and not multimodal removes 113 tests, of which 108 are Omni: 107 in components/src/dynamo/vllm/tests/omni/test_output_formatter.py and 1 in tests/serve/test_vllm_omni.py. So the gate on this PR does not exercise the Omni surface the PR moves. Post-merge does: .github/workflows/post-merge-ci.yml:736 uses (pre_merge or post_merge) and vllm, which selects 349 and includes tests/serve/test_vllm_omni.py. The coverage exists. It lands after merge.
Generated vs hand-written, and evidence the SBOM was re-captured rather than hand-edited
42465 of the 42485 changed lines are one generated file. The hand-written part is 20 lines.
| file | changed lines | kind |
|---|---|---|
container/compliance/base_sboms/vllm-openai-xpu@96db42e2-amd64.cdx.json |
42465 | generated, syft CycloneDX |
container/compliance/base_sboms/manifest.json |
12 | hand-written |
container/context.yaml |
8 | hand-written |
Git records the SBOM as a rename with 75 percent similarity, not an add plus a delete. Re-capture evidence, from the two files:
| field | old | new |
|---|---|---|
metadata.component.version |
v0.27.1 | v0.29.0 |
serialNumber |
urn:uuid:79bbb587... | urn:uuid:7662fe04... |
| total components | 16597 | 17585 |
| library components | 1807 | 1913 |
The recorded vllm library version moves 0.27.1+xpu to 0.29.0+xpu, so the scan hit the intended image. manifest.json:59 and manifest.json:61 agree with the filename stem 96db42e2, and I found no remaining reference to the old stem 3309c2e1 anywhere in the tree.
I checked two things that looked like they could be unrelated movement, and cleared both.
First, the capture tool went backwards, syft 1.51.0 to syft 1.49.0. The repo pins no syft version, and the committed baselines already span 1.42.4 to 1.51.1, so this is within the existing spread. It caused no detection loss here: components carrying a deb purl went up, 421 to 480.
Second, level-zero and level-zero-devel at 1.28.2 disappear from the package list, which would be odd for an Intel XPU image. They were renamed upstream, not dropped. The new SBOM carries libze1 and libze-dev at 1.32.0, and the loader file moves from libze_loader.so.1.28.2 to libze_loader.so.1.32.0.
Push shape, merge base, and the interaction check against main
Established by ancestry, not by the label. The head 01dbe36 is a real two-parent merge. Its second parent 0dc991c is an ancestor of origin/main, so this is a genuine merge of main into the branch and not a squash onto an older main. The branch point moved from 78310370 to 0dc991c.
Merge base: 0dc991c01b995196d752a276e917e509966780fb.
main gained two commits after that merge base: 402c2611 and 71c94bcb. Neither touches a file in this diff. Neither touches container/render.py, container/templates/, container/compliance/, or components/src/dynamo/vllm/omni/. Their files are all under lib/llm/ plus Cargo lock files. No contract moved.
Signed-off-by: Wenxin Zhang <wenxin.zhang@intel.com>
|
/ok to test 3f82eea |
dmitry-tokarev-nv
left a comment
dmitry-tokarev-nv
left a comment
There was a problem hiding this comment.
Re-approving at 3f82eea1d5746aaeaaa1249b5654a618b0f0a1cd. My earlier approval covered 01dbe3662, and one commit landed after it, so that approval no longer described the tree in front of you. One P3 stays open, on the guard that the new commit deleted.
What I re-ran at the live head: push shape, pin table, bill of materials, interaction and marker checks
Push shape: a plain append of one commit. 01dbe3662 is still an ancestor of the head. A fresh fetch reported 01dbe36625..3f82eea1d5, a fast-forward and not a forced update. The timeline records no head_ref_force_pushed event. Committer dates stayed spread and equal to the author dates. The branch carries one merge commit, 01dbe36625, and it was already there when I approved. The merge base is 0dc991c01b995196d752a276e917e509966780fb before and after, so I compared at one base.
Pin resolution, re-run with container/render.py on both trees. Every rendered file has the same size on both trees, so I compared checksums.
| lane | build argument | merge base | live head |
|---|---|---|---|
| vllm/cuda | BASE_IMAGE_TAG | 25.11-cuda13.0-devel-ubuntu24.04 | 25.11-cuda13.0-devel-ubuntu24.04 |
| vllm/cuda | RUNTIME_IMAGE_TAG | v0.29.0-ubuntu2404 | v0.29.0-ubuntu2404 |
| vllm/cuda | VLLM_OMNI_REF | v0.29.0rc1 | v0.29.0rc1 |
| vllm/cuda | BASELINE_SBOM_FILE | cuda@2ab6381d | cuda@2ab6381d |
| vllm/xpu | BASE_IMAGE_TAG | v0.27.1 | v0.29.0 |
| vllm/xpu | RUNTIME_IMAGE_TAG | v0.27.1 | v0.29.0 |
| vllm/xpu | VLLM_OMNI_REF | v0.27.0rc1 | v0.29.0rc1 |
| vllm/xpu | BASELINE_SBOM_FILE | vllm-openai-xpu@3309c2e1 | vllm-openai-xpu@96db42e2 |
| vllm/cpu | BASE_IMAGE_TAG | 22.04 | 22.04 |
| vllm/cpu | RUNTIME_IMAGE_TAG | v0.29.0 | v0.29.0 |
| vllm/cpu | VLLM_OMNI_REF | v0.29.0rc1 | v0.29.0rc1 |
| sglang/xpu | all (control) | unchanged | unchanged |
Every lane now resolves at or above 0.29, and no override is left behind. container/context.yaml holds one vllm_omni_ref key, and 0.27 appears nowhere in the file. The new commit dropped the xpu: vllm_omni_ref line, which held the same value as the repository default: the rendered vllm/xpu Dockerfile is byte-identical between 01dbe36 and 3f82eea (sha256:1fafd130c45a5717), so no build argument moved.
The pin governs what is installed. The rendered vllm/xpu Dockerfile runs bash /tmp/install_vllm_omni.sh, that script installs vllm-omni==${VLLM_OMNI_VERSION} as an exact version, and vllm-omni is not in container/deps/vllm/protected_packages.txt, so the constraints file cannot hold it back.
Bill of materials: unchanged since the approved commit. git diff 01dbe3662..3f82eea1d -- container/compliance/ is empty, so I did not re-check it. The old stem 3309c2e1 appears nowhere in the tree, and the new stem 96db42e2 matches the file name vllm-openai-xpu@96db42e2-amd64.cdx.json and its three entries in manifest.json.
Interaction check: clean. No commit on main since the merge base touches container/context.yaml, container/compliance/base_sboms/manifest.json, components/src/dynamo/vllm/omni/base_handler.py, or components/src/dynamo/vllm/tests/omni/test_omni_base_handler.py.
Marker selection: the Intel lane still does not run this file. test_omni_base_handler.py carries unit, vllm, gpu_0 and pre_merge. The lane in .github/workflows/xpu-ci.yaml:182 appends and xpu_1 to the caller expression. Collected counts:
vllm and pre_merge and not multimodal and xpu_1 -> no tests collected (12 deselected)
vllm and pre_merge and not multimodal and xpu_2 -> no tests collected (12 deselected)
(pre_merge or post_merge) and vllm and xpu_1 -> no tests collected (12 deselected)
vllm and pre_merge and not multimodal -> 12 tests collected
unit and vllm -> 12 tests collected
The xpu_1 term is what deselects it, and that gap predates this pull request. The CUDA lane does run the file, and that lane builds with v0.29.0rc1.
What the new commit changed. It deleted the parallel-field filter and its ValueError from base_handler.py, the two tests that pinned them, and the redundant xpu: vllm_omni_ref override with the two comments I had flagged. The comments are no longer wrong, so that P3 is closed. The removal itself is the new P3.
Signed-off-by: Wenxin Zhang <wenxin.zhang@intel.com>
|
/ok to test 32e9344 |
main landed the xpu vLLM and Omni 0.29.0 upgrade (#15033), which re-captured its own baseline SBOM and rewrote the same manifest this branch rewrites. The entries merged cleanly, because the two changes touch different images: main's `vllm-openai-xpu@96db42e2` and this branch's `release@2af29022` for both architectures. The only conflict was `generated_at`, which `capture_baseline_sbom.py` stamps at each capture and nothing reads. Kept the later of the two, `10:42:46Z` over `02:12:55Z`, since that is when the newest capture in the merged manifest ran. Checked after resolving: the file parses, all 14 entries resolve to a file that exists, no orphan `.cdx.json` is left behind, and `container/context.yaml` carries both sides, `v0.29.0` with `vllm-openai-xpu@96db42e2` for xpu and `1.3.0rc27` with `release@2af29022` for trtllm. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Dmitry Tokarev <dtokarev@nvidia.com>
4 participants
Overview:
Upgrade the XPU vLLM runtime and vLLM Omni reference to v0.29.0.
Details:
vllm/vllm-openai-xpu:v0.29.0.vllm_omni_reftov0.29.0.sha256:96db42e2...and remove the superseded v0.27.1 baseline.python3 container/compliance/base_sboms/check_drift.py.Where should the reviewer start?
container/context.yamlcontainer/compliance/base_sboms/manifest.jsonRelated Issues
🚫 This PR is NOT linked to an issue:
Summary by CodeRabbit