机器学习工程与系统
请求批处理（request batching）
/ ree-KWEST BACH-ing /
请求批处理，是把几个进来的请求攒成一组、一趟送进模型里一起跑，而不是一个一个来。回想一下：加速器芯片就像一间有成千上万名厨工的厨房，只递给它一张单子，等于浪费了绝大多数厨工。批处理就是那位领班，他先攒上十几张单子，再一次性全送进厨房，好让每名厨工都忙起来。不论芯片处理 1 个还是 32 个输入，干的活儿大致一样多，所以批处理近乎是白来的额外产能。
最简单的做法是等上几毫秒、攒齐一批再跑——拿每个用户一丁点儿等待时间，去换总产能的一大笔进账。现代文本生成里用的更聪明的方案，叫「连续批处理」或「动态批处理」，它不让已经办完的请求陪着慢的一起等：某个用户的答案一出来，那个空位就腾出来，新请求随即补进去，让芯片始终满载，又不必让谁去等整组人。这是压低大语言模型运行成本最大的杠杆之一。
为什么这很重要：批处理往往就是「养得起的服务」与「贵到要命的服务」之间的分界，有时能把成本效率提上好几倍。诚实的权衡是：它总会给单个请求添上一些延迟，而且只有在流量足够、能把批填满时才管用——凌晨三点只有一个用户在线时，根本没东西可攒，你只能按每个请求的全价付钱。它是一种吞吐量优化，有意地花延迟去买产能。
服务器在第一个请求到来后最多等 10 毫秒，把这段时间里来的其他请求一并扫进来。若进来了 16 个，这 16 个就在 GPU 里一趟跑完——耗时和单跑一个差不多，却以一个的代价应答了 16 个用户。
10 毫秒的等待，把 16 个独立任务并成了一个——这就是廉价推理背后的核心戏法。
批处理并不是质量上的改进——它丝毫不改变模型给出的答案，只改变硬件产出这些答案的效率。它纯粹是一根关乎成本与速度的杠杆，而且只有当进来的请求足够、能填满一批时，这根杠杆才拉得动。
又称
另见