Why Agentic Inference Needs Prefix-Aware Routing Infrastructure

Agentic Inference: 前缀缓存与路由 | CoreWeave

发布日期

2026年8月21日

5

分钟阅读

为什么Agentic Inference需要Prefix-Aware路由基础设施

作者

Selene Cecchinel

Faadil Shaikh

已复制

在本系列的第一篇博客中，我们探讨了Agentic应用如何与传统聊天应用相比，创造出本质上不同的基础设施工作负载：每个推理请求都会重用之前大部分内容，因此系统提示、工具定义和对话历史在每次调用之间基本保持不变。

本文接着前文的讨论，分析这些重复请求实际包含的内容，包括基础设施如何避免反复处理相同令牌。

如果基础设施能够识别并重用模型已处理的内容，就可以避免重新计算提示的大部分内容，显著减少首次生成令牌时间（TTFT），并为代理提供更可预测的推理性能。

这就是前缀缓存的承诺，但要在生产环境中实现这一优势，需要能够防止缓存命中变成缓存未命中的基础设施。

Agentic提示的结构

Agentic工作流中的提示由两部分组成：前缀和新内容。

• 前缀：系统提示、工具定义以及到目前为止构建的对话历史
• 新内容：当前调用的新部分，通常是最新用户消息、工具结果或其他新附加的上下文

在许多代理循环中，连续的推理请求共享大部分相同的前缀。唯一的新内容只是末尾的一小部分：最新的工具结果或模型的下一步推理。

在代理的工具调用循环中，每次连续调用都携带相同的系统提示、工具模式和累积历史。只有末尾的一小部分是新的——但前缀会持续增长。

这种结构的重要性取决于注意力机制的工作原理。模型生成的每个令牌都会关注它之前所有令牌的键/值状态，因此这些状态必须在生成开始前就存在。即使提示与上一次调用相比大部分未发生变化，模型仍会从头开始重新构建。

一个令牌的键值状态仅取决于它前面的令牌，这正是使未更改前缀可重用的原因。无论后面附加了什么内容，它都会生成完全相同的键值状态。但通常，服务引擎会从头开始重新构建所有内容。

代理循环中的每个工具调用都会将其结果添加到上下文末尾，因此随着会话进行，前缀只会越来越长。对于长期的Agentic工作流，这意味着需要反复在相同前缀上消耗更多计算时间。

更长的延迟。更长的TTFT。

通过前缀缓存加速Agentic推理

长期共享的前缀在Agentic工作流中会产生显著的开销，但存在减少开销并加快响应生成的机会。

在模型生成任何内容之前，必须首先处理前缀并构建键值缓存。这个过程称为预填充，对于长提示，它可能占据TTFT的很大一部分。排队、调度和网络开销构成了其余部分。在负载较高时，排队通常占比较大份额。

这正是前缀缓存发挥作用的地方。前缀缓存通过复用匹配提示前缀的缓存KV状态，使服务引擎能够跳过已缓存令牌的预填充计算，仅对未缓存的后缀进行计算。这是一种显著提升此类工作负载TTFT（首次生成令牌时间）的技术，多轮对话和智能体工具调用是最典型的场景。

在没有缓存复用的情况下，引擎会在第一个令牌生成前重新计算整个提示的KV状态。有了缓存复用后，已缓存的令牌会被跳过，预填充仅覆盖未缓存的后缀部分。

然而，如果某个节点上的热缓存无法被后续请求命中，其价值就无法体现。在没有前缀感知路由的情况下，每个推理请求都会从提示的开头重新构建KV缓存——即使这些令牌几乎完全相同。

为了提升TTFT，除了良好的缓存机制，还需要高效的路由策略。

前缀缓存需要前缀感知路由

基础负载均衡器会将每个请求发送到任意空闲的副本，既不识别会话归属，也不了解缓存位置。这本质上就是一次缓存未命中。

前缀感知路由会考虑哪些工作节点已经持有请求前缀的可复用KV状态，并据此进行路由，同时在缓存复用与当前工作节点负载之间保持平衡。这正是路由与缓存同样重要的原因。

• 没有前缀感知路由：每次交互都会触发一个持续增长的前缀的完整重新计算，会话越长，TTFT表现越差。
• 有前缀感知路由：请求会优先路由到已持有匹配前缀的工作节点，预填充仅覆盖新生成的令牌，TTFT指标反映的是新内容的长度而非完整历史的长度。

请查看下图以直观理解这种差异。

没有缓存状态感知的负载均衡器会将智能体的交互请求分散到不同工作节点，每次都需要完整重新计算。而前缀感知路由会将每个请求发送到已持有可复用KV状态的工作节点，预填充仅覆盖新生成的令牌。

基础设施需要支持这种行为的规模化

前缀缓存和缓存感知路由减少了智能体推理中的冗余计算。现在，生产环境中的智能体基础设施必须在工作负载增长、流量波动和部署扩展时持续保持这些优势。

实际操作中需要关注四个关键点：

• 将请求路由到已缓存的前缀：前缀感知路由会考虑哪些工作节点已经持有请求前缀的可复用KV状态，并据此进行路由。这与"这是哪个会话？"的问题不同，关键在于哪个工作节点具有最大的有效前缀重叠。
• 在系统扩展时保持缓存局部性：随着推理任务扩展到更多GPU和节点，缓存的前缀会分布在更多工作节点上。基础设施需要知道可复用KV状态的位置，并在容量变化时保持局部性，最大限度减少冗余计算和昂贵的缓存迁移。
• 在缓存局部性和负载之间保持平衡：拥有最多可复用KV状态的工作节点不一定是最佳目标。如果该节点过载，等待它可能比在其他节点重新计算部分前缀付出的代价更高。因此，路由和调度需要在缓存亲和性、队列深度和可用容量之间进行平衡，以优化整体延迟和吞吐量。

• 衡量其效果 缓存命中率、首令牌时间（TTFT）、路由行为和延迟百分位数等指标帮助团队验证请求是否到达了预热副本，并识别重新计算发生的位置。可观测性使团队能够在这些缓存未命中影响用户体验之前就发现潜在的性能问题。

在生产规模下，这些措施无一可选。这正是区分“恰好运行代理的基础设施”与“为代理实际行为构建的基础设施”的关键所在。

对生产环境代理推理的启示

前缀缓存可以显著减少代理推理所需的工作量，但前提是基础设施能够在工作负载扩展和流量模式变化时支持这一特性。路由、调度、扩展和可观测性共同决定了缓存前缀是被重复使用还是需要重新计算。

随着代理工作流变长且上下文窗口持续扩大，这些基础设施决策对延迟、GPU效率和成本的影响越来越直接。这就是为什么为代理推理构建的基础设施不仅要理解GPU和负载均衡，更要理解工作负载本身的结构。

CoreWeave Inference 围绕这些执行模式进行设计，结合前缀感知路由、高效调度和可观测性，以最大化生产环境中代理工作负载的缓存复用率。在本系列的下一篇文章中，我们将深入探讨 CoreWeave Inference 如何支持生产环境中的代理工作流。

了解更多：

• 阅读博文：Your Agent Is Only as Good as Your Infrastructure
• 阅读博文：From Experimentation to Production: Why Inference Is the Defining Layer of AI
• 观看演示：How Reinforcement Learning Improves AI Agent Reliability in Production
• 阅读博文：Why Inference Latency and Availability Drift in Production

在关于代理AI的三部分系列文章的第二部分中，了解前缀缓存和缓存感知路由如何减少代理推理的首令牌时间。

分享本文： [社交媒体图标链接]