北大团队推出 MapFlow 方案，它解决了现在多模型串联推理时的一大痛点，不同大模型之间切换上下文的时候，传统 KV 缓存没办法跨模型直接复用，只能把全部上下文重新跑一遍 prefill 预填充，浪费大量算力和时间。MapFlow 不走复用 KV 缓存的老路，改成复用注意力图，注意力图记录的是 token 之间的依赖关系，这种依赖信息在不同异构模型之间更容易迁移，搭配轻量线性映射、部分重算、块稀疏压缩这些手段，既能减少预填充延迟，又基本不影响模型输出质量，适合多 Agent、模型路由、长上下文多模型接力这类场景。之所以之前 KV 没法跨模型共享，是因为 KV 缓存和模型的网络结构、头数、参数深度绑定，A 模型算出的 KV 放到 B 模型里完全不能用，市面上现有的前缀缓存方案基本都只能在同一个模型内部生效。MapFlow 的做法是上游模型跑完推理之后，把注意力图保存下来，而不是保存 KV；切换到下游另一个模型的时候，用线性转换层把注意力图适配到下游模型的层和注意力头，再配合少量局部重算补齐误差，还做了块级稀疏压缩降低显存占用，搭配融合检索内核加快读取速度。从实测结果来看，这套方案在异构模型配对、多轮路由任务里，端到端推理效率明显提升，文本生成效果和完整重算 KV 的基线差距很小，不用对原有大模型做微调，属于推理侧的加速方案。简单总结，MapFlow 换了复用对象，用注意力图代替 KV 缓存做跨模型上下文传递，绕开 KV 跨模型不兼容的难题，降低多模型接力推理的算力开销。
一、MapFlow 核心思路
- 放弃跨模型传递 KV 缓存，改为传递注意力图
- 注意力图代表 token 之间的关联依赖，跨模型迁移性更强
- 不需要修改基座大模型权重，属于推理服务层优化
- 适配异构模型，比如 Llama、Qwen 这类不同模型之间接力
二、MapFlow 关键技术组件
- 跨层、跨注意力头轻量线性映射：把上游模型的注意力图，转换成下游模型可以识别的格式
- 部分重算机制：只重新计算误差比较大的部分，不用全部重算，平衡速度和效果
- 块级稀疏压缩：长上下文场景下压缩注意力图，减少显存占用
- 融合检索内核：优化注意力图读取、加载的速度，降低 IO 开销
三、传统 KV 缓存和 MapFlow 的对比
| 方案 | 可跨模型复用 | 复用对象 | 缺点 |
|---|---|---|---|
| 传统 KV 前缀缓存 | ❌ | KV 缓存 | 和模型结构强绑定，换模型必须重算 prefill |
| MapFlow | ✅ | 注意力图 | 需要额外存储、转换注意力图，少量场景需要局部重算 |
四、适合 MapFlow 的业务场景
- 多 Agent 工作流，多个模型轮流处理同一套对话上下文
- 模型路由系统，根据子任务自动切换不同能力的大模型
- 长文档拆解推理，先用小模型做摘要，再交给大模型深度处理
- 工具调用链，多个模型共享同一套系统提示词、工具描述上下文
五、当前开源情况
MapFlow 项目已经开源，代码托管在 PKU-DAIR 的 GitHub 仓库，研究者可以直接拿到代码做推理服务的二次改造，目前是论文阶段的原型系统，还没有集成到主流推理框架 vLLM、TensorRT-LLM 的官方版本里。
【相关 FAQ】
问题 1：MapFlow 为什么跨模型上下文交接不用重算 KV？
回答 1：MapFlow 不再复用 KV 缓存，而是复用注意力图，注意力图存储 token 依赖关系，更容易跨模型迁移，搭配线性映射和局部重算，跨模型上下文交接就不用完整重算 KV。
问题 2：MapFlow 的注意力图复用和普通 KV 缓存有什么区别？
回答 2：普通 KV 缓存和模型结构绑定，只能同模型复用；MapFlow 复用的是注意力图，重点保留 token 之间的依赖关系，支持异构模型之间传递上下文，规避 KV 跨模型不兼容的问题。
问题 3：MapFlow 会不会让跨模型推理的输出质量变差？
回答 3：MapFlow 搭配部分重算机制校正误差，在实验里跨模型注意力复用之后，生成质量和完整重算 KV 的基线差距很小，适合大部分多模型接力场景。
问题 4：MapFlow 需要重新训练大模型吗？
回答 4：不需要，MapFlow 是推理侧的加速方案，不用微调基座模型，只在推理服务链路里做注意力图的存储、转换和复用。
【参考资料】
[2026-10-14]（MapFlow：跨模型复用注意力图加速 LLM 服务）沙丘社区
[2026-10-10]（Accelerating Cross-Model LLM Inference via Attention Map Reuse）arXiv
[2026-10-10]（北大 DAIR 团队 MapFlow 开源，跨模型注意力图复用）GitHub
【免责声明】
本文为公开论文、开源项目信息整理，MapFlow 属于学术原型方案，相关加速效果、适配能力以北大团队原始论文和开源代码实测为准；不构成线上生产环境直接落地部署建议，大模型推理性能受硬件、模型组合、上下文长度影响，实际收益存在波动。