北大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 位置。

这就给跨模型复用提供了一个自然的对齐基础：两个模型用相同 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 延迟与质量怎么权衡？MapFlow 比完整 prefill 少花 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 为高效多模型推理打开的一种可能。