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

Demo 成功了。Beta 测试也通过了。接着，正式发布带来的流量是平时的十倍，直接撞上了你从未进行过压测的每分钟 Token 配额，而在产品最受瞩目的时刻，所有超出上限的用户都收到了 429 错误。

这是无人排练过的故障模式。团队会偏执地对自己的服务器进行压测——副本、连接池、数据库索引——然后将每个请求都路由到一个存在于别人账户中的供应商配额，而那个上限他们从未真正触及过。限流不是一个在 try 块中捕获的错误。它是一个硬性的产品约束，如果你没有围绕它进行规划，那么产品发布之时，就是你第一次发现坑在哪里的时刻。

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

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

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

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