2 篇博文 含有标签「benchmarking」

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

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

评测团队在 PPT 上写下一个数字：“p95 延迟为 1.2s。” 产品上线。一周后，值班人员发布了一张图表：生产环境中的 p95 为 4.8s，并且在晚餐高峰期持续攀升。工程师们在接下来的五天里争论是否有性能倒退、为模型版本增加埋点、向供应商提交工单——最终发现，除了测量数字的地点之外，什么都没有改变。评测环境报告的是一台安静的机器在热缓存上运行串行调用的延迟。而生产环境是另一套系统。p95 从未出错；它只是在回答一个不同的问题。

这就是评测工具的延迟谎言。这并不是因为基准测试做得不好——大多数团队使用的工具都很合理，报告数字也很诚实。问题在于“模型延迟”与“用户感知的延迟”之间的鸿沟，以及你为开发构建的环境几乎总是测量前者，却暗示后者这一事实。一旦你理解了这一点，基于基准测试得出的延迟 SLO 就不再像是产品承诺，而更像是对一个没人能复现的私人测试环境的声明。