LLM 请求前缀缓存命中率优化的架构设计分析

一、背景：Prompt 前缀缓存为什么重要

主流大语言模型推理服务普遍在服务端实现了 Prompt 前缀缓存机制。其基本原理是：当两个请求的 token 序列从起始位置开始存在一段完全相同的部分时，服务端可以复用该前缀对应的键值缓存，跳过这部分 token 的注意力计算，只处理后续新增的 token。

这一机制对 Agent 类应用尤为关键。一个典型的多轮 Agent 会话会触发数十次甚至上百次模型调用，而每次调用通常需要携带完整的对话历史、工具描述、系统提示词等上下文。如果请求与请求之间的大部分前缀保持一致，服务端就可以大幅减少重复计算。

具体收益体现在两个层面：

第一，输入计费显著降低。以包含长系统提示词和完整历史记录的请求为例，如果每次仅有末尾少量 token 发生变化，那么变化部分之外的输入都可以命中缓存。在很多按 token 计费的场景下，缓存命中的 token 通常采用更低的计费系数，整体输入费用可能降低一个数量级。

第二，首 token 延迟缩短。前缀缓存命中意味着服务端无需为已经计算过的前缀重新执行前向推理，计算起点后移到新增 token 的位置。对于上下文较长的请求，这一优化对响应体感的影响非常明显。

二、前缀缓存命中的前提条件

要理解如何提升缓存命中率，首先需要明确缓存命中的判定逻辑。服务端进行前缀匹配时，通常以 token 序列的字节级或词元级前缀为依据。也就是说，如果请求 A 的 token 序列是 [t1, t2, t3, t4]，请求 B 的 token 序列是 [t1, t2, t3, t5, t6]，那么 B 可以命中 A 的前三个 token。

这意味着一个关键事实：缓存命中的概率取决于请求序列之间前缀的一致程度。如果每一次请求的完整上下文中，前序部分都保持不变、只有末尾追加了新内容，那么理论上每一次请求都可以最大化地复用前一次请求的缓存。

反过来说，如果请求组装过程中存在任何“插入、删除、重排”操作，比如在历史记录中间插入了一条新的系统消息，或者对历史消息做了摘要压缩后再拼接，又或者对话历史的排序发生变化，那么前缀一致性就会被破坏，缓存命中率随之下降。

因此，前缀缓存命中率本质上是一个请求序列构造方式的属性，而非一个可以事后修补的独立优化点。

三、追加式日志：从数据结构层面保证前缀稳定

一种被验证有效的设计思路是将会话状态建模为追加式日志。所谓追加式日志，指的是会话中的每一条消息——无论来自用户、模型还是工具——都按照产生的时间顺序追加到日志末尾，已经写入的内容不会被原地修改或删除。

在这个模型下，第 N 次模型请求携带的上下文，实际上是同一份日志在不同时间点的两个快照。第 N 次请求看到的是日志从第 1 条到第 M 条的内容，第 N+1 次请求看到的则是日志从第 1 条到第 M+K 条的内容。两者之间的差异仅仅在于末尾新增了 K 条消息。

将这一性质映射到 token 序列层面，可以得到一个直接推论：当前请求的 token 序列必然是前一次请求 token 序列的一个前缀扩展。也就是说，前一次请求的完整 token 序列完整地出现在当前请求的开头，当前请求只是在其后追加了新的 token。

这一推论意味着，只要服务端保留了前一次请求的缓存，当前请求就可以全部命中，仅需对新追加的 token 进行计算。缓存命中率在结构上逼近理论最大值，而不需要引入任何额外的缓存管理逻辑、失效策略或键值设计。

四、纯函数投射：消除非确定性因素

仅有追加式日志还不够。从日志到最终请求报文的转换过程必须具有确定性，否则前缀稳定仍然无法保证。

这里涉及一个关键概念：消息投射函数。日志中存储的是结构化的消息记录，而发送给模型服务的请求需要被序列化为特定的文本格式或消息数组格式。这个从日志到请求的转换过程，本质上是一个函数。

如果这个函数是纯函数，即对于相同的输入日志前缀，始终产生相同的输出前缀，那么只要日志前缀未变，请求报文中对应的前缀部分就不会发生任何变化。这样，追加式日志带来的前缀稳定性才能完整地传递到最终的请求 token 序列上。

实际工程中，破坏纯函数性的常见因素包括：

在消息投射中嵌入时间戳或随机标识符。即便对话内容完全不变，这类动态字段会导致每次生成的请求报文在对应位置产生差异。如果动态字段出现在请求的前缀区域，整个缓存都会失效。实践中应避免在请求前缀范围内放置任何非确定性内容，或者将其移至请求尾部。

对历史消息进行摘要或改写。某些实现为了控制上下文长度，会定期对较早的历史消息进行压缩。这种操作会修改日志中已经存在的记录，等价于原地编辑，会破坏前缀的连续性。

根据当前状态动态调整系统提示词。例如根据当前时间、用户属性或运行环境拼接不同的系统提示段落。如果这些段落出现在请求的开头，任何变化都会导致全部缓存失效。

因此，纯函数投射的核心要求是：给定相同的前缀日志，生成的请求前缀必须逐字节一致。这不是一个性能优化建议，而是保证前缀缓存命中率的结构性前提。

五、架构推论的工程价值

上述设计的真正价值在于，将前缀缓存命中从“需要主动管理的优化目标”转变为“架构的结构性推论”。两者的区别在实践中非常显著。

当缓存命中率被视为需要管理的问题时，工程团队通常需要引入额外的机制：设计缓存键、管理缓存生命周期、处理缓存失效、监控命中率指标、排查未命中原因。这些工作不仅增加系统复杂度，还可能引入新的缺陷。

而当请求组装架构天然保证了前缀稳定性时，缓存命中不再是一个需要专门维护的状态。每一次请求的前缀与上一次请求的关系由数据结构和投射函数的性质直接决定，不依赖于任何外部状态或运行时决策。工程团队无需关心缓存是否存在、是否有效或何时失效——服务端的缓存机制会自然地在连续请求之间发挥作用。

这种设计还具有很强的可预测性。由于命中行为不依赖启发式规则或运行时条件，开发者可以在设计阶段就准确预判缓存表现，而不需要在部署后通过观测来反向验证。对于需要估算成本、规划容量的场景，这种可预测性具有直接的工程意义。

六、对请求组装实现的具体启示

将上述原则落到请求组装层的实现中，可以归纳出以下实践要点。

第一，会话日志只增不改。将对话历史、工具调用记录和系统事件统一建模为有序日志，所有新增信息一律追加到末尾。任何形式的原地修改——包括更新状态、修正错误、插入补充说明——都应该以新日志条目的形式表达，而不是覆盖已有条目。

第二，分离稳定前缀与易变后缀。请求中相对稳定的部分（如系统提示词、工具定义、历史对话）应集中放置在 token 序列的前部，而每次请求可能变化的内容（如当前查询、最新工具结果）自然位于后部。这样即使尾部内容发生变化，也不影响前缀部分的缓存有效性。

第三，保持序列化逻辑确定性。日志到请求报文的序列化过程不应依赖任何非确定性的运行时信息。如果确实需要包含时间戳或请求标识等动态字段，应确保它们不出现在可能参与前缀匹配的区域。

第四，警惕隐式的前缀破坏。某些看似中性的操作可能间接破坏前缀稳定。例如，根据消息角色动态调整模板格式、对超长历史进行截断或重排、在不同调用路径中使用不同的消息组装逻辑，都可能导致相同日志内容产生不同的序列化结果。

七、边界条件与适用场景

需要指出的是，这种架构设计并非适用于所有场景。它的核心假设是：连续请求之间存在大量可复用的前缀，且新增内容集中在尾部。在以下场景中，这一假设可能不成立：

并行分支场景。如果一个会话从某个节点分叉出多个并行子任务，每个子任务携带不同的分支上下文，那么同一个日志前缀之后会派生出多个不同的请求序列。这些请求之间共享前缀，但与线性追加模型下的连续请求关系不同，缓存命中率取决于服务端缓存管理策略对分支前缀的保留能力。

频繁插入或重排的场景。某些对话流程要求在历史记录中插入或修改消息，例如多参与者的协作编辑、带有后编辑机制的内容生成等。这类场景天然不适合追加式日志模型。

上下文窗口溢出后的处理。当日志长度超过模型上下文窗口限制时，必须对历史进行裁剪或压缩。此时前缀稳定性的前提被打破，缓存命中策略需要重新设计。常见的应对方式包括分段缓存、分层摘要或滑动窗口，但这些方案都引入了额外的复杂度。

对于上述场景，开发者需要在缓存命中率与功能需求之间做出权衡，而不能机械地套用追加式日志模型。

八、总结

Prompt 前缀缓存命中率的提升，最有效的方式不是在缓存层面做加法，而是在请求组装层面做减法。通过将会话状态设计为追加式日志、将消息投射实现为纯函数，可以让请求序列天然满足前缀扩展性质，从而在不需要显式缓存管理的前提下逼近理论上限的缓存命中表现。

这种将性能目标转化为架构结构性推论的设计思路，在更广泛的意义上也值得借鉴：当一个系统特性需要持续的人为干预才能维持时，往往意味着架构本身还有改进空间。与其不断修补，不如重新审视数据结构和数据流的设计，让期望的行为成为系统结构自然涌现的结果。