开源项目推荐｜k6：给 AI API 做接近真实业务的负载测试

开源项目推荐｜k6：给 AI API 做接近真实业务的负载测试

AI API 能返回一次正确答案，并不意味着它能承受真实用户同时到来。模型推理时间长、输出长度不固定、流式连接持续占用资源，上游还可能限流；如果测试仍只盯着 QPS，很容易得到一个看似漂亮却无法指导上线的数字。k6 是 Grafana 维护的开源负载测试工具，它用脚本描述请求、负载场景、指标和通过门槛，适合把 AI 接口的性能要求变成可重复执行的工程检查。

为什么 AI 接口不能只看 QPS

传统短请求常把吞吐量和总耗时放在第一位。AI 场景至少还要区分首字节等待、完整响应时间、失败与限流比例、输入输出规模、重试次数以及完成一次业务任务的成本。同样每秒十个请求，短摘要与长代码生成对计算资源的压力完全不同；把二者混在一组平均值里，会掩盖尾部延迟和成本波动。

k6 内置 HTTP 请求耗时、等待时间、失败率、收发数据量等指标，也允许创建自定义 Counter、Rate 和 Trend。团队可以把 P95 等分位数、错误率与自定义业务指标写成 thresholds。官方文档将 threshold 定义为测试的通过或失败标准，门槛不满足时进程以失败状态结束，因此它可以进入 CI，而不只是生成一张事后观看的图表。

先还原用户，而不是先放大并发

一份有价值的压测脚本应从业务流量模型开始。在线问答可以模拟用户提交问题、等待结果、阅读数秒后继续；异步视频任务则要覆盖创建任务、轮询状态、获取结果三个阶段；带工具调用的 Agent 还可能访问检索、数据库和外部 API。k6 的 scenarios 可以为不同函数配置不同执行器、起止时间和环境变量，让多类流量在同一轮测试中按合理比例出现。

建议先建立基线，再逐级增加到目标负载与短时峰值。测试数据要固定难度区间，并记录模型、参数、最大输出、Prompt 版本和测试时段。否则一次测试生成 100 字、另一次生成 2000 字，性能差异很可能来自任务内容，而不是系统优化。

给 AI API 设计一组可执行门槛

第一层是协议正确性：状态码、响应结构、任务 ID 和错误对象符合约定。第二层是可靠性：成功率、429 比例、超时率和重试后成功率。第三层是体验：首字节等待、完整完成时间以及 P95、P99 尾部。第四层是业务效率：单位成功任务的 Token、费用或 GPU 时间。

具体数值不应照抄别人的示例，而应来自产品 SLO 和预算。例如交互式聊天更重视首字延迟，批处理更重视单位时间完成数与失败恢复。k6 的 tags 可以按端点、模型或任务类型拆分子指标，避免一个快速健康检查把核心生成接口的结果平均掉。checks 适合验证响应内容；若要让失败影响发布，则还应对 checks 的成功率设置 threshold。

需要注意，普通 HTTP 指标可以观察请求等待与总时长，但真正的 SSE Token 间隔、断流位置和重连语义，需要支持流式解析的客户端、扩展或应用侧埋点配合。不要把收到响应头的时间误称为所有流式体验，也不要用完整缓冲后的结果替代用户看到第一个有效 Token 的时间。

压测应使用隔离环境、专用密钥和明确限额，提前评估调用费用，不要突然冲击生产或第三方服务。对于模型切换和阈值调整，可让另一套独立模型审阅场景覆盖与异常样本，再由真实监控和人工判断确认结论，减少测试脚本自身的盲区。

从一次压测变成持续性能治理

参考资料

• [Grafana k6：Thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/)
• [Grafana k6：Scenarios](https://grafana.com/docs/k6/latest/using-k6/scenarios/)
• [Grafana k6：Built-in metrics](https://grafana.com/docs/k6/latest/using-k6/metrics/reference/)

如果你正在统一测试多模型接口，可以先在 AnyAIS 选择目标模型并建立一条真实业务基线，再把关键阈值纳入发布流程。