LLM API benchmark 应该看哪些指标
LLM API benchmark 指标指南：正确比较 P50/P95/P99、TTFT、成功率、429、吞吐、prompt cache、模型纯度和真实 token 成本。
快速答案
LLM API benchmark 至少要同时看成功率、P95 延迟、TTFT、输出速度、429 限流、prompt cache、模型纯度和实际 token 成本。平均延迟或单次测速无法代表生产体验，比较时还必须固定模型、地域、提示词和输出长度。
先看结论
- 平均延迟必须配合 P95/P99，才能看到尾部抖动。
- 聊天体验看 TTFT，批处理更关注端到端完成时间。
- 速度比较必须以模型纯度和成功率达标为前提。
- 成本应按真实 usage 和缓存命中计算，而不是只看标价。
先把指标分成四类
一个可用于采购或架构决策的 benchmark，应覆盖可靠性、响应体验、协议质量和经济性。只测速度，会把频繁失败或偷换小模型的渠道误判为优秀。
| 维度 | 核心指标 | 回答的问题 |
|---|---|---|
| 可靠性 | 成功率、5xx、429、超时 | 能否稳定完成请求 |
| 响应体验 | TTFT、P50/P95/P99、输出 tokens/s | 用户实际等待多久 |
| 协议质量 | 模型纯度、stream、tool call、usage、缓存字段 | 是否真的兼容且未降级 |
| 经济性 | 输入/输出/缓存 token 成本 | 完成同一任务实际花多少钱 |
P50、P95、P99 和平均值怎么用
P50 描述典型请求，P95 表示 95% 请求在该时间内完成，P99 用来观察极端尾延迟。平均值容易被少量异常拉高，也可能掩盖双峰分布，所以不应单独作为排序依据。
面向聊天和 Agent 的服务通常更应关注 P95；对严格 SLA 或高并发链路，P99 和超时率也很重要。报告应同时给样本量，否则百分位没有解释基础。
TTFT 和输出速度不是一回事
TTFT 是从发出请求到收到第一个有效内容 chunk 的时间，直接影响用户何时感到系统开始回应。输出 tokens/s 描述开始生成后的持续速度。一个渠道可能首字很快但后续生成慢，也可能首字等待较长但生成吞吐高。
流式测试还应检查空 chunk、chunk 间隔、连接中断和 usage 是否在流末正确返回。
成功率与限流必须放在速度前面
统计 2xx、401/403、429、5xx 和超时，并区分客户端配置错误与上游故障。429 不只是失败次数，还要结合响应头判断 RPM/TPM 余量、重试等待和并发边界。
如果测试工具自动重试，应同时记录首次成功率和重试后成功率，避免重试把真实不稳定性隐藏掉。
模型纯度、缓存和真实成本
更小或量化后的模型通常更快、更便宜，所以速度榜必须先通过模型身份和协议一致性门槛。否则 benchmark 会奖励静默降级。
成本要从实际 usage 读取输入、输出和缓存 token，再结合当日价格计算每次任务成本。对长上下文应用，缓存命中率可能比标称单价更影响总成本。
怎样让不同渠道可公平比较
固定模型版本、提示词、温度、max tokens、stream 设置、测试地域和并发。预热后再采样，分时段运行，并公开样本量、失败处理和价格日期。
- 交互聊天：重点看 TTFT、P95、stream 稳定性和成功率。
- Agent：重点看 tool call 兼容、尾延迟、429 和重试成本。
- 批处理：重点看端到端吞吐、P99、单位任务成本和失败恢复。
- 长上下文：重点看缓存命中、输入成本和上下文长度限制。
常见问题
LLM API benchmark 测多少次才有意义？
快检可用少量样本初筛；采购或 SLA 决策应分时段扩大样本，并公开样本量。P95/P99 在样本过小时没有稳定解释力。
TTFT 和总延迟哪个更重要？
聊天产品更关注 TTFT 和流式稳定性，批处理更关注端到端耗时与吞吐，应按业务场景设置权重。
为什么不能只比较官方标价？
真实成本还取决于输出长度、缓存命中、失败重试和模型是否降级，应按实际 usage 计算单位任务成本。
继续阅读
用真实 API 运行一次检测
使用临时 key 检查连通性、延迟、缓存、限流、模型纯度和 token 成本。