一句话：Goodput（有效吞吐）指单位时间内被成功消费、且满足时限要求的请求数量——不光干了活，而且活真的被用上了。
打个餐厅的比方。后厨一小时出锅 500 道菜，这是吞吐量（throughput）。但其中一些因为太慢被客人退单，一些端上桌时已经凉透被倒掉，真正被吃掉、且客人满意的只有一部分。这一部分，才是 Goodput。
所以它的分子里，每条请求都要同时满足几个条件：
1. 成功返回：没报错、没中断、没被丢弃；
2. 在约定时限内返回：比如约定超过 2 秒即超时（timeout），超时的结果用户已经不要了，等于没产出；
3. 结果真的被消费：流式输出被打断，后半截内容生成了却没人接收，这部分算白算。
分母是时间。大致写成：Goodput = 满足 SLO 的成功请求数 ÷ 时间。这里的 SLO（Service Level Objective，服务等级目标）就是那条“算不算数”的线，由业务方约定。
关键区别在于，它和相邻指标问的不是同一个问题：
| 指标 | 在问什么 | 典型口径 |
|---|---|---|
| 吞吐量 Throughput | 一共处理了多少 | 请求数/秒、token/秒 |
| 利用率 Utilization | 资源有多忙 | GPU 占用率、CPU 使用率 |
| 有效吞吐 Goodput | 多少活儿真被用上了 | 达标成功请求数/秒 |
| 延迟 Latency | 单个请求要等多久 | P50 / P95 / P99 |
| 成功率 | 有没有报错 | 成功请求占比 |
利用率高不等于有产出。GPU 跑满 100% 看起来很美，但如果都在重试失败的请求，Goodput 可能是零。忙，不等于有用。
对 AI 从业者，这是最容易踩的坑：推理服务加大批处理（batching），吞吐量曲线能继续往上走，但单条请求的排队时间也在涨，一旦越过 SLO 线，多出来的吞吐就是负收益——占着显存，没有用户买单。做压测、容量规划和成本核算时，用 Goodput 当分子更诚实，它直接回答：这套系统每秒能交付多少个用户真正拿到手的回答。
对普通职场人同理。客服团队一天接通 1000 通电话是吞吐量；其中在规定时间内解决、客户也没再回拨的，才是有效吞吐。汇报时，后者往往更能说明问题。
最后提醒：什么算“成功”、超时线画在哪儿，各家口径不同。跨团队比较前先对齐定义，具体以各自的官方文档或 SLO 约定为准。