做多模型路由和混合推理时有个很常见的浪费一段很长的上下文已经被小模型完整读过一遍等大模型接手时它却必须从头再读一遍。大模型推理里的“从零开始读一遍”指的就是 Prefill 阶段。这段计算与 Prompt 长度成正比长上下文场景下它消耗的时间常常比后续生成答案还多。KV Cache 本来就是为了避免“重复读”而存在的。你把已读过的 Token 对应的 Key、Value 缓存下来后续生成时不用重新计算。但 KV Cache 是模型私有的层数、头数、维度、位置编码方式都不同7B 模型的缓存塞给 13B 模型大概率是维度不匹配即使强行塞进去语义空间也对不上。所以当我看到 “Cross-Model KV Cache Transfer in LLM Families: A Closed-Form Linear Mapping for Prefill Reuse” 这个研究方向时第一反应是它终于把“缓存复用”从一个模型推到了同一个模型家族。核心判断非常直接同一家族内不同规模的模型虽然维度不同但表示空间是近似对齐的。既然 KV Cache 本质是输入内容经过模型映射后的中间产物那么用一个闭式线性映射把小模型的 KV Cache 翻译成大模型的 KV Cache大模型就有可能跳过 Prefill直接从 Decode 开始生成。这篇博客的目标读者不是只想跑通一个 demo 的人而是想理解 “KV Cache 为什么是模型私有的”“跨模型缓存迁移为什么可行”“闭式线性映射到底在解什么数学问题” 的工程师。我会先讲清 Prefill 和 KV Cache 的基本原理再拆解跨模型 KV Cache 传输的定义然后用教学代码演示一个最小二乘闭式解最后讨论它和 KV 压缩、模型蒸馏、LoRA 等方案的区别以及真正落地时有哪些限制。1. 这篇文章真正要解决的问题1.1 Prefill 阶段是大模型推理的隐形瓶颈大模型文本生成分为两个阶段这一点理解清楚了后面很多问题都能顺下来。Prefill 阶段把用户输入的 Prompt 全部 Token 一次性通过 Transformer 各层得到第一个输出 Token。这个阶段是计算密集的计算量与输入长度近似呈平方关系因为每个 Token 都要和它之前的所有 Token 做注意力。Decode 阶段逐个生成后续 Token每步只生成一个新 Token但需要读取历史 KV Cache。这个阶段是访存密集的速度受显存带宽和缓存容量限制。从用户感知看长 Prompt 场景下“等到第一个字出现”的延迟主要由 Prefill 决定。这也是为什么很多推理引擎在调度器里会把 Prefill 和 Decode 分开排队、分开算力分配。如果 Prompt 有 2 万 Token即使矩阵运算是并行的也需要很大的算力开销和显存占用。KV Cache 就是为了让生成阶段不重复算历史 Token 的 Key 和 Value。可以这样理解没有 KV Cache 时每生成一个新 Token模型都要从头去看所有历史内容等于把一个 O(n) 的问题变成了 O(n²) 的反复计算有了 KV Cache历史内容被“记住”了新 Token 只需要做自己这一小步的计算。但有一个残酷的事实KV Cache 是模型私有的中间产物。你无法直接把 LLaMA-7B 的 KV Cache 塞给 LLaMA-13B 使用因为它们的层数不同、注意力头数不同、隐层维度不同。如果把它们理解为坐标那么同一个句子在不同模型里处于不同的“坐标系”一个坐标系的向量不能直接被另一个坐标系消费。1.2 多模型路由里重复 Prefill 的浪费再举一个真实的工程场景。假设你在做一个 Agent 系统用户传入一份很长的文档系统先用小模型做意图识别、信息抽取和上下文压缩经过小模型处理后把完整的上下文交给大模型生成最终回答。在这个流程里小模型已经对文档做过一次 Prefill等大模型拿到同一份文档时它又得从头再做一次 Prefill。如果文档长度是几万字这个重复计算的成本会非常可观。Cross-Model KV Cache Transfer 想解决的问题就是把这个“重复”减掉如果小模型在 Prefill 阶段已经产生了 KV Cache那么用一个线性变换把它翻译成大模型的 KV Cache大模型无需再算整个 Prompt而是直接基于这份“翻译后的缓存”开始 Decode 生成。换个角度说它降低的不是单次推理本身的算力而是在多个模型都要消费同一段 Prompt 时重复 Prefill 造成的额外成本。这就决定了它的适用场景同一条输入要被多个模型处理且源模型和目标模型属于同一模型家族。1.3 为什么强调“模型家族”跨模型 KV Cache 迁移有两种理解方式一种是随便拿两个 LLM 做迁移另一种是在同一个模型家族内做迁移。从标题看这里强调的是后者。模型家族通常共享这些特性相同的 Tokenizer 和特殊 Token 定义相近的训练数据分布和训练范式类似的 Transformer 结构只是深度和宽度不同相同的位置编码机制例如 RoPE。这些相似性意味着不同规模模型在相同语义位置的表示空间存在天然的近似线性对应关系。同一个句子在小模型某层的 K/V与大模型对应层的 K/V虽然向量长度不同但很可能表达的是同一个概念的两种“坐标”。这为线性映射提供了合理基础。反过来跨模型家族的迁移困难得多。比如从 LLaMA 到 Qwen即使 Tokenizer 看起来相近训练数据、缩放规则、模型结构差异都很大表示空间的对应关系会更复杂线性映射的精度会明显下降。1.4 哪些读者最应该关注这个方向正在设计多模型路由、级联推理、Agent 长上下文方案的技术负责人想降低首 Token 延迟、减少重复 Prefill 的推理服务开发人员对 KV Cache、缓存复用、表示空间对齐感兴趣的算法工程师。如果暂时不涉及推理优化这篇文章也能帮你把 KV Cache 的机制、Preflfill 和 Decode 的差异以及“模型表示”这个概念理解得更扎实。2. KV Cache 与 Prefill 的核心概念2.1 从注意力公式看 KV Cache 从哪来Transformer 的注意力公式是Attention(Q, K, V) softmax(Q K^T / sqrt(d_k)) V其中 Q 来自当前 TokenK 和 V 来自所有相关 Token。在自回归生成时生成第 n 个 Token需要和前面 n-1 个 Token 都计算注意力。如果不缓存每次都要重算这些 K、V如果缓存下来新 Token 只需要计算自己的 Q再读取历史 K、V 做注意力。KV Cache 的基本结构通常如下[layers, batch_size, seq_len, num_heads, head_dim]如果模型用了 GQAGroup Query Attention或 MQAMulti Query Attention那么缓存的实际是 num_kv_heads而不是 num_heads也就是 KV 头数量小于 Q 头数量。不同模型在这个细节上差异很大跨模型迁移时这往往是第一个需要对齐的维度。2.2 为什么 Prefill 昂贵Prefill 阶段要一次性处理整段 Prompt每个 Token 都要与更早的 Token 算注意力。虽然矩阵乘法可以并行但计算量仍然很大。更重要的是Prefill 阶段产生的 KV Cache 会一直保留到整个请求结束所以 Prompt 越长显存占用越高。有一个常见的误解KV Cache 是在减少计算而不是减少内存。它把“重新计算”的算力节省下来但代价是显存。正因为显存占用高KV Cache 的压缩和量化才成了一个大方向。2.3 跨模型 KV Cache 传输的严格定义设源模型为 S目标模型为 T。给定同一段 Prompt X源模型的 KV Cache 为 C_s {K_s^l, V_s^l}l 遍历源模型的层目标模型的 KV Cache 为 C_t {K_t^m, V_t^m}m 遍历目标模型的层。理想情况下存在一个变换 F使得C_t ≈ F(C_s)随后目标模型可以使用 F(C_s) 作为初始 KV Cache跳过 Prefill 阶段直接进入 Decode 阶段。如果目标模型生成的结果和它自己对 X 执行 Prefill 后生成的结果足够接近就说明 F 有效。这里要注意F 通常不是一个全局矩阵。不同层、不同注意力段可能需要各自的映射。它的本质是“表示空间对齐”不是把缓存文件做一次格式转换后再拼接的问题。3. 闭式线性映射为什么这件事可行3.1 从直觉到数学形式为什么线性映射是合理的想象同一条句子在两个同源模型中各自过一遍。因为模型来源于同一个家族在相似语义层中大模型和小模型对“东京”这个词的表示虽然在维度上不同但语义上是同一个概念。可以把这两个表示看成是同一个语义向量在不同基底下的坐标。如果这种“基底转换”近似线性那么就可以用矩阵 W 来建模vec(K_t) ≈ W × vec(K_s)其中 vec 表示重排或展平。这里的 W 就是线性映射矩阵。3.2 最小二乘与闭式解如果给定一批成对数据X [vec(K_s_1), vec(K_s_2), ...]即源模型的 KV 特征Y [vec(K_t_1), vec(K_t_2), ...]即目标模型的 KV 特征。我们希望找到一个 W让映射误差最小min_W || Y - X W ||_F^2 λ ||W||_F^2这里 λ 是正则化系数防止过拟合也保证矩阵求逆稳定。这个问题的解是一个闭式解W (X^T X λ I)^(-1) X^T Y这就是“闭式线性映射”的数学本质。它不需要迭代训练直接用线性代数库一步算出结果。3.3 为什么选择闭式解而不是训练一个神经网络从工程角度看闭式解有几个非常实际的优势参数少一个映射矩阵的参数量远小于一个小型 MLP不需要反向传播不依赖 GPU 做长时间训练离线可以一次性算好推理时只做一个矩阵乘延迟可忽略不容易过拟合线性模型本身就是最强正则化。缺点也很明显表达能力有限只能捕捉线性关系如果源模型和目标模型之间的语义对应关系具有明显非线性闭式线性映射会残留较大误差层与层之间可能需要很多个映射矩阵当模型家族成员很多时版管理会变复杂。所以后续评估的重点应该是“线性映射在各层的剩余误差”而不是只看某个全局误差很低。4. 与相关方案的关键区别跨模型 KV Cache 迁移和很多常见的方案容易混淆。下面用一张表梳理清楚。方案核心目标作用对象是否改变模型权重与跨模型 KV Cache Transfer 的关系KV Cache 压缩减小缓存显存提升解码速度同一个模型自身否可以叠加使用不解决模型间复用Prompt Cache / Prefix Reuse多个会话共享同一前缀避免重复 Prefill同一个模型多个会话否同一模型内的缓存复用跨模型迁移可以叠加模型蒸馏让小模型学习大模型行为两个模型训练阶段是训练期对齐而 KV Cache 迁移是推理期映射LoRA / Adapter在模型旁加低秩矩阵微调模型行为单个模型是改变模型权重KV Cache 迁移不改变任何权重Cross-Model KV Cache Transfer把一个模型的 KV Cache 翻译成另一个模型的 KV Cache源模型和目标模型否本文主题这张表说明一个关键点KV Cache Transfer 不做“模型训练”也不做“缓存压缩”它是在推理流程中增加一个轻量翻译层。5. 简化示例用线性最小二乘学习 KV 映射我先给一个不带深度学习框架重依赖的教学示例。这个示例不涉及真实模型而是用随机数据模拟“成对的 KV Cache 特征”重点演示闭式解的计算过程。5.1 环境准备Python 3.9 以上NumPy如果要在真实模型上提取 KV Cache会用到 PyTorch 和 HuggingFace transformers但这部分因库的版本差异较大这里只讲思路不绑定具体版本。5.2 核心代码# kv_mapping_demo.py import numpy as np def learn_linear_mapping(X, Y, lam1e-5): 学习从源模型特征 X 到目标模型特征 Y 的线性映射。 X: [num_samples, dim_src] Y: [num_samples, dim_tgt] 返回: W 形状为 [dim_src, dim_tgt] A X.T X lam * np.eye(X.shape[1]) B X.T Y W np.linalg.solve(A, B) return W def mapping_error(X, Y, W): pred X W return np.linalg.norm(pred - Y) / np.linalg.norm(Y) if __name__ __main__: np.random.seed(0) num_samples 200 dim_src 32 dim_tgt 48 X np.random.randn(num_samples, dim_src) # 构造一个“真实”的映射再加上一点噪声 W_gt np.random.randn(dim_src, dim_tgt) noise 0.01 * np.random.randn(num_samples, dim_tgt) Y X W_gt noise W_learned learn_linear_mapping(X, Y, lam1e-5) err mapping_error(X, Y, W_learned) print(W shape:, W_learned.shape) print(relative mapping error:, err) x_new np.random.randn(1, dim_src) y_pred x_new W_learned y_exact x_new W_gt print(predicted:, y_pred) print(exact :, y_exact)这段代码做了三件事构造一批源特征 X 和目标特征 Y两者确实存在线性关系用最小二乘闭式解学习 W在新的样本上测试映射效果。运行方式python kv_mapping_demo.py在构造数据下相对误差会接近 0说明线性映射能很好地恢复真实关系。真实场景中误差会大很多因为它要逼近的是两个模型之间的语义关系而不是一个随机生成的线性关系。5.3 真实模型中的 KV Cache 适配思路真实 KV Cache 的形状通常是[layers, batch_size, seq_len, num_kv_heads, head_dim]不能直接把整段缓存展平学一个巨型矩阵那样维度太大、数据量要求过高。常见做法是按层、按注意力段分别学习映射。伪代码如下# 伪代码逐层学习映射 for layer_id in range(num_layers_src): X_k collect_k_cache_source(layer_id) # 所有采样样本在源模型该层的 K Cache Y_k collect_k_cache_target(mapped_layer(layer_id)) # 对应目标层 W_k_map[layer_id] learn_linear_mapping(X_k.reshape(-1, dim_src), Y_k.reshape(-1, dim_tgt), lam0.01) # 推理时应用 k_cache_for_target apply_mapping(k_cache_source, W_k_map, layer_id)一个小提醒源模型和目标模型的层数往往不相等哪些层配对是一个需要设计的工程问题。如果完全按序号对应可能不是最优可以结合相似度搜索把语义最近的层配对起来。这也说明论文或工程实现中真正的难点不只是“最小二乘求 W”还有“如何构造训练数据”和“如何做层间对齐”。6. 运行结果与效果验证6.1 同一个模型内部验证最直接的验证方法是用目标模型自身在一批 Prompt 上做一次 Prefill得到真实 KV Cache R再用“源模型 KV 经过映射”得到 M。然后对比两套缓存的差异。指标可以分三层缓存空间误差||M - R|| / ||R||Logits 分布差异给定同一个新 Token模型基于 M 与 R 生成的 logits 是否接近下游任务效果回答质量、检索相关性、代码正确率等。只关注误差不够因为缓存空间误差低并不代表生成结果一致。更接近真实目标的是 logits 偏差和下游效果。6.2 Top-K 一致性检查一个简单有效的评估指标是 Top-K Token 重合率。用映射后的 KV Cache 让目标模型生成下一步 Token记录概率最高的 K 个 Token再换成真实 KV Cache同样记录 Top-K Token统计两者重合比例。import torch def topk_overlap(logits_real, logits_mapped, top_k10): top_real set(torch.topk(logits_real, top_k).indices.tolist()) top_map set(torch.topk(logits_mapped, top_k).indices.tolist()) return len(top_real top_map) / top_k这个指标能直观反映“映射后的缓存到底会不会让模型选错方向”。如果 Top-10 重合率低于 0.8我认为在生产环境里需要谨慎使用。6.3 失败时先查哪里如果映射效果不好优先检查这几项KV Cache 的层配对是否正确源模型和目标模型的位置编码是否一致采样数据是否太单一导致 X^T X 病态对 K 和 V 是否真的分开学习还是误用了同一个映射序列长度是否对齐矩阵乘法能否正常执行。7. 工程实践与落地建议7.1 适合的场景最能发挥价值的场景是级联推理。小模型先处理长输入完成分类、抽取、路由随后大模型负责最终生成。如果 KV Cache 映射足够可靠大模型就不需要重新读一遍长 Prompt首 Token 延迟能显著下降。另一个场景是模型规格切换。用户会话原本跑在 7B 模型上系统因为负载或质量要求希望切换到 13B 模型继续生成。如果两个模型同一家族且共享 Tokenizer映射缓存可以让切换后的对话无缝继续而不是让用户重新提交历史。7.2 不适合的场景Prompt 很短Prefill 开销本身可以忽略映射反而增加了复杂度和风险源模型和目标模型差异过大Tokenizer、位置编码、层语义都不一致对生成质量要求极高任何缓存误差都不可接受上下文极长且需要多轮迭代映射误差可能随生成过程累积。7.3 生产上线的注意事项把映射模型接入生产不能只做一个离线实验。以下几点建议值得收藏先离线评估再灰度。在线流量只能在“映射后的错率低于阈值”的前提下逐步放开保留回滚机制。如果不加映射也能工作应该把映射做成可动态关闭的开关建立版本管理。映射矩阵和模型版本强相关不要跨版本混用区分长短上下文。短上下文场景可能不需要映射长上下文场景才值得承担映射风险定期回归。用上线后真实用户数据抽样检查 Top-K 重合率和下游指标 如果指标退化及时切换回原流程。8. 主要局限与开放问题8.1 线性表达能力有边界闭式线性映射有一个显而易见的天花板它假设源模型和目标模型的表示空间存在近似线性关系。当模型规模差距很大或者训练数据的领域分布差异明显时线性假设未必成立。这时候更复杂的非线性映射会更好但代价是失去闭式解的低成本优势。这也意味着跨模型 KV Cache 迁移更适合作为“近似加速”手段而不是“无损等价变换”。对它最合理的定位是在质量和速度之间给多模型协作增加一个可调节的旋钮。8.2 位置编码与层配对问题RoPE 等位置编码的引入方式在不同模型上可能不同。如果两个模型采用的位置编码机制不一致KV Cache 的“坐标系”本身就存在本质差异线性映射很难解决。跨模型 KV Cache Transfer 成立的前提条件是两个模型使用相同或高度相似的位置编码机制。8.3 Tokenizer 对齐的重要性模型家族内部 Tokenizer 通常一致但不同版本间可能更新词汇表、增加特殊 Token。一旦 Tokenizer 不对齐同样的字符串会被切分成不同的 Token 序列KV Cache 的语义对应关系就被破坏了。不要小看这一点。很多“跨模型复用”的失败案例最终排查下来不是映射矩阵不够好而是数据还没有进入模型前序列长度和 Token 顺序就已经不一致了。8.4 推理引擎接入成本目前主流推理服务例如基于 PagedAttention 的 vLLM、TGI 等对 KV Cache 的管理非常内部化。要接入跨模型 KV Cache 映射至少需要做到在源模型推理结束时导出指定层的 KV Cache在 GPU 上或 CPU 上完成线性映射把映射结果注入目标模型的缓存管理器并正确处理显存分配和分页。这是架构层面的改动。如果只是做研究在 HuggingFace 模型中手动接管 KV Cache 会容易很多但要做生产级服务接入成本会明显高于算法本身的复杂度。8.5 数据依赖与积累误差闭式解依赖成对数据的质量。如果训练映射矩阵时用的数据主要是通用对话线上却用来处理代码仓库或金融文档效果可能明显退档。建议按领域建模、按场景采样。另外映射后的 KV Cache 不建议在多轮生成中长期累积。因为每一轮新 Token 的 KV 都是基于“映射后的误差”继续生成的误差可能像滚雪球一样放大。更适合的做法是在模型切换时用映射做一次“冷启动预热”后续仍然使用目标模型自身生成的 KV Cache 继续推理。9. 总结与后续学习方向从标题到技术拆解可以这样理解 Cross-Model KV Cache Transfer in LLM Families它把 KV Cache 从“模型私有”变成了“同一家族内可翻译”的资源数学基础是最小二乘闭式解应用场景是多模型协作中的重复 Prefill 消除。如果你决定深入研究这个方向建议按下面的路线走先用 PyTorch 手工实现一个不带缓存的自回归 Transformer理解 QKV 的计算与缓存流程再在同一模型家族中选两个规模不同的模型用 Hook 提取成对 KV Cache用本文的最小二乘闭式解学习映射矩阵量化对比缓存空间误差、Logits 偏差和下游任务效果进一步对比线性映射与更复杂的 MLP 映射确认线性的边界在哪里。最后提醒一句不要在一开始就把这个方案放到生产系统里。先在离线评测中确认“映射后的 KV Cache 能让目标模型稳定生成”再逐步灰度。跨模型缓存复用是非常新且实用的方向但它还没有成熟到可以无条件信任的程度。如果你正在设计多模型路由方案或者正在被长上下文重复 Prefill 折磨你至少可以把“SV Cache Transfer”当作一个备选项理解它的边界之后再决定值不值得为你的场景引入这层映射。