← 返回 2026-05-11

UniPrefill:通过块级动态稀疏化实现通用长上下文 Prefill 加速 UniPrefill: Universal Long-Context Prefill Acceleration via Block-wise Dynamic Sparsification

Qihang Fan, Huaibo Huang, Zhiying Wu, Bingning Wang, Ran He 📅 2026-05-07 👍 22 2026-07-13 08:36
LLM推理加速 Prefill优化 vLLM集成 动态稀疏化 混合架构 长上下文

在 token 级稀疏选择,让任意 LLM 架构的 prefill 加速并集成 vLLM。

前置知识

LLM Prefill 与 TTFT

Prefill 是 LLM 推理的两个阶段之一(另一个是 Decode),指把整段 prompt 一次性送入模型并行计算得到第一个 token;TTFT(Time-To-First-Token)是其延迟指标,随序列长度呈 $O(N^2)$ 二次增长,是长上下文场景下的主要瓶颈之一。

本文所有优化目标都是缩短 TTFT,必须先理解 prefill 与 decode 的分阶段特性,才能明白为什么要在 prefill 阶段做 token 级丢弃、以及为什么不能简单沿用 KV cache 压缩(如 SnapKV)的思路。

混合注意力架构(Hybrid Attention)

把全注意力层与线性注意力、SSM、滑窗注意力等高效替代层按固定比例交错堆叠的 LLM,如 Qwen3-Next 的 3:1 linear/full 混合、Gemma-3-12B 的 5:1 sliding-window/full 混合,目的把每层复杂度从 $O(N^2)$ 降到线性 $O(N)$。

论文核心论点是现有 sparse attention 方法在混合架构上失效,因为加速只发生在少数全注意力层;理解 hybrid 的层比例和层类型分布,是读懂 UniPrefill「跨架构通用」声明的必要前提。

稀疏注意力(Sparse Attention)与 MInference/FlexPrefill

挖掘注意力分数矩阵的 vertical-slash-block 稀疏模式、跳过部分 attention 计算以加速 prefill 的方法。MInference 报告纯全注意力模型上可达 $10\times$ 加速,但跳过只发生在 attention 子算子内部,FFN/GEMM 不受影响。

UniPrefill 直接对比 MInference、FlexPrefill、XAttention、ProxyAttn 等稀疏注意力方法;理解它们「只省 attention FLOPs、不省 GEMM FLOPs」的本质缺陷,才能体会 UniPrefill 在 token 级传播稀疏性的核心创新。

vLLM 连续批处理与 PagedAttention

连续批处理指在 decode 阶段允许不同请求动态进入/退出批次的调度策略,使 GPU 利用率远高于静态 batching;PagedAttention 则把 KV cache 分页存储以减少显存碎片。vLLM 把两者作为默认调度范式,但要求每个请求的序列长度在 attention 计算时静态已知。

现有 sparse attention 方法大多假设 batch 组成固定、与连续批处理不兼容;理解 vLLM 的 query_start_loc/seq_lens 等 metadata 是怎么和 KV cache slot mapping 耦合的,才能读懂 UniPrefill 在 §3.5 如何维护各层 KV 长度一致性。

Top-p 选择与注意力汇聚(Attention Sink)

Top-p(nucleus)选择指按重要性降序排列后保留累计概率达到阈值 $p$ 的最小集合,对分布自适应;注意力汇聚是 StreamingLLM 提出的现象——前若干 token 即使语义无关也获得不成比例的注意力概率,必须无条件保留以维持数值稳定性。

UniPrefill 用 top-p 而非 top-k 做块级选择,并强制保留前 $A=128$ 个 sink token 和最后 $n=128$ 个 query window token;理解这两个 trick 的必要性才能看懂为什么 $p=0.99$ 时仍可证明 $\le 1\%$ 的注意力质量损失。

RULER 长上下文基准

RULER 包含检索、多跳追踪、聚合、问答等多类任务,序列长度可配置至 128K,是替代简单 needle-in-a-haystack 的系统性长上下文评测标准。

论文几乎所有精度数字(90.45、93.94、78.87)都是在 RULER 上给出,必须先理解 RULER 的任务多样性和长度可配置性,才能判断 UniPrefill 在精度几乎不降的同时拿到 2× 加速的份量。

研究动机

随着 LLM 部署到文档理解、RAG 等场景,上下文长度从 4K 跃升到 128K 甚至百万 token,Softmax self-attention 的 $O(N^2 d_k)$ 复杂度使 prefill 成为首要瓶颈。当前主要加速手段分两类:混合架构(Qwen3-Next-80B-A3B 的 3:1 linear/full、Gemma-3-12B 的 5:1 sliding-window/full)和稀疏注意力(MInference、FlexPrefill、XAttention、ProxyAttn)。然而二者互相不兼容:3:1 linear/full 混合上全注意力层只占 1/4,sparse attention 至多加速 25% 层,剩余 75% 线性层和所有 FFN GEMM 完全不被触及——Tab. 1 显示 MInference 在 Qwen3-Next 128K 仅 $1.05\times$,Gemma-3-12B 仅 $1.03\times$。FlexPrefill 还与 vLLM 的 continuous batching 调度冲突,难以落地到生产引擎。

本文的目标是本文目标明确:设计一个架构无关(architecture-agnostic)的 prefill 加速框架 UniPrefill,同时满足三个硬性约束:(1)在 full-attention、linear/full hybrid、sliding-window/full hybrid 三类架构上一致有效;(2)与 continuous batching 原生兼容,可作为 vLLM 的透明加速层直接部署,不改模型权重;(3)在 RULER 长上下文基准上保持精度不退化的情况下达到显著 TTFT 加速。具体实验目标是 LLaMA-3.1-8B-Instruct 上达 $2.1\times$ TTFT 加速、RULER 精度维持在 baseline 90.36 附近(实测 90.45),同时吞吐在 vLLM TP=8 部署下最高提升 +109%。

与已有工作不同的是,现有方法的共同盲区是把「prefill 加速」等同于「attention 子算子加速」。本文的独特切入角度是把加速单元从「attention 操作」提升到「token」——一旦在某一层全注意力处判定某 token 不重要,就在该 block 后续所有子层(全注意力、线性注意力、滑窗注意力、FFN)的 GEMM 中同时把它排除掉。这个 block-wise 稀疏传播机制使得 UniPrefill 不依赖具体层类型,因此能跨混合架构工作;并且它作用在 token 维度上、附带 query_start_loc/seq_lens/KV slot 的精细更新,天然适合 vLLM 的连续批处理调度器。这种「token 级 + 跨层传播 + 系统级元数据同步」的三层联动,正是稀疏注意力方法所不具备的,也是论文声称 universal 的根本依据。

核心方法

UniPrefill 整体思路:在每个全注意力层用便宜方法估计 token 块重要性,丢掉得分最低的块后让该决策在后续所有子层都被尊重——把丢弃 token 在 FFN、线性注意力、滑窗注意力中全部排除,并把 vLLM 的 query_start_loc、seq_lens、KV slot mapping 同步更新到保留集规模。直觉上 LLaMA-3.1-8B 有 32 层全注意力,若在第 10 层丢 50% token,后续 22 层 attention 与 FFN 计算量立刻减半——这是 sparse attention 只省 attention FLOPs 而 UniPrefill 能同时省下 GEMM FLOPs 的原因。技术路线四步:(1) 用最后 $n=128$ 个 query 的注意力分数对 $G=64$ 的块打分;(2) top-p($p=0.99$)选择保留块,强制保留前 $A=128$ 个 sink 与最后 $n$ 个 query;(3) 后续子层只在保留集上计算;(4) vLLM 调度器 fused kernel + per-layer KV 修正。

核心创新是把「跳 attention 计算」升级为「丢 token」并在所有下游层传播稀疏性。本质区别三层。第一层稀疏粒度:MInference/FlexPrefill 在 $N\times N$ 注意力矩阵内做 vertical-slash-block 稀疏,仅省 attention 内乘加;UniPrefill 在 token 维度把整块 token 从剩余所有子层排除,使 GEMM 输入从 $N$ 缩到 $\rho N$,同时省 attention 与 GEMM FLOPs。由 Eq. (11),$N\gg d$ 时加速比趋于 $\frac{(L-\ell_1) N d^2}{N^2 d_k} \to \infty$。第二层选择准则:用 top-p,保留集注意力质量损失 $\le (1-p)V_\text{max}$(Eq. 6)。第三层系统集成:把 token dropping 实现为 vLLM 连续批处理原语,按 Eq. (17) 修正每层 KV 长度,使 PagedAttention 无需 slot 物理重排—这是 sparse attention 一直未能跨过的工程门槛

方法步骤详情

方法分五个环节。环节一预处理分块:序列按 $G=64$ 划块,固定保留前 $A=128$ 个 sink token 和最后 $n=128$ 个 query window token。环节二重要性打分:在全注意力层用最后 $n$ 个 query 计算 partial GEMM $S=Q[N-n:N]K^\top$,经 online softmax 后 reduce 到块级得分 $\bar{s}_g^{(b)}$,代价仅 $O(nNd_k)$。环节三 Top-p 选择:降序找最小 $k^*$ 使前缀累计 $\ge p$(Eq. 5),用 IEEE-754 bitcast 把 (score, index) 编码到 int64。环节四稀疏传播:block 内子层只在保留集上计算;block 末尾通过 Eq. (8) 把丢弃 token 旧状态前传。环节五 vLLM 集成:4 个 fused kernel 在 cu_seqlens 变长 packed 表示上工作;TP 度 $T$ 下同步 $\bar b$;调度器维护 drop history 并按 Eq. (17) 注入 seqused 修正

技术新颖性

新颖性可从算法、系统、理论三维度评估。算法:把 sparse pattern 从 attention 矩阵提升到 token 流,通过 block-wise top-p 选择同时控制 attention 与 GEMM 冗余的思路在文献中尚属首次;对比 SnapKV——同样利用观察窗口估计重要性但仅压缩 decode 阶段 KV cache,对 prefill FLOPs 零贡献,而 UniPrefill 在 prefill 阶段就省下 $(1-\rho^{(b)}) M_b O(Nd^2)$ 的 GEMM FLOPs。系统:把 token dropping 实现为 vLLM 的连续批处理原语并精确维护 query_start_loc、seq_lens、KV slot mapping 三套耦合元数据;UniPrefill 通过 per-layer seqused 修正绕开物理 KV 重排。理论:给出 (i) 单层丢弃误差上界(Eq. 6)和 (ii) 跨层累积上界(Eq. 12),为精度不崩提供可解释理由。

Overview of UniPrefill
Figure 2: Overview of UniPrefill

实验结果

实验在 RULER 和 vLLM (TP=8) 两维度展开,覆盖三类架构:LLaMA-3.1-8B 全注意力、Qwen3-Next-80B-A3B 3:1 线性/全混合、Gemma-3-12B 5:1 滑窗/全混合。精度(Tab. 1):UniPrefill RULER 平均分 90.45/93.94/78.87,相对 baseline 退化 $\le 0.82$ 分;LazyLLM/SlimInfer 退化 10+ 分。效率:LLaMA 4K→128K TTFT 加速从 $1.21\times$ 升到 $2.26\times$,Qwen $1.08\times$→$1.68\times$,Gemma $1.15\times$→$1.49\times$。vLLM 吞吐(Tab. 2):LLaMA BS=64 4K +24%,128K +109%;Qwen +13%~+43%;Gemma +19%~+27%。消融(Tab. 3/4):$G=32$ 在 128K 拿到 LLaMA +121%、Qwen +78% 的极端加速(精度 89.88),确认 $G=64$、$n=128$ 默认

Performance vs. efficiency across different models and methods
Table 1: Performance vs. efficiency across different models and methods
Prefill throughput (tokens/s) of Standard Prefill and UniPrefill within vLLM (TP=8)
Table 2: Prefill throughput (tokens/s) of Standard Prefill and UniPrefill within vLLM (TP=8)
Ablation study of block size G
Table 3: Ablation study of block size G
Ablation study of last n
Table 4: Ablation study of last n
Prefill Throughput: Standard Prefill vs. UniPrefill (TP=8)
Figure 1: Prefill Throughput: Standard Prefill vs. UniPrefill (TP=8)
查看结构化数据
任务指标本文基线提升
LLaMA-3.1-8B-Instruct RULER 4K-128K 平均 RULER 精度 / TTFT 加速比 90.45 avg;128K 处 79.87 精度 + 2.26× TTFT Baseline 90.36 avg / 1.00×;MInference 90.68 / 1.34×;FlexPrefill 89.62 / 1.46×;XAttention 89.34 / 1.38× 精度较 baseline +0.09、较 MInference -0.23,但 128K TTFT 加速 2.26× 显著高于所有 sparse 方法(最高 1.79×)
Qwen3-Next-80B-A3B RULER 4K-128K 平均 RULER 精度 / TTFT 加速比 93.94 avg;128K 处 91.41 精度 + 1.68× TTFT Baseline 94.76 / 1.00×;MInference 94.31 / 1.05×;FlexPrefill 93.97 / 1.08×;XAttention 93.53 / 1.05× 在 3:1 linear/full hybrid 上加速比是所有 sparse attention 方法的 15× 以上,精度退化 0.82 分属可接受范围
Gemma-3-12B RULER 4K-128K 平均 RULER 精度 / TTFT 加速比 78.87 avg;128K 处 58.38 精度 + 1.49× TTFT Baseline 79.99 / 1.00×;MInference 79.25 / 1.03×;FlexPrefill 78.64 / 1.04×;XAttention 78.26 / 1.02× 在 5:1 sliding-window/full hybrid 上加速 1.49×,约是次优方法(ProxyAttn 1.06×)的 1.4×,且精度反超 0.08 分
vLLM TP=8 Prefill 吞吐 LLaMA-3.1-8B BS=64 tokens/s(吞吐提升百分比) 4K 68721 (+24%) / 8K 72139 (+35%) / 16K 67361 (+39%) / 32K 67618 (+65%) Standard Prefill 同条件 55431 / 53541 / 48603 / 40869 tokens/s 吞吐随 batch 增大单调提升,32K 时 +65% 是论文单点最高 LLaMA 数据
vLLM TP=8 Prefill 吞吐 LLaMA-3.1-8B 128K tokens/s(吞吐提升百分比) BS=1: 43672 (+107%);BS=4: 43698 (+108%);BS=16: 44042 (+109%);BS=64: — Standard Prefill 21013 / 21054 / 21062 tokens/s 128K 长序列下 BS=1 即翻倍,BS=16 达 +109%,论文标题 Fig. 1 的标志性数据
vLLM TP=8 Prefill 吞吐 Qwen3-Next-80B-A3B 128K tokens/s(吞吐提升百分比) BS=1: 49732 (+48%);BS=4: 52442 (+57%);BS=16: 56398 (+68%);BS=64: — Standard Prefill 33512 / 33364 / 33489 tokens/s 在 3:1 linear/full hybrid 128K 上 +68%,是 MInference 同长度 1.05× 的近 14× 提升
vLLM TP=8 Prefill 吞吐 Gemma-3-12B 128K tokens/s(吞吐提升百分比) BS=1: 25673 (+42%);BS=4: 25932 (+41%);BS=16: 26231 (+42%);BS=64: — Standard Prefill 18103 / 18403 / 18513 tokens/s 5:1 sliding-window/full hybrid 上仍稳定 +42%,证明 block-wise drop 对滑窗局部性同样有效

局限与改进

局限有四点。第一,128K TTFT 加速极值是 LLaMA 的 $2.26\times$,相对 MInference 在纯全注意力上的 $10\times$ 仍有差距——UniPrefill 的卖点是「跨架构通用」而非单架构极值,对只跑全注意力 LLaMA 的用户而言 MInference 仍是更快选择。第二,$p=0.99$、$G=64$、$n=128$、$A=128$ 是三个模型手工调出的默认配置,缺乏自适应机制,不同架构需重新搜索。第三,RULER 上 Qwen 93.94 vs 94.76、Gemma 78.87 vs 79.99 都微低于 baseline,论文未充分分析短上下文下 top-p 选择可能引入的系统偏差。第四,Tab. 2 显示 BS=64 在 64K/128K 全部以「—」缺失,意味着方法在高 batch + 超长上下文组合下的稳定性尚未验证;考虑到 KV 长度修正在 batch 维度需为每个请求维护独立 drop history,这一空缺可能在系统层面就是 hard limitation。

独立分析的弱点

独立分析弱点四块。第一块,drop 决策只在全注意力层做,依赖 attention score 可获得性,对纯 Mamba/SSM-only 架构完全失效——与「universal」措辞有冲突,应理解为「对所有含 full attention 的混合架构」而非任意架构。第二块,Eq. (17) 的 per-layer seqused 修正在 batch 维度需为每个请求维护 drop history;batch=64 且每请求 drop 数十次时 host-side 元数据本身会成为调度瓶颈,论文未给出 overhead 测量。第三块,精度对比基于 HuggingFace Transformers BS=1,加速实验基于 vLLM TP=8——两个评测栈不一致,缺乏端到端 vLLM 内的精度闭环实验。第四块,UniPrefill 在 4K 仍维持 $1.21\times$,但论文没有讨论 fused kernel 在短上下文下的固定开销(4 个 kernel launch + TP 同步),可能让 1K 以下短 prompt 上反而变慢。

未来方向

作者方向主要在 §5 暗示的「推广到更高维稀疏(head 维、专家维)」和「与 speculative decoding 协同」两点。第一个延伸是设计「上下文长度自适应块大小」——$G$ 随 $N$ 增大而减小,使短上下文用粗粒度省 kernel launch、长上下文用细粒度多丢 token。第二个延伸是把 top-p 与 RLHF/在线反馈结合,在精度敏感请求(医疗、法律)上自动调高 $p$、在延迟敏感请求(搜索补全)上自动调低 $p$,把 $p$ 从超参提升为运行时可控接口。第三个延伸是把 block-wise drop 扩展到 MoE 模型,按专家路由分数做 expert-wise sparsification,与 token drop 形成二维稀疏。第四个延伸是把 prefill drop 与 SnapKV 类 decode KV 压缩级联——prefill 已 drop 的 token 在 decode 永远不需要 attend,KV cache 大小可进一步压缩 $\rho\times$,在百万 token 场景下尤其有价值。

复现评估

复现性整体中等偏上。代码:§1 给出 GitHub 链接 https://github.com/qhfan/UniPrefill.git 承诺开源,但未提供 docker 镜像或具体 commit hash。数据:完全基于公开 RULER 基准与三类公开模型,无需私有数据。算力:Tab. 2 的 TP=8 配置意味至少 8 张 H100/A100 80GB 跑 Qwen3-Next 的 vLLM 部署,加上 baselines 对比和 3 类模型 × 6 长度 × 4 batch size 矩阵,估算单次完整复现需 200+ GPU-hours。难度:fused kernel 涉及 Triton/CUDA 编程、vLLM 调度器 hook、tensor parallel 通信原语,独立复现 kernel pipeline 需较强 GPU 系统编程经验;但精度对比(Tab. 1)只需 HuggingFace Transformers 加作者提供的 token scoring 函数即可重现。综合可复现性约 6/10:算法清晰、数据公开、但算力门槛高、kernel 实现细节多。