AI 模型推理的批量执行优化方案，这个主题我前前后后折腾了小半年，踩过的坑能列一长串。从单张显卡跑一个请求美滋滋，到并发一上来直接显存溢出、GPU利用率掉到个位数，再到后来把吞吐量拉上去近十倍，这个过程里最深的体会就是：批量优化不是一个锦上添花的技巧，而是从开发原型走向生产服务的必经之路。不管你是做内容审核的图像模型、客服场景的文本模型，还是最近特别火的向量化推理服务，只要你的接口要面向多个用户、多路请求，批量执行这事儿就躲不开。
这篇东西我打算把整个优化思路从头到尾捋一遍，包括瓶颈分析、三种主流分批策略的取舍、关键参数怎么定、踩过的坑和排查手段，最后再放一份可以直接参考的实操配置。内容不算短，但每一段都是从实际项目里逼出来的经验，照着做大概率能少走弯路。
1. 先搞清楚瓶颈在哪里：批处理优化的底层逻辑
很多人一上来就调 batch size，结果死活不生效，问题往往出在没搞明白推理系统真正的瓶颈是什么。批量执行优化的本质不是“把多个请求凑在一起跑”，而是“让计算硬件以最饱和的状态工作”。
1.1 算力利用率的真相：GPU 不喜欢等
先想一个场景：单张消费级显卡去跑一张 512x512 的图片分类，纯计算时间可能只要 20 毫秒，但加载模型、预处理、数据搬运这些杂活加起来可能要 100 毫秒。如果你一次只处理一个请求，GPU 大部分时间都在空转等数据。这就像一条流水线，工人（计算单元）干活只要 1 秒，但物料送到工位要 4 秒，那整条线每 5 秒才出一个成品，效率是 20%。
批量执行解决的正是这个问题。一次把 8 个、16 个甚至 64 个请求的数据打包送到 GPU 上，数据搬运的开销被摊薄了，计算单元持续处于工作状态，单位时间产出的结果数量就上去了。这就是吞吐量提升的核心来源，不是单个请求变快了，而是同时处理的请求变多了。
但这里有个非常容易踩的认知误区：批量执行并不是免费的。当 batch size 增大到一定程度，单个请求的响应时间会明显变长，因为大家要排队共享算力。这就是业界常说的吞吐量和延迟的跷跷板关系。如果你做的是实时交互场景，比如在线对话、实时翻译，那延迟是有硬上限的；如果你做的是离线批量任务，比如晚上跑全量数据的向量化，那延迟根本不重要，吞吐量越高越好。明确自己的业务属于哪一类，是选择优化策略的第一步。
1.2 CPU 与 GPU 的差异决定了优化方向完全不同
还有一个特别常见的翻车点是把 GPU 上的优化思路直接搬到 CPU 上。CPU 推理的瓶颈往往是内存带宽和指令级并行，而不是简单堆 batch size。我记得有个用户拿 CPU 跑 BERT 类模型，强行把 batch size 从 1 提到 32，结果推理时间长了 16 倍，吞吐量几乎没变，因为 CPU 的内存带宽早就被吃满了，多加请求只是排队。后来换成适当的多进程并行 + 较小的 batch size，情况才好转。
GPU 侧则相反，只要显存装得下，batch size 越大通常越划算，因为 GPU 的架构天生适合大规模并行计算，短板是数据搬运。GPU 是有“饥饿”属性的，你喂给它的数据越饱满，它的利用率就越高。所以做批量优化之前，先搞清楚你跑在什么硬件上，再去谈参数调优，这个顺序不能颠倒。
1.3 一个可靠的性能基线怎么测
没有基线就开始优化，等于闭着眼睛开车。我在项目中通常先做一次最简单的压测，步骤很简单：
- 准备好一个和线上业务最接近的请求样本，图片、文本、向量都行。
- 先测单请求的延迟，连续跑几十次取 p50 和 p95。
- 再测并发 1、2、4、8、16 的吞吐量变化，记录 GPU 利用率、显存占用、端到端延迟。
这些数据就是你的起跑线。我见过太多团队一开始就直接上复杂方案，性能没提上去，反而引入了一堆新问题。老老实实先把基线数据拿出来，你会清楚地看到瓶颈到底在预处理、模型计算、还是后处理上。基线测量的结果也决定了你要不要上批量优化：如果单请求延迟已经很高，直接堆并发只会更糟糕。
2. 分批策略的核心取舍：动态分批、静态分批、连续批处理
分批策略听起来简单，就是攒一批再处理，但具体怎么攒、攒多少、等多久，里面有很多门道。我最初做的时候也是从最简单的静态分批开始，后来才逐步过渡到动态方案。这三个策略的适用场景差异很大，选错了会非常痛苦。
2.1 静态分批：规则简单但浪费明显
静态分批的做法是固定一个 batch size，比如一次收满 32 个请求就开始推理。实现很简单，特别适合离线场景。但在线服务里这玩意儿很尴尬：如果并发不够高，你等半天都攒不满 32 个，请求就在那里干等，延迟直接爆表。如果并发远远超过 32，那又会出现一批 32、下一批还是 32 的情况，后到的请求排队时间很长。
更浪费的是，静态分批对请求的大小差异无感。比如做多模态任务，一个请求是一张 1K 分辨率的大图，另一个请求只是一段 10 个 token 的文本，两个强制凑到一个 batch 里，结果整个 batch 的执行时间被最慢的请求拖住，其他请求都在陪跑。这是静态策略的天然缺陷，也是后来我用动态分批替代它的原因。
2.2 动态分批：在线推理的主流玩法
动态分批的核心是设置两个参数：最大 batch size 和最大等待时间。系统收到请求后不立即处理，而是放进队列等一小段时间，比如 5 毫秒或者 10 毫秒。时间到了或者请求数量攒到上限，就开始批量推理。这个策略的好处是能把短时间内的突发并发聚合起来，同时用最大等待时间兜底，防止请求被饿死。
我曾经在一个图像 embedding 服务上用动态分批做过对比实验。单请求推理时间约 40 毫秒，并发 20 时如果完全一个接一个跑，吞吐量大概 50 QPS。改成动态分批后，最大 batch size 设为 8，最大等待时间设为 10 毫秒，同样的并发下吞吐量直接涨到 280 QPS，p95 延迟只增加了几十毫秒。这个收益是实打实的，而且代码改动量并不大。
2.3 连续批处理：下一代推理引擎的秘密武器
连续批处理，也叫 Continuous Batching，是这几年大模型推理框架中最核心的优化之一，我实測下来非常管用。和动态分批最大的区别是，连续批处理允许一个请求在自己的生成步骤结束后立刻离开 batch，不用等整个 batch 全部完成。
以文本生成模型为例，传统的 batch 策略下，如果 batch 里有请求生成长度不同，短的早就结束了，却要一直占着显存等长的跑完，浪费非常严重。连续批处理的做法是：每当一个请求生成完一个 token，就把它从 batch 里移出去，同时立刻塞进一个新的请求补位。整个 batch 的成员是动态进出的，硬件利用率被压到极限。现在主流的大模型推理框架基本都是这个思路，比如各家开源推理引擎的核心调度器实现的就是连续批处理。
2.4 三种策略的对比与选型建议
| 策略 | 适用场景 | 优点 | 缺点 | 推荐优先级 |
|---|---|---|---|---|
| 静态分批 | 离线批量任务 | 实现简单、开销低 | 等待浪费、拖尾严重 | 低 |
| 动态分批 | 在线轻量模型 | 均衡、延迟可控 | 需要调等待参数 | 高 |
| 连续批处理 | 长文本生成与 LLM 推理 | 利用率极高、吞吐量大 | 实现复杂、显存管理要求高 | 最高 |
选型建议：如果是基础的小模型（图像分类、embedding、目标检测这类单次前向计算），用动态分批就够了；如果是自回归生成模型（文本生成、代码补全、语音合成），咬牙也得上连续批处理或者直接选用支持该特性的推理引擎。死磕自己实现连续批处理不是不行，但要评估成本，成熟引擎已经解决了绝大部分细节问题，除非你的业务形态非常特殊，否则没必要重复造轮子。
3. 落地实操：三步完成批量推理优化
聊完了理念和策略，接下来说说我实际做优化时的步骤。整个流程可以拆成三步：准备正确的加载与预处理管线、选对推理引擎和运行时、再用压测反向调参。每一步都有一些细节，我尽量把参数和原因都交代清楚。
3.1 第一步：做好数据管线，让请求按规格进入队列
很多人都忽略了数据预处理在批量优化中的关键地位。你攒了一批请求，如果图像尺寸各不相同、文本长度参差不齐，进到模型前还得临时做各种 padding 和 resize，这部分开销会直接吃掉落落實實后端的优化收益。
我在项目中统一在预处理阶段做三件事：
- 图像类请求全部统一做尺度缩放和归一化，尺寸不一致的在进入批处理队列前就转换好。
- 文本类请求统一做 tokenization，并记录原始长度，方便后处理还原。
- 所有预处理结果放入一个按到达时间排序的队列，供批调度器消费。
预处理做完就缓存结果，同一批次内的数据格式保证完全一致。很多人的优化效果不明显，就是因为在 GPU 前端的 CPU 预处理部分花了太多时间，GPU 吃饱了 CPU 跟不上，系统瓶颈从算力转移到了数据供给，最终吞吐量还是上不去。
3.2 第二步：选对推理引擎，别急着造轮子
选引擎这件事，我的经验是：先看成熟的推理服务框架，再考虑自己写。目前几个主流选项各有侧重，我结合自己的使用体验给个参考。
某跨平台推理服务框架是我用得最多的，它原生支持动态批处理，你可以直接配置最大 batch size、并发实例数、超时时间。它在显存管理上做得比较完善，多模型共存时的显存隔离非常方便，生产环境稳定性和可观测性都很出色。文本生成类引擎也是绕不开的选项，特别是做 LLM 推理时，它把连续批处理、KV Cache 量化、Prefix Cache 这些优化都内建好了，直接部署就能吃到红利。如果追求极致性能，可以用编译型优化工具，把模型编译成高度优化的执行引擎，和上面的服务框架配合使用效果更好。
我自己在项目里的经验是：当模型结构复杂多变时用通用服务框架管理，当模型固定且追求极限吞吐时用编译器优化加专用引擎。不要指望一个方案通吃所有场景，也不要为了炫技自己从头写调度器，调度器里的坑远比想象中多。
如果你还是决定自己实现，最少要处理好以下问题：动态队列的线程安全性、等待超时的触发机制、返回结果和原始请求的对应关系、批处理失败时的回滚策略。任何一环出了问题，线上都是事故。
3.3 第三步：用压测反向调参的三个核心参数
引擎部署好之后，真正的重头戏是参数调优。我通常盯着三个参数反复调：最大 batch size、最大等待时间、并发度。
最大 batch size 不是越大越好。显存是硬约束，你先估算一张显卡能装下多大的 batch 不爆显存。有个简单的估算方式：单请求的显存占用乘以目标 batch size，再加上模型权重和激活值的开销，不能超过总显存。比如单请求激活显存占用约 0.5GB，模型权重 2GB，一块 24GB 显存的卡，最大 batch 大概可以试 32，但实际要留出至少 15% 的显存余量给临时分配，所以保守点可以设在 24 左右。
最大等待时间则要看业务容忍的延迟增量。假设你的业务 p95 延迟要求 300 毫秒，单请求推理 80 毫秒，那等待时间超过 100 毫秒就非常危险。一般从 5 毫秒起步调，并发波动大的场景可以稍微调高，但不要超过单请求推理时间的一半，否则等待成本会反超批处理的收益。
并发度要匹配 GPU 数量。每张显卡一个独立实例，并发请求数建议从 1 开始逐渐加压。并发度调高后吞吐量通常会先上升后下降，转折点就是你的最优并发。我见过不少人以为提高并发就一定提升性能，结果显存被多实例瓜分，每个实例的 batch 都降级，整体性能反而下滑。正确的做法是先固定每实例的 batch size，再调实例数量，观察整体 QPS 的变化。
4. 实测中常踩的坑与排查实录
这部分是我最想分享的内容，因为网上教程大多只讲理想流程，很少讲失败案例。实际操作中，批量优化的道路可以说是“坑坑相扣”，我至少踩过八个大坑，下面几个几乎人人都会遇到。
4.1 显存爆炸：不是调小 batch 就完事
有一次压测，我把 batch size 调到 64，结果跑了两百多个请求后显卡直接 OOM。第一时间想到的是调小 batch，但后来仔细排查发现，问题出在显存没有及时释放。某些返回结果被 Python 侧的长生命周期对象引用着，推理引擎以为显存里的数据还需要保留，就一直不释放。后来加上显存监控，并强制在推理结束后释放缓存对象，问题才解决。
经验就是：OOM 不一定是 batch size 的锅，先看显存监控曲线。如果显存是缓慢爬升然后突然爆掉，大概率是内存泄漏；如果是瞬间冲高，才是 batch 太大。两者的解法完全不同。
4.2 动态分批的等待时间设太大：延迟雪崩
动态分批的等待时间特别迷惑人。我一开始把最大等待时间设成 50 毫秒，想着能多攒点请求，结果业务方反馈接口变得特别慢。一查才发现，在低峰期一个请求要等满 50 毫秒才被处理，直接给所有请求人为增加了 50 毫秒延迟，这个代价太大了。后来把等待时间降到了 10 毫秒，并且设置了条件提前触发：当队列里已经有 4 个请求时就立刻开始推理，不等 10 毫秒到点。这种设置兼顾了突发流量和低峰延迟，实测效果很好。
4.3 一个请求拖垮整个 batch：拖尾效应
做多模态任务时，一张又大又模糊的图片可能预处理就要 300 毫秒，而同一批里的其他图片只要 20 毫秒。batch 的执行时间不以平均值计算，而是以最慢的那个请求为准，其他请求全部陪跑。这就是拖尾效应。
我的解决方案是两层：一是预处理单独做超时控制，超时的请求直接降级或拒绝；二是请求分类分批，把大图请求和小图请求分到不同的 batch，避免混合。这类优化虽然增加了一点代码复杂度，但效果立竿见影，p95 延迟降了接近一半。
4.4 请求超时却还占用显存：队列与推理实例的协调问题
还有一次压测时发现 QPS 掉得厉害，排查后发现是部分请求在队列里等太久，被上游网关判定超时断开了连接，但我们的批处理服务并不知道，依然把计算做完并把结果放到响应通道里。由于没人消费结果，这些响应通道持续占用显存，越积越多。后来我加了一个监控协程，定时清理掉已经超时的任务，并主动释放对应资源。这个细节虽然小，但在高并发下影响极大。
4.5 常见问题速查表
| 现象 | 可能原因 | 排查方向 | 解决建议 |
|---|---|---|---|
| batch 增大但吞吐量不变 | CPU 预处理成为瓶颈 | 看 CPU 利用率与 GPU 利用率对比 | 异步化预处理、增加缓存 |
| 显存缓慢爬升后 OOM | 内存泄漏 | 监控显存曲线、检查对象引用 | 强制释放缓存、缩短对象生命周期 |
| 低峰期延迟偏高 | 等待时间过大 | 检查 p50 延迟 | 降低最大等待时间、设置提前触发条件 |
| 高并发时 QPS 反而下降 | 实例数过多互相争抢显存 | 观察每实例 batch 是否降级 | 减少实例数、增大单实例 batch |
| 个别请求拖慢整体 | batch 内请求规模差异过大 | 查看 batch 完成时间分布 | 按请求大小分类分批 |
| 上游超时但服务还在算 | 队列与超时机制脱节 | 检查超时任务是否清理 | 增加超时监控与资源回收 |
5. 监控与持续调优：不盯数据的优化没有意义
批量优化不是一锤子买卖，上线只是开始。之后要持续盯监控数据，我个人的习惯是关注五个指标：GPU 利用率、显存占用曲线、端到端 p50/p95 延迟、每秒处理请求数和排队任务数。这些指标缺一不可。
GPU 利用率能看到硬件是否吃饱，显存占用能预判 OOM，p95 延迟能反映用户体验，QPS 是最终产出指标，排队任务数则能提前预警系统过载。五个指标连起来看，能形成一个完整的判断链：如果 GPU 利用率高、延迟也高，说明算力吃紧，该扩容了；如果 GPU 利用率低、排队任务多，说明调度策略有问题，可能是等待时间不够或者批处理触发条件太保守。
监控数据到位后，调参就有了依据。我一般每周根据监控做一次微调，重点关注业务高峰期的 p95 延迟和 QPS 是否匹配预期。批量优化的持续性也体现在这里：模型会更新、流量会变化、数据分布会漂移，没有一劳永逸的最优配置。我现在每次业务部门说要上线新模型，都会同步检查一遍批量配置，这个习惯帮我挡掉了不少后续的线上事故。
关于批量执行优化，我个人在实际操作中最大的体会是：不要迷恋某一个单一参数或者某个“万能公式”，真正有用的是把系统当做一个整体来看。数据管线、调度策略、显存管理、监控告警，每个环节漏一点，最终性能就拉胯一大截。先把基线测清楚，再小步快跑地调参，每一步都拿数据说话，这个方向基本不会走偏。
最后再分享一个小技巧：当你调试完一套看起来不错的配置，务必用压测工具连续跑 30 分钟以上再下结论。很多间歇性问题（比如显存泄漏、队列堆积）都要靠长跑才能暴露出来，跑两分钟看起来正常的配置，可能 20 分钟后就崩了。批量优化方案，稳永远是第一位的。
