FlashAttention 的“加速玄学”为什么 A100 能快 2 倍910 却只能快 1.5 倍之前有个做推理服务的朋友跟我吐槽他在 A100 上测 FlashAttention长序列推理快了 2.3 倍结果把同样的代码搬到昇腾 910 上一跑加速比竟然只有 1.5 倍不到。他很困惑“FlashAttention 不就是把 O(N²) 的显存读写省了吗这跟硬件有什么关系难道省下来的显存在 910 上就不叫显存了”这个问题问到了点子上。FlashAttention 的加速比其实极度依赖硬件的“脾气”。今天我们就用盖房子的逻辑把这件事掰扯清楚。1. 核心比喻盖房子的“搬砖”与“和泥”为了搞懂这个问题我们先把硬件看成一个工地把 Attention 计算看成盖房子。盖一栋房子完成一次推理主要分两步搬砖HBM 读写把砖头Key、Value 矩阵从仓库显存搬到工地缓存。和泥矩阵计算把砖头砌成墙计算 QK^T 和 PV。FlashAttention 做了什么它发明了一种新工艺不需要把所有的砖头都搬出来堆在地上而是边搬边砌。这极大地减少了“搬砖”的次数。那么问题来了在什么情况下这种新工艺最能省时间答案是当“搬砖”特别慢而“和泥”特别快的时候。这就引出了两个关键的“工地指标”搬砖速度HBM 带宽每秒能搬多少吨砖。和泥速度算力 TFLOPS每秒能砌多少平米墙。2. 两个“工地”的硬指标对比我们来看看 A100 和 Ascend 910 这两个“工地”的真实数据硬件型号搬砖速度 (HBM 带宽)和泥速度 (FP16 算力)关键比值 (带宽/算力)NVIDIA A1001935 GB/s (超快)312 TFLOPS (快)6.2Ascend 9101200 GB/s (快)256 TFLOPS (超快)4.7注意看最后一列——带宽与算力的比值。A100 的比值是 6.2而 910 的比值是 4.7。这意味着Ascend 910 的“和泥”能力相对于“搬砖”能力更强。换句话说在 910 上计算和泥本来就很快甚至快到很多时候要停下来等数据砖头搬过来。3. 用数据算一笔账为什么 910 的加速比更低假设我们要盖一栋很大的房子序列长度 seq_len4096。标准 Attention老工艺搬砖量超大要先把所有砖头搬出来。和泥量正常。总耗时主要取决于搬砖时间 和泥时间。FlashAttention新工艺搬砖量极少只有原来的 2.5%。和泥量不变甚至因为在线 Softmax 修正多了 0.5% 的计算。总耗时主要取决于和泥时间因为搬砖已经不花时间了。场景推演在 A100搬砖相对慢上老工艺花了很多时间搬砖。新工艺省下了大量的“搬砖”时间虽然“和泥”时间没变但整体时间大幅下降。结果加速比极高2.3x。在 Ascend 910和泥相对极快上老工艺因为“和泥”太快大部分时间其实就在等“搬砖”。新工艺FlashAttention 确实省下了“搬砖”时间但因为 910 的“和泥”实在太快了计算和泥瞬间就完成了。瓶颈转移优化完之后你会发现瓶颈不再是搬砖而是计算本身。既然计算量没变那么加速比就被“计算时间”锁死了。结果加速比不如 A100 高1.5x。一句话总结FlashAttention 是把“搬砖”省下来的。如果你的硬件如 910本来就是“大力士高算力”搬砖对你来说本来就不算最累的活那我帮你省了这点搬砖时间对你整体进度的提升自然就没那么夸张。4. 那个“神秘的 1.5 倍”是怎么算出来的我们来修正一下之前的计算模型把“瓶颈锁死”考虑进去。假设处理 4096 长度的序列标准 Attention 在 910 上计算时间因为算力强大概 3.0ms 就算完了。但显存带宽有限光是读写中间结果QK矩阵就要花 2.8ms。总时间因为要等数据所以总时间是max(计算, 搬砖)加上叠加时间约为5.8ms。FlashAttention 在 910 上计算时间还是 3.0ms计算量没变。搬砖时间几乎为 0只有微不足道的分块读取。总时间现在没有了显存等待直接就是计算时间3.0ms。加速比5.8ms / 3.0ms ≈1.93x。注实测的 1.5x 比理论值更低是因为在短序列或特定 Kernel 调度上910 的计算核心利用率可能没有完全跑满或者存在其他的调度延迟导致实际计算时间略高于理论值从而拉低了加速比。5. 昇腾 NPU 上的“破局”之道既然算力强导致加速比“看起来”低那是不是意味着在 910 上用 FlashAttention 没意义大错特错虽然加速比数字不如 A100 惊艳但 FlashAttention 在昇腾上的核心价值在于显存容量。它能把显存占用从 16GB 降到 4GB这才是业务能跑起来的关键。而且想在 910 上把 FlashAttention 的性能压榨到极致我有三个实战建议堆 Batch Size并发单个请求Batch1的时候910 的算力太强跑不满。当你把 Batch Size 堆到 16 或 32 时计算量大了显存瓶颈也出来了。这时候 FlashAttention 的优势会重新显现加速比能轻松回到 2.0x 以上。开启 INT8 KV Cache利用昇腾 NPU 的 INT8 高吞吐特性。FlashAttention 配合 INT8 量化相当于把“搬砖”的体积再减半进一步释放带宽压力。善用 PagedAttention结合 CANN 的ops-transformer库使用 PagedAttention 管理显存。这能让你在 910 上塞进更多的长文本虽然单次推理加速比是 1.5x但吞吐量QPS能翻倍。6. 总结与选型建议FlashAttention 的加速比公式是加速比 原始显存耗时 / (计算耗时 极少量显存耗时)。A100显存耗时 计算耗时所以加速比极高2.3x。Ascend 910计算耗时 ≈ 显存耗时优化后主要剩计算耗时所以加速比被锁死在 1.5x-1.8x。最终结论不要因为 910 上的加速比数字低就放弃它。FlashAttention 在昇腾上的核心使命是**“显存换算力”**。只要你的业务涉及长文本2048 tokens不管加速比是 1.5 倍还是 2 倍它都是让你的模型从“跑不起来”到“跑得流畅”的唯一解。相关代码与文档[CANN ops-transformer 项目仓库](https://atomgit.com/cann/ops-transformer