Repository navigation
Conversation
…working eat-up.sh stops on compute_platform=xpu and sends the user to K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up. No release up to 0.1.93 serves that path (#339 fixes the two causes), and with the fix it has not yet served end to end on an Arc B70. The check now also asks that the refusal say so, and that it no longer reads "for vLLM on an Intel GPU run". It fails on main: 171 passed, 1 failed.
No release since the vLLM agent shipped (0.1.21, 2026-10-16) up to 0.1.93 serves with vLLM. It was seen on hardware with the vllm backend on Arc; llm-scaler and the Gaudi image are built on vLLM 0.26 and 0.30, whose upstream source has the same two checks. The hardware canary for #326 found the causes on an Arc Pro B70: the Service named vllm gives the pod VLLM_PORT=tcp://..., on which vLLM exits at engine start, and the warm-up reaches vLLM with no Content-Type, which it answers with 400. The pinned v0.32.0 image exits on the first of these on the same host. #339 fixes both and is in no release yet. Several released texts presented the path as working. They now say what is true and link one status note in the README: - README: the Arc and Gaudi sections state the two causes, the fix, that the end-state proof on an Arc B70 is pending, and that llm-scaler and the Gaudi path have not run on hardware. The vllm table row and the Gaudi device row no longer read as serving. - docs/intel.md: the roadmap lists the vLLM paths under Planned, not Shipped; the engines row says no release up to 0.1.93 serves with vLLM. - docs/platforms.md and docs/intel/upstream-eat.md: vLLM XPU is no longer listed as already covered. - docs/quickstart.md and docs/first-run.md: quickstart and agent up do not serve on a Gaudi in those releases. - docs/fit.md: the fit's vLLM pick carries the same status. - integrations/eat/eat-up.sh and its README: the compute_platform=xpu refusal names K3D_GPU_AGENT_BACKEND=vllm and says it has not yet served end to end on Arc, instead of sending the user there. - canary/README.md: the runtime check runs the image under docker run, not in the launcher's pod. A new section says what that leaves out (the pod's Service variables, the launcher's warm-up request, and any serving of the XPU and Gaudi images, which are surface-only on hosted runners), and that both vLLM agent faults were of that kind. Checks: eat_test 172 passed, 0 failed (171/1 before this commit); detect_test 1252/0 (relative doc links resolve); claims_check and ledger_drift_check clean; platforms_doc_test 195/0; canary_spec_test 110/0; mkdocs build --strict clean; shellcheck 0.11.0 at warning severity clean.
… 0.1.94 Release 0.1.94 carries #339 and is the first whose vLLM agent serves. On 2026-11-08 it served end to end on an Arc Pro B70, unpatched. The xpu refusal in eat-up.sh should therefore send users to K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up again, name 0.1.94 as the first release that serves, and no longer say the path has not yet served. Before the eat-up.sh change: 171 passed, 1 failed.
…26-11-08) The record of the hold on crescent (Xeon 6741P, 4x Arc Pro B70, xe, kernel 7.0.0-31, Ubuntu 26.04.1) that ran K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up through the launcher alone, with no kubectl patch and no warm-up sent by hand: - release 0.1.94, installed by packaging/install.sh from main at e5f55b2 (k3d-gpu_0.1.94-1_all.deb, sha256 60a1dc5b...), with vllm/vllm-openai-xpu:v0.32.0@sha256:20509fab...; - #357's head 0985b17 from a clean checkout (launcher 0.1.95), with vllm/vllm-openai-xpu:v0.33.0@sha256:be3a9aea.... Both passed. The pod was Ready on one card with enableServiceLinks false and no VLLM_PORT, the launcher's warm-up was answered, "What is 17 times 23?" gave 391 through the port-forward agent up prints, and the hermes parser returned get_weather with {"city": "Paris"}. Teardown left 0 GiB on all four cards. The record holds each run's files, the hold's log, the install and removal of the release, and the scripts as they ran. pins/classes lists bench/vllm-agent/** as historical, since the files hold image digests.
…ase 0.1.94 Release 0.1.94 is the first with #339. On 2026-11-08 it served with K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up on an Arc Pro B70, unpatched. It was installed by the public packaging/install.sh and ran with the default vllm/vllm-openai-xpu:v0.32.0 (vLLM 0.32.0, sha256:20509fab...) and Qwen/Qwen3-4B at 1cfa9a72. The pod was Ready on one card and the launcher's warm-up was answered. Through the port-forward agent up prints, "What is 17 times 23?" gave 391 and a hermes tool call was parsed. The record is bench/vllm-agent/results/2026-11-08/. The texts that said this proof was pending now give the result, the versions and the record path: - README: the Arc status note leads with the verified run; the vllm table row says it served on an Arc Pro B70 at 0.1.94; the llm-scaler row, the Gaudi device row and the Gaudi section say they have not yet run on hardware. - docs/intel.md: vLLM XPU on Arc is back under Shipped, from 0.1.94. The Planned item now covers only the Gaudi path and llm-scaler, and the engines row says the same. - docs/platforms.md and docs/intel/upstream-eat.md: vLLM XPU through agent up is covered from 0.1.94. - docs/quickstart.md, docs/first-run.md and docs/fit.md: releases up to 0.1.93 do not serve with vLLM; 0.1.94 served on an Arc Pro B70; on a Gaudi it has not yet run on hardware. - integrations/eat/eat-up.sh and its README: the compute_platform=xpu refusal sends users to K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up with k3d-gpu 0.1.94 or later. - canary/README.md: the fix was checked by hand on an Arc Pro B70, for vllm-xpu only. Releases 0.1.21 through 0.1.93 still read as not serving with vLLM.
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
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.
The vLLM agent is verified end to end on an Arc Pro B70 at release 0.1.94. This PR records that run in the repo and updates the docs that called the proof pending. The Gaudi path and llm-scaler still read "not yet run on hardware". It changes no launcher code.
This branch carries #359's two commits unchanged, rebased onto main. #359 has not merged, and its texts say the B70 proof is pending, which is no longer true. With this PR, main goes straight to the result instead of landing #359 first. This PR supersedes #359.
The run
On 2026-11-08 on crescent (Xeon 6741P, 4x Arc Pro B70 on
xe, kernel 7.0.0-31-generic, Ubuntu 26.04.1 LTS), with nokubectl patchand no warm-up sent by hand, each launcher rank3d-gpu up, thenK3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent upwith the default image and model./usr/bin/k3d-gpu0.1.94 fromk3d-gpu_0.1.94-1_all.deb(sha25660a1dc5b..., matching theaur-v0.1.94release asset), installed bypackaging/install.shfrom main at e5f55b2scripts/k3d-gpu0.1.95 from a clean checkout (sha256e2d97e19...)vllm/vllm-openai-xpu:v0.32.0@sha256:20509fab...(vLLM 0.32.0)vllm/vllm-openai-xpu:v0.33.0@sha256:be3a9aea...(vLLM 0.33.0)Qwen/Qwen3-4Bat1cfa9a72, hermes tool parsergpu.intel.com/xe: 1,enableServiceLinks: false, noVLLM_PORTwarm-up reply (2s): I am a large language model developed by Alibaba Cloud.get_weatherwith{"city": "Paris"}, finishtool_callsThe results were first posted on #339, #357 and #326.
Changes
bench/vllm-agent/results/2026-11-08/(new): the proof record. It has a README with every version and digest, each run's files (up,agent up, the pod spec, describe, events, the vLLM log, both requests and replies, teardown), the hold's log, the install and removal of the release package, and the scripts as they ran.pins/classeslistsbench/vllm-agent/**as historical, because the files hold image digests.README.md: the Arc status note now leads with the verified run and the record path. It keeps the account of why releases 0.1.21 through 0.1.93 do not serve. Thevllmtable row says it served on an Arc Pro B70 at 0.1.94. Thellm-scalerrow, the Gaudi device row and the Gaudi section say they have not yet run on hardware.docs/intel.md: vLLM XPU on Arc is back under Shipped, from 0.1.94, with the record. The Planned item now covers the Gaudi path and llm-scaler only, and the engines row says the same.docs/platforms.md,docs/intel/upstream-eat.md: vLLM XPU throughagent upis covered from 0.1.94.docs/quickstart.md,docs/first-run.md,docs/fit.md: releases up to 0.1.93 do not serve with vLLM, 0.1.94 served on an Arc Pro B70, and on a Gaudi it has not yet run on hardware.integrations/eat/eat-up.sh(checkout-only) and its README: thecompute_platform=xpurefusal sends users toK3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent upagain, with k3d-gpu 0.1.94 or later.canary/README.md: the fix was checked by hand on an Arc Pro B70, forvllm-xpuonly.Tests
tests/eat_test.shchanged first, in its own commit. The xpu refusal must nameK3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent upandk3d-gpu 0.1.94 or later, and must not say it has not yet served. Before the fix: 171 passed, 1 failed. After: 172 passed, 0 failed.tests/claims_check.sh: 28 files clean.tests/claims_check_test.sh: 83 passed.python3 tests/ledger_drift_check.py: 43 files agree with 83 ledger rows.tests/ledger_drift_check_test.py: OK.tests/platforms_doc_test.sh: 195 passed.tests/canary_spec_test.sh: 110 passed.tests/pe_premise_check.sh: ok.tests/docs_test.sh: 63 passed, andmkdocs build --strictis clean, run with the pinneddocs-buildtoolchain in its pinned Python image.hack/pin-guard --base origin/main: ok.hack/pin-classes coverage: ok.tests/pin_guard_test.sh: 39 passed.python3 tests/pin_classes_test.py: OK.scripts/images-lock check: ok.tests/image_pins_test.sh: 64 passed.python3 tests/ledger_freshness_test.py: OK.tests/ci_wiring_test.sh: 179 passed.tests/detect_test.sh: 1257 passed, 0 failed, including "relative doc links resolve".integrations/eat/eat-up.sh,tests/eat_test.shand the record's scripts. The record'suninstall-release.shgot one directive comment for SC2024, and that is its only change since the run.