长上下文 LLM 这两年的故事,本质是在跟两块墙搏斗:显存墙靠 KV cache 压缩、FlashAttention 的 IO 优化撑住;算力墙靠 chunked prefill、投机解码、MoE 来分摊。到了 256K 这种长度,FlashAttention 的"先扫一遍找 top-k 关键块、再算这些块"两段式流程暴露一个尴尬事实——决定要算哪些块本身,就要把所有 query-key 扫一遍,内存开销跟不解码的全注意力几乎一样。ICML 2026 上复旦 Qiu Xipeng 团队 "Faster Than Flash"(arXiv:2609.00097),把这个看似不动的天花板又往上顶了一截。
一份"老问题"的硬约束
长上下文解码的主流路径是稀疏注意力:既然 query-key 矩阵只有少数块真正重要,何必都算?问题在于怎么"知道"哪些块重要。最朴素的做法是用 query-block 历史最大注意力分数当"打分牌",但这块牌要外挂元数据、要 GPU 全局同步,在 H100 这种带宽吃紧的卡上,这块牌本身的读写就足以把后面的稀疏计算收益吃光。Faster Flash Decoding(FFD)的第一刀:把"selector"和"computer"塞进同一个完全融合的 kernel,中间不留任何元数据同步。selector 怎么工作?靠低比特量化过的 query 直接在块上扫描,scan 的结果当场就喂给 attention 计算——既不用写回全局内存,又跳过 top-k 截断需要的那次全量排序。
top-delta:把"全局同步"也拆掉
FFD 的第二个关键设计是 top-delta 策略。当 query 在不同上下文段落里分布极不均匀时(比如 256K 里只关心最后 4K 的事实),传统做法要么"全选"浪费算力,要么"全阈值"漏掉长程依赖。top-delta 改为"保留分数最高的 d 个块 + 跟最高分差距在 δ 内的所有块",每个 query 独立决定 d,本地决策,无需 GPU-wide barrier。这条思路在 RULER 和 LongBench 上跑下来,关键检索类任务精度几乎不掉,代价是 scan 的工作量跟着上下文长度线性增长,但因为融合进了 kernel,反而被带宽优化吸收。
数字层面的承诺与边界
按论文数据,FFD 单 kernel 层达到最高 11.6× 加速,端到端 2.37×,上下文推到 256K。最关键是"训练-free + plug-and-play":不重训、不改权重、装到任何已训练好的 LLM 上即用,代码已开源在 github.com/qluoluo/faster-flash-decoding。但边界要标:kernel 级 11.6× 是峰值不是平均;论文只在 RULER 和 LongBench 两个长上下文基准验证精度,真实业务(代码库理解、长视频字幕、agent 跨页操作)是否保精度,得跑过才知道;FFD 吃显存换带宽,如果同时叠 KV cache 压缩,在 H100 之外的老卡能不能稳,也是部署前要测的。
所以呢
长上下文赛道的下一步,大概率是"Faster Than X"这条线:FlashAttention 把 IO 优化做到 3.0,后续拼的是 selector-computer 融合、扫描-计算复用、动态分布自适应这三件事。FFD 给出的不是"又一个 2×",而是把以前默认要做的事直接砍掉——这种架构层面的减法,比纯算 kernel 优化更值得被同行盯。