北大MapFlow：注意力图跨模型复用，prefill延迟降15%–20%

让模型 A 做规划、模型 B 去细化和总结，难题交给强模型、简单任务丢给轻量模型——多模型协作这条路，能让 AI Agent 应用在效果和成本之间找到平衡。

可一旦 Agent 之间、模型之间开始交接，就有一笔重复计算的开销藏在里面。上一轮大模型刚啃完一份长文档，下一轮小模型接手，往往还得把同样的内容再算一遍。数据库结构、工具说明、对话历史、任务背景……这些反复冒出来的上下文，换了模型之后就又成了新的 prefill 负担。

那么，一个模型已经算完的东西，能不能帮另一个模型更快地处理同一份上下文？

北京大学数据与智能实验室（PKU-DAIR）苗旭鹏助理教授团队给出的答案是 MapFlow。他们把注意力图当作跨模型复用的中间状态，靠轻量映射、稀疏压缩和融合 GPU 内核，让规模不同的模型共享已经算出来的 token 依赖关系。

论文评测显示，MapFlow 在所测任务上保住了生成质量，同时把 prefill 延迟压低了 15%–20%；在多轮对话路由场景下，相同 P90 首 token 延迟约束下，吞吐量最多提升 25%。相关论文已被 SIGMOD 2027 录用，代码也已开源。

• 论文标题是《Accelerating Cross-Model LLM Inference via Attention Map Reuse》。可问题是，一旦换了模型，先前算好的缓存为什么就很难接着用？

• 论文链接：https://arxiv.org/abs/2610.14688

• 项目代码：https://github.com/PKU-DAIR/MapFlow

大模型动笔回答之前，得先把输入上下文过一遍，这个阶段叫 prefill。输入越长，算力开销往往越大，用户等第一个 token 的时间也就跟着被拉长。前缀缓存已经能省掉一部分重复计算：同一个模型再次碰到相同前缀时，此前生成的 KV Cache 可以直接拿来用。多轮对话里的历史消息、多个请求共用的系统提示词，都能靠它省事。

不过，跨模型时麻烦就来了。KV Cache 跟模型自己的参数和内部表示绑得很死。两个模型就算处理一模一样的文字，层数、注意力头数、隐藏维度也可能各不相同，产出的 KV 状态天生就对不上。

结果就是，多模型系统能在任务层面分工，底层的计算结果却还是共享不了。小模型接手大模型攒下的长上下文时尤其明显：模型一换，prefill 就得重做一遍，原本指望的效率收益被削掉一块。

MapFlow 把目光挪到了另一种中间状态上——注意力图（Attention Map）。换句话说，它要做的，是从内部表示转向 token 与 token 之间的依赖关系。

注意力图记录的是一个 token 在计算时给其他 token 分了多少注意力，它的两个主要维度对应输入里的 token 位置。这就给跨模型复用提供了一个现成的对齐依据：只要两个模型用的是同一套 tokenizer、处理的是同一段上下文，注意力图里的位置就能一一对上。模型内部的向量表示即便不同，它们对文本依赖关系的刻画仍可能藏着可用的相似性。

打个比方，两个人读同一份材料，各自脑子里的理解并不一样，但多半会盯住相同的关键段落和上下文联系。后读的那个人如果能看到前一个人标出来的这些联系，自己的处理就能快一些。

MapFlow 要复用的就是 token 之间这层注意力结构，接收模型照样用自己的 Value 表示和后面的计算，产出自己的结果。当然，不同模型的注意力图彼此有差别，为了不让复用失效，MapFlow 把部分重计算和轻量映射结合了起来。

具体做法是：接收模型先照常算完前若干层，把自己的隐藏状态建起来；到了后面适合复用的层，再把发送模型的注意力图映射过来。层映射管的是不同深度的对应，头映射则靠学习线性组合去适配不同的注意力头。

整个训练只动映射权重，两个大模型的原始参数全程冻结。论文给出的 Ministral3-8B → 3B 配置里，新增权重占接收模型参数量的比例不到 0.001%。映射关系靠离线校准得到，之后就能用于源源不断到来的在线请求。

想让复用真的省下时间，存储和执行这两关也得过

注意力图能迁移，不代表把它缓存下来就一定划算。最直接的一道坎是体积：完整注意力矩阵的大小随序列长度平方增长，每层每个头都存稠密矩阵的话，长上下文很快就把存储撑满。读取和转换这些状态的开销，还可能把省下来的计算时间又吃回去。

围绕这个难题，MapFlow 设计了三个互相配合的系统组件。头一个是按重要性保留稀疏块——注意力本来就不是均匀铺在所有位置上的，MapFlow 依据累计注意力概率挑出重要区域，把注意力图压成块稀疏格式；采用规则的二维块，后续访问和计算也更适合 GPU 来跑。压缩分阶段进行，先算块级统计再提取保留块，不必先生成完整的稠密注意力矩阵。

第二块是共享前缀缓存怎么管。不同层、不同位置留下的稀疏块，数量并不一样。MapFlow 给这些状态建了前缀哈希索引，索引里带着前序上下文的信息，接收模型据此定位到对应的缓存块；取缓存的动作，则跟前几层的重计算叠在一起跑。同一份发送端状态，也能同时供多个下游模型使用。

第三块是映射和 Value 聚合放到一起算。要是先把接收模型的完整注意力矩阵还原出来，再拿它乘 Value，中间数据又会堆起来。MapFlow 的融合内核换了条路：直接读稀疏块，在片上把各个注意力头做线性组合，紧接着乘上接收模型的 Value、累加出结果，显存读写和中间张量开销都省了。

这套系统已经进了 vLLM，其中融合检索内核用 Triton 写，PagedAttention、Chunked Prefill、变长序列打包这些机制都在支持之列。

实验部分看两件事：prefill 能不能更快，在线吞吐能不能更高。

测试环境用的是 NVIDIA A800 80GB GPU，Qwen3 和 Ministral3 两个模型家族都上了，模型配对有四组不同规模，任务覆盖问答、对话和摘要。

先看 prefill 延迟和质量的取舍。跟完整 prefill 比，MapFlow 把延迟压低了 15%–20%，对应评测任务里的生成质量没有掉；跟 FlexPrefill 比，在质量持平或更好的配置下，prefill 延迟又少了 7%–12%。

再看多轮对话路由。团队拿 LMSYS 和 ShareGPT4 的对话数据搭出模拟路由负载，在同样的 P90 首 token 延迟约束下，MapFlow 的请求吞吐量最多涨了 25%。这多出来的是在线服务能力——响应时间要求不变，系统能接的请求更多了。

三个模型串联的工作流也测了：14B 模型管规划，8B 和 3B 分别做细化和总结，两个下游模型共用 14B 产出的注意力状态。结果是每轮工作流省下 0.48–0.73 秒，端到端加速最高 5.4%。

给多模型协作添一层计算复用

从模型路由到 Agent 工作流，多模型系统既要定下谁来处理任务，也得应付模型交接时反复出现的重复计算。

注意力图能当跨模型的中间状态用，这是MapFlow给出的思路。模型和模型之间，传的不只是文本，对同一份上下文算好的依赖关系也能接着用。映射、压缩、缓存管理、融合执行这几步走下来，这份复用得已变成实打实的延迟下降和吞吐提升。

一次上下文计算，供后面多个模型共用。在MapFlow看来，高效多模型推理可以往这个方向走。