吞吐量是什么：单位时间完成多少工作，不能替代延迟
解释请求吞吐与词元吞吐的口径，说明并发、输入长度和失败记录怎样影响模型服务容量比较。
先说结论
先理解这个概念
吞吐量表示单位时间处理或完成的工作量，模型服务可能报告每秒请求数或词元数。不同单位不能直接互换，输入和输出长度也会影响含义。吞吐高不代表单个用户等待短，更不代表答案质量高。比较前应定义统计窗口、有效完成条件及请求负载，避免把大量失败请求或重复输出也计作可用产出。
01
处理总量与单次等待描述不同问题
NVIDIA 的性能测试区分吞吐与延迟，PagedAttention 论文则讨论服务内存与批处理如何影响请求处理。增加并发可能提高整体产出，也可能让单条任务排队更久。每秒词元还要说明包含输入处理还是只计算生成，不同统计不能直接排序。一个系统输出很长答案，会与固定短标签任务产生不同数字。容量评估应结合任务质量与等待目标，不能只挑设备最忙时的最高值作为全部业务承诺。
02
同一负载核对有效完成和排队
例如固定公开分类输入和输出要求，在允许测试范围逐步增加并发，记录每段时间完成且合格的结果。失败、取消和重试单独统计，不能把重试产生的重复任务当作新增工作。同时记录单条等待，确认总量提高没有突破使用者能接受的范围。本文没有负载测试或测量吞吐，步骤仅为验证设计。比较设备或后端时保持模型与数值格式一致，避免把质量降低或模型变小带来的变化全归为服务优化。
03
持续容量还需要故障和资源条件
短时间峰值不能证明长时间稳定运行，应按任务需要观察内存、队列与恢复。批量方式可能适合离线总量，交互应用则还需控制每个请求的等待。维护时保留负载配置与版本，更新后重跑相同条件，再判断容量是否变化。成本包括资源预留和人工处理失败，不只计算理论单位产出。最终报告说明统计单位及条件，不能用一个高数字掩盖没有完成或质量不合格的工作，让吞吐真正对应可使用结果。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。