跨模型上下文交接还要重算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%。映射关系通过离线校准获得，随后可以用于持续到来的在线请求。

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

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

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

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，在质量相当或更好的配置下，进一步降低 7%–12%的 prefill 延迟。

在多轮对话路由中， 团队使用 LMSYS 和 ShareGPT4 对话数据构造模拟路由负载。在相同 P90 首 token 延迟约束下，MapFlow 的请求吞吐量最高提升 25%。这一收益对应的是在线服务能力：系统能够在满足响应时间要求的前提下，处理更多请求。

在三个模型串联的工作流中， 14B 模型负责规划，8B 和 3B 模型分别负责细化与总结，两个下游模型共享 14B 模型产生的注意力状态。实验中，每轮工作流减少 0.48–0.73 秒耗时，端到端加速最高达到 5.4%。

为多模型协作增加一层计算复用

从模型路由到 Agent 工作流，多模型系统需要决定由谁处理任务，也需要处理模型交接时不断重复的计算。

MapFlow 展示了注意力图作为跨模型中间状态的价值：不同模型之间，除了传递文本，还可以复用对同一份上下文已经计算出的依赖关系。通过映射、压缩、缓存管理和融合执行，这种复用能够转化为实际的延迟与吞吐收益。

让一次上下文计算，为后续多个模型所用。这是 MapFlow 为高效多模型推理打开的一种可能。