如果你手头同时维护着两个不同规模的 LLM 服务，比如一个 7B 模型负责日常问答，一个 13B 模型负责复杂任务，你大概率会遇到这样的场景：用户把同一段很长的 prompt 先发给 7B，然后又切到 13B，两个模型都完整跑了一遍 prefill。GPU 空转还在其次，真正让人难受的是，KV Cache 明明已经在 7B 里算好了，却因为模型参数不同，13B 一个都用不上，一切从头再来。
跨模型 KV Cache 复用，听起来像是一个“缓存命中策略”问题，实际上比同一模型内的缓存复用难得多。标题里提到的“Cross-Model KV Cache Transfer”和“Closed-Form Linear Mapping”就是想解决这件事：把源模型的 KV Cache 通过一个闭式线性映射，转换到目标模型能直接使用的状态，从而省掉目标模型的 prefill 阶段。这个方向如果成立，模型大小的切换、多模型路由、甚至模型升级，都可以少付一笔可观的重复计算成本。但它到底能不能落地、适合什么场景、有哪些坑，值得先把原理和边界拆清楚。
1. 先搞清楚 KV Cache 复用的“表层省时”和“底层问题”
1.1 KV Cache 省下的不是推理，而是重复计算
在 LLM 推理里，token 是逐个生成出来的。第一个 token 的处理阶段叫 prefill，它会把整个输入 prompt 并行过一遍模型，计算出每个 token 的注意力键值矩阵，也就是 K 和 V。真正生成的阶段叫 decode，每生成一个新 token，只需要计算它的 Q、K、V，再和之前缓存下来的 K、V 做注意力计算。
所以 KV Cache 的本质，是把“已经计算过的历史状态”保存下来，避免 decode 阶段把整个历史重新算一遍。它省掉的是重复的矩阵计算，不是推理本身。在这种情况下，同一个模型的 KV Cache 复用已经非常成熟：多轮对话里，上一轮的 KV Cache 直接用于下一轮；长文本分段处理时，前缀部分的 KV Cache 也可以被复用。
1.2 跨模型复用时，困难不在缓存大小，而在“坐标系”
跨模型复用之所以难，是因为 KV 缓存不是一个可独立搬运的数据块。它本质上是在某个模型的参数空间里计算出来的中间表示。不同模型的词表、hidden size、层数、注意力头数、位置编码方式都不同，直接拿 7B 模型的 K、V 塞给 13B 模型，目标模型根本不知道这些向量是什么意思。
你可以把 K、V 理解成“用模型自己的语言对上下文做的摘要”。7B 写出来的摘要，13B 读不懂，因为两套参数的坐标系不一样。跨模型 KV Cache 传输要解决的，不是“把缓存搬运过去”，而是“把一种坐标系下的表示，翻译成另一种坐标系下的表示”。
这也是这个方向真正有价值的地方：它不是在缓存读写层面做优化，而是在表示对齐层面解决问题。一旦能够在两个模型之间建立可用的映射，KV Cache 就不再是某个模型专属的临时数据，而变成了一种可以跨模型流转的中间资产。
2. 闭式线性映射：跨模型 KV Cache 传输的核心思路
2.1 核心假设：同一家族的模型共享一份“抽象空间”
为什么可以尝试用线性映射去做跨模型 KV Cache 传输？关键假设是：同一家族的不同规模模型，比如同一个预训练底座演化出来的 7B、13B，虽然参数量不同，但它们在某种程度上共享了相似的抽象表示空间。
这种共享不是完全一致的，但可能在局部存在近似线性关系。也就是说，源模型某一层的 KV 表示，经过一个线性变换之后，能够逼近目标模型对应层的 KV 表示。这个假设并不总是成立，但在模型结构相似、训练数据相近、分词器一致的前提下，它是一条值得验证的路径。
闭式线性映射的好处在于：它不引入额外的非线性参数，也不需要像训练一个小神经网络那样做大量迭代优化。只需要在一些配对样本上估计出一个映射矩阵，然后直接应用到新的 KV Cache 上。这在真实推理场景里更容易落地，因为映射本身的开销可控，不会在请求链路上增加太多时延。
2.2 映射矩阵怎么来：最小二乘或岭回归
假设源模型的 KV Cache 记为 K_s、V_s，目标模型对应的 KV Cache 记为 K_t、V_t。我们希望找到一个线性映射矩阵 W，使得：
K_t ≈ W K_s
这个目标可以直接用最小二乘来求解。为了避免过拟合，通常会在对角加上一个正则项，变成岭回归问题。如果只看 K 矩阵，求解形式大致是：
W = (K_s^T K_s + λI)^(-1) K_s^T K_t
其中 λ 是正则化系数，控制映射矩阵的复杂度。V 矩阵的映射可以单独估计，也可以和 K 共享同一种求解方式。实际工程里，因为 KV 矩阵往往很大，通常不会直接对整个矩阵做一次全局求解，而是按注意力头、按层分别求解映射矩阵，这样既容易并行，也更容易定位是哪一层映射效果差。
下面是一个简化后的估计流程示例，用来帮助理解整体思路：
import numpy as np def estimate_mapping(source_kv, target_kv, alpha=1e-3): """ source_kv: shape (num_samples, hidden_kv_dim) target_kv: shape (num_samples, hidden_kv_dim) 返回线性映射矩阵 W """ A = source_kv.T @ source_kv B = source_kv.T @ target_kv W = np.linalg.solve(A + alpha * np.eye(A.shape[0]), B) return W这个示例假设源和目标已经做了 token 级和 head 级对齐。实际使用时，要先确保两条 KV Cache 的 token 顺序、层索引、注意力头索引一一对应，否则估计出来的映射矩阵没有意义。
2.3 对齐细节：层数、hidden size、词表和位置编码
真正让映射变得复杂的是各种维度不对称。不同规模的模型可能有不同的层数、不同的注意力头数、不同的 hidden size，甚至不同的词表。下面这张表列了常见的不对齐情况和基本处理思路：
| 不对齐项 | 影响 | 常见处理思路 |
|---|---|---|
| 层数不同 | 无法直接按层索引对应 | 手工设计层映射关系，或使用相似度搜索为每层找最近源层 |
| hidden size 不同 | K/V 向量维度不一致 | 在线性映射矩阵中加入维度投影，让源维度映射到目标维度 |
| attention head 数量不同 | 多头注意力结构不一致 | 按 head 分别估计映射，或者在 head 维度做 reshape 对齐 |
| tokenizer/词表不同 | token 切分不一致，KV 数量对不上 | 需要对 token 做重对齐，或选择同源 tokenizer 的模型组合 |
| 位置编码不同 | token 的位置语义不一致 | 只有位置编码方式相似的模型可以复用，否则建议直接放弃 |
这些细节决定了映射不是简单的一步矩阵乘法。你必须在设计实验之前，先想清楚两个模型的哪些部分是“可对应”的。很多看起来合理的模型组合，可能因为位置编码方式的细微差异，导致映射后的 KV Cache 质量明显下降。
3. 如何从零构建一个可验证的跨模型缓存映射流程
3.1 选择模型和数据集
先别想着一步到 bit 做到跨家族、跨架构的通用映射。最稳妥的起点，是选同一家族里结构尽可能接近的两个模型。比如你选了某个系列的两个不同规模版本，它们如果共享 tokenizer、共享位置编码方式，层数接近，那么验证成本会低很多。
这里有一个经验：不要一开始就用随机数据跑全量映射。先准备一组覆盖不同业务场景的样本，建议至少包含短文本、长文本、代码、数学推理、多轮对话等常见输入类型。数量上可以先从几百条开始，重点看映射趋势，而不是追求一次性达到生产级效果。
数据集还有一个容易忽略的点：合规性。用来估计映射矩阵的数据，会间接成为服务的一部分。如果数据里包含用户隐私或未授权内容，映射矩阵本身就可能带入数据风险。所以在项目启动阶段，就要把数据来源和授权边界梳理清楚。
3.2 最小验证链路：单层映射到全模型
一个最容易起步的验证方式是：先把整个模型的 KV Cache 传输拆成“单层映射验证”。只挑中间一层，比如第 10 层的 K 和 V，在配对数据上估计映射矩阵，然后用没参与训练的样本验证映射结果。
验证维度至少有三个：
- 映射后的 K/V 向量和目标模型真实 K/V 的余弦相似度；
- 用映射后的 KV Cache 代替真实 KV Cache，目标模型生成的输出是否和真实输出接近；
- 端到端下游指标，比如推理问答准确率或代码通过率，是否掉点。
如果单层映射效果很差，就不要急着扩展到全模型。先排查对齐是不是有问题，比如 token 顺序、层对应、数据范围差异过大。如果单层效果尚可，再扩展到所有层，最后再做全链路集成。
3.3 集成到推理服务的基本结构
当映射矩阵已经准备好，真正接入推理服务时，流程大致是：
- 用户请求先被路由到源模型，源模型 prefill 后产出原始 KV Cache；
- 系统把原始 KV Cache 保存到缓存层，不立即丢弃；
- 当同一请求需要由目标模型处理时，从缓存读取源 KV Cache；
- 对 KV Cache 执行映射转换，变成目标模型可用的格式；
- 目标模型跳过 prefill，直接使用转换后的 KV Cache 进行 decode。
流程看起来直接，但要注意一点：映射本身也有计算开销。如果 prompt 很短，比如只有几十个 token，重新 prefill 一次可能比映射一遍更快。只有当 prefill 消耗明显大于映射开销时，这个方案才划算。
4. 边界与坑点：哪些情况下能复用，哪些情况下不如重新 prefill
4.1 可以尝试复用的场景
跨模型 KV Cache 传输最值得尝试的场景，不是“每个请求都跨模型”，而是“同一个模型家族内不同规模模型之间的切换”。
典型例子是系统提示词或长固定前缀。如果业务里所有请求都带一段很长的系统指令，而不同模型服务于不同等级的用户，那么这段公共前缀的 KV Cache 就能被反复利用。这时只需要对前缀部分做一次映射，整段前缀的 prefill 成本就省下来了。
另一个相对友好的场景是多模型 A/B 实验。同一个 prompt 需要分别发给 7B 和 13B 做结果对比，如果跨模型映射质量达到可接受水平，实验平台可以减少一半的 prefill 开销。
4.2 不建议复用的场景
跨模型 KV Cache 传输并不适合所有组合。
跨家族模型通常不建议尝试。不同家族的词表、训练数据、架构细节差异太大，线性映射假设很容易失准。勉强做出来，映射矩阵可能非常大，但效果还不如重新 prefill。
极端长文本场景也要谨慎。长文本下 KV Cache 本身占用很高，映射矩阵乘法的计算量随 token 数增长，误差也更容易在多层传递后累积。如果遇到几万 token 的上下文，直接重新 prefill 可能更稳定。
还有一种情况是 prompt 非常短。比如用户只发了一句“你好”，prefill 本身耗时很低，映射的固定开销反而可能超过 prefill。这种场景下，跨模型映射毫无收益。
4.3 工程上最容易踩的三个坑
第一个坑是精度和存储。KV Cache 在生产环境里通常会用 BF16、FP16，甚至量化到 INT8 来节省显存。映射矩阵乘法会把数值误差继续放大。特别是经过多层映射后，早期层的误差会传导到后续层，最终生成结果可能看起来没问题，但语义已经偏移。建议在做可行性验证时，至少对比一次 FP16 和量化条件下的效果差异。
第二个坑是版本漂移。模型权重如果做过微调、合并、或重新导出，之前的映射矩阵可能就失效了。尤其是当源模型和目标模型都经过 fed 不同版本迭代时，映射矩阵必须记录对应的模型版本。否则线上出现莫名其妙的输出质量下降，排查起来会很痛苦。
第三个坑是评估偏差。很多人看到“能生成”“没有报错”就以为映射成功了。实际上，KV Cache 映射只保留了近似信息，生成的文本可能流畅，但事实性、逻辑性都出现了隐性衰减。因此评估环节必须包含有明确正确答案的任务，而不只是看生成文本是否通顺。
5. 一个可复用的跨模型缓存复用评估框架
5.1 三层判断标准：有效性、一致性、稳定性
面对一个新方案，我习惯用三层标准去判断它是否值得继续投入。
第一层是有效性。映射后的 KV Cache 是否真的能让目标模型跳过 prefill 并正常生成？如果不能，后面的优化都没有意义。
第二层是一致性。使用映射后的 KV Cache 和使用真实 KV Cache，目标模型的输出差异是否在可接受范围内？一致性不是要求完全一样，而是要求关键任务指标不明显掉点。
第三层是稳定性。在不同长度、不同领域、不同批大小的条件下，映射效果是否稳定？有的方案在短文本上表现很好，一旦输入变长就开始崩溃，这种方案很难线上使用。
5.2 评估维度表
| 评估维度 | 观察对象 | 可接受的临界判断 |
|---|---|---|
| 向量相似度 | 映射后 K/V 与真实 K/V 的余弦相似度 | 不等于判断标准，只用于早期筛查 |
| 生成困惑度 | 目标模型映射后生成文本的困惑度 | 和真实 KV 的差距不宜过大 |
| 任务准确率 | 问答、分类、代码生成等具体任务指标 | 掉点范围需要结合业务容忍度 |
| 端到端时延 | 映射开销 + decode 开销 vs 重新 prefill + decode | 有明确正收益才值得上线 |
| 存储占用 | 原始 KV Cache + 映射矩阵的额外存储 | 不能比直接保存目标 KV Cache 更大 |
| 长文本扩展 | 不同 prompt 长度下的效果趋势 | 越长越差时需要设置长度上限 |
实际执行时，不建议把所有指标一次性跑齐。先跑向量相似度和端到端时延，这两个指标能快速判断方案是否值得继续。
5.3 落地前的检查清单
在把跨模型 KV Cache 传输放进生产环境之前，至少确认下面这些点：
- 模型版本是否固定，映射矩阵是否和模型版本锁绑定；
- 缓存存储格式是否支持源 KV Cache 的读取和重映射；
- 映射过程是否加入日志，能否在效果异常时快速定位是哪一层映射出问题；
- 是否设置了降级策略，一旦映射后生成质量下降，能够自动回退到重新 prefill；
- 是否评估过引入数据合规风险，映射矩阵本身是否会泄露训练数据或用户数据。
这份清单看起来琐碎，但每个点都可能导致线上故障。
6. 先跑通一条最小链路，再讨论规模化
6.1 最小落地路径
如果你想真正验证这个方向，我的建议是先跑通一条最小链路，不要一开始就设计成完整的可复用平台。
第一步，选一对结构最接近的模型，准备 200 条左右有代表性的 prompt 样本。
第二步，只对中间一层做映射矩阵估计，在测试集上验证这层的 K/V 相似度和生成效果。如果效果太差，先检查对齐问题。
第三步，扩展到全部层，评估端到端时延收益。
第四步，如果前几步都通过了，再考虑接入缓存系统和路由策略。
这样一个流程能帮你用比较低的成本判断：这个方案在你的模型组合里，到底是一场值得投入的优化，还只是论文里的漂亮思路。
6.2 这个方向真正改变的是什么
跨模型 KV Cache 传输如果最终能稳定工作，它改变的不只是“少跑一次 prefill”。它让 KV Cache 从“和某个模型强绑定的临时数据”变成“可以被翻译和迁移的中间表示”。这意味着模型的升级、切换、A/B 评估，都可以少支付一次重复理解输入的成本。
从长期看，这可能是推理系统架构演进的一部分。未来服务里未必只有一个模型，而是多个模型共享同一份语义上下文。谁先能把上下文表示在一个统一空间里管理好，谁就能让多模型服务的切换更便宜、更快速。
6.3 最后提醒
不要被“跨模型缓存复用”这个概念冲昏头。它确实有吸引力，但它的成立依赖很多条件：模型结构相似度、token 对齐成本、映射矩阵维护成本、实际时延收益。对一个工程团队来说，最稳妥的做法不是全面铺开，而是先问三个问题：
映射之后，生成质量能不能接受？
映射的开销，是否真的小于重新 prefill 的开销？
映射矩阵和数据链路，能不能长期维护？
在回答完这三个问题之前，它更适合作为一个低成本预研方向，而不是默认的推理加速方案。把单层验证跑通，用真实数据说话，这才是把一个研究想法变成工程能力的第一步。
