提速 47 倍只动了「一行均值」腾讯 FlashPrefill V2 把长上下文 Prefill 推理重写了一遍Hugging Face 每日论文2026-08-22 精选 · 反差流论文FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM Serving作者Qihang Fan、Huaibo Huang、Zhiying Wu、Bingning Wang、Ran HeTencentarXiv2608.19758cs.CL2026-08-20一、荒谬的事实在第一句话一台 NVIDIA H20 跑 128K 上下文、FP8 精度FlashPrefill V2 比 FlashAttention-2 快了47.26 倍。把精度换回 BF16还有27.19 倍哪怕对照的是已经对齐 FA3/4 流水线的高密度基线FP8 下仍然有30.49 倍。这三个数字放在一起读会让人觉得「H20 终于不是 AI 算力的尾巴了」。但事实正好相反——硬件没换、显存没多、KV 没动被改的只是「注意力算法怎么算」那一段。腾讯把这个系列从算法原型推到生产环境的关键写在一篇不到一页纸的 abstract 里主题词只有三个mean correction、sparse operator、SGLang。把长上下文推理加速到三四十倍这个事过去一年没人能做到——稀疏是做过、动态阈值是做过、稀疏算子写入 FA 风格的 Paged KV 也是做过但同时把精度不掉、算子对齐 FA3/4、又能跑进 vLLM/SGLang 在线服务的连续 batching这件事之前没人串成一根链。FlashPrefill V2 的贡献就在于把这三件事打包了。二、要解决的真问题Prefill 不是 Decode复杂度是 O(N²)「长上下文」这件事对很多人来说只是 token 多一点但它在系统侧意味着完全不同的瓶颈。一次 LLM 推理被切成两段Prefill一次把整段 prompt 读完、算 KV cache和Decode逐 token 生成输出。Decode 部分早已被 KV cache 和投机解码做成熟了瓶颈一直在 Prefill。为什么因为 Prefill 阶段要做完整的注意力矩阵序列长度 N要算 N×N 个注意力权重。对于 128K 上下文来说就是 1.68 亿次浮点运算而当 batch 内多个长 prompt 并发时复杂度又乘 batch 量级GPU 算力很快被打空延迟陡升。行业里所有长上下文优化的核心目标都是同一个怎么让 Prefill 阶段的注意力矩阵变稀疏但稀疏后模型输出的质量不要掉。三、上一代 FlashPrefill 做到了什么、又卡在哪腾讯去年提出的 FlashPrefill原版是这条路的起点。它有两条核心机制瞬时模式发现用「左下角」掩码的稀疏模式快速探测哪些 query-key 对是显著相关的基于最大值动态阈值用一个全局 max 值动态决定保留哪些块让稀疏率随数据自适应。但 abstract 里他们自己写得很坦白「仍是一个远离生产部署的算法原型」。三个生产部署的硬伤痛点原版缺什么极端稀疏时精度掉缺一个全局的「均值校正」算子对齐不上 FA3/4显存访问、流水线调度没重做服务端集成空白paged KV cache / 连续 batching 没接入FlashPrefill V2 是把上面三个空格逐一补完的版本。四、V2 三件套mean correction 算子重写 服务集成4.1 一行均值项把极端稀疏的误差压回去稀疏注意力最反直觉的一点当稀疏率很高时比如 95% 以上的块被砍掉「最大注意力」往往集中在少数 token 上其余的近似误差被这些最大值掩盖了——但误差本身还在累积。V2 的解决思路非常克制在动态阈值后加一个均值校正项mean correction term把被砍掉那部分的期望值补回来。这「一行」不是真的只有一行而是计算上只多一个 block 级的均值读取但效果是让稀疏率可以推到更激进。具体收益abstract 里 V2 在 128K FP8 下做到了 47.26× 加速同时精度损失在大多数下游任务上几乎可以忽略——这是「稀疏 校正」组合拳第一次跑到这种密度。4.2 算子重写对齐 FA3/4 的全部工程优化仅有数学公式没意义。V2 把稀疏算子重写成三类并行结构PackGQA 显存访问把 KV cache 按 Grouped Query Attention 打包连续内存访问避开显存瓶颈Warp 特化把 warpGPU 内最小调度单位分成 compute warp 与 data warp 两类前者算 GEMM、后者搬运数据流水线并行乒乓流水线pingpong pipelining双缓冲让计算和数据搬运几乎零等待。这一套对得上 FA3/4 的工程骨架所以同一个模型只要把 attention backend 切到 V2不需要改任何上层代码额外显存占用和计算开销都很小FP8 也得到原生支持。4.3 服务框架直接接入 SGLang加速只在实验室跑通不够必须能进推理服务。V2 显式支持Paged KV cacheKV 不再按连续显存布局而是分页存放碎片率显著下降连续 batchingcontinuous batching服务里新请求随时插进旧 batchPrefill 与 Decode 不再交替阻塞。这意味着 V2 不只是一个 kernel而是一个后端模块——现在已经被接入 SGLang 作为可选项对 vLLM 的接入也是路线图里的下一步。五、关键数据47.26× / 27.19× / 30.49× 三个数字怎么读abstract 给出的基准全部在NVIDIA H20 GPU上跑128K 上下文长度三组核心数字如下表。精度对照基线加速比FP8FlashAttention-247.26×BF16FlashAttention-227.19×FP8FA3/4 对齐的稠密基线30.49×这三个数字放在一起解读很重要47.26× vs FA2是「技术演进红利」——FA2 已经是四年前的 kernelFA3/4 引入了大量 warp 调度优化所以哪怕其他厂商的「长上下文优化」号称 30×、40×很多是拿 V2 跟 FA2 比30.49× vs FA3/4 对齐稠密基线是「真的工程产出」——同样的算子流水线、同样 paged KV、同样 batchV2 的稀疏校正能再压 30 倍27.19× BF16 vs 47.26× FP8是「精度换速度」的常规梯度BF16 比 FP8 多一倍比特加速比从 ~47 降到 ~27说明 FP8 的稀疏下均值校正发挥得更干净。六、这个工作对工业界的真正意义对一个普通开发者来说「47× 加速」意味着什么对长上下文应用128K 文档摘要、整本 PDF 问答、长代码库 review原先要等几十秒的首 token现在接近实时可用。对推理服务提供方同等 QPS 下 GPU 数量可减少到 1/30或同等 GPU 数量下并发能力提升 30 倍——单位 token 推理成本大幅下降。对模型训练侧长上下文训练的 Prefill 也可用相同 kernel训练效率提升同样成立。局限也很明显基准仅在 H20 上A100/H100 上的对照表需要等待论文后续 benchmark 放出均值校正项在极端稀疏95%下的稳定性还需要在更多长上下文任务书摘、长代码、长视频脚本上验证质量评测细节abstract 未给出需要看正文具体任务perplexity、long-bench 等。七、和近一年同类工作的对比把近 12 个月的长上下文推理加速工作摆到一起工作时间核心机制部署形态StreamingLLM2024-01Attention Sink算法MInference2024-07三种动态稀疏模式CUDA kernelFlashAttention-32024-12异步流水线kernelFlashPrefillV12025动态阈值稀疏算法原型FlashAttention-42026-03warp 特化kernelFlashPrefill V22026-08均值校正 稀疏算子 SGLang生产模块V2 的关键差别在于不止一个 kernel它把稀疏算法、对齐 FA3/4 的工程、和服务框架集成一次做完。这一套之前没人同时交付过。八、给做长上下文应用的人三条结论优先升级到 V2 兼容的 SGLang 后端如果你的服务长 prompt 多、Prefill 占比大升级后单 GPU 可承载的 QPS 大概率翻倍以上极端稀疏 均值校正是新的「甜点组合」比起单纯追求稀疏率「稀疏 误差校正」是 2026 下半年长上下文推理的标配关注 FP8 块稀疏的组合从 47.26× 的数字看FP8 数值范围对稀疏更友好BF16 上拿 27× 已经接近上限。arXiv2608.19758cs.CL2026-08-20HF 链接https://huggingface.co/papers/2608.19758 提速 47 倍只动了「一行均值」，腾讯 FlashPrefill V2 把长上下文 Prefill 推理重写了一遍
提速 47 倍只动了「一行均值」腾讯 FlashPrefill V2 把长上下文 Prefill 推理重写了一遍Hugging Face 每日论文2026-08-22 精选 · 反差流论文FlashPrefill V2: Block-Sparse Prefill Attention for Long-Context LLM Serving作者Qihang Fan、Huaibo Huang、Zhiying Wu、Bingning Wang、Ran HeTencentarXiv2608.19758cs.CL2026-08-20一、荒谬的事实在第一句话一台 NVIDIA H20 跑 128K 上下文、FP8 精度FlashPrefill V2 比 FlashAttention-2 快了47.26 倍。把精度换回 BF16还有27.19 倍哪怕对照的是已经对齐 FA3/4 流水线的高密度基线FP8 下仍然有30.49 倍。这三个数字放在一起读会让人觉得「H20 终于不是 AI 算力的尾巴了」。但事实正好相反——硬件没换、显存没多、KV 没动被改的只是「注意力算法怎么算」那一段。腾讯把这个系列从算法原型推到生产环境的关键写在一篇不到一页纸的 abstract 里主题词只有三个mean correction、sparse operator、SGLang。把长上下文推理加速到三四十倍这个事过去一年没人能做到——稀疏是做过、动态阈值是做过、稀疏算子写入 FA 风格的 Paged KV 也是做过但同时把精度不掉、算子对齐 FA3/4、又能跑进 vLLM/SGLang 在线服务的连续 batching这件事之前没人串成一根链。FlashPrefill V2 的贡献就在于把这三件事打包了。二、要解决的真问题Prefill 不是 Decode复杂度是 O(N²)「长上下文」这件事对很多人来说只是 token 多一点但它在系统侧意味着完全不同的瓶颈。一次 LLM 推理被切成两段Prefill一次把整段 prompt 读完、算 KV cache和Decode逐 token 生成输出。Decode 部分早已被 KV cache 和投机解码做成熟了瓶颈一直在 Prefill。为什么因为 Prefill 阶段要做完整的注意力矩阵序列长度 N要算 N×N 个注意力权重。对于 128K 上下文来说就是 1.68 亿次浮点运算而当 batch 内多个长 prompt 并发时复杂度又乘 batch 量级GPU 算力很快被打空延迟陡升。行业里所有长上下文优化的核心目标都是同一个怎么让 Prefill 阶段的注意力矩阵变稀疏但稀疏后模型输出的质量不要掉。三、上一代 FlashPrefill 做到了什么、又卡在哪腾讯去年提出的 FlashPrefill原版是这条路的起点。它有两条核心机制瞬时模式发现用「左下角」掩码的稀疏模式快速探测哪些 query-key 对是显著相关的基于最大值动态阈值用一个全局 max 值动态决定保留哪些块让稀疏率随数据自适应。但 abstract 里他们自己写得很坦白「仍是一个远离生产部署的算法原型」。三个生产部署的硬伤痛点原版缺什么极端稀疏时精度掉缺一个全局的「均值校正」算子对齐不上 FA3/4显存访问、流水线调度没重做服务端集成空白paged KV cache / 连续 batching 没接入FlashPrefill V2 是把上面三个空格逐一补完的版本。四、V2 三件套mean correction 算子重写 服务集成4.1 一行均值项把极端稀疏的误差压回去稀疏注意力最反直觉的一点当稀疏率很高时比如 95% 以上的块被砍掉「最大注意力」往往集中在少数 token 上其余的近似误差被这些最大值掩盖了——但误差本身还在累积。V2 的解决思路非常克制在动态阈值后加一个均值校正项mean correction term把被砍掉那部分的期望值补回来。这「一行」不是真的只有一行而是计算上只多一个 block 级的均值读取但效果是让稀疏率可以推到更激进。具体收益abstract 里 V2 在 128K FP8 下做到了 47.26× 加速同时精度损失在大多数下游任务上几乎可以忽略——这是「稀疏 校正」组合拳第一次跑到这种密度。4.2 算子重写对齐 FA3/4 的全部工程优化仅有数学公式没意义。V2 把稀疏算子重写成三类并行结构PackGQA 显存访问把 KV cache 按 Grouped Query Attention 打包连续内存访问避开显存瓶颈Warp 特化把 warpGPU 内最小调度单位分成 compute warp 与 data warp 两类前者算 GEMM、后者搬运数据流水线并行乒乓流水线pingpong pipelining双缓冲让计算和数据搬运几乎零等待。这一套对得上 FA3/4 的工程骨架所以同一个模型只要把 attention backend 切到 V2不需要改任何上层代码额外显存占用和计算开销都很小FP8 也得到原生支持。4.3 服务框架直接接入 SGLang加速只在实验室跑通不够必须能进推理服务。V2 显式支持Paged KV cacheKV 不再按连续显存布局而是分页存放碎片率显著下降连续 batchingcontinuous batching服务里新请求随时插进旧 batchPrefill 与 Decode 不再交替阻塞。这意味着 V2 不只是一个 kernel而是一个后端模块——现在已经被接入 SGLang 作为可选项对 vLLM 的接入也是路线图里的下一步。五、关键数据47.26× / 27.19× / 30.49× 三个数字怎么读abstract 给出的基准全部在NVIDIA H20 GPU上跑128K 上下文长度三组核心数字如下表。精度对照基线加速比FP8FlashAttention-247.26×BF16FlashAttention-227.19×FP8FA3/4 对齐的稠密基线30.49×这三个数字放在一起解读很重要47.26× vs FA2是「技术演进红利」——FA2 已经是四年前的 kernelFA3/4 引入了大量 warp 调度优化所以哪怕其他厂商的「长上下文优化」号称 30×、40×很多是拿 V2 跟 FA2 比30.49× vs FA3/4 对齐稠密基线是「真的工程产出」——同样的算子流水线、同样 paged KV、同样 batchV2 的稀疏校正能再压 30 倍27.19× BF16 vs 47.26× FP8是「精度换速度」的常规梯度BF16 比 FP8 多一倍比特加速比从 ~47 降到 ~27说明 FP8 的稀疏下均值校正发挥得更干净。六、这个工作对工业界的真正意义对一个普通开发者来说「47× 加速」意味着什么对长上下文应用128K 文档摘要、整本 PDF 问答、长代码库 review原先要等几十秒的首 token现在接近实时可用。对推理服务提供方同等 QPS 下 GPU 数量可减少到 1/30或同等 GPU 数量下并发能力提升 30 倍——单位 token 推理成本大幅下降。对模型训练侧长上下文训练的 Prefill 也可用相同 kernel训练效率提升同样成立。局限也很明显基准仅在 H20 上A100/H100 上的对照表需要等待论文后续 benchmark 放出均值校正项在极端稀疏95%下的稳定性还需要在更多长上下文任务书摘、长代码、长视频脚本上验证质量评测细节abstract 未给出需要看正文具体任务perplexity、long-bench 等。七、和近一年同类工作的对比把近 12 个月的长上下文推理加速工作摆到一起工作时间核心机制部署形态StreamingLLM2024-01Attention Sink算法MInference2024-07三种动态稀疏模式CUDA kernelFlashAttention-32024-12异步流水线kernelFlashPrefillV12025动态阈值稀疏算法原型FlashAttention-42026-03warp 特化kernelFlashPrefill V22026-08均值校正 稀疏算子 SGLang生产模块V2 的关键差别在于不止一个 kernel它把稀疏算法、对齐 FA3/4 的工程、和服务框架集成一次做完。这一套之前没人同时交付过。八、给做长上下文应用的人三条结论优先升级到 V2 兼容的 SGLang 后端如果你的服务长 prompt 多、Prefill 占比大升级后单 GPU 可承载的 QPS 大概率翻倍以上极端稀疏 均值校正是新的「甜点组合」比起单纯追求稀疏率「稀疏 误差校正」是 2026 下半年长上下文推理的标配关注 FP8 块稀疏的组合从 47.26× 的数字看FP8 数值范围对稀疏更友好BF16 上拿 27× 已经接近上限。arXiv2608.19758cs.CL2026-08-20HF 链接https://huggingface.co/papers/2608.19758