什么是 吞吐量（Throughput）？
吞吐量（Throughput）是 LLM 服务系统在明确工作负载下，单位墙钟时间内完成的已定义工作量，例如成功请求数或输出 Token 数。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
选择正确分子
Request Throughput 统计完成请求，Output Throughput 统计生成输出 Token，Input Throughput 统计 Prefill Token，Total Throughput 则按声明口径合并输入输出。业务吞吐还可以统计已核验答案、已接受代码变更或完成的 Agent 轨迹。成功、失败、取消与截断工作应分别报告；从分子排除失败却不披露失败率，会夸大系统容量。
找到可持续负载
应在真实输入输出分布上扫描 Request Rate 或 Concurrency，找出仍满足尾延迟、错误、质量与公平性目标的最大负载。[DistServe](https://arxiv.org/abs/2401.09670) 把 TTFT 与 TPOT 目标内可服务的最大速率称为 Goodput，其论文收益只适用于被测系统。Closed-loop 测试会因客户端等待后再发请求而掩盖过载；Open-loop 或 Trace Replay 更接近独立到达，但必须记录 Schedule Lag。吞吐进入平台期且 Queue Depth 持续上升，说明服务已经饱和，即使 GPU Utilization 很高。
正确聚合
Completed Request 与 Token 等 Counter 可以在同一窗口对齐后跨 Replica 求和；Percentile 不能直接取平均，应合并原始样本或兼容 Histogram Bucket。[AIPerf 指标参考](https://docs.nvidia.com/aiperf/reference/ai-perf-metrics-reference)区分请求级记录、聚合 Counter 与派生速率。固定模型、Tokenizer、Runtime、硬件、Replica 数、精度、Cache 状态、到达分布、时长与 Warmup。聚合容量旁还要报告单用户延迟与速率，避免 Batch 掩盖交互体验退化。
主要特点
- 在一个声明的 Benchmark Window 内测量聚合完成工作
- 可使用请求、输入 Token、输出 Token、总 Token 或业务结果作为单位
- 会随 Offered Load、请求形态、批处理、Cache 状态和 Replica 数变化
- 可能在单用户 TTFT、TPOT、Jitter 或公平性恶化时继续上升
- 达到饱和区后，Queue 增长但完成量不再同比增加
- 只有应用成功、延迟、质量与安全门禁后才成为 Goodput
常见用途
- 按生产流量分布规划 Replica 与加速器容量
- 找出仍满足延迟和质量 SLO 的最大到达速率
- 在同等工作负载下比较调度、批处理、量化或并行策略
- 按合格任务而不是尝试 Token 计算成本与能耗
- 发现饱和、Queue 增长、Preemption 与公平性回退
示例
Loading code...常见问题
LLM 吞吐量与每秒 Token 数相同吗？
每秒 Token 数只是吞吐量的一种单位。报告也可以统计成功请求、输入 Token、输出 Token、总 Token 或已核验任务；必须说明分子、统计范围和完整测量区间。
Throughput 与 Goodput 有什么区别？
Throughput 按声明规则统计完成工作；Goodput 只统计还满足成功、质量、TTFT、TPOT、安全或正确性标准的工作。高原始吞吐可以与低 Goodput 同时出现。
为什么更高吞吐量可能增加延迟？
更大或更密集的 Batch 可以摊薄模型计算并提高聚合容量，但请求可能排队更久，或在 Decode 中更少获得调度。具体权衡取决于到达形态、调度器、上下文长度与硬件。
如何确定可持续 LLM 吞吐量？
逐步提高真实 Offered Load，直到延迟、错误、质量或公平性边界失效，并取满足全部 SLO 的最高速率。报告中应包含 Warmup、测试时长、失败与客户端 Schedule Lag。
多实例吞吐量可以直接相加吗？
同一窗口内对齐的完成请求或 Token Counter 可以求和。不同 Replica 的 Percentile 不能直接平均，应合并原始请求样本或兼容 Histogram Bucket，并计入路由不均、失败和实例健康状态。