吞吐口径要先算对
谈吞吐之前必须先定义口径：是输出 token 数每秒、总 token 数每秒，还是每秒完成的请求数。对外承诺、容量规划与压测报告都应用同一口径，否则网关、引擎与压测工具的数字永远对不上，讨论也就无从收敛。
基本信息
| 输出吞吐 | 输出 token 数 / 秒 |
|---|---|
| 总吞吐 | 输入加输出 token / 秒 |
| 请求吞吐 | 完成请求数 / 秒 |
| 关键动作 | 三方口径统一 |
| 常见问题 | 网关与引擎口径不一致 |
典型使用场景
- 给业务承诺吞吐指标
- 做容量规划与扩容评估
- 对账网关与引擎的监控数字
- 对比两个版本之间的性能变化
- 把三种口径的换算公式写进监控看板的说明里
口径换算
口径换算
# 输出吞吐 ≈ 并发请求数 ÷ 单 token 时间
# 总吞吐 = (输入 + 输出 tokens) / 时间
# 请求吞吐 = 完成请求数 / 时间
# 比较之前先确认三方用的是同一口径与采样点三种口径的适用范围
| 口径 | 适用 | 注意 |
|---|---|---|
| 输出吞吐 | 评估生成能力 | 最常用 |
| 总吞吐 | 成本核算 | 输入占比高时差异很大 |
| 请求吞吐 | 业务侧视角 | 与长度结构强相关 |
网关与引擎的指标要抽查对齐：同一时段对不上，先查口径与采样点差异，而不是先怀疑数据本身有问题。
采样差异来源：引擎按调度批统计、网关按请求统计、压测工具按时间窗口统计，三方归到同一口径下再比较。
压测报告要写清口径与采样窗口：否则过两个月没人能复现这组数字，也就没法作为决策依据。
对外的容量承诺要留余量：实测吞吐是上限值，按上限承诺等于把系统常年压在饱和点上运行。
让压测脚本直接输出统一口径的数字：人工换算既慢又容易出错，报告的可信度也跟着下降。