感谢提出 KV Cache 批量写入的需求。将多组等长拷贝合并到一次 Kernel 启动，适合用于减少逐段提交带来的调用和调度开销。这里的功能边界也比较清晰：调用侧负责计算 slot 对应的目标地址，group_memcpy 仅按地址对搬运原始字节，不承担缓存布局转换或 Attention 计算。实际性能收益仍需结合任务数量、单段长度及指针表构建成本评估。
设计建议
“任务分核、段内分块”可以作为候选实现方向，建议同时明确以下约束：
- 接口与地址有效性：明确设备端指针表的地址表示、地址对数量 H 和统一字节数 W，以及 H 或 W 为零时的行为。调用侧需要保证指针表及源、目的内存在执行期间有效，并保证源数据和指针表准备完成后才启动拷贝。
- 并行与重叠语义：建议首版明确限定各任务的写入范围不冲突，且写入不会覆盖其他任务尚未读取的源数据；单个地址对的源、目的区间是否允许重叠也需要明确，不能默认具备 memmove 语义。
- 分块与尾块安全：tile 大小需要计入输入、输出两份 UB 缓冲及其他开销。尾块不仅要避免越界写入，也要保证读取不越界；非对齐地址和长度的处理方式需结合目标平台支持的搬运接口确定。
GM → 输入 UB → 输出 UB → GM 中的两份 UB 缓冲是否必要，也值得评估。若所用搬运接口和同步约束允许，可以考虑复用一份缓冲，减少 UB 占用及段内搬运。另一方面，H 很小时，仅按地址对分核可能无法充分利用并行资源，可结合大段拷贝场景评估是否需要段内跨核拆分。
请补充目标昇腾型号、CANN 版本，以及典型的 H、W 范围和地址对齐情况。这些信息有助于判断搬运接口的适用范围，并确定与逐段设备拷贝进行性能对比的代表性场景。
您好，您是要新增attention 算子吗？ 建议参加每周一的attention 领域的评审会议：
会议详情:
attention torch接口评审
发起人:
hw_huangjunjian3_huawei.com_01
会议时间:
每周星期一 16:00 到 18:00 (UTC+08:00)Beijing 有效期从2026/09/28 至 2026/12/31
会议平台:
WeLink
会议ID:
964720761
会议链接:
https://meeting.huaweicloud.com:36443/#/j/964720761
Etherpad链接:
https://etherpad-cann.meeting.osinfra.cn/p/Attention_torch_extension_api
KV Cache需求已经正常合入，本issue进行关闭
Backgroud（背景信息）
大语言模型 Attention 推理需要将当前 token 的 K、V 数据写入 KV Cache。源数据段连续，而目标缓存位置由调用侧根据 slot、有效序列长度等信息确定，不同 token 的目标地址可以分散。逐段提交设备拷贝会产生多次调用和调度开销。
Benefit / Necessity （价值/作用）
本算子（group_memcpy）基于 Ascend C 实现，将多个源／目的地址对组成设备端指针表，一次启动 Kernel，完成各地址对之间相同字节数的数据复制。该算子只搬运原始字节，不执行归一化、类型转换或 Attention 数值计算。
Design（设计方案）
group_memcpy 算子用于批量完成多组等长的设备内存拷贝，主要应用于 Attention 推理过程中的 KV Cache 写入。
调用侧将多个源地址和目的地址组成设备端指针表，按照 [src0, dst0, src1, dst1, ...] 排列。算子通过一次 Kernel 启动处理全部地址对，减少逐段提交设备拷贝带来的调用和调度开销。
Kernel 采用“任务分核、段内分块”的设计。不同地址对分配给不同 AI Core 并行处理；当单个数据段超过 UB 可用空间时，再按 tile 分块执行。每个 tile 按照 GM → 输入UB → 输出UB → GM 的流程完成搬运，尾块仅写回实际有效字节。
算子内部以字节为单位复制数据，不进行数值计算、类型转换或格式转换。所有任务共用相同的拷贝长度，但源地址和目的地址可以不连续。整体数据搬运复杂度为 O(H × W)，其中 H 为地址对数量，W 为每个任务的拷贝字节数。