测量四种不同的延迟信号
单一的延迟数字会掩盖用户实际在等待哪一段时间。串流聊天即使完整生成需要更久，只要 TTFT 较低，体感仍可能很快；而批次抽取可能只关心端到端持续时间。
- 首 token 时间：从请求开始到收到第一个串流 token。
- 生成吞吐量：输出 tokens 除以生成时间。
- 端到端持续时间：从请求开始到回应完成。
- 可靠性：成功回应数除以总尝试次数。
控制基准工作负载
使用固定的提示词集合，以代表预期的工作负载。记录模型 ID、供应商路由、区域、请求参数、输入 tokens 与要求的输出长度。
- 在开始记录测量前先执行暖身请求。
- 随机化供应商顺序，以降低时段偏差。
- 在超过一个流量窗口的时间内重复测试。
- 将串流与非串流结果分开处理。
使用分布，而不是排行榜截图
回报中位数、p90 与 p95 值，并附上样本数。某条路由即使中位数最快，但若经常出现极端延迟，实际上的生产环境体验可能会比稍慢但更稳定的路由更差。
{
"sample_size": 100,
"ttft_ms": { "median": 640, "p95": 1840 },
"output_tokens_per_second": { "median": 42.1 },
"end_to_end_ms": { "median": 5120, "p95": 9080 },
"success_rate": 0.98
}以上数值仅为示范性的报告格式，不是实时的 CoreAPI 基准测试结果。
每份报告都应公开方法
只有当读者能理解测量了什么，并且能重现方法时，基准测试才有价值。请包含限制条件，并说明供应商路由是固定选取还是自动选取。