[BugFix]Added the store_kv_block_metadata ascendC operator

[ZT-AIA]

What this PR does / why we need it?

1. The operator obtains data from slot_mapping.cpu instead of slot_mapping.gpu. This is because slot_mapping.cpu!=slot_mapping.gpu is transmitted to sfa_v1.
2. Therefore, the cpu_slotmapping variable is deleted. It is not used as a placeholder in other places and can be deleted after being checked with the FO.
3. To adapt to aclgraph, the tensor address of the input parameter store_kv_block_metadata is fixed.

Does this PR introduce any user-facing change?

No

How was this patch tested?

test

• vLLM version: v0.23.0
• vLLM main: vllm-project/vllm@1f486d9

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

---

Tip

💡 Consider Linking a Related Issue or RFC

Your PR title contains the [BugFix] tag, indicating a bug fix or new feature.

Linking a related issue or RFC in the PR description is strongly encouraged — it gives reviewers helpful context and speeds up the review. You can use any of these keywords:

• Fixes #<issue_number>
• Closes #<issue_number>
• Resolves #<issue_number>
• Refs #<rfc_or_issue_number> (for RFCs)

🙏 Thanks for helping us keep the project well-organized!

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces the store_kv_block_metadata AscendC operator to offload metadata generation from the host to the device. By performing this operation on the GPU, the PR eliminates the need for slot_mapping_cpu transfers, reducing host-device synchronization overhead and simplifying the attention metadata pipeline.

Highlights

• New Operator Implementation: Added the store_kv_block_metadata AscendC operator to handle slot mapping metadata generation directly on the device.
• Removal of Host-Side Processing: Removed the slot_mapping_cpu variable and associated host-side logic to eliminate unnecessary data transfers and synchronization overhead.
• Operator Refactoring: Updated the store_kv_block operator to use int32_t for group indices and improved tiling logic for better performance.
• Integration and Cleanup: Refactored sfa_v1, model_runner_v1, and related components to integrate the new metadata operator and cleaned up build scripts and bindings.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

Suggested PR Title:

[Attention][Feature] Implement StoreKvBlockMetadata operator on AICPU

Suggested PR Summary:

### What this PR does / why we need it?
This pull request introduces a new AICPU operator `StoreKvBlockMetadata` to compute grouping metadata (such as `group_len`, `group_key_idx`, and `group_key_cache_idx`) directly on the device, replacing the previous host-side `store_kv_block_pre` logic. This eliminates the need for host-to-device memory copies of slot mapping lists, improving performance. Additionally, it updates the `store_kv_block` operator tiling and kernel logic to use signed integers for group lengths and indices.

However, several critical issues were identified during the review:
- In `store_kv_block.h`, direct scalar access via `GetValue(idx)` on `GlobalTensor` is not supported in Ascend C and will cause compilation errors or severe performance degradation.
- In `store_kv_block_metadata_aicpu.cpp`, there are missing bounds checks on `idxGroups` against `outCapacity` and a lack of verification for output tensor capacities, which could lead to out-of-bounds memory writes.
- In `model_runner_v1.py` and `llm_base_proposer.py`, slicing the metadata tensors with `[:num_reqs_padded]` or `[:num_reqs]` instead of token-level counts is a critical bug since speculative decoding and batching process multiple tokens per request.
- In `store_kv_block_tiling.cpp`, `params.coreNum` is used but not defined in the `StoreKVBlockParams` struct, causing compilation failure.
- Direct inclusion of a `.cpp` file (`store_kv_block_metadata_torch_adpt.cpp`) in `torch_binding.cpp` is non-standard.

### Does this PR introduce _any_ user-facing change?
No, this is an internal optimization for Ascend NPU attention metadata processing.

### How was this patch tested?
The patch was tested using the updated end-to-end test `test_store_kv_block.py` and unit tests in `test_sfa_v1.py`.

[gemini-code-assist]

In Ascend C, GlobalTensor does not support direct scalar access via GetValue(idx). Attempting to compile this will result in a compilation error. Even if supported by some emulators, performing direct global memory reads inside a loop on the AI Core is extremely inefficient and will severely degrade performance. To resolve this, allocate a small LocalTensor in the Unified Buffer (UB), copy the metadata tensors from Global Memory to UB using DataCopy before the loop, and then access them locally.

[gemini-code-assist]

There is no bounds check on idxGroups against outCapacity before writing to groupKeyIdxData and groupKeyCacheIdxData. If the number of groups exceeds outCapacity, this will cause an out-of-bounds memory write (buffer overflow), leading to crashes or security vulnerabilities. Add a bounds check to prevent this.

        if (idxGroups >= outCapacity) {
            KERNEL_LOG_ERROR("idxGroups %d exceeds outCapacity %ld", idxGroups, outCapacity);
            return false;
        }

        int32_t blockId = cacheSlot / blockSize_;

        // Record group start: source index and destination cache index
        groupKeyIdxData[idxGroups] = idxSlotmap;
        groupKeyCacheIdxData[idxGroups] = cacheSlot;

[gemini-code-assist]

Slicing self.group_len, self.group_key_idx, and self.group_key_cache_idx with [:num_reqs_padded] is a critical bug. These metadata tensors need to hold grouping information for all tokens in the batch, so they must be sliced with [:num_tokens_padded] (the number of tokens), not [:num_reqs_padded] (the number of requests). Slicing with num_reqs_padded will make the tensors far too small, causing the operator to fail or write out of bounds.

Suggested change

	group_len = self.group_len.gpu[:num_reqs_padded],
	group_key_idx = self.group_key_idx.gpu[:num_reqs_padded],
	group_key_cache_idx = self.group_key_cache_idx.gpu[:num_reqs_padded],
	group_len = self.group_len.gpu[:num_tokens_padded],
	group_key_idx = self.group_key_idx.gpu[:num_tokens_padded],
	group_key_cache_idx = self.group_key_cache_idx.gpu[:num_tokens_padded],

[gemini-code-assist]

The variable params.coreNum is used here, but coreNum is not a member of the StoreKVBlockParams struct. This will cause a compilation failure. Please use the correct local variable or platform API to retrieve the core count.

Suggested change

	if (params.coretail < params.coreNum) tilingData.set_coreTail(params.coretail);
	if (params.coretail < coreNum) tilingData.set_coreTail(params.coretail);

[gemini-code-assist]

The kernel does not verify that the output tensors groupKeyIdx_ and groupKeyCacheIdx_ have the same capacity as groupLen_ (or at least outCapacity). If they are smaller, the subsequent memset and writes will overflow. Also, using GetTensorShape()->GetShapeSize() is more robust than GetDimSize(0) to handle any potential shape variations.

    if (slotMapping_ == nullptr || slotMapping_->GetData() == nullptr) {
        KERNEL_LOG_ERROR("slot_mapping is empty");
        return false;
    }
    if (groupLen_ == nullptr || groupLen_->GetData() == nullptr ||
        groupKeyIdx_ == nullptr || groupKeyIdx_->GetData() == nullptr ||
        groupKeyCacheIdx_ == nullptr || groupKeyCacheIdx_->GetData() == nullptr) {
        KERNEL_LOG_ERROR("input tensor is empty");
        return false;
    }

    int32_t *slotMappingData = static_cast<int32_t *>(slotMapping_->GetData());
    int32_t *groupLenData = static_cast<int32_t *>(groupLen_->GetData());
    int32_t *groupKeyIdxData = static_cast<int32_t *>(groupKeyIdx_->GetData());
    int32_t *groupKeyCacheIdxData = static_cast<int32_t *>(groupKeyCacheIdx_->GetData());

    // total elements in slot_mapping
    int64_t slotMappingLen = slotMapping_->GetTensorShape()->GetShapeSize();

    // total capacity of output tensors
    int64_t outCapacity = groupLen_->GetTensorShape()->GetShapeSize();
    int64_t keyIdxCapacity = groupKeyIdx_->GetTensorShape()->GetShapeSize();
    int64_t keyCacheIdxCapacity = groupKeyCacheIdx_->GetTensorShape()->GetShapeSize();

    if (keyIdxCapacity < outCapacity || keyCacheIdxCapacity < outCapacity) {
        KERNEL_LOG_ERROR("Output tensors capacity mismatch: groupLen %ld, groupKeyIdx %ld, groupKeyCacheIdx %ld",
                         outCapacity, keyIdxCapacity, keyCacheIdxCapacity);
        return false;
    }

[gemini-code-assist]

Slicing with [:num_reqs] is incorrect because speculative decoding processes multiple tokens per request. The metadata tensors should be sliced with the actual number of tokens being processed, not the number of requests.

[gemini-code-assist]

Including a .cpp file directly in csrc/torch_binding.cpp and having header guards inside a .cpp file is non-standard and violates C++ best practices. It should be renamed to a header file (.h or .hpp) to match the pattern of store_kv_block_torch_adpt.h.