43 篇博文 含有标签「performance」

我曾合作过的一个团队花了三天时间寻找他们智能体（agent）循环中 22% 的延迟回归原因。他们归咎于新的工具路由（tool router）。他们归咎于切换了模型版本。他们归咎于前一周悄悄升级的 JSON schema 验证器。他们最终在代码下游两层的地方找到了元凶：一个运行器镜像（runner image）进行了更新，新镜像将 cpufreq 调节器（governor）的默认值从 performance 改为了 schedutil，而智能体工具调用循环的突发性使得 schedutil 的升频延迟在 p95 指标中变得显而易见。模型没问题。智能体也没问题。仅仅是内核在微突发任务之间改变了 CPU 频率的调节策略，导致整个基准测试结果发生了偏移。

这是大多数智能体团队从未见过的故障模式，因为他们从不观察。你的 CI 基准测试数字并不是对模型或智能体的测量。它们是对一个技术栈的测量，这个栈恰好包含了模型、网络、共享虚拟机、虚拟机监控程序（hypervisor）调度器、具有未知邻居的缓存层级，以及——最隐蔽的——频率缩放策略，它决定了给定的每一毫秒计算是以 1.0 GHz 还是 3.6 GHz 运行。

我上季度合作的一个团队对一个客户支持智能体（Agent）进行了为期一周的埋点分析。从纸面上看，该智能体的中值延迟非常合理：P50 在 SLO 范围内，P95 虽然偏高但尚可解释，工具调用的追踪（traces）看起来也很健康。然而，当有人按类型对 span 进行分桶统计时，全场陷入了沉默。该智能体每次运行的墙钟时间（wall-clock time）中，约有 58% 耗在了标记为“规划（plan）”、“反思（reflect）”、“决定下一步（decide-next-step）”和“自我检查（self-check）”的 span 中。而真正的工具执行——数据库查询、CRM 写入、权限检查——占比不足 30%。这个智能体在核心业务逻辑上花费的精力，竟然比那些没人关注的中间步骤还要少。

这个比例并非偶然。它是任何你不主动监管的“规划-行动-观察（plan-act-observe）”循环的自然状态。编排器（Orchestrator）为了思考和行动支付延迟代价，而增加思考步骤几乎总是比增加行动步骤更容易，因此它会野蛮生长。当你意识到这一点时，“决定下一步做什么”已经变成了一个独立的预算大头——甚至比你最初构建智能体要服务的业务逻辑还要大。

你的供应商状态页面显示为绿色。每秒 token 数 (TPS) 仪表盘显示的曲线一如既往地平稳。SLA 报告显示你完全处于合同约定的速率范围内。然而，支持队列里挤满了用户，他们形容聊天输出“一跳一跳的”、“断断续续”、“比上周还差”。你的监控指标中没有任何一项能证实他们的说法，因为你的监控根本没有在测量他们真正在关注的东西。

这是没有人察觉到的供应商交付故障模式。他们没有突破速率限制，而是重新定义了单位。每秒到达的 token 数量没变，但它们是以单 token 块的形式流式传输的，而不是针对渲染器优化过的 4 token 块。平均吞吐量依然完好，但感知质量却被毁掉了。SLO 依然达标，因为 SLO 是针对网络传输（wire）制定的，而网络传输是供应商控制的那部分系统。

一段对话在同一个 Claude 会话里跑了四十分钟。十一轮回合，每轮平均首字延迟（TTFT）800ms，每轮都很便宜——因为那段 28,000 token 的前缀命中了提示词缓存。第十二轮到来，TTFT 飙到 3.4 秒。对话的形态没变，模型没切换，网络也正常。缓存输入 token 从 27,800 掉到 0。下一轮的 prefill 账单从第一个 token 起就全额计费。

你去追踪里找原因，没有任何一条日志写着"另一个租户的突发流量把你逐出了缓存"。对这次毛刺最诚实的解读是：在同一片 GPU 池的某处，另一个客户的 prompt 让调度器认为，丢掉你这段温热的前缀是代价最小的选择。你无法重放这一轮，无法证明那次逐出。那一刻的缓存状态是陌生人流量的函数，而那些流量不在你的追踪里，因为它们本来就不属于你。

一个 200 毫秒的工具调用在火焰图（flame graph）上看起来就像是杂音。但在 Agent 循环中堆叠七个这样的调用，杂音就变成了信号 —— 模型在 800 毫秒内完成了思考，但用户却等待了 4.5 秒，因为每一次工具调用都在重新支付首个调用已经吸收掉的启动成本。残酷之处在于，这种成本在任何单一的追踪（trace）中都不会显示为异常。它表现为干脆利落的 Demo 与反应迟缓的生产环境 Agent 之间的差异，而大多数团队会将其归咎于模型。

Model Context Protocol (MCP) 已成为 Agent 工具链的默认集成界面，这意味着它也成了延迟（latency）堆积的重灾区。MCP 的设计 —— 基于 stdio 或可流式 HTTP 的 JSON-RPC、能力协商（capability negotiation）、动态工具发现 —— 对于一个必须桥接任意客户端和服务器的协议来说是正确的。但它隐含的单次调用成本结构对于 Agent 实际的访问模式并不友好。Agent 的模式不是“每个会话调用一次工具”，而是“每轮对话调用七个工具，每个会话进行四十轮对话”。

这篇文章将探讨这种错配：冷启动税究竟存在于何处，为什么它在长生命周期的 Agent 中是叠加而非被摊销（amortize）的，以及如何通过“预热池”（warm-pool）规范将数秒的惩罚降低到 100 毫秒以下。

你的 LLM API 返回的 P50（中位数）延迟为 800 毫秒。你的仪表板显示为绿色。你的 SLA 规定“两秒以内”。接着，一个用户提交了工单：“它转了 30 秒然后就放弃了。”你检查日志，发现 P99 延迟高达 28 秒。

这种差距——中位数与尾部延迟之间 35 倍的比率——并非偶然。这是 LLM 工作原理的结构性属性，仅仅通过调整超时时间是无法消除的。

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。

每隔六个月，就会有一款配备更大上下文窗口的模型问世。GPT-4.1 达到了 100 万 Token，Gemini 2.5 紧随其后，达到 200 万，而 Llama 4 如今更是号称支持 1000 万 Token。隐含的承诺是：把所有内容都塞进去，不用再纠结该放什么，让模型自己搞定。

这个承诺在生产环境中站不住脚。一项 2024 年针对 18 个主流 LLM 的研究发现，随着输入长度增加，每一个模型的性能都出现下降——不是某些模型，而是每一个。上下文窗口是天花板，而非地板。把它当作地板来用的团队，正在以痛苦的方式发现这一点。

你的 LLM API 调用在 P99 分位下于 500 毫秒内完成。但你的用户却在等待 12 秒。这两个数字都是准确的，谁都没有撒谎——它们只是在测量完全不同的东西。两者之间的差距正是大多数 Agent 系统性能无声流失的地方，而且大多数团队从未对其进行过监控（instrumentation）。

问题是结构性的：P99 LLM 延迟是一个应用于多步执行模型的单次调用指标。一个 ReAct Agent 进行五次连续的工具调用、重试一个幻觉化的函数、组装不断增长的上下文并生成 300 个 token 的推理链，这并不是一次 LLM 调用。这是一个分布式工作流，其中 LLM 只是一个节点，而其他每个节点都有其自身的延迟开销。

你的智能体管道很慢，于是你把任务拆分给五个并行子智能体。p50 下降了，你把它上线了。三天后，告警响了：一批用户请求超时。你挖进去发现 p99 从 4 秒涨到了 22 秒。单个智能体本身没有任何变化。超时是因为编排层在等最慢的那个——它以 1% 的概率遇到了检索抖动，但现在任何触碰全部五条路径的请求都会遇到这个概率。

这就是并行陷阱：这个模式看起来是显而易见的提速方案，实则以一种伤害真实用户更多的方式重构了延迟分布，p50 的改善远不能弥补 p99 的恶化。在生产基准测试中，单个智能体在 64% 的评估任务上能匹配甚至超过多智能体管道。并行扇出奏效的时候，确实奏效得很干净——但仅限于特定类别的问题。把扇出当作默认选项，才是错误所在。

某团队构建了一个 RAG 功能，测量端到端延迟后发现慢得无法接受，随即开始优化模型调用。他们尝试了更小的模型、批量请求，并调整了 temperature 和 token 上限。经过两个迭代周期，延迟下降了 15%，但功能依然太慢。他们从未测量过的是：在 LLM 收到任何提示词之前，文本分块和嵌入生成就已经耗费了 600ms。

这种模式在分布式系统中普遍到有了专有名词：优化了错误的组件。在 AI 流水线中，LLM 调用显而易见且易于测量，而其之前的所有环节都是隐形的——除非你主动做埋点，否则根本发现不了——而吞吐量恰恰死在那里。

仪表盘显示智能体很快。P50 停留在 1.2 秒，团队开会庆祝，然后放弃率却在持续攀升。没有人关注用户真正体验到的那个图表。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%A4%9A%E6%AD%A5%E6%99%BA%E8%83%BD%E4%BD%93%E7%9A%84%E5%BB%B6%E8%BF%9F%E9%A2%84%E7%AE%97%EF%BC%9A%E4%B8%BA%E4%BB%80%E4%B9%88%20P50%20%E4%BC%9A%E8%AF%B4%E8%B0%8E%EF%BC%8C%E8%80%8C%20P99%20%E6%89%8D%E6%98%AF%E7%94%A8%E6%88%B7%E7%9A%84%E7%9C%9F%E5%AE%9E%E6%84%9F%E5%8F%97"]

这是生产环境中多步智能体可靠的失效模式：中位数是你能够达到的指标，而尾部延迟才是你用户感受到的指标。随着你在流水线上不断增加子调用，这两者之间的差距会呈非线性增长。一个包含四个步骤的智能体，即使每一步在“中位数表现”上都很快，其 P99 通常也会比任何单步操作糟糕 6 到 8 倍。用户体验到的不是中位数，而是他们那次特定请求中最慢的一步。

如果你的团队优化了错误的分位线，你交付的系统将拥有出色的基准测试表现和精美的演示效果，但在你从未监测的长尾场景中，用户正不断流失。