NexAIX-官方博客
AI API性能测试怎么做？先固定 prompt 长度、max_tokens、并发梯度、采样时段、模型标识五个变量，再分别用离线基准跑和线上灰度对照回答不同问题。先做第一步：把你要回答的问题写下来。AI API性能测试的第一步不是写压测脚本，而是判断你面对的是能力回归、性能基准还是线上灰度——这三类问题对应完全不同的测试形态。换个模型想验证回答质量，那是能力回归；想确认新版本延迟是否变差，才是性能基准；想评估真实流量下的表现，则需要灰度。用压测脚本去回答能力问题，只会得到一堆无意义的数字。
先分清三类问题：能力回归、性能基准、线上灰度
在动手之前，先对照下表判断你的场景属于哪一类，避免用错工具。
| 问题类型 | 典型场景 | 适合的测试方式 |
|---|---|---|
| 能力回归 | 换模型、换版本后回答质量是否下降 | 离线评测集、人工评估 |
| 性能基准 | 延迟、吞吐是否达标 | 离线基准跑（固定变量） |
| 线上灰度 | 真实流量下稳定性、长尾表现 | 小流量A/B对照 |
换版本主要做性能基准+能力回归；换模型三类都要做；换供应商额外要加线上灰度，因为路由与排队行为只有真实流量能暴露。换模型或换供应商前，如果只关心延迟和吞吐差异，直接进入性能基准环节。但请注意：离线基准跑得好，不代表线上无忧，最终仍需要灰度验证。
五个必须固定的变量：prompt 长度、max_tokens、并发梯度、采样时段、模型标识
AI API性能测试最容易被忽略的是变量控制。以下五个变量不固定，结果就无法复现。
| 变量 | 为什么影响 | 建议固定方式 | 未固定时的典型症状 |
|---|---|---|---|
| prompt 长度 | 输入token数直接影响TTFT（首个token延迟） | 用固定长度的业务prompt模板 | 每次TTFT差异大，无法比较 |
| max_tokens | 决定输出上限，影响吞吐口径 | 设为固定值（如1024） | 输出长度不一，吞吐失真 |
| 并发梯度 | 不同并发下延迟和吞吐表现不同 | 1→2→5→10→20逐级递增 | 不知道在哪一级开始劣化 |
| 采样时段 | 高峰期与低谷期性能差异显著 | 记录测试的具体时段，尽量避开高峰期 | 同一脚本跑出天壤之别 |
| 模型标识 | 确保测试的是同一模型版本 | 记录模型名、版本、供应商 | 模型被静默降级而不知 |
离线基准跑：固定输入输出长度，用并发梯度找吞吐塌陷点
离线基准跑回答的是“这个模型在理想条件下的延迟和吞吐天花板”。操作如下：
- TTFT：从发送请求到收到第一个流式chunk的时间，在客户端记录发送时刻与首 chunk 到达时刻的差值。
- 输出吞吐：用生成的token数除以首token之后的时长，单位是token/s。
- E2E：整个请求从发起到完成的耗时，单独记录。
并发从1开始，按梯度递增（1、2、5、10、20），每档记录P50/P95延迟与错误率。当吞吐不再上升而延迟陡增时，那个点就是吞吐塌陷点。
离线基准跑无法回答真实流量下的问题，比如真实prompt长度分布、突发流量下的表现。这些需要线上灰度。
线上灰度对照：端点级 A/B 分流能测出离线测不到的什么
2026年8月，Together AI 在推理平台推出了端点 A/B 灰度测试，支持多模型与多权重版本并行业务验证。这意味着灰度能力正从应用层下沉到端点层，你可以在不写路由代码的情况下，让部分请求打到新模型，对比真实表现。
线上灰度能暴露三件离线测不到的事：真实prompt长度分布、真实并发波形、长尾请求（比如超长输入或特殊格式）。分流比例没有统一标准，以远低于主流量的小比例起步，先跑满一个可统计的观察窗，确认样本量与错误率稳定后再逐级放大。不要拍脑袋定死一个数。
灰度测试的前提是两组流量必须可对比，否则结论无效。例如，如果供应商在负载高时静默切换到更便宜的模型，那么你测出的差异反映的是路由行为而非模型能力。
AI API性能测试结果判读：看分位数而不是平均值
判读规则：以P50/P95/P99为主，平均值仅作参考。单次跑不算结论，需要重复采样并跨时段复测。差异要与同一组内的波动幅度对比，如果两组P95的重叠区间较大，就不能下结论。同时记录错误率和429比例，否则可能把限流误判为延迟优势。
结果表模板字段：
| 模型版本 | 服务档位 | 并发数 | P50延迟 | P95延迟 | P99延迟 | 输出吞吐 | 错误率 | 429比例 |
|---|---|---|---|---|---|---|---|---|
| (填入) | (填入) | (填入) | (填入) | (填入) | (填入) | (填入) | (填入) | (填入) |
工具链下沉：强类型 SDK 与服务档位如何改变测试口径
换模型前怎么测延迟和吞吐差异，还取决于你用的 SDK 版本与服务档位。Together AI 在2026年8月发布了基于强类型 OpenAPI 生成的 Python SDK v2.0，SDK 版本和参数类型变化会影响请求体，因此测试前必须锁定SDK版本。
同时，服务档位也是一个必须记录的变量。DeepInfra 提供与 OpenAI 兼容的 Batch API（JSONL 异步提交，20%成本折扣），以及 Flex、Standard、Priority 实时档位。不同档位的延迟目标完全不同，实时对话与离线批处理不能混在一张表里比较。测试报告必须写明服务档位。
灰度的前提：模型标识可信与不静默降级
要做好AI API性能测试，必须确认测试的确实是宣称的模型。如果平台在满载时静默降级，你的对照组就失去了意义。NexAIX 提供统一 OpenAI 兼容接口（base_url https://api.nexaix.net/v1），返回体 model 字段对应实际执行模型，满载返回标准 429 与重试建议而非静默切换，从而保证 A/B 两组可比。相关实践可参考自有算力AI API与AI API延迟的讨论。
换模型或换供应商的性能回归清单
- [ ] 固定五个变量：prompt长度、max_tokens、并发梯度、采样时段、模型标识
- [ ] 离线基准跑：用并发梯度找吞吐塌陷点
- [ ] 记录服务档位（如Flex/Standard/Priority）
- [ ] 线上灰度：小比例起步，按观察窗放大
- [ ] 校验模型标识：确认无静默降级
- [ ] 记录错误率与429比例
- [ ] 用分位数比较，不只看平均值
- [ ] 跨时段复测，确认结果稳定
把这份清单落到你自己的业务 prompt 上跑一轮基准，再决定是否进灰度。需要跨模型对照时，可在 NexAIX 模型页核对当前可用模型与规格，用测试额度跑首轮。关于并发和评测方法，可进一步阅读AI API并发和AI模型评测。
常见问题
性能测试结果每次都不一样是什么原因？
多半是变量未固定：输入长度不同、并发波动、时段差异、服务档位变化。也可能是上游限流导致的重试，误差被计入延迟。严格固定五个变量，并记录时段和档位，可大幅降低随机性。
TTFT 和输出吞吐分别怎么测？
TTFT 从请求发送到首个token到达的毫秒数，在客户端记录发送时刻与首 chunk 到达时刻的差值。输出吞吐用生成的token数除以首token后的时长（token/s）。两者要分开测，因为影响TTFT的主要是网络和排队，而吞吐主要受模型解码速度影响。
批处理任务需不需要单独做性能测试？
需要。批处理任务通常使用异步接口，延迟口径不同，且可能享受单独的成本折扣（如DeepInfra Batch API 20%优惠）。应单独测试其吞吐和完成率，不要与实时接口混在一起比较。
同一个 prompt 跨供应商对照要固定哪些参数？
至少固定 prompt 长度、max_tokens、温度、并发数、服务档位。此外，确认模型版本一致，且记录测试时段。如果供应商有灰度或缓存机制，也要在报告中注明，否则对照结果可能失真。
评论(0)