提速 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 倍哪怕對照的是已經(jīng)對齊 FA3/4 流水線的高密度基線FP8 下仍然有30.49 倍。這三個數(shù)字放在一起讀會讓人覺得「H20 終于不是 AI 算力的尾巴了」。但事實正好相反——硬件沒換、顯存沒多、KV 沒動被改的只是「注意力算法怎么算」那一段。騰訊把這個系列從算法原型推到生產(chǎn)環(huán)境的關鍵寫在一篇不到一頁紙的 abstract 里主題詞只有三個mean correction、sparse operator、SGLang。把長上下文推理加速到三四十倍這個事過去一年沒人能做到——稀疏是做過、動態(tài)閾值是做過、稀疏算子寫入 FA 風格的 Paged KV 也是做過但同時把精度不掉、算子對齊 FA3/4、又能跑進 vLLM/SGLang 在線服務的連續(xù) batching這件事之前沒人串成一根鏈。FlashPrefill V2 的貢獻就在于把這三件事打包了。二、要解決的真問題Prefill 不是 Decode復雜度是 O(N2)「長上下文」這件事對很多人來說只是 token 多一點但它在系統(tǒng)側(cè)意味著完全不同的瓶頸。一次 LLM 推理被切成兩段Prefill一次把整段 prompt 讀完、算 KV cache和Decode逐 token 生成輸出。Decode 部分早已被 KV cache 和投機解碼做成熟了瓶頸一直在 Prefill。為什么因為 Prefill 階段要做完整的注意力矩陣序列長度 N要算 N×N 個注意力權(quán)重。對于 128K 上下文來說就是 1.68 億次浮點運算而當 batch 內(nèi)多個長 prompt 并發(fā)時復雜度又乘 batch 量級GPU 算力很快被打空延遲陡升。行業(yè)里所有長上下文優(yōu)化的核心目標都是同一個怎么讓 Prefill 階段的注意力矩陣變稀疏但稀疏后模型輸出的質(zhì)量不要掉。三、上一代 FlashPrefill 做到了什么、又卡在哪騰訊去年提出的 FlashPrefill原版是這條路的起點。它有兩條核心機制瞬時模式發(fā)現(xiàn)用「左下角」掩碼的稀疏模式快速探測哪些 query-key 對是顯著相關的基于最大值動態(tài)閾值用一個全局 max 值動態(tài)決定保留哪些塊讓稀疏率隨數(shù)據(jù)自適應。但 abstract 里他們自己寫得很坦白「仍是一個遠離生產(chǎn)部署的算法原型」。三個生產(chǎn)部署的硬傷痛點原版缺什么極端稀疏時精度掉缺一個全局的「均值校正」算子對齊不上 FA3/4顯存訪問、流水線調(diào)度沒重做服務端集成空白paged KV cache / 連續(xù) batching 沒接入FlashPrefill V2 是把上面三個空格逐一補完的版本。四、V2 三件套mean correction 算子重寫 服務集成4.1 一行均值項把極端稀疏的誤差壓回去稀疏注意力最反直覺的一點當稀疏率很高時比如 95% 以上的塊被砍掉「最大注意力」往往集中在少數(shù) token 上其余的近似誤差被這些最大值掩蓋了——但誤差本身還在累積。V2 的解決思路非?？酥圃趧討B(tài)閾值后加一個均值校正項mean correction term把被砍掉那部分的期望值補回來。這「一行」不是真的只有一行而是計算上只多一個 block 級的均值讀取但效果是讓稀疏率可以推到更激進。具體收益abstract 里 V2 在 128K FP8 下做到了 47.26× 加速同時精度損失在大多數(shù)下游任務上幾乎可以忽略——這是「稀疏 校正」組合拳第一次跑到這種密度。4.2 算子重寫對齊 FA3/4 的全部工程優(yōu)化僅有數(shù)學公式?jīng)]意義。V2 把稀疏算子重寫成三類并行結(jié)構(gòu)PackGQA 顯存訪問把 KV cache 按 Grouped Query Attention 打包連續(xù)內(nèi)存訪問避開顯存瓶頸Warp 特化把 warpGPU 內(nèi)最小調(diào)度單位分成 compute warp 與 data warp 兩類前者算 GEMM、后者搬運數(shù)據(jù)流水線并行乒乓流水線pingpong pipelining雙緩沖讓計算和數(shù)據(jù)搬運幾乎零等待。這一套對得上 FA3/4 的工程骨架所以同一個模型只要把 attention backend 切到 V2不需要改任何上層代碼額外顯存占用和計算開銷都很小FP8 也得到原生支持。4.3 服務框架直接接入 SGLang加速只在實驗室跑通不夠必須能進推理服務。V2 顯式支持Paged KV cacheKV 不再按連續(xù)顯存布局而是分頁存放碎片率顯著下降連續(xù) batchingcontinuous batching服務里新請求隨時插進舊 batchPrefill 與 Decode 不再交替阻塞。這意味著 V2 不只是一個 kernel而是一個后端模塊——現(xiàn)在已經(jīng)被接入 SGLang 作為可選項對 vLLM 的接入也是路線圖里的下一步。五、關鍵數(shù)據(jù)47.26× / 27.19× / 30.49× 三個數(shù)字怎么讀abstract 給出的基準全部在NVIDIA H20 GPU上跑128K 上下文長度三組核心數(shù)字如下表。精度對照基線加速比FP8FlashAttention-247.26×BF16FlashAttention-227.19×FP8FA3/4 對齊的稠密基線30.49×這三個數(shù)字放在一起解讀很重要47.26× vs FA2是「技術演進紅利」——FA2 已經(jīng)是四年前的 kernelFA3/4 引入了大量 warp 調(diào)度優(yōu)化所以哪怕其他廠商的「長上下文優(yōu)化」號稱 30×、40×很多是拿 V2 跟 FA2 比30.49× vs FA3/4 對齊稠密基線是「真的工程產(chǎn)出」——同樣的算子流水線、同樣 paged KV、同樣 batchV2 的稀疏校正能再壓 30 倍27.19× BF16 vs 47.26× FP8是「精度換速度」的常規(guī)梯度BF16 比 FP8 多一倍比特加速比從 ~47 降到 ~27說明 FP8 的稀疏下均值校正發(fā)揮得更干凈。六、這個工作對工業(yè)界的真正意義對一個普通開發(fā)者來說「47× 加速」意味著什么對長上下文應用128K 文檔摘要、整本 PDF 問答、長代碼庫 review原先要等幾十秒的首 token現(xiàn)在接近實時可用。對推理服務提供方同等 QPS 下 GPU 數(shù)量可減少到 1/30或同等 GPU 數(shù)量下并發(fā)能力提升 30 倍——單位 token 推理成本大幅下降。對模型訓練側(cè)長上下文訓練的 Prefill 也可用相同 kernel訓練效率提升同樣成立。局限也很明顯基準僅在 H20 上A100/H100 上的對照表需要等待論文后續(xù) benchmark 放出均值校正項在極端稀疏95%下的穩(wěn)定性還需要在更多長上下文任務書摘、長代碼、長視頻腳本上驗證質(zhì)量評測細節(jié)abstract 未給出需要看正文具體任務perplexity、long-bench 等。七、和近一年同類工作的對比把近 12 個月的長上下文推理加速工作擺到一起工作時間核心機制部署形態(tài)StreamingLLM2024-01Attention Sink算法MInference2024-07三種動態(tài)稀疏模式CUDA kernelFlashAttention-32024-12異步流水線kernelFlashPrefillV12025動態(tài)閾值稀疏算法原型FlashAttention-42026-03warp 特化kernelFlashPrefill V22026-08均值校正 稀疏算子 SGLang生產(chǎn)模塊V2 的關鍵差別在于不止一個 kernel它把稀疏算法、對齊 FA3/4 的工程、和服務框架集成一次做完。這一套之前沒人同時交付過。八、給做長上下文應用的人三條結(jié)論優(yōu)先升級到 V2 兼容的 SGLang 后端如果你的服務長 prompt 多、Prefill 占比大升級后單 GPU 可承載的 QPS 大概率翻倍以上極端稀疏 均值校正是新的「甜點組合」比起單純追求稀疏率「稀疏 誤差校正」是 2026 下半年長上下文推理的標配關注 FP8 塊稀疏的組合從 47.26× 的數(shù)字看FP8 數(shù)值范圍對稀疏更友好BF16 上拿 27× 已經(jīng)接近上限。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 倍哪怕對照的是已經(jīng)對齊 FA3/4 流水線的高密度基線FP8 下仍然有30.49 倍。這三個數(shù)字放在一起讀會讓人覺得「H20 終于不是 AI 算力的尾巴了」。但事實正好相反——硬件沒換、顯存沒多、KV 沒動被改的只是「注意力算法怎么算」那一段。騰訊把這個系列從算法原型推到生產(chǎn)環(huán)境的關鍵寫在一篇不到一頁紙的 abstract 里主題詞只有三個mean correction、sparse operator、SGLang。把長上下文推理加速到三四十倍這個事過去一年沒人能做到——稀疏是做過、動態(tài)閾值是做過、稀疏算子寫入 FA 風格的 Paged KV 也是做過但同時把精度不掉、算子對齊 FA3/4、又能跑進 vLLM/SGLang 在線服務的連續(xù) batching這件事之前沒人串成一根鏈。FlashPrefill V2 的貢獻就在于把這三件事打包了。二、要解決的真問題Prefill 不是 Decode復雜度是 O(N2)「長上下文」這件事對很多人來說只是 token 多一點但它在系統(tǒng)側(cè)意味著完全不同的瓶頸。一次 LLM 推理被切成兩段Prefill一次把整段 prompt 讀完、算 KV cache和Decode逐 token 生成輸出。Decode 部分早已被 KV cache 和投機解碼做成熟了瓶頸一直在 Prefill。為什么因為 Prefill 階段要做完整的注意力矩陣序列長度 N要算 N×N 個注意力權(quán)重。對于 128K 上下文來說就是 1.68 億次浮點運算而當 batch 內(nèi)多個長 prompt 并發(fā)時復雜度又乘 batch 量級GPU 算力很快被打空延遲陡升。行業(yè)里所有長上下文優(yōu)化的核心目標都是同一個怎么讓 Prefill 階段的注意力矩陣變稀疏但稀疏后模型輸出的質(zhì)量不要掉。三、上一代 FlashPrefill 做到了什么、又卡在哪騰訊去年提出的 FlashPrefill原版是這條路的起點。它有兩條核心機制瞬時模式發(fā)現(xiàn)用「左下角」掩碼的稀疏模式快速探測哪些 query-key 對是顯著相關的基于最大值動態(tài)閾值用一個全局 max 值動態(tài)決定保留哪些塊讓稀疏率隨數(shù)據(jù)自適應。但 abstract 里他們自己寫得很坦白「仍是一個遠離生產(chǎn)部署的算法原型」。三個生產(chǎn)部署的硬傷痛點原版缺什么極端稀疏時精度掉缺一個全局的「均值校正」算子對齊不上 FA3/4顯存訪問、流水線調(diào)度沒重做服務端集成空白paged KV cache / 連續(xù) batching 沒接入FlashPrefill V2 是把上面三個空格逐一補完的版本。四、V2 三件套mean correction 算子重寫 服務集成4.1 一行均值項把極端稀疏的誤差壓回去稀疏注意力最反直覺的一點當稀疏率很高時比如 95% 以上的塊被砍掉「最大注意力」往往集中在少數(shù) token 上其余的近似誤差被這些最大值掩蓋了——但誤差本身還在累積。V2 的解決思路非?？酥圃趧討B(tài)閾值后加一個均值校正項mean correction term把被砍掉那部分的期望值補回來。這「一行」不是真的只有一行而是計算上只多一個 block 級的均值讀取但效果是讓稀疏率可以推到更激進。具體收益abstract 里 V2 在 128K FP8 下做到了 47.26× 加速同時精度損失在大多數(shù)下游任務上幾乎可以忽略——這是「稀疏 校正」組合拳第一次跑到這種密度。4.2 算子重寫對齊 FA3/4 的全部工程優(yōu)化僅有數(shù)學公式?jīng)]意義。V2 把稀疏算子重寫成三類并行結(jié)構(gòu)PackGQA 顯存訪問把 KV cache 按 Grouped Query Attention 打包連續(xù)內(nèi)存訪問避開顯存瓶頸Warp 特化把 warpGPU 內(nèi)最小調(diào)度單位分成 compute warp 與 data warp 兩類前者算 GEMM、后者搬運數(shù)據(jù)流水線并行乒乓流水線pingpong pipelining雙緩沖讓計算和數(shù)據(jù)搬運幾乎零等待。這一套對得上 FA3/4 的工程骨架所以同一個模型只要把 attention backend 切到 V2不需要改任何上層代碼額外顯存占用和計算開銷都很小FP8 也得到原生支持。4.3 服務框架直接接入 SGLang加速只在實驗室跑通不夠必須能進推理服務。V2 顯式支持Paged KV cacheKV 不再按連續(xù)顯存布局而是分頁存放碎片率顯著下降連續(xù) batchingcontinuous batching服務里新請求隨時插進舊 batchPrefill 與 Decode 不再交替阻塞。這意味著 V2 不只是一個 kernel而是一個后端模塊——現(xiàn)在已經(jīng)被接入 SGLang 作為可選項對 vLLM 的接入也是路線圖里的下一步。五、關鍵數(shù)據(jù)47.26× / 27.19× / 30.49× 三個數(shù)字怎么讀abstract 給出的基準全部在NVIDIA H20 GPU上跑128K 上下文長度三組核心數(shù)字如下表。精度對照基線加速比FP8FlashAttention-247.26×BF16FlashAttention-227.19×FP8FA3/4 對齊的稠密基線30.49×這三個數(shù)字放在一起解讀很重要47.26× vs FA2是「技術演進紅利」——FA2 已經(jīng)是四年前的 kernelFA3/4 引入了大量 warp 調(diào)度優(yōu)化所以哪怕其他廠商的「長上下文優(yōu)化」號稱 30×、40×很多是拿 V2 跟 FA2 比30.49× vs FA3/4 對齊稠密基線是「真的工程產(chǎn)出」——同樣的算子流水線、同樣 paged KV、同樣 batchV2 的稀疏校正能再壓 30 倍27.19× BF16 vs 47.26× FP8是「精度換速度」的常規(guī)梯度BF16 比 FP8 多一倍比特加速比從 ~47 降到 ~27說明 FP8 的稀疏下均值校正發(fā)揮得更干凈。六、這個工作對工業(yè)界的真正意義對一個普通開發(fā)者來說「47× 加速」意味著什么對長上下文應用128K 文檔摘要、整本 PDF 問答、長代碼庫 review原先要等幾十秒的首 token現(xiàn)在接近實時可用。對推理服務提供方同等 QPS 下 GPU 數(shù)量可減少到 1/30或同等 GPU 數(shù)量下并發(fā)能力提升 30 倍——單位 token 推理成本大幅下降。對模型訓練側(cè)長上下文訓練的 Prefill 也可用相同 kernel訓練效率提升同樣成立。局限也很明顯基準僅在 H20 上A100/H100 上的對照表需要等待論文后續(xù) benchmark 放出均值校正項在極端稀疏95%下的穩(wěn)定性還需要在更多長上下文任務書摘、長代碼、長視頻腳本上驗證質(zhì)量評測細節(jié)abstract 未給出需要看正文具體任務perplexity、long-bench 等。七、和近一年同類工作的對比把近 12 個月的長上下文推理加速工作擺到一起工作時間核心機制部署形態(tài)StreamingLLM2024-01Attention Sink算法MInference2024-07三種動態(tài)稀疏模式CUDA kernelFlashAttention-32024-12異步流水線kernelFlashPrefillV12025動態(tài)閾值稀疏算法原型FlashAttention-42026-03warp 特化kernelFlashPrefill V22026-08均值校正 稀疏算子 SGLang生產(chǎn)模塊V2 的關鍵差別在于不止一個 kernel它把稀疏算法、對齊 FA3/4 的工程、和服務框架集成一次做完。這一套之前沒人同時交付過。八、給做長上下文應用的人三條結(jié)論優(yōu)先升級到 V2 兼容的 SGLang 后端如果你的服務長 prompt 多、Prefill 占比大升級后單 GPU 可承載的 QPS 大概率翻倍以上極端稀疏 均值校正是新的「甜點組合」比起單純追求稀疏率「稀疏 誤差校正」是 2026 下半年長上下文推理的標配關注 FP8 塊稀疏的組合從 47.26× 的數(shù)字看FP8 數(shù)值范圍對稀疏更友好BF16 上拿 27× 已經(jīng)接近上限。arXiv2608.19758cs.CL2026-08-20HF 鏈接https://huggingface.co/papers/2608.19758