智能体的性能优化竞赛：延迟、吞吐与缓存的技术博弈

智能体的性能优化竞赛：延迟、吞吐与缓存的技术博弈

单轮对话的延迟优化是上个时代的问题，智能体把延迟竞赛升级成了新的难度：一次任务由十几个 LLM 调用与几十次工具调用串联而成，任何一环的延迟都会被乘上轮次放大。用户对"等多久"的忍耐是有硬阈值的——超过十秒的静默等待流失率陡增——而智能体任务的原始形态动辄一两分钟。过去两年，从应用到推理服务的各个层面都在为压缩这条延迟曲线投入工程资源：提示缓存把预填充时间砍掉大半，并行工具调用把串行链路折叠，推理引擎的持续批处理与投机解码把解码速度推高数倍。这篇文章拆解智能体的延迟结构，盘点各条优化路径的收益量级与适用条件。

一次响应的延迟解剖

优化的前提是看清钱的去向（延迟意义上的）。一次智能体任务的端到端耗时由四类成分构成。预填充（prompt processing）：模型处理输入 token 的时间，与输入长度近似线性，10 万 token 级的上下文预填充可达数秒；缓存命中时这部分大幅缩短，因为 KV 状态直接复用。解码（decode）：逐 token 生成的时间，与输出长度线性相关，主流模型每秒三十到一百五十 token 的解码速度意味着一段八百字的回答要五到二十秒。工具执行：检索、抓取、代码运行等外部调用的耗时，从几百毫秒到数十秒不等，且经常是全链路里最大的单项。多轮串联：以上三项乘以轮次，这是智能体与单轮调用的本质区别——第 n 轮要等第 n-1 轮的输出，延迟是累加而非取最大。

这个结构指明了优化杠杆的优先级。串联轮次是乘数，砍轮次（更好的规划、减少空转）是第一杠杆；工具执行通常占比最大，缓存与并行是第二杠杆；预填充靠提示缓存，解码靠推理侧加速与输出长度控制，是第三、第四杠杆。值得强调的是延迟与成本的联动：提示缓存同时省时间与钱，输出长度控制同时省解码时间与输出 token 费用，凡是同时改善两本账的优化，优先级永远最高。

缓存层次：从精确前缀到语义缓存

缓存是智能体性能优化里确定性最高的手段，按精确度分三层。第一层是提示缓存（prompt cache）：推理服务复用相同前缀的 KV 状态，Anthropic 的实现里命中输入按 0.1 倍计价、官方口径可大幅缩短首 token 延迟（宣称最高可降 85%），OpenAI 自动缓存命中半价，DeepSeek 同样给出十分之一的命中价。吃满这层红利要求前缀结构设计：system prompt 与工具定义字节级稳定放在最前，参考资料居中，动态内容放尾部；前缀断点数量有限制（Anthropic 当前最多四个 cache_control 断点），且缓存有生存时间（默认约五分钟），低频会话要么接受失效要么用刷新保活。

第二层是应用层缓存：工具结果的确定性缓存。同一 URL 的抓取、同一文件的读取、同一查询的检索结果，在应用侧用哈希键缓存，重复任务的第二遍跑起来快得多也便宜得多。嵌入向量同样该缓存——同一文本重复嵌入是纯粹的浪费。第三层是语义缓存：用嵌入相似度判断新请求与历史请求是否"语义相同"，相同则直接返回缓存答案，连模型调用都省掉。它的收益诱人（FAQ 类场景命中率可观）但风险实质存在：语义相似不等于答案等价——"iPhone 15 多少钱"和"iPhone 16 多少钱"嵌入距离很近，答案却完全不同。工程上的安全做法是把语义缓存限制在答案稳定的场景（产品说明书、政策条款），加相似度阈值与时效过滤，并且永远避开个性化与时效性内容。

flowchart LR
    A["用户请求"] --> B["路由 / 意图判断"]
    B --> C["并行工具调用<br/>检索 + 读文件 + 查询"]
    C --> D["预填充<br/>缓存命中则大幅缩短"]
    D --> E["解码生成<br/>流式输出首字节"]
    E --> F["工具执行轮 2"]
    F --> D
    D -.->|"串行：全链路相加"| G["总延迟 = 轮次 x（预填充+解码+工具）"]
    C -.->|"并行折叠"| H["总延迟 ≈ 最长支路 + 少量串联"]

并行化：把串行链路折叠起来

多轮串联是延迟的乘数，并行化是对抗它的核心武器。第一层是并行工具调用：现代模型的 API 支持单次响应返回多个工具调用（一次返回"读文件 A、读文件 B、检索 C"三个调用），运行时并发执行后把全部结果一起回传，原本三轮的往返折叠成两轮。对多源信息汇总类任务，三到五路的并行折叠可以把这一段的耗时从串行相加压到最长支路，实测两到四倍提速常见。第二层是子智能体扇出：相互独立的子任务派发给并行的子智能体各自完成，主智能体只汇总结论——研究类、批量分析类任务收益最大。第三层是微观的流水线：上一轮解码的同时预执行可以预判的调用（比如解码到一半已可确定要读哪个文件），以及用户输入阶段就预加载大概率需要的上下文（会话打开时预取记忆与知识库索引），这些"隐藏等待"的技巧合计能省下可观的端到端时间。

配套的感知层优化同样重要：流式输出让首 token 尽快呈现，工具执行期间的状态播报把静默期变成可感知的进度，配合前面交互设计篇讨论的手段，绝对延迟没变，体验延迟大幅下降。性能优化在智能体场景永远是"绝对延迟"与"感知延迟"两条战线并行。

推理侧与应用侧的加速选项

推理服务侧的技术选项对自建推理的团队是主战场。推理引擎的选择已经是数量级差异：vLLM 的 PagedAttention 与连续批处理（continuous batching）让 GPU 在多请求间无缝切换填满算力，相对朴素的推理实现吞吐提升数倍到十几倍；SGLang 在结构化输出与多轮会话场景进一步优化前缀复用。投机解码（speculative decoding）用小模型起草、大模型验证的方式把解码速度提升一到三倍，数学上输出分布不变、质量无损，主流推理引擎均已支持。量化（AWQ、INT8）用少量精度换取显存占用与吞吐的改善，在中小模型上性价比突出。KV 缓存的显存管理（前缀复用、量化 KV）直接影响并发容量，是吞吐优化的深水区。

应用侧的加速选项同样不能忽视。输出长度是解码时间与输出成本的共同驱动：要求简洁输出、设置合理的 max_tokens、让结构化数据走 JSON 而非 Markdown 表格、推理模型关闭简单任务的深度思考——这些措施对长回答场景的端到端延迟改善常常超过任何推理侧技巧。模型路由是延迟与成本的双重杠杆：TTFT 敏感的场景（补全、语音链路）用小模型起步，大模型异步深化。最后是延迟预算分配法：把端到端目标拆解到各环节——网络一百毫秒、预填充一秒、首 token 八百毫秒、单次工具五秒——每项埋点监控，超预算即告警。没有预算分配的团队优化起来像无头苍蝇，有了它，任何延迟回归都能在分钟内定位到环节。

吞吐与容量：延迟之外的另一半战场

延迟优化的镜像问题是吞吐：用户量上来之后，每分钟数千个并发任务的容量规划成为独立的工程战场。第一道约束来自模型供应商的配额体系——每分钟请求数与 token 数的双限速——生产系统必须做配额感知的流量调度：按优先级排队（付费用户优先、交互式请求优先于后台批任务）、逼近配额时的降级路径（切换备用供应商、降级到小模型、或让任务排队等待）。多供应商路由因此成为标配：单供应商依赖既是可用性风险也是议价劣势，路由层做健康探测与成本比价，同代模型之间的热切换要提前用评测集验证过质量差异，而不是事故时临场决定。

背压与准入控制是智能体负载特征的特殊要求。智能体任务的爆发性很强——一个新功能上线、一批用户同时触发长任务，队列深度瞬间翻倍——此时正确的做法是拒绝降级而不是硬撑：新任务被告知预计等待时间或被限制提交，系统保持已接受任务的服务质量，比无节制接收后全线超时好得多。容量测算有个实用的口径换算：以"并发长任务数"为容量单位而不是传统的 QPS——高峰期 200 个并发任务、平均每个任务峰值产生 3 路并发 LLM 调用，意味着需要支撑约 600 路在途调用的配额与连接池，这个数字才是与供应商谈配额、规划自建 GPU 的基准输入。

降级预案必须演练而不能只写在文档里。三类高频场景值得列入季度演练：高峰熔断（队列超过阈值时的降级行为是否符合预期）、供应商宕机（切换到备用供应商的切换时长与质量表现）、缓存失效（前缀结构变更导致提示缓存命中率归零——延迟与账单同时冲击，这是生产事故复盘里的高频案例：一次不起眼的 system prompt 格式调整让缓存命中率从 92% 掉到 3%，当天成本翻倍、P95 延迟恶化三倍，而没有任何报警直到财务侧发现）。容量工程的本质与延迟优化共享同一个哲学：给每一条资源曲线建立预算与报警，让系统在触碰边界之前被看见，而不是在触碰之后被道歉。

小结

智能体的性能优化是一场多层博弈：延迟结构由预填充、解码、工具执行与轮次串联构成，串联轮次是乘数所以砍轮次与并行化是第一杠杆；提示缓存是确定性最高的单项优化，稳定前缀设计换来十分之一计价与大幅缩短的首 token 延迟，语义缓存收益诱人但要严守"答案稳定场景"的边界；推理侧的连续批处理、投机解码与量化决定自建服务的吞吐上限，应用侧的输出长度控制与模型路由则是零基础设施投入的双重杠杆。配合延迟预算分配与状态播报的感知管理，智能体的响应体验可以从"分钟级的等待"压进用户可容忍的区间——性能优化在智能体时代不是可选项，而是产品能否被日常使用的前提条件。