2 篇博文 含有标签「load-testing」

你的暂存环境显示 p50 延迟为 400ms。你的生产环境仪表盘却显示 1.8 秒。你检查了代码 —— 同样的模型，同样的提示词（Prompt），同样的供应商。部署和发布之间没有任何改动。数据不应该有这么大的分歧，但事实就是如此。

罪魁祸首几乎总是缓存状态。提示词缓存（Prompt caching）—— 大多数团队依赖的最重要的延迟优化手段 —— 在暂存流量模式下的表现与生产流量模式下有着本质的不同。如果你不考虑这种差异，那么你在发布前收集的每一个延迟数据都是虚假的。

你运行了负载测试。k6 报告平均延迟为 200ms，P99 延迟低于 800ms，在 50 个并发用户时错误率为零。你上线到了生产环境。不到一周，用户就开始反馈 8 秒的卡顿、连接中断以及流式输出中途 Token 预算耗尽。发生了什么？

测试之所以通过，是因为你衡量错了指标。传统的负载测试工具是为在几毫秒内返回完整响应的无状态 HTTP 端点设计的。LLM API 的行为与这些工具所建模的完全不同：它们在几秒钟内流式传输 Token，按 Token 而非请求计费，消耗的是 GPU 显存而非 CPU 线程，并且响应速度完全取决于缓存是否命中。一个对 /chat/completions 端点进行压测的 k6 脚本产生的数据看起来像是性能数据，但实际上几乎无法反映生产环境的真实情况。