Enable Intel XPU via accelerator auto-detect (no per-guide duplication)#1514
Enable Intel XPU via accelerator auto-detect (no per-guide duplication)#1514WenjiaoYue wants to merge 4 commits into
Conversation
|
Unsigned commits detected! Please sign your commits. For instructions on how to set up GPG/SSH signing and verify your commits, please see GitHub Documentation. |
There was a problem hiding this comment.
Pull request overview
Adds an Intel XPU (intel-xe device-plugin) variant of the precise-prefix-cache-routing benchmark configuration so it can be rendered and run using the existing template/spec pipeline.
Changes:
- Added an Intel XPU scenario (
accelerator.type=intel-xe, XPU vLLM image, Qwen3-0.6B, eager mode) with decode replicas set to 2 for prefix-hit routing across endpoints. - Added a matching specification Jinja template that points to the new XPU scenario file.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| config/specification/guides/precise-prefix-cache-routing-xpu.yaml.j2 | New spec template wiring the XPU guide to defaults + template dir + XPU scenario. |
| config/scenarios/guides/precise-prefix-cache-routing-xpu.yaml | New Intel XPU scenario defining model, routing plugins, decode command, resources, storage mode, and kv-events publishing for precise prefix cache routing. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Hello @WenjiaoYue. I would like to explore the possibility of extending the "accelerator auto-detect" to include Intel XPU's. Ideally, I would like to avoid the need for replicating each guide for this particular accelerator (while maintaining full support for it, of course!) |
|
This PR is marked as stale after 21d of inactivity. After an additional 14d of inactivity (7d to become rotten, then 7d more), it will be closed. To prevent this PR from being closed, add a comment or remove the |
Address review feedback on llm-d#1514 (maugustosilva, kalantar): rather than copying each guide into an -xpu variant, extend the accelerator auto-detect path so Intel XPU (i915/Xe device-plugins) is selected automatically and shares the canonical guides. - cluster_resource_resolver: map device-plugin resources to accelerator profiles (nvidia/amd/intel-gaudi/google/intel-i915/intel-xe) and add Intel XPU resource priority; accept an explicit profile/kubeconfig. - render_plans + config_schema: resolve and apply the accelerator profile overlay so image, security-context and command overrides are selected per profile. - values/overlays/intel-xpu.yaml: shared Intel XPU machine profile (vLLM XPU image, dtype/exec/memory/block-size args, storage, resource sizing). - Guides (optimized-baseline, pd-disaggregation, precise-prefix-cache-routing): use accelerator-neutral substitution points instead of duplicated XPU files. - step_02_admin_prerequisites: gateway CRD handling for the XPU path. - tests: accelerator profile rendering coverage. Signed-off-by: WenjiaoYue <wenjiao.yue@intel.com>
9ec7f75 to
afe7874
Compare
Hi @maugustosilva Thanks for your suggestion. I've updated the PR to use auto-detection instead of duplicating the guides, as you suggested. Intel device-plugin resources are now detected and mapped to the corresponding I've also closed the other two PRs, as their changes are now covered by this one. I've tested the updated implementation, and everything works as expected with no issues. Please take a look when you have time, and let me know if you'd prefer a different approach. |
| # The cluster resolver deliberately removes both fields when a device | ||
| # resource is available but no portable SKU label exists. In that case | ||
| # Kubernetes schedules from the accelerator resource request alone. | ||
| labelKey: str | None = None | ||
| labelValue: str | None = None |
There was a problem hiding this comment.
Fixed in 616701e. Standalone node affinity and affinity metadata now render only when non-empty accelerator label data exists; otherwise scheduling relies on the accelerator resource request. Added an end-to-end standalone render regression test for the no-SKU-label case.
| ${accelerator.dtypeArgs} \ | ||
| ${accelerator.executionArgs} \ | ||
| --prefix-caching-hash-algo sha256_cbor \ | ||
| --kv-events-config '{"enable_kv_cache_events":true, "publisher":"zmq", "endpoint":"$(KV_EVENTS_ENDPOINT)", "topic":"kv@$(POD_IP):$(POD_PORT)@$(MODEL_NAME)"}' \ |
There was a problem hiding this comment.
Fixed in 616701e. Replaced the undefined POD_PORT with the injected VLLM_INFERENCE_PORT and added a regression assertion for the rendered precise-routing command.
e77b751 to
43472b0
Compare
Address review feedback on llm-d#1514 (maugustosilva, kalantar): rather than copying each guide into an -xpu variant, extend the accelerator auto-detect path so Intel XPU (i915/Xe device-plugins) is selected automatically and shares the canonical guides. - cluster_resource_resolver: map device-plugin resources to accelerator profiles (nvidia/amd/intel-gaudi/google/intel-i915/intel-xe) and add Intel XPU resource priority; accept an explicit profile/kubeconfig. - render_plans + config_schema: resolve and apply the accelerator profile overlay so image, security-context and command overrides are selected per profile. - values/overlays/intel-xpu.yaml: shared Intel XPU machine profile (vLLM XPU image, dtype/exec/memory/block-size args, storage, resource sizing). - Guides (optimized-baseline, pd-disaggregation, precise-prefix-cache-routing): use accelerator-neutral substitution points instead of duplicated XPU files. - step_02_admin_prerequisites: gateway CRD handling for the XPU path. - tests: accelerator profile rendering coverage. Signed-off-by: WenjiaoYue <wenjiao.yue@intel.com>
Signed-off-by: WenjiaoYue <wenjiao.yue@intel.com>
Signed-off-by: WenjiaoYue <wenjiao.yue@intel.com>
Summary
Enables the benchmark guides to run on Intel XPU by extending the existing
accelerator auto-detect, instead of duplicating each guide into an
-xpuvariant (per review feedback on this PR).
What changed
Auto-detect maps device-plugin resources to accelerator profiles in
cluster_resource_resolver.py:nvidia.com/gpu→nvidiaamd.com/gpu→amdhabana.ai/gaudi→intel-gaudigoogle.com/tpu→googlegpu.intel.com/xe/gpu.intel.com/i915/intel.com/gpu→
intel-xe/intel-i915(with a resolution priority for the Intel resources)Single shared overlay
config/templates/values/overlays/intel-xpu.yamlholds the XPU-specific settings (vLLM XPU image, dtype/exec/block-size/memory
args, security context, storage and resource sizing).
render_plansappliesthe detected profile's overlay so image and command overrides are selected
automatically.
Guides are now accelerator-neutral (
optimized-baseline,pd-disaggregation,precise-prefix-cache-routing) — they run on XPU withno per-guide copies. The previous
precise-prefix-cache-routing-xpuscenario/spec have been removed.
Cluster scan is skipped for the
nok8smethod.Added
tests/test_accelerator_profiles.pycovering profile detection andrendering across the three guides.
Result
A cluster exposing an Intel GPU device-plugin resource is detected
automatically and the matching profile is applied — full Intel XPU support
with zero guide duplication.