批处理推理的吞吐优化
【摘要】 做离线推理时，很多人第一反应是把 batch size 拉大。但吞吐上不去，往往不是 batch 不够大，而是下面几项没配对：序列长度分布。 一个 batch 里混着 50 token 和 4000 token 的请求，padding 会浪费大量算力。按长度分桶，比盲目加大 batch 更有效。动态批处理窗口。 窗口太短，batch 拼不满；窗口太长，延迟上升。要看业务能接受的最大等待时间，...
做离线推理时，很多人第一反应是把 batch size 拉大。但吞吐上不去，往往不是 batch 不够大，而是下面几项没配对：
序列长度分布。 一个 batch 里混着 50 token 和 4000 token 的请求，padding 会浪费大量算力。按长度分桶，比盲目加大 batch 更有效。
动态批处理窗口。 窗口太短，batch 拼不满；窗口太长，延迟上升。要看业务能接受的最大等待时间，而不是只看吞吐。
KV cache 管理。 长上下文场景下，KV cache 可能比权重更吃显存。限制最大长度、及时释放、分页管理，都会影响并发数。
量化与精度。 INT8/FP8 能提升吞吐，但要评估对任务指标的影响，尤其是抽取和数值推理。
CPU 预处理。 tokenizer、图像解码、后处理如果拖后腿，GPU 利用率会卡在 60% 上不去。
调度策略。 短请求优先还是 FIFO，会影响 P99。离线任务也要看尾延迟，不然整体完成时间被长尾拖住。
我现在的顺序是：先看 GPU 利用率和显存瓶颈，再看序列长度分布，最后才调 batch size。顺序反了，很容易调了半天只优化了 benchmark。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）