你给 AI 一份很长的报告，它迟迟不开始回答。这里的等待不全是因为模型“想得慢”。正式生成第一个字之前，模型要先读完整份材料，并建立内部缓存。这个阶段叫预填充（prefill），它直接影响首个 token 延迟（time-to-first-token，TTFT），也就是用户按下发送键后，要等多久才能看见回答开头。
稀疏注意力试图缩短这段等待：每个查询位置不再查看全部历史，只挑出一小部分重要内容，像查资料时只翻索引指向的页面。QUILT 关注的是更深一层的问题。即便已经少看了很多内容，芯片仍可能反复搬运、解压同一批数据。论文的思路很直接：既然相邻查询经常查到相同页面，就让它们一起查，别各自把同一摞资料搬一遍。
以下方法、测量和结果均来自 QUILT 论文作者的实验；目前没有第二个独立信源交叉验证。
少算之后，瓶颈变成了少搬
注意力计算会使用 KV——key 和 value，是模型读上下文时为各个位置生成的中间数据。处理长文本时，KV 数据通常放在芯片的高带宽显存 HBM 中，需要搬到片上存储后才能计算。为节省容量和带宽，系统还常把 KV 压成低精度格式；真正使用时，再执行反量化（dequantization），还原成可参与计算的近似高精度数值。
现有稀疏注意力内核通常按 query，也就是“当前这个位置要查什么”，并行处理。每个 query 独立取得自己选中的 KV，独立加载、反量化和计算。这样容易并行，却忽略了一个规律：相邻 queries 选出的 KV 往往高度重叠。
作者在 GLM-5.3 和 LongBench 长文本任务上测量发现，当两个相邻 queries 组成一组时，Qasper 与 GovReport 的所有模型层中，重叠率分别始终超过 85.91% 和 78.06%；第一层更超过 90.03%。如果仍让它们分头工作，同一份 KV 就会被从 HBM 搬入多次，也会被反量化多次。此时，省下来的注意力计算可能被重复的数据处理吃掉。
QUILT 因而把执行单位从单个 query 改成一组相邻 queries。组内共同需要的 KV 只加载、反量化一次，再供多个 queries 使用。它优化的不是模型“关注什么”，而是已经选好内容之后，芯片怎样更省事地完成工作。
先把共同清单找出来
一起处理的第一道难题，是快速拆分多个查询清单：哪些 KV 大家都要，哪些只属于某个 query。普通的集合求交可能需要循环、逐项查找和频繁分支。稀疏注意力本来已经把计算压得较小，如果整理清单本身太慢，复用所得的收益就会被抵消。
QUILT 为此提出 Shift-and-Compare Set Decomposition（SCSD，可理解为“移位比较式集合拆分”）。它先把多个 KV 索引清单拼接并排序。相同索引排序后会挨在一起，于是系统只需把序列向左、向右各错开一格，再做并行相等比较，就能找出交集与各自独有的部分。
这一步的巧处不在新的集合定义，而在执行形式。原本不规则的“这个编号是否也在另一张清单里”，被改写成排序、移位、比较和布尔运算。这些都是现代加速器擅长批量完成的规则操作。
作者还把 SCSD 塞进注意力计算的流水线。矩阵计算单元处理当前一段注意力时，通用向量单元同时准备后面要用的共享或私有 KV 清单。完整拆分任务还会被切成更小阶段，尽量填进向量单元原本空闲的时隙。论文称，这能让大部分集合整理开销不落在关键路径上。
共享不能只选一个尺度
相邻两个 queries 往往最相似，但只按两两分组，会错过更大范围的共同内容。反过来，一次把很多 queries 放进一组，只有“所有成员都需要”的 KV 才能共享，又会漏掉只在小组内部重复的部分。
QUILT 的 cascaded sharing（级联共享）同时使用多个尺度。默认先从 8 个 queries 的大组开始，提取全组共有的 KV；再把剩余清单拆成更小子组，继续寻找局部共享；最后才单独处理各 query 的残余项。像整理多人购物单：先统一购买八个人都要的东西，再处理四人、两人共同需要的东西，最后各买各的。
论文给出的示例中，不做共享需要处理 16 个 KV；固定按 2 个或 4 个 queries 分组，都要处理 10 个；级联共享只处理 8 个，恰好等于示例里不同 KV 的总数。这个例子用于说明机制，并不等于真实任务都会减少一半。
数据少了，硬件也未必跑得满
芯片通常以 tile（固定大小的数据块）为单位计算。一段共享 KV 即便只多出几项，也可能触发一个新的 tile；这个 tile 大半空着，时间却照样要付。QUILT 因此同时考虑共享量和 tile 利用率。
对于装不满的共享尾部，系统以 50% 为默认阈值：占用足够高，就补齐并在当前层处理；占用太低，就把尾部推到下一层，与更细粒度的任务合并。这种下推不改变计算语义，只是少共享一点，换取更满的 tile。
到了最末端，已经没有下一层可推。作者观察到，剩余的 query-specific tails（各 query 独有的尾部条目）大多位于原始 Top-K 排名末端，重要性分数较低。QUILT 会删去其中排名最低的一部分，避免再启动一个利用率很差的 tile。这是整套 tile-aware execution（感知 tile 的执行策略）中唯一的近似步骤。
它到底快了多少？
作者在 16 块 Ascend 910C NPU 上测试，每块配有 64 GB HBM，软件栈为 CANN 9.1.0。任务来自 LongBench，覆盖问答、文档摘要和代码生成；模型采用 GLM-5.3 与 DeepSeek-3.2，两者每个 query 都选择 Top-2048 个 KV。实验同时覆盖 tensor parallelism（把一次张量计算拆到多块设备）和 sequence parallelism（按序列维度拆分任务）。
对照基线是 OPS-Transformer 提供的优化稀疏注意力内核。作者把基线与 QUILT 接入同一个 XYServe 推理引擎，使调度、内存管理和运行环境保持一致，主要差别落在稀疏注意力内核。
在作者报告的最佳配置中，QUILT 将平均内核执行延迟最多降低 55.1%，将实际处理的 KV 数据量最多降低 55.9%；端到端 TTFT 最多降低 36.8%。这三个数字不能混为一谈：前两个描述注意力内核及其数据处理，第三个才是用户更直接感受到的首次出字时间，而且都只是“最高降幅”，不是所有任务的平均收益。
精度方面，作者比较了 21 个 LongBench 数据集。相对基线，DeepSeek-3.2 的平均绝对分数差为 0.75 分，GLM-5.3 为 0.42 分；对应的平均绝对百分比差异分别是 2.01% 和 0.90%。单项成绩有升有降，例如 DeepSeek-3.2 在 HotpotQA 上下降 1.45 分，在 Musique 上提高 2.71 分。因此，比起笼统地说“精度几乎不变”，更准确的表述是：作者测得总体差异较小，但不同任务存在波动。
为什么值得关注
QUILT 的意义不只是又做了一个更快的稀疏注意力内核。它指出，长上下文优化正在跨过一个分界点：当算法已经减少大量乘法后，真正拖慢系统的可能变成数据搬运、反量化，以及硬件小块没有装满。
它也展示了一种更贴近实际工作负载的设计方法。系统不再假设每个 query 彼此独立，而是利用它们真实存在的相关性；既关心“理论上少处理多少 KV”，也关心这些 KV 最终能否规整地装进硬件 tile。说白了，QUILT 不是继续削减清单长度，而是在重新安排多人如何共用同一份清单。
局限与未知
- 全部证据来自论文作者。实验集中在 Ascend 910C、CANN 9.1.0、两款模型与 LongBench；作者认为方法也适用于具有类似矩阵和向量流水线的 GPU，但材料没有提供 GPU 实测结果。
- 55.1%、55.9% 和 36.8% 均为最佳情形。现有材料未完整呈现不同上下文长度、任务及并行配置下的收益分布，不能据此推断任意部署都能获得相同加速。
- QUILT 唯一的近似步骤会裁掉低分残余 KV。21 项评测的总体差异较小，但个别任务仍有升降，实际应用是否可以接受，需要按任务判断。