长文本推理越来越长，但你的显卡等不起

你有没有想过，当你把一份十万字的合同扔给AI助手，让它帮你审核条款时，那个转圈的加载动画背后到底发生了什么？

答案可能会让你意外：在这段等待时间里，显卡正在做一件极其笨拙的事情。它要把你输入的每一个字，和前面所有已经输入过的字，两两配对计算一遍相关性。十万字的文本，配对次数是十万乘以十万，也就是一百亿次。这还只是一层网络的计算量，大模型往往有几十层。

这就是所谓的**注意力机制**

> 注意力机制：大模型理解文本的核心方式，它让模型在处理每一个字时，都去"回头看"前面所有字，判断哪些字和当前字关系密切，从而决定该重点参考谁。

的代价。它让大模型变得聪明，却也让计算量随着文本长度的增加呈平方级暴涨。文本长度翻一倍，计算量就变成四倍。这个阶段有个专门的名字，叫**预填充阶段**

> 预填充阶段（Prefilling）：大模型处理输入文本、生成第一个回复字之前的准备计算过程，长文本场景下这个阶段往往是最耗时的部分。

腾讯微信团队和中科院自动化所联合做的这项研究，就是奔着这个"计算量爆炸"的老大难问题去的。他们把这套方案命名为FlashPrefill V2，而这已经是第二代了。

上一代方案留下的三个坑

故事要从他们的第一代工作FlashPrefill说起。

FlashPrefill的核心思路其实挺聪明的：既然文本里大部分字和字之间的关联度很低，那为什么要老老实实地把每一对字都算一遍呢？如果能提前大致猜出哪些区域是"重点关注区"，剩下的直接跳过不算，计算量不就降下来了吗？

这个思路本身没问题，甚至称得上巧妙。FlashPrefill用了一种"实时探测"的办法，先粗略估算出哪些文本块之间关系密切，再用一套基于最大值的动态阈值规则，快速筛选出真正需要精确计算的部分，跳过了传统方法里那种耗时的排序步骤。

但问题是，这套方案离真正能在生产环境里用起来，还差得远。

第一个坑是精度失控。当筛选变得越来越激进，也就是说保留的计算量越来越少时，模型的准确率会跟着"雪崩"，而且没有任何刹车机制。你永远不知道压缩到什么程度就会突然崩掉。

第二个坑是引擎太老。FlashPrefill的底层计算内核是建立在FlashAttention-2这套两年前的技术上的，而如今NVIDIA的Hopper架构显卡（比如H20）已经用上了更先进的**FlashAttention-3/4**

> FlashAttention-3/4：目前最先进的显卡底层注意力计算加速方案，充分利用了Hopper架构显卡的异步数据搬运和低精度计算能力，把硬件性能榨得更干净。

技术，靠的是TMA（张量内存加速器）和异步流水线这些硬件级的优化手段。用老引擎去跑，就像开着十年前的发动机去跑今天的赛道，再好的路线设计也发挥不出应有的速度。

第三个坑更致命，直接关系到能不能真正落地：FlashPrefill假设所有文本的键值缓存是连续存放在显存里的一整块。但现代的推理服务框架，比如vLLM和SGLang，普遍采用的是**分页KV缓存**

> 分页KV缓存（Paged KV Cache）：把显存像操作系统的虚拟内存一样，切成一页一页管理，不同请求的数据可以灵活分布在不同的显存页里，避免浪费空间，这是目前主流推理框架处理并发请求的标准做法。

加**连续批处理**

> 连续批处理（Continuous Batching）：让多个用户的请求可以动态地混合在同一批计算里处理，一个请求算完了就腾出位置给新请求，而不是死等一批请求全部完成才开始下一批，这样能大幅提升显卡的利用率。

的方式来管理显存，好让多个用户的请求可以灵活地混着处理。FlashPrefill那种"整块连续存放"的假设，根本没法直接塞进这套体系里。

这就好比你设计了一套非常高效的图书馆检索算法，前提是所有书都必须按照固定顺序摆在一排书架上。可现实中的图书馆为了应对每天成千上万的借还需求，早就采用了"哪里有空位就往哪里塞，用一张索引卡记录每本书具体在哪"的动态管理方式。你的算法再快，只要它要求书必须连续摆放，就没法用在这种真实的图书馆里。如果不解决这个问题，FlashPrefill就永远只能停留在实验室里的性能测试，没法真正服务于线上成千上万个并发用户的请求。

FlashPrefill V2要做的，就是把这三个坑一个个填上。

均值修正：给激进的剪枝装上一道保险丝

先说精度失控这个问题，论文里给出的解法叫**均值修正**

> 均值修正（Mean Correction）：对于那些被判定为"不重要"而被跳过精确计算的文本块，不是完全丢弃它们，而是用这个块里所有词向量的平均值，打个折扣加回到最终结果里，从而挽回被丢弃的那部分概率质量。

要理解这个修正为什么重要，得先弄明白原来的筛选机制是怎么工作的。

模型在处理长文本时，会把文本切成一个个小块，比如每128个字算一块。对于每一块，系统会计算出一个"重要性分数"，分数达标的块会被完整、精确地计算，分数不达标的直接扔掉，一点贡献都不留。

问题出在"扔掉"这个动作上。数学上，softmax注意力机制的输出是一个加权平均，所有token的贡献都会累加进最终的分母和分子里。当你把某些块直接归零，相当于人为地扭曲了这个概率分布。当保留的计算量还比较多的时候，丢掉的这部分概率质量占比很小，扭曲可以忽略不计。但当压缩比例变得极端，比如只保留5%的计算量时，被丢弃的那些块加起来可能占了相当可观的概率份额，这时候直接无视它们，误差就会明显显现出来。

均值修正的思路是这样的：对每一个被判定为不重要、要跳过的文本块，不是简单地丢掉，而是先把这个块里所有的键向量和值向量各自求个平均，得到一个"代表向量"。然后用这个代表向量去参与最终的softmax计算，只不过要乘上这个块里原本有多少个token这个权重，相当于告诉系统"这里虽然没细算，但大概有这么多字，贡献了大概这么多概率"。

这个操作背后有一层数学上的巧思。论文用泰勒展开做了详细推导，证明这种均值替代产生的误差，本质上只跟块内部"打分和实际值之间的协方差"有关，是一个二阶小量。而如果你什么都不做直接丢弃，误差是跟"这个块和其他块之间的系统性差异"挂钩的，是一个更大的量级。换句话说，均值修正巧妙地把一个大误差换成了一个小误差。

这就像你去参加一场需要投票表决的会议，有一部分与会者因为各种原因没法逐条发表详细意见。如果直接把这些人的意见完全排除在统计之外，最终结果可能会明显偏离全体真实意愿，尤其当缺席的人数比例不小的时候。但如果你至少收集了他们一个大致的"倾向性投票"，哪怕不是详细论证，也能把最终结果的偏差大幅缩小。如果不做这个"大致收集"的动作，压缩比例一旦超过某个临界点，模型的表现就会突然失准，你完全没法预判这个临界点在哪，这在生产环境里是不可接受的风险。

论文里的实验数据很能说明问题。在RULER这个专门测试长文本能力的评测集上，不加修正的版本在128K长度、FP8精度下，比加了修正的版本要低整整6.2个百分点。而加了修正之后，即便在128K这种极端长度下，跟"完整计算所有内容不做任何压缩"的版本相比，BF16精度下的差距也只有1.5个百分点左右。更值得关注的是，这个修正操作带来的额外计算开销小到可以忽略：在64K序列长度、90%的块被压缩掉的情况下，额外延迟也就是3.6到4.5毫秒，相对开销大概在18%到27%之间，而这恰恰是压缩最激进、最需要这层保险的场景。

论文还专门做了一个阈值扫描实验，把控制压缩激进程度的参数从0.2一路调到0.0125，对应的计算密度从5.2%涨到23.6%。结果发现，加了均值修正的版本，在整个扫描范围内准确率始终稳定在80分左右浮动，波动不超过0.6分。而没加修正的版本，同样的扫描范围内准确率从74.68一路爬升到78.02，本身就很不稳定，且始终比修正版本低3到5分。这说明均值修正不只是修补了极端情况，而是把整个可用的压缩区间都拓宽了，原本只能压缩到9%密度左右保持可用，现在可以压到5.2%还保持相对稳定。

让稀疏计算真正"物理提速"：跟上硬件的最新节奏

解决完精度问题，接下来要解决的是"算得快不快"这件事。

这里有个容易被忽视的真相：稀疏计算理论上省了很多次乘法运算，不代表实际跑起来就一定快。如果你的底层代码写得不够贴合硬件特性，理论上省下来的计算量很可能会被各种"隐性摩擦"吃掉，比如内存搬运的延迟、线程之间的等待、指令调度的空转。

FlashPrefill V2这一部分的工作，本质上是把整套计算内核推倒重来，对齐到目前业界最先进的FlashAttention-3/4的执行范式上。这里面有几个关键设计，值得逐一拆开看。

第一个是**PackGQA内存布局**

> PackGQA：一种针对分组查询注意力（GQA）场景的显存访问优化技术，通过重新排布查询矩阵的行列结构，让多个共享同一组键值缓存的查询头能够真正共享显存加载的数据，而不是各自重复加载一遍。

现在主流大模型为了省显存，普遍采用**分组查询注意力**

> 分组查询注意力（GQA, Grouped-Query Attention）：让多个查询头共用同一组键值向量，而不是每个查询头都配一套独立的键值，这样能大幅减少存储键值缓存所需的显存。

的设计，就是让好几个"查询头"共用同一份"键值"数据。这里有个分组比例g，表示有多少个查询头共享一组键值。

如果按照最直白的方式来实现，系统会给每一个查询头单独分配一个计算单元，结果就是这g个计算单元会各自重复加载同一份键值数据，白白浪费显存带宽。PackGQA的做法是把查询矩阵重新打包，让一个计算单元里同时装下这g个头的查询，这样加载一次键值数据，g个头能一起用，加载次数直接除以g。

这就像一个班级里有六个学习小组共用同一本参考书。如果每个小组都各自从书架上取一本相同的参考书回自己座位查阅，那书架的取书压力就是六倍。但如果把六个小组安排坐在同一张大桌子旁边，一次性把参考书放在桌子中央，六个小组同时翻看同一本书，取书的动作只需要发生一次。如果不这样安排座位，显存带宽的压力会随着分组数量线性增长，尤其在解码阶段查询长度很短的时候，这种重复加载造成的浪费比例会非常惊人，论文里提到最坏情况下能省下整整g倍的加载量。

第二个关键设计是**warp specialization（warp专精化）**

> Warp专精化：把显卡上负责计算的线程束（warp）明确分成"生产者"和"消费者"两种角色，生产者专门负责从显存搬运数据，消费者专门负责做矩阵乘法运算，两者并行工作，避免互相等待。

配合**pingpong流水线**

> Pingpong流水线：让矩阵乘法运算和归一化计算（softmax）这两类不同性质的计算任务交替重叠执行，一边算这一块数据的乘法，一边处理上一块数据的归一化，让硬件里不同的计算单元都不闲着。

这两个设计合在一起，本质上是在打一场"流水线作业"的仗。传统的同步流水线，是搬运数据、计算、再搬运、再计算，一步一步来，每一步都得等上一步做完。这就好比一家餐馆，如果厨师非要等服务员把上一桌的菜全部上完才开始炒下一桌的菜，中间厨房设备大量时间是闲置的。

FlashPrefill V2把线程束明确分工，一部分专门负责从显存往芯片里搬运数据（生产者），另一部分专门负责用搬来的数据做矩阵运算（消费者）。生产者和消费者可以同时工作，生产者在搬第n+1块数据的时候，消费者正在处理第n块数据的计算，两者互不阻塞。更进一步，在消费者内部，矩阵乘法和归一化运算（也就是softmax里的指数运算和重新缩放）也做成交替重叠的节奏，一边算这块的QK矩阵乘法，一边算上一块的PV矩阵乘法，一边处理更上一块的归一化，三件事情齐头并进。如果不这样设计，硬件里负责矩阵乘法的核心单元和负责普通运算的核心单元就会互相干等，谁也不能真正把对方的空闲时间利用起来。

第三个是**FP8**

> FP8：一种比常见的BF16精度更低、数据体积更小的浮点数表示方式，用更少的比特位存储数字，计算速度更快、显存占用更少，但精度损失需要额外补偿。

支持。这是这次升级里专门为了配合实际部署需求加的能力。FP8的挑战在于，它的数值动态范围比BF16窄得多，直接拿来做softmax容易溢出或者精度丢失。论文里用了一个巧妙的技巧：把softmax里的概率值先乘以256这个偏移量，把数值映射到e4m3格式能表示的完整动态范围里，这个偏移量在最后计算比值的时候会自动抵消掉，不会影响最终结果，只在做log-sum-exp汇总的时候才需要专门处理一下。

论文还提到了一个很细节的工程难题：FP8下做矩阵乘法的第二步（也就是概率乘以值向量）时，硬件要求数据必须按照特定的转置格式排列，但值向量原始存储可能是按行存的，也可能是按列存的，两种情况需要不同的处理方式。列存的话，直接在寄存器里用位移和字节重排来调整概率矩阵的格式，不产生额外的显存读写；行存的话，则要在共享内存里做一次转置操作，过程中还得小心避开"存储体冲突"这种硬件层面的性能陷阱。这些细节听起来琐碎，但正是这些看似不起眼的工程打磨，决定了理论加速比能不能真正兑现成显示器上看到的秒表读数。

这三项设计叠加起来，效果非常显著。在H20显卡上，128K上下文长度下，FlashPrefill V2相比FlashAttention-2实现了27.19倍的加速（BF16精度），FP8版本更是达到47.26倍。就算拿来跟同样用了先进流水线技术的密集计算基准比，FlashPrefill V2依然能快17.54倍（BF16）和30.49倍（FP8）。而且这个加速优势不是只有极长文本才有，4K这种相对短的文本长度下，依然能跑赢老版本的FA2。

让稀疏注意力真正能塞进生产系统里

前两项工作解决的是"算得准"和"算得快"，第三项工作解决的是"能不能真的用起来"。

前面提到过，现代推理服务框架普遍用分页KV缓存和连续批处理来管理显存和调度请求。FlashPrefill V2这次专门针对这套体系做了原生适配。

核心机制是一个叫**CSR索引**

> CSR索引（Compressed Sparse Row）：一种紧凑记录"哪些块被选中"的数据结构，只存储被选中块的编号列表，而不是给每个块都标记一个"选中或不选中"的标志位，这样在选中比例很低的时候能大幅节省索引本身占用的存储空间。

的数据结构。它的思路很简单：与其给每一个文本块都打一个"选中/不选中"的标记（哪怕这个块根本没被选中，这个标记位也占地方），不如只记录那些真正被选中的块的编号列表。当选中比例很低的时候，比如只有5%的块被选中，这种记录方式能省下大量的索引存储空间。

论文里做了个对比：跟腾讯内部另一套生产级的稀疏注意力算子HPC-Ops相比，在128K长度、单批次32个查询头4个键值头的配置下，HPC-Ops采用的是密集掩码格式，不管实际密度多少，索引占用固定是32MB。而FlashPrefill V2用CSR索引，在5%密度下只占用6MB，省了超过80%的索引存储开销。

分页KV缓存这块，论文里给出了一个具体的地址计算公式：某个键值token的真实显存地址，等于查页表得到这一页的起始地址，再加上这个token在页内的偏移量。这个查表过程通过异步拷贝指令在后台完成，不阻塞主计算流程。

调度层面还有一个值得一提的细节，叫**KV分裂负载均衡**

> KV分裂负载均衡：在稀疏场景下，把每个查询块实际选中的键值块数量作为衡量计算量的标准，而不是简单按位置范围切分工作，确保多个并行处理单元分到的实际工作量是均等的，避免某些单元干等着别的单元把活干完。

因为稀疏计算下，不同的查询块需要处理的实际计算量差异很大，有的块可能选中了一大堆键值块要算，有的可能只选中了寥寥几个。如果还是按照位置范围机械地切分给不同的并行单元，就会出现有的单元早早算完在那儿闲着，有的单元还在埋头苦干的情况。FlashPrefill V2改成按"实际选中的块数量"来切分工作，确保每个并行单元分到的活儿是均等的。

这些工程细节堆叠起来的最终效果，体现在SGLang这套真实的推理服务框架里的表现上。团队把FlashPrefill V2作为标准的注意力后端集成进SGLang，无需改动模型定义、KV缓存结构或调度逻辑。在128K上下文、批次大小16的场景下，Qwen3-30B-A3B模型的首字延迟（也就是用户从提交请求到看到第一个字蹦出来的等待时间）从123.2秒压缩到36.2秒（BF16），FP8精度下更是压到了25.5秒。

在更贴近真实场景的开放式并发测试中，也就是模拟用户按照泊松分布随机到达、请求长度混杂在4K到128K之间的场景下，效果更加突出。传统的密集计算后端在16次每秒的请求速率下几乎被压垮，首字延迟的中位数长达82到106秒，请求吞吐能力被死死卡在每秒0.29到0.37个请求。而FlashPrefill V2把首字延迟中位数压到17到46秒，请求吞吐提升到每秒0.70到0.76个，FP8版本更进一步提升到每秒0.88到1.34个。有意思的是，这种加速在低负载下反而更明显，因为长文本的预填充过程会一直占用计算资源，进而拖慢排在后面等待解码的其他用户请求，预填充算得越快，整个系统的排队积压就消解得越快。

论文还专门测了一下跟**分块预填充**

> 分块预填充（Chunked Prefill）：为了保护并发请求的响应延迟，把一个长文本请求的计算拆成若干个小块分批处理，而不是一次性把整个长文本算完再让出计算资源给别的请求，这是生产系统里常用的延迟保护机制。

配合使用的情况。分块本身会稀释稀疏计算的优势，因为索引选择这个动作要在每个小块上重新做一遍，而且每个短块里那些必须保留的"锚点""窗口"区域占比会相对变高，拉高了整体密度。测试显示，把分块大小设为8K时，加速效果会打一些折扣，但设为16K时基本能恢复大部分优势，所以论文建议实际部署时分块大小至少设为8K。

数据说话：三个模型、两大评测集的全面验证

这套方案不是纸上谈兵，团队在Llama-3.1-8B-Instruct、Qwen3-4B-Instruct-2507和Qwen3-30B-A3B-Instruct-2507三个具有代表性的模型上，用RULER和LongBench两个长文本评测基准做了系统验证。

| 模型 | 完整注意力平均分 | FlashPrefill V2平均分 | FlashPrefill V2-FP8平均分 |

| Llama-3.1-8B-Instruct | 88.82 | **87.79** | 86.57 |

| Qwen3-4B-Instruct-2507 | 87.06 | **86.23** | 85.82 |

| Qwen3-30B-A3B-Instruct-2507 | 92.05 | **91.76** | 91.39 |

从这张表能看出，FlashPrefill V2在三个模型上都能把精度损失控制在1到1.3分以内，FP8版本的额外损失也只有零点几分。而在LongBench这个覆盖更广泛真实任务的评测集上，FlashPrefill V2在三个模型上的平均分都超过了此前所有的对比方法，比如在Llama-3.1-8B上拿到49.31分，比排名第二的XAttention（48.25分）还高出一截。

速度对比方面，下面这张表汇总了不同方法在128K上下文长度下相对FlashAttention-2的加速倍数：

| 方法 | 128K加速倍数 |

| MInference | 2.76× |

| FlexPrefill | 5.43× |

| XAttention | 3.42× |

| FlashPrefill（第一代） | 18.67× |

| FlashPrefill V2 | 27.19× |

| **FlashPrefill V2-FP8** | **47.26×** |

从2.76倍到47.26倍，这中间差了十几倍的鸿沟，背后就是这篇论文里讲的三层升级：更聪明的压缩策略、更贴合硬件的计算内核、更适配真实部署环境的系统设计。三者缺一不可，少了均值修正，压缩激进不敢用；少了硬件对齐，理论加速兑现不了；少了分页缓存适配，方案压根用不进生产系统。

写在后面

读完这篇论文，最让我意外的其实不是速度提升了多少倍，而是团队愿意花这么大的篇幅去讲工程细节。FP8下概率矩阵怎么用位移和字节重排在寄存器里转置，避免存储体冲突要怎么排布列的顺序，这些内容放在一篇论文里其实挺少见的，大部分做算法的论文不会写到这个粒度。这说明这个团队清楚地知道，稀疏注意力这条路走了好几年，卡脖子的从来不是"想不想得到压缩的点子"，而是"这个点子能不能在真实硬件上兑现成秒表上的数字"。

还有一个细节值得单独说一说：均值修正在FP8下的重要性明显高于BF16。这背后的原因论文解释得挺有意思，是因为量化压缩了分数之间的差距，导致原本该被判定为"不重要"的块，实际承载的概率份额反而变大了。这提醒我们，低精度和稀疏化这两件事叠加在一起时，误差不是简单相加，而是会互相放大，这在设计其他压缩方案时可能也是个容易被忽视的坑。

如果长文本处理的成本能一直这样指数级下降，下一步大概率会有人开始琢磨反过来的问题：既然预填充这么快了，能不能干脆让上下文长度不设上限，把整个知识库直接塞进提示词里，不再需要检索增强这类折中方案？这个问题现在还没有答案。

Q&A

Q1：FlashPrefill V2是什么？

A：FlashPrefill V2是腾讯微信团队联合中科院自动化所提出的一种长文本大模型推理加速方案，专门针对处理长文本时的预填充阶段做优化，通过稀疏注意力计算、均值修正和硬件级内核重写，在128K上下文长度下实现最高47.26倍的加速。

Q2：FlashPrefill V2相比第一代FlashPrefill改进了什么？

A：主要有三点改进。一是引入均值修正机制，解决了极端压缩下精度崩溃的问题；二是把计算内核重写对齐到最新的FlashAttention-3/4架构，充分利用Hopper显卡的硬件特性并支持FP8低精度计算；三是原生支持分页KV缓存和连续批处理，能直接集成进SGLang这类主流推理框架。

Q3：FlashPrefill V2会不会明显损失模型的回答质量？

A：不会。在RULER和LongBench两个长文本评测集上，FlashPrefill V2的平均得分和完整注意力计算相比只差1到1.3分左右，即使在128K这种极端长度、只保留不到5%计算量的情况下，差距也控制在1.8分以内。