跨模型上下文交接还要重算KV？北大提出MapFlow，让注意力跨模型复用

模型 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%。映射关系通过离线校准获得，随后可以用于持续到来的在线请求。

让复用真正省时，还需要解决存储和执行问题

注意力图具有可迁移性，并不意味着把它缓存下来就一定划算。

一个直接的难题是体积：完整注意力矩阵的大小随序列长度平方增长。如果为每一层、每一个头都保存稠密矩阵，长上下文很快就会带来巨大的存储压力。读取和转换这些状态，也可能抵消省下的计算时间。

主题：