[Refact.]: refactoring for 310p kvcache and some ops class - #6117
Merged
Merged
Conversation
Tflowers-0129
requested review from
realliujiaxu,
wangxiyuan and
zzzzwwjj
as code owners
January 22, 2026 03:48
Contributor
|
👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:
If CI fails, you can run linting and testing checks locally according Contributing and Testing. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request refactors the KV cache implementation for 310P and some operator classes. The changes include moving 310P-specific logic for layernorm and activation ops into their own classes and files, which improves code organization. The KV cache initialization for 310P is also refactored for better memory efficiency by using in-place operations. However, I've found a critical issue in the activation op refactoring that will prevent the 310P-specific implementation from being used.
I am having trouble creating individual review comments. Click here to see my feedback.
vllm_ascend/ops/activation.py (39-42)
Moving the 310P-specific logic to a dedicated class is a good refactoring. However, the corresponding 310P-specific class for SiluAndMul appears to implement a forward method instead of forward_oot. vLLM's custom operator mechanism prioritizes forward_oot. Since the base class AscendSiluAndMul provides forward_oot, the generic implementation (which no longer contains the 310P logic after this change) will be used, and the 310P-specific logic will effectively be dead code. This is a critical issue that defeats the purpose of the refactoring for this operator.
To fix this, the method in the 310P-specific class should be renamed to forward_oot.
csoulndai
reviewed
Jan 22, 2026
Contributor
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
pu-zhe
reviewed
Jan 22, 2026
pu-zhe
reviewed
Jan 22, 2026
Tflowers-0129
force-pushed
the
refactoring
branch
from
January 22, 2026 11:05
62300b0 to
1c95903
Compare
Tflowers-0129
force-pushed
the
refactoring
branch
3 times, most recently
from
January 23, 2026 06:33
c9da2e4 to
9416643
Compare
38 tasks
Tflowers-0129
force-pushed
the
refactoring
branch
from
January 23, 2026 09:43
97b10e8 to
30a4106
Compare
Contributor
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Tflowers-0129
force-pushed
the
refactoring
branch
from
January 23, 2026 14:24
30a4106 to
3aca61d
Compare
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Tflowers-0129
force-pushed
the
refactoring
branch
from
January 24, 2026 02:23
3aca61d to
88d7981
Compare
Signed-off-by: Tflowers-0129 <2906339855@qq.com>
Tflowers-0129
force-pushed
the
refactoring
branch
from
January 24, 2026 03:06
88d7981 to
24ce1b4
Compare
wangxiyuan
approved these changes
Jan 24, 2026
starmountain1997
pushed a commit
to starmountain1997/vllm-ascend
that referenced
this pull request
Jan 31, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
starmountain1997
pushed a commit
to starmountain1997/vllm-ascend
that referenced
this pull request
Jan 31, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
maoxx241
pushed a commit
to maoxx241/vllm-ascend
that referenced
this pull request
Mar 2, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
LCAIZJ
pushed a commit
to LCAIZJ/vllm-ascend
that referenced
this pull request
Mar 7, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
jiangyunfan1
pushed a commit
to jiangyunfan1/vllm-ascend
that referenced
this pull request
Apr 9, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
yangzhe-2026
pushed a commit
to yangzhe-2026/vllm-ascend
that referenced
this pull request
May 6, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
nanxingMy
pushed a commit
to nanxingMy/vllm-ascend
that referenced
this pull request
May 15, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com> Signed-off-by: nanxing <1014662416@qq.com>
ader47
pushed a commit
to ader47/vllm-ascend
that referenced
this pull request
Jun 18, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
CXY-Katrina
pushed a commit
to CXY-Katrina/vllm-ascend
that referenced
this pull request
Jun 27, 2026
…#6117) ### What this PR does / why we need it? * Refactor the LayerNorm and activation operator classes to decouple the 310P device implementation from the main branch. * Refactor `mm_encoder_attention` on 310P to use the `torch_npu._npu_flash_attention_unpad` operator. * Refactor the QKV inputs in the prefill stage of `attention_v1` on 310P so they are no longer padded to 16× alignment. * Refactor `model_runner` on 310P to align the KV-cache initialization logic with the mainline implementation. ### Does this PR introduce _any_ user-facing change? NO ### How was this patch tested? use the e2e tests. - vLLM version: v0.13.0 - vLLM main: vllm-project/vllm@d682094 --------- Signed-off-by: Tflowers-0129 <2906339855@qq.com>
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
4 participants
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.
What this PR does / why we need it?
mm_encoder_attentionon 310P to use thetorch_npu._npu_flash_attention_unpadoperator.attention_v1on 310P so they are no longer padded to 16× alignment.model_runneron 310P to align the KV-cache initialization logic with the mainline implementation.Does this PR introduce any user-facing change?
NO
How was this patch tested?
use the e2e tests.