Closed
【社区任务】[Requirement|需求建议]: 新增 SlidingTileAttention 算子 #6492
little_apple_12Add on 18 days agoClosed at 9 days ago
18 days ago Associated pull request
周云飞
18 days ago Comments:
18 days ago Comments:
/assign @little_apple_12


18 days ago Assign little_apple_12 as responsible person
周云飞
18 days ago Comments:
18 days ago Comments:
感谢提交 SlidingTileAttention 的需求与详细设计。该方案面向视频长序列注意力,通过三维 tile 窗口限制图像 query 访问的 KV 范围,并保留图像与文本之间的注意力规则,能够覆盖逐 head 配置窗口的使用场景。
需求与方案分析
按窗口直接生成 KV 块列表,是避免构造完整 blocks × blocks 掩码的一种可行方向。不过,列表存储与计算开销仍取决于所有 query 实际选中的 KV 总量;窗口覆盖整个画布时,图像注意力仍可能退化为全量计算。因此,最大画布的可用性还需要结合窗口大小、头数及 workspace 占用判断,不能仅由 tile 数确定。
支持范围也需要统一表述:价值说明中的“任意 T×H×W”与参数校验中的整除限制不一致。按当前设计,画布各维需在 [1,200] 内,且 T、H、W 分别能被 6、8、8 整除,并非支持该范围内的所有尺寸。
处理方向
可以以文中两段式接口和分头维执行路径作为实现基础。不同路径需要保持相同的窗口边界、文本 KV 有效范围和输出语义;头维补零后,注意力缩放仍应按原始头维定义,输出恢复为原始 D。逐 bit 一致性则需要在所声明的相同软硬件环境下,分别覆盖 MIX 与 BlockSparseAttention 路径验证。
您提到设计文档已合入、验收已通过。请补充对应的设计文档链接和验收记录;若已有实现 PR,也请一并关联,便于确认已交付范围及后续是否仍有待处理事项。


9 days ago Close issue
8 days ago Added label: resolved
Backgroud(背景信息)
视频生成模型(如 FastVideo / Wan 系列)的注意力输入是一段很长的视频 token 序列:把视频按
(T, H, W)三维画布展开后,30x48x80 这种常见画布就有 115200 个图像 token,再加上文本 token。对这样的序列做全量注意力,计算量随序列长度平方增长。
FastVideo 的
sliding_tile_attention把图像 token 按(6, 8, 8)划分成 tile,每个 head 只在自己的三维滑动窗口内做注意力:窗口以 query 所在 tile 为中心、每侧
k/2个 tile,在画布边界处整体内移并按 tile 网格截断;存在文本时,图像 query 额外访问有效文本 KV,文本区 query 访问全部图像 KV 与有效
文本 KV。昇腾侧此前没有等价算子。
本算子来源于 CANN 社区任务(2026 年 8 月社区任务),设计文档已按社区任务流程评审合入,验收已通过。
Benefit / Necessity (价值/作用)
sliding_tile_attention语义对齐,视频生成模型可直接在昇腾上使用三维滑窗注意力,计算量随窗口内选中的 tile 数增长,而不是随序列长度平方增长。
blocks x blocks的 block mask:host 只下发每个 head 的窗口(单位为 tile)与 tile网格,向量核在 Cube 启动前按窗口写出每个
(head, image block)的 KV 块列表。内存与预处理开销由O(blocks^2)降为O(选中块数),因此最大画布198x200x200(20625 个 tile)也可用。windowSize长度为 1 时广播到所有 head,长度为 N 时逐 head 生效),覆盖 FastVideo 中不同 head 使用不同窗口的用法。
TxHxW。支持设备:
Design(设计方案)
aclnn 两段式接口:
主要输入输出:
[B,N,S,D]S覆盖图像 token 与文本区[B,N,S,D][B,N,S,D][B,N,S,D](Kt, Kh, Kw),单位为 tile"TxHxW"host侧设计
1. Shape 和 dtype 推导
输出 shape 与 dtype 跟随 query;InferShape 要求 query 为四维 BNSD,否则返回失败。
2. 参数校验与头维路由
校验 q/k/v/output 的四维 BNSD、shape 与 dtype 一致、
B/N/S/D均大于 0;seqShape的T/H/W需在[1,200]内且分别能被 6/8/8 整除(6x8x8的 tile 前提),否则返回参数错误。按头维选择执行路径,补零列不改变
Q·K的结果:3. 窗口下发与 launch 划分
host 把每个 head 的有效窗口(已按 tile 网格截断)写成
[1,N,1,3]的 INT8 窗口表,并以属性下发 tile网格(
T | H<<16 | W<<32)与单个 query 块最多选中的 KV 块数。窗口相同的连续 head 合并到一次 launch:两个 kernel 都按位置把一次 launch 的任务分给各核,一次 launch 内混合大小窗口会让拿到小窗口的核空等
最大窗口的核。
4. Tiling 与 workspace
tiling 下发 tile 网格、图像块数、文本块标志、每个 head 的列表容量与向量子核分工等;workspace 用于
补零后的 Q/K/V 副本、KV 块列表以及 score/概率的中转缓冲。
kernel侧设计
1. KV 块列表构建
Cube 启动前,向量子核按窗口为每个
(head, image block)写出 KV 块列表(按列表容量对齐),文本区对应的列表追加在图像块之后;所有 batch 共用同一份列表。
2. 分块 online softmax
沿用 BlockSparseAttention 在 A2 上的数据流:384 行 query 为一个任务,KV 以 512 key 为一个栈,
Cube 做
Q·K^T与P·V,向量核在 FLOAT32 下做 online softmax 与输出累加,不生成完整的S x S矩阵。阶段 2(
P·V与 rescale)跨 query 任务滞后若干个 KV 栈执行,host 按平台 L2 容量选择滞后深度。3. 文本区
文本区作为一个 384 token 的块参与选择:图像 query 的列表追加该块,文本区 query 的列表包含全部图像块
与该块;
textLength之外的预留槽只作为 query 行输出,不参与 KV softmax。