批处理是怎么提升利用率的？机制细节全梳理

AI 显卡是大力士，一次只让它搬一块砖，力气全浪费在来回跑腿上。推理服务里的批处理，就是把同时到达的请求凑成一摞，让显卡一口气算完，同样的时间处理量翻几番。它是提升利用率的关键手段，机制值得拆开看。

一张卡的胃口有多大

显卡擅长并行：算一条请求和算八条相似结构的请求，耗时差距远小于八倍。因为显存里的权重已经就位，多条请求的数据可以一起「过机器」，计算单元同时开动。单条请求让大部分计算单元闲着，凑够一批才把机器喂饱——这是批处理能提升效率的根本原因。

请求怎么凑成一批

凑批像拼车：司机不会来一位走一位，而是稍微等一等，凑够一车再出发。推理服务把新到的请求放进队列，攒一小段时间或攒够一定数量就成批发送。等多久、凑多大，是一对天然的矛盾——等得久批次大、效率高，但每位乘客的等待时间变长；随到随走响应快，但车常常坐不满。

拼车类比失效的地方也要说清：拼车超载要被罚，批处理这辆车却讲究尽量装满，只要显存装得下、延迟扛得住，批越大单位成本越低。真正要权衡的是延迟和效率的天平。

批大批小的取舍

交互类对话对延迟敏感，批次要小、队列要短，宁可机器吃不饱也不能让用户干等；离线任务反过来，延迟无所谓，批次往大了开，把效率拉满。效率有没有真的提上去，最终看GPU 利用率的变化。批太大还有另一重压力：显存里权重装好后余量有限，批大了中间数据一起挤，这也是很多人给模型做压缩的原因，原理见量化部署；单卡实在喂不下就多卡分摊，路线见模型切分。

批次和队列怎么设，取决于负载对延迟的敏感程度。

连续批处理的门道

传统凑批有个毛病：一批里最长的请求没算完，其他卡位干等着陪跑。连续批处理改了规则——谁算完谁退出，队列里的新请求随时补位，车辆边开边上下客，机器几乎不空转。这套机制和排队的先后规则紧密配合，怎么排、怎么插队，由调度器统一指挥；算子层面的提速配合，见算子融合。日常你在豆包里连续提问感觉响应稳定，在 DeepSeek 网页上高峰期也不见明显排队，背后都是这类机制的功劳。

给新手的实践建议：先搞清自己服务的延迟底线，再倒推允许的批次大小和等待窗口。比如要求九成请求在一秒内返回，等待窗口就不能超过几百毫秒，批次上限也由此锁定。底线清楚了，调参就不用来回试错。另外，改动凑批参数后要盯两个数：批次平均大小和队列等待时间的分位数，前者涨、后者稳，说明改对了；前者涨、后者也涨，说明等待窗口开太大，往回收一点。

批处理速查表

• 一句话原理：多条请求合并计算，喂饱并行单元
• 核心矛盾：批次越大越省，等待时间越长
• 分类施策：交互小批快回，离线大批拉满
• 进阶机制：连续批处理边跑边补位

记住这句：批处理是天平和杠杆——天平两端是延迟与效率，杠杆撬动的是利用率。

还有一个变量影响凑批效率：请求之间的长度差异。长度接近的请求凑在一起，补齐浪费少；长短混搭时，短请求要陪着长请求算到结束。条件允许的话，把长文任务和短问答分流到不同实例，各自按各自的最佳批次跑，两边都舒服。

换个问法再问批处理三句

• 批处理会让回答变慢吗？：排队等待会增加一点延迟，换来整体处理能力上升，交互服务会把批次调小来平衡。
• 不同长度的请求能进同一批吗？：能，框架会做对齐补齐，长请求之间差距过大时才拆分处理。
• 为什么深夜响应反而更快？：请求少、队列短、批次小，等待环节几乎消失，单条延迟自然下降。