分布式推理中的前缀缓存与调度：理解LLM服务为何“迟迟不回答

在部署大语言模型（LLM）服务的实际生产中，一个常见的现象是：用户提交请求后，系统看似忙碌，但迟迟没有输出第一个字。很多人会本能地归因于GPU算力不足或模型规模过大，但在某些场景下，真正的瓶颈并不在计算本身，而在于请求的排队方式与重复计算。以“同一份长文档被多次提问”为例：第一次请求要求总结，第二次追问结论，第三次索要修改建议。对人类而言，这些提问共享同一份阅读材料，理所当然可以重复利用之前的理解；但对模型服务来说，每一次请求都从零开始“读题”，还是可以复用之前的“笔记”，取决于底层架构对前缀缓存与调度策略的处理方式。

一、概念定义：什么是前缀缓存与请求调度

在分布式推理系统中，请求调度指的是将用户请求合理分配给后端模型实例的过程。传统负载均衡通常依据实例的连接数、CPU或内存使用率做简单分发，但在LLM服务中，调度必须考虑更细粒度的状态——尤其是前缀缓存（Prefix Cache）。前缀缓存是指模型服务在完成“预填充”阶段后，将输入Token对应的键值（Key-Value）状态暂存于显存或内存中。当新请求的输入前缀与已缓存内容一致时，就可以跳过这部分重复计算，直接进入后续解码阶段。

需要强调的是，这里讨论的“复用”并非把旧答案直接返回，而是复用计算过程中的中间状态。新请求的独有问题部分仍需处理，输出生成也仍然逐Token进行。能否命中缓存，取决于输入前缀是否完全一致，而非语义上的“主题接近”。因此，调度器需要回答一个关键问题：把请求交给哪个实例，才能既利用缓存，又不让队列过长？

二、背景与价值：为何需要“懂上下文的调度员”

在单体应用时代，服务端处理请求的逻辑相对简单：接收输入、计算、返回结果。但LLM服务的请求特征与传统Web请求有本质区别。首先，输入长度可能达到数千甚至数万Token，处理这些输入所需的计算量远超生成单个输出Token的成本。其次，同一个模型可能被多个租户、多个Agent应用共享，不同请求对延迟和吞吐的诉求不同。最后，模型实例的状态不在请求之间天然隔离——前缀缓存让“有记忆的实例”变得有价值，但也带来了新的管理复杂度。

一个只做轮询分配的负载均衡器，可能把请求发给没有缓存的空闲实例，导致重复计算；而一个只追求缓存命中的调度器，又可能让大量请求涌向同一实例，形成新的排队瓶颈。因此，生产级推理服务需要一种能同时观察缓存状态、实例负载、租户优先级和服务等级协议（SLA）的调度机制。这就是“懂上下文的调度员”存在的意义：它不一定追求某个单一指标的最优，而是在多重约束下选择当前请求最合适的去处。

三、核心组成：缓存感知路由与状态维护

这类调度系统的核心可以拆解为三个部分：请求入口与端点选择、缓存状态追踪、路由决策策略。

1. 请求入口与端点选择

请求入口负责接收来自客户端或上层Agent的调用，统一进行鉴权、限流和超时管理。端点选择则是从若干个后端模型服务实例中选出目标实例。在分布式系统中，这一层往往与负载均衡器或网关组件结合，但LLM场景下的选择逻辑远不止于“最小连接数”。它需要感知每个实例当前是否持有与请求前缀匹配的缓存片段。

2. 缓存状态追踪

这是实现缓存感知路由的基础。系统需要知道“哪个实例的缓存中存有哪些前缀的KV状态”。然而，缓存是动态变化的：内存压力可能导致旧缓存被淘汰，实例重启会清空全部状态。因此，路由层对缓存信息的掌握程度直接影响决策质量。实践中存在两类实现：一类是基于近似信息的推断，例如通过请求历史或哈希指纹估算某实例可能持有缓存；另一类是基于模型服务主动上报事件的精确追踪，实例在缓存命中或缓存淘汰时发送状态变更消息。后者更准确，但需要额外的消息队列和状态存储基础设施，并非零成本。

3. 路由决策策略

有了缓存状态和实例负载数据，调度器需要制定决策。这一决策通常是一个多目标优化问题：既要尽可能命中前缀缓存以减少预填充开销，又要避免单个实例过载。例如，三个实例中，甲保留着相关缓存但队列较长，乙空闲但无缓存，丙持有其他内容的缓存。合理的调度可能选择甲，也可能选择乙，取决于队列长度阈值和该租户的延迟要求。若只追求缓存命中，所有请求都涌向甲，甲的GPU利用率会飙升，新请求反而要等待更久；若只做简单负载均衡，则每次都浪费乙的预填充算力。

四、工作原理：一次请求的调度旅程

为了更直观地理解，我们用一个示意流程说明请求如何被调度。假设三个请求都以同一段长文本为前缀，但后续问题不同。

1. 客户端提交请求R1，前缀为P，问题为Q1。
2. 请求入口接收后，查询缓存状态表，发现当前所有实例均无P对应的缓存。
3. 调度器按负载最低原则选择实例A，请求R1被发送至A。
4. A执行预填充，计算P+Q1的KV状态，并生成答案。同时，A将前缀P的KV状态写入本地缓存。
5. 客户端提交请求R2，前缀为P，问题为Q2。
6. 请求入口查询缓存状态表，发现实例A报告持有P的缓存。
7. 调度器检查A的当前队列长度，发现仍在可接受范围内，于是将R2发送至A。
8. A检测到输入前缀P已在缓存中，跳过P的预填充计算，仅处理Q2部分，直接进入解码阶段。延迟显著降低。
9. 客户端提交请求R3，前缀为P’，与P略有差异（例如开头写入了一个空格）。缓存状态表显示无匹配，调度器选择空闲实例B。
10. B执行完整预填充，处理P’+Q3，生成答案，并缓存P’的KV状态。

这个流程体现了调度器的两大作用：识别“可复用的计算单元”（即前缀），以及在实例之间做有依据的分配。值得注意的是，R3虽然内容上与P接近，但前缀不匹配，因此无法复用A的缓存。这解释了为何“主题相似”不等于“缓存可命中”。

agent-">五、典型场景：多租户与Agent服务

前缀缓存感知调度在以下场景中尤其具有实用价值：

• 多租户共享同一模型服务：当多个业务线共用底层推理集群时，不同租户的请求可能涉及相似的公共材料（如企业知识库、产品文档）。调度器可以根据租户的优先级和资源配额，决定缓存资源的占用比例，避免低优租户挤占高优租户的缓存空间。
• 多轮对话与Agent链式调用：Agent应用常常需要模型连续处理多个相关任务，例如先总结文档，再提取关键数据，最后生成报表。这些请求共享同一份输入文档，若能复用前缀缓存，整体任务耗时将大幅缩短。
• 周期性批处理任务：例如每日定时分析同一批日志文件，虽然日期变化，但日志格式和系统提示词相同。此时，前缀缓存结合调度策略可以有效减少重复计算。

六、相关概念区别：预填充与解码的拆分架构

除了在实例间调度请求，另一类优化思路是将预填充阶段和解码阶段分离到不同的实例上处理。预填充计算密集且并行度高，适合用高吞吐的GPU实例批量处理；解码是逐Token自回归生成，对延迟敏感，更适合用低延迟的推理实例。两者通过传输中间状态（即KV缓存）衔接。

这种拆分的优点在于：不同阶段的资源需求不同，可以独立扩缩容；预填充实例即使发生队列积压，也不会阻塞正在执行解码的实例。但代价同样明显：需要额外的网络传输将KV状态从预填充实例传送到解码实例，这既是I/O开销也是编排复杂度。此外，还要考虑两类实例的数量配比——预填充过剩则浪费算力，解码不足则生成成为瓶颈。因此，这一方案通常适用于对吞吐要求极高、且请求前缀较长（例如长文档分析）的业务场景，而非所有请求都适合。

七、使用注意事项与选型建议

在实际部署中，以下几点值得格外关注：

• 缓存淘汰策略与内存预算：缓存并非无限存储，显存是稀缺资源。需要为不同优先级的前缀分配缓存空间，并设置合理的淘汰策略。频繁的缓存抖动可能导致命中率大幅下降，因此监控缓存命中率是核心运维指标。
• 调度信息的时效性：采用近似缓存感知路由时，可能因状态滞后作出错误决策——例如把请求发给已经淘汰缓存或已重启的实例。精确事件上报能减少此类问题，但需要额外的消息传输和存储开销。选型时需权衡准确性与基础设施成本。
• 请求前缀设计:为了使缓存生效，应用层应尽量保持系统提示词、上下文材料的开头部分稳定。若每次请求都在开头加入随机时间戳或动态变量，前缀缓存将形同虚设。
• 监控与告警：除了传统的延迟、吞吐指标，还应关注预填充时间与解码时间的比例、缓存命中率、实例队列深度、KV缓存淘汰次数等细粒度指标，以便定位“排队”与“重复读题”的具体来源。

八、总结

大语言模型服务出现的“用户等待久久无响应”，往往不是单一算力问题，而是调度策略与缓存复用机制未协同工作的结果。理解前缀缓存与请求调度的关系，是构建高并发、低延迟推理系统的关键环节。一个理想的生产系统，既不会盲目追逐缓存命中，也不会无视缓存状态去机械地均衡负载，而应在缓存收益、实例负载、租户权益等多重信号间做动态权衡。同时，预填充与解码的拆分扩展了系统设计的灵活性，但代价是额外的编排复杂度。对于技术选型者而言，明确业务请求形态、前缀稳定性、资源成本和延迟容忍度，是配置这类系统的首要前提。归根结底，调度的本质不是让某一指标最优，而是在复杂约束下寻找当前请求的“合适去处”，这正是分布式推理从可用走向好用的分水岭。