Skip to content

feat: add vllm router - #272

Merged
yxf0314 merged 2 commits into
gpustack:mainfrom
aiwantaozi:feat/pd
Sep 15, 2026
Merged

yxf0314 merged 2 commits into
gpustack:mainfrom
aiwantaozi:feat/pd

Conversation

@aiwantaozi

Copy link
Copy Markdown
Collaborator

No description provided.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds the installation of vllm-router to both the CANN and CUDA Dockerfiles, and resolves a shared library loading issue for Mooncake on CANN by updating the RUNPATH of libtransfer_engine.so using patchelf. It also includes a patch to fix DecodeBenchConnector for backends with tuple-based KV caches, such as Ascend MLA. The review feedback points out that patchelf may not be pre-installed in the CANN base image, which could cause build failures, and suggests conditionally installing it during the build process.

Comment thread pack/cann/Dockerfile.vllm Outdated
@yxf0314

yxf0314 commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

Rebase onto the latest main branch, then rename the patch sequence number to 002

Since the CANN vLLM fork hasn't fixed the 002-related issue, stick with 003.

Every one of the six vLLM Dockerfiles carried none of it, so a disaggregated
group had no router to run: the Ascend recipe fell back to an engine example
script with no metrics and no circuit breaker, and the CUDA one could not be
deployed at all.

CANN and CUDA first because those are the two recipes GPUStack ships a PD mode
for. The wheel is prebuilt for both aarch64 and x86_64, so this is an install
rather than a build.

The build fails if the binary is missing afterwards. Without that check the
failure surfaces at deploy time as a container that exits immediately, one
layer away from anything that explains why.
`_fill_blocks` assumed every layer's KV cache is a single block-indexed tensor
and dereferenced `kv_cache.device` directly. vllm-ascend's MLA backend registers
it as a tuple (kv_c_cache, k_pe_cache), so the first request that reaches
`start_load_kv` raises

    AttributeError: 'tuple' object has no attribute 'device'

which propagates out of the worker and kills EngineCore -- the server then 500s
every request and the container exits. Measured on 910B2 with GLM-4.7-Flash
(MLA) on vLLM 0.23.0: `capD-1xtp2` and `capD-1xtp4` both died ~40 s after the
benchmark started.

Both tuple members are block-indexed with the same num_blocks, so the existing
single-tensor path applies to each unchanged. The fill body moves into
`_fill_block_tensor` and is called once per member.

Scope: block-indexed layouts only. Non-block-indexed state (Mamba / linear
attention, where upstream fills the whole buffer) is left alone; upstream main
handles that separately via `_fill_state_tensor` and `CircularBufferSpec`.

@yxf0314 yxf0314 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@yxf0314
yxf0314 merged commit 848db08 into gpustack:main Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants