简介：前缀复用是推理框架中一项关键优化能力。本文从概念定义、背景价值、核心组成、工作原理、典型场景、相关概念区别与使用注意事项等角度，系统拆解“重复前缀只算一次”的技术逻辑，帮助开发者理解其适用边界与选型意义。
前缀复用，在推理框架的语境下，指的是：当多个推理请求共享相同的前置输入片段时，系统对该片段只执行一次计算，并将计算结果缓存下来，后续请求直接复用缓存内容，而不必重复计算。
这里所说的“前缀”，通常不是任意长度的字符串，而是从输入序列起始位置开始的一段连续内容。它可以是一段系统提示词、一组少样本示例、一份文档上下文，也可以是多轮对话中保持不变的历史记录。只要这部分内容在多个请求之间完全相同，就具备被复用的条件。
从一个更技术的视角看，前缀复用本质上是一种以缓存换计算的优化策略。它利用了生成式模型在解码过程中的一个结构特性：模型对某个位置的计算结果，只依赖于该位置之前的内容，而不受之后内容的影响。因此，当一段前缀已经被计算过，后续任何携带相同前缀的请求都可以跳过这部分计算，直接从缓存中读取中间状态。
这个机制的价值不在于改变模型的行为，而在于降低推理的系统成本。它让同样的硬件资源在单位时间内能够承载更多请求，也让单个请求在携带长前缀时能够更快地返回首个结果。
要理解前缀复用为什么重要，需要先理解生成式模型推理的两个基本特征。
第一，生成式模型的推理过程通常分为两个阶段。在“预填充”阶段，模型需要读取并理解全部输入内容，生成对应的中间表示；在“解码”阶段，模型根据已有的中间表示逐token生成输出。预填充阶段的计算量与输入长度正相关，输入越长，计算量越大。
第二，在很多实际应用里，输入的“有效增量”远小于输入的“总长度”。一个典型的例子是：系统给模型设置了一段很长的角色说明和工作规则，真正的用户提问只有一句话。另一个例子是少样本学习场景，提示词中塞入了大量示例，而需要模型处理的新内容只占很小一部分。
这两点叠加，就产生了一个明显的浪费：每当一个新的用户请求到达，系统都会把那段很长的、不变的前缀重新计算一遍。这段计算消耗了大量计算资源，却并没有产生新的信息。对于服务提供方来说，这意味着更高的硬件成本和更低的吞吐；对于用户来说，这意味着更长的等待时间和更差的体验。
前缀复用要解决的，正是这个问题。它的核心判断很直接：如果一段输入在多个请求之间没有变化，那么与它对应的那部分计算就不应该被重复执行。
这种优化在多租户服务、Agent 工作负载和批处理场景中尤其重要。因为这些场景的共性特征是：前缀高度重复，请求频繁到来，计算资源相对紧张。在这类环境下，前缀复用的收益会被显著放大。
前缀复用不是一个孤立的算法，而是一套需要多个环节协同工作的机制。理解它的核心组成，有助于判断一个推理框架是否真正具备完整的复用能力。
第一个组成部分是前缀的识别与切分。 系统需要能够判断，两个请求的前面部分是否完全相同。这个判断通常发生在token层面，而不是原始字符串层面。因为两个在字符层面完全相同的文本，经过分词器处理后可能产生不同的token序列；反之，字符层面不同的文本也可能共享相同的token前缀。前缀识别必须基于token序列进行，才能保证复用是安全的。
第二个组成部分是中间状态的缓存管理。 被复用的并不是原始文本，而是模型在前向计算过程中产生的中间状态。这些状态通常以键值缓存的形式存在，占用显存或内存空间。缓存管理需要回答几个问题：哪些前缀值得缓存、缓存保留多久、缓存空间不足时优先淘汰哪些内容。一个只存不管的系统，在实际运行中很容易出现缓存命中率低或缓存膨胀的问题。
第三个组成部分是前缀匹配与状态恢复。 当一个新请求到来时，系统需要快速判断它是否命中了某个已缓存的前缀，并在命中后将缓存状态恢复到当前请求的执行上下文中。这个过程必须足够高效，否则前缀复用的收益会被匹配和恢复的开销抵消掉。
第四个组成部分是调度与资源分配。 在多请求并发的场景下，不同请求可能命中不同长度的前缀，也可能完全不命中。调度器需要根据请求的前缀命中情况，合理分配计算资源和缓存空间，避免某些请求因为复用而过度挤占其他请求的资源。
这四个部分共同构成了前缀复用的完整链路。缺少任何一环，复用机制要么无法工作，要么收益大打折扣。
前缀复用的工作过程，可以拆解为以下几个阶段。
第一步是前缀标准化。系统将输入的原始文本转换为token序列，并确定哪些部分属于可复用的前缀。在多轮对话场景中，这个前缀通常是从对话开始到当前轮用户消息之前的所有内容；在少样本场景中，前缀通常是所有示例加上固定的说明文字。
第二步是缓存查找。系统根据规范化后的前缀，在缓存中查找是否存在对应的中间状态。这个查找过程通常基于哈希或树形索引实现，以保证在缓存规模较大时仍能快速命中。
第三步是状态加载与续算。如果命中缓存，系统会跳过前缀部分的预填充计算，直接将缓存中的中间状态加载到计算设备上，然后从缓存对应的位置继续处理剩余的新输入。此时，模型看到的完整输入和未做优化时完全一致，但实际执行的计算量已经大幅减少。
用一段示意性的伪代码来表示这个过程：
请求进入：将输入转换为 token 序列识别前缀部分 prefix_tokens 和新增部分 suffix_tokens在缓存中查找 prefix_tokens 对应的中间状态 cache_state如果 cache_state 存在：加载 cache_state 到计算设备从 cache_state 对应位置继续计算 suffix_tokens返回完整计算结果否则：对 prefix_tokens 执行完整计算将计算结果写入缓存继续计算 suffix_tokens返回完整计算结果
这段伪代码展示的是最基础的逻辑。在实际系统中，还需要处理更复杂的情况：前缀部分命中、缓存并发读写、缓存跨请求共享时的隔离性、以及缓存内容因模型权重更新而失效等问题。
一个值得强调的点是：前缀复用对模型输出结果没有影响。它改变的是计算路径，而不是计算内容。复用前后，模型看到的输入序列完全一致，因此输出的概率分布也完全一致。这意味着前缀复用是一种无损优化，开发者不必担心它会影响生成质量。
前缀复用的收益大小，取决于前缀重复率和前缀长度在总输入中的占比。以下几个场景中，这两个条件通常同时满足。
多轮对话服务。 在一个对话会话中，系统提示词、对话历史和角色设定在每个新请求中都会原样携带。随着对话轮次增加，前缀长度持续增长，而每一轮真正需要新计算的内容只是用户刚输入的那一条消息。前缀复用可以将每个新轮次的计算量压缩到接近单条消息的长度。
基于固定提示模板的批处理。 如果开发者使用同一套提示词模板处理大量输入数据，比如对一批文档做分类、摘要或信息抽取，那么模板部分就是天然的可复用前缀。批量请求越多，复用收益越明显。
Agent 与工具调用。 在 Agent 工作负载中，模型需要在多个步骤中反复调用，而每一步都会携带完整的任务描述、历史工具调用记录和当前状态信息。这些前置内容在步骤之间高度重合，前缀复用可以有效控制每一步的预填充开销。
检索增强生成。 当外部检索系统将相关文档片段拼接到提示词中时，请求之间的系统指令部分通常是一致的，差异主要来自检索到的文档和用户问题。如果系统指令较为固定，复用可以有效降低这部分固定开销。
少样本推理。 少样本提示词中往往包含大量示例，而每个请求携带的示例可能是相同的。复用示例部分的计算结果，可以让每个新请求只承担实际待处理内容的计算成本。
前缀复用经常和一些相邻概念放在一起讨论，但它们之间有明确的边界。
前缀复用与提示词压缩。 提示词压缩的目标是减少输入长度本身，通过删除冗余内容或提取关键信息，让模型看到更短的输入。前缀复用不修改输入内容，它只是避免对相同内容重复计算。两者可以同时使用，但解决的问题不同：前者降低输入长度，后者降低重复计算。
前缀复用与批处理。 批处理是将多个请求合并到一起执行，以提高硬件利用率。前缀复用可以在批处理内部发挥作用，让同一批请求中共享前缀的部分一起受益。但前缀复用不等于批处理优化，它也可以作用于单个串行请求的连续调用。
前缀复用与语义缓存。 语义缓存通常指将模型的输出结果缓存起来，当后续请求在语义上相似时直接返回缓存结果。前缀复用缓存的是中间计算状态，而不是最终输出。语义缓存改变了返回路径，可能返回与原始计算不完全一致的结果；前缀复用不改变返回结果，只优化计算过程。
前缀复用与投机解码。 投机解码使用一个较小的模型快速生成候选内容，再由大模型进行验证。它优化的是解码速度，和前缀复用作用于不同的阶段。两者可以叠加使用，但机制上相互独立。
理解这些区别，有助于在实际工程中做出合理的优化组合，而不是将不同机制混为一谈。
前缀复用虽然机制清晰，但在实际落地中仍有若干需要关注的问题。
缓存命中率取决于前缀的token级精确匹配。 如果两个请求的前缀在字符层面完全相同，但tokenize结果不同，就无法复用。这在多语言、混合编码、特殊符号较多的情况下尤其需要留意。对于依赖前缀复用的系统，保持前缀在token层面的高度一致是提升命中率的前提。
缓存空间不是无限的。 中间状态通常会占用大量显存，长前缀和高并发会快速消耗缓存空间。系统需要具备淘汰策略，在缓存空间不足时优先移除使用频率低或长度较短的前缀。开发者应关注缓存的容量上限和淘汰行为，避免因缓存膨胀导致显存不足。
模型更新会使命中缓存失效。 如果模型权重发生更新、微调或替换，之前缓存的前缀中间状态将不再与当前模型匹配。此时如果不做失效处理，可能导致推理结果错误。系统需要在模型版本变更时清理相关系列的缓存。
并发访问时需保证隔离性。 多个请求可能同时命中同一段前缀缓存。缓存状态在加载和续算过程中需要保证不会被其他请求修改，否则可能出现数据竞争问题。实现上通常需要拷贝或只读共享机制来保证安全。
收益高度依赖场景特征。 如果一个服务的请求前缀变化频繁、重复率低，前缀复用带来的收益可能不足以覆盖缓存管理的开销。在选型或启用该机制前，建议先对数请求的前缀重复情况进行量化评估。
前缀复用是一种无损的推理优化机制。它利用生成式模型“当前位置的计算只依赖前文”这一结构特性，将重复前缀的计算结果缓存起来，在新请求到来时直接复用，从而降低预填充阶段的计算量，提升服务吞吐并缩短响应延迟。
它的价值在长前缀、高重复率、多请求的场景中最为突出，比如多轮对话、Agent 工作负载、少样本推理和基于固定模板的批量任务。但它并不是万能的：缓存空间压力、模型更新导致的缓存失效、并发隔离以及前缀命中率评估，都是实际使用中必须认真对待的问题。
回到定义本身：前缀复用不改变模型看到了什么，只改变系统算了几遍。理解这一点，是判断它是否适合当前业务需求的关键。