吞吐与延迟的权衡：批开大为什么更便宜也更慢

一句话定义

吞吐（Throughput）是单位时间里系统能处理完多少请求、吐出多少 token；延迟（Latency）是单个请求从发出到拿到结果等了多久。这两件事经常此消彼长：想压低成本、提高吞吐，往往就得让单个请求多等一会儿。

打个比方：公交车与出租车

出租车随叫随走，你一个人坐一辆车，快，但每公里成本高。公交车要等人凑够一车才发车，人均成本低得多，可你得在站台等。AI 推理服务里的 batching（批处理）就是公交车：把多个用户的请求攒成一批，一起送进 GPU 算。

为什么攒批有效？因为 GPU 做矩阵运算时，一批算 1 条和算几十条，在算力没被喂饱的情况下耗时差不多。批开得越大，同样的电费和机器时间摊到更多 token 上，单位成本就越低。代价是：你得等批凑齐，而且这一批必须整体算完才能把结果发出去——首字延迟（TTFT，Time To First AI 词典：Token">Token）因此变长。

现代服务常用 continuous batching（连续批处理）来缓解：不等整批全部生成完，谁先结束就把它踢出去，立刻塞进新请求，这样吞吐不掉太多，延迟也不至于太难看。

和相邻概念的区别

要注意两点。第一，吞吐不是延迟的倒数，两者没有简单换算关系。第二，延迟本身还分首字延迟和每 token 输出时间（TPOT），聊天时人最敏感的是前者，读长文时后者更影响体感。并发则是手段不是目标：适当提高并发能把吞吐拉上去，但排队过长会反过来把延迟拖垮。

对你意味着什么

对服务商，批大小是核心旋钮之一。开大，单位成本低，就能把价格卖便宜；开小，响应快，适合实时交互场景。所以你会看到同一家常常提供"实时接口"和"批处理接口"两档，后者通常便宜不少，但结果要等，且可能不保证时效——具体折扣、等待上限和可用模型，以官方页面为准。

对从业者，选型前先问自己看哪个指标。客服机器人、代码补全看首字延迟；夜里给十万条数据打标看吞吐。只盯"每百万 token 多少钱"容易踩坑，因为那个价通常是在特定批规模下测出来的，你的实际负载未必跑得到。

对普通人，一个直观解释是：为什么有的 AI 功能秒回，有的转半天圈？一部分原因就是服务商在替你坐这趟公交车——你的请求被塞进了多大的批里。