ONNX Runtime：动态批处理调优

可视化演示

动态展示ONNX Runtime动态批处理的工作流、三类触发策略、吞吐量提升(3-10x)及vLLM连续批处理机制，帮助理解如何通过智能合并请求最大化GPU利用率。

批处理原理

火锅店后厨有个铁锅，每次开火前都要烧热锅、倒油、洗锅铲，这套“准备动作”需要一分钟。单独炒一份蛋炒饭要三分钟，其中一分钟花在准备上。但如果是拼桌后一次炒四份，准备动作还是一分钟，炒饭本身四分钟，总共五分钟就出了四份饭。平均每份饭只要一分多钟——这就是拼桌的魔力。

在 AI 推理服务里，GPU 就是那口铁锅。每一次推理请求，ONNX Runtime 都要经历内核启动、数据搬运、算子加载等固定开销。如果来一个请求就推理一次，固定开销重复支付，GPU 大部分时间都在“热锅”而不是“炒菜”。动态批处理做的事情很简单：把短时间内到达的多个请求合并成一个批次，一次送进 GPU，让固定开销只付一次。

假设批处理一堆请求的总耗时由两部分组成：固定开销 $T_{overhead}$ 和每请求的计算时间 $T_{compute}$，则每请求平均耗时可用下面公式描述：

火锅店的铁锅不会因为一次炒四份饭就多烧一次锅，GPU 也不会因为一次推理四个请求就多启动四次内核。把固定开销摊薄，是动态批处理最本质的收益来源。理解了这一条，后面所有调优思路都是围绕它展开的。

请求到达模式

火锅店的客流有鲜明的潮汐：午餐十二点涌进一波客流，下午三点门可罗雀。服务员拼桌的效果，完全取决于当下有多少客人在等位。客流汹涌时，不用招呼就能坐满一桌；客流稀疏时，等上半小时也凑不齐四个人。

推理服务的请求到达同样有波峰波谷。波峰时，请求像潮水一样涌来，队列瞬间堆满，批次很快就攒够了；波谷时，半天来一个请求，批次一直凑不满。请求到达的密集程度，在数学上用一个量来刻画——到达率 $\lambda$，表示单位时间内平均到达的请求个数。到达率直接影响攒批的快慢，也决定了服务中积压的请求数量。

排队论里的 Little's Law 描述了积压量、到达率与等待时间之间的稳定关系。当系统处于稳定状态时，积压的请求数等于到达率乘以平均等待时间：

火锅店老板一看等位区的人越来越多，就知道要么客人来得太密，要么上菜太慢。对应到推理服务，队列积压上涨时，你需要判断是到达率飙升了，还是攒批等待把 $W$ 拖长了。请求到达模式决定了你在调参时的发力方向，波峰期要防积压，波谷期要防饿着 GPU。

批次大小决策

火锅店的桌子有四种规格：两人桌、四人桌、六人桌和大圆桌。服务员拼桌时，如果只有两位客人却坐六人桌，桌面空间浪费；如果硬塞十个人到六人桌，客人挤得难受，厨师一次也炒不了十人份。桌子大小，就是餐厅的“批次大小”。

在 ONNX Runtime 中，max_batch_size 决定了一次推理最多合并多少个请求。这个值不是拍脑袋定的：首先，GPU 显存是硬约束——批次越大，中间张量占用的显存越多，超出显存直接报错；其次，模型本身的延迟特性也有限制——有些模型批次增大后单请求耗时暴涨，收益急剧缩水。

批次大小与吞吐量的关系并非线性增长，而是遵循收益递减规律。设固定开销为 $a$，每个请求的计算时间为 $b$，则吞吐量 $S(B)$ 随批次大小 $B$ 的变化为：

火锅店老板发现，四人桌翻台效率最高，换成六人桌后上菜时间变长，客人满意度反而下降。调批次大小也是这个道理：找到吞吐量曲线的“拐点”，在显存允许的范围内选择一个让吞吐提升明显、延迟增加可接受的批次大小。记住，不是桌子越大越好，合适才是最好。

超时窗口机制

服务员小李有个苦恼：刚把两位客人领到四人桌，是立刻下单，还是等等看有没有新客人来拼桌？立刻下单，两位客人不用久等，但可能错过大单；一直等，客人可能不耐烦起身走人。餐厅定了个规矩：凑不齐四人，最多等三分钟，三分钟一到立刻下单。

这个“三分钟”就是动态批处理里的超时窗口（timeout）。在 ONNX Runtime 中，即使请求没有攒够 max_batch_size，只要达到超时窗口，也必须把现有请求作为一批送出去。超时窗口是吞吐量和延迟之间的调节旋钮：窗口越大，攒够批次的机会越多，但每个请求的等待时间也越长。

超时窗口的期望等待时间可以用一个简洁的概率表达式刻画：当批次在超时前未凑满时，请求需要等到超时时刻才能被处理；若批次提前凑满，则请求可以更早出发。因此平均等待时间近似等于超时窗口长度乘以“没凑满”的概率：

火锅店的“三分钟规则”本质上是在赌：三分钟内来新客人的概率高，拼桌成功，餐厅多赚钱；概率低，直接下单，至少保住眼前客人。超时窗口何尝不是一场赌博，赌的是请求到达的节律。调参时，观察业务的请求到达间隔分布，如果大多数请求都在几百毫秒内成群到达，窗口就不必设得太长。

吞吐量优化

火锅店的运营指标里有一个“翻台率”：一张桌子一晚上接待了几波客人。拼桌之所以让老板高兴，不是因为单桌客人多，而是因为同样的灶台、同样的桌位数，一晚上能服务更多客人。翻台率，就是餐厅的“吞吐量”。

在推理服务里，吞吐量指单位时间内成功完成的推理请求数。吞吐量的上限很大程度上取决于 GPU 在“炒菜”还是在“做准备工作”。如果 GPU 空转等待请求，或者反复做固定开销动作，它的有效工作时间占比就低。动态批处理正是让 GPU 忙碌起来的核心手段。

衡量 GPU 忙得有没有价值，要看有效计算时间占总时间的比例。批次大小为 B 时，GPU 利用率可以写为：

火锅店老板发现，只要铁锅一直不冷，翻台率自然就高。GPU 也一样，它的理想状态是“灶台从来不等菜”——请求到达后立刻攒批、立刻处理，处理完立刻接下一批。让 GPU 始终处于有效计算状态，吞吐量的提升是立竿见影的。调优的每一天，你都在回答同一个问题：GPU 有多少时间真正在炒菜？

延迟约束

火锅店里总有几位急躁的客人，落座后盯着手机看时间，三分钟不上菜就要发火。服务员心里有一根红线：不管怎么拼桌，不能让客人等超过五分钟。这根红线，就是服务等级协议（SLA）。

推理服务也有类似的红线，通常用 P95 或 P99 延迟来表达——95% 或 99% 的请求必须在某个时间上限内返回。动态批处理虽然提升吞吐，但也给请求增加了“等拼桌”的时间。所以调优不是一味地增大批次和超时窗口，而是要在 SLA 红线内做文章。

端到端延迟由排队等待、批处理计算和网络传输三部分组成。设延迟预算为 $T_{SLA}$，排队等待为 $T_{queue}$，网络传输为 $T_{network}$，则批次大小上限可以由 SLA 倒推出来：

火锅店宁可少拼一桌，也绝不让客人等超过五分钟。推理服务同样如此——一个突破了 P95 红线的模型，无论吞吐多漂亮，都是失败的部署。调优时先问自己：SLA 是多少？排队和网络占了多少？剩下的时间能支撑多大的批次？把预算算清楚，再回头调批次大小和超时窗口。

监控调优

火锅店打烊后，老板会掏出账本复盘：今晚翻台率多少？平均上菜时间几分钟？有没有客人等太久给差评？哪张桌子空置最久？这些数据决定了明天的拼桌策略。没有账本，一切调整都是拍脑袋。

推理服务同样需要“账本”来支撑调参决策。核心监控指标有四个：吞吐量（每秒处理请求数）、P95 延迟（SLA 是否越线）、GPU 利用率（资源是否吃饱）、队列积压（攒批是否过度）。这些指标实时跳动，直接观察容易被噪声干扰。ONNX Runtime 在实际调优中常采用指数移动平均（EMA）对监控数据做平滑处理：

火锅店老板根据账本发现：周末翻台率低是因为拼桌等待太久，于是把三分钟规则改成两分钟，果然差评少了。调优动态批处理也是一样的循环：观察监控指标，发现瓶颈，调整批次大小或超时窗口，再观察指标反馈。日拱一卒，滚动优化，才能让批处理策略始终贴合业务的真实流量节律。

AI 应用场景

Python 演示

import random  class DynamicBatcher:    """模拟 ONNX Runtime 动态批处理调度器。"""     def __init__(self, max_batch_size, timeout, process_time_per_item):        self.max_batch_size = max_batch_size        self.timeout = timeout        self.process_time_per_item = process_time_per_item        self.batch_count = 0        self.latency_sum = 0.0     def simulate(self, arrival_times):        """arrival_times 为升序排列的请求到达时间列表。"""        results = []        idx = 0        t = 0.0        pending = []        batch_open = None         while idx < len(arrival_times) or pending:            while idx < len(arrival_times) and arrival_times[idx] <= t:                pending.append(arrival_times[idx])                idx += 1             if not pending:                if idx < len(arrival_times):                    t = arrival_times[idx]                continue             if batch_open is None:                batch_open = t             if len(pending) >= self.max_batch_size:                t = self.dispatch(pending[:self.max_batch_size], t, results)                pending = pending[self.max_batch_size:]                batch_open = t            else:                deadline = batch_open + self.timeout                if idx < len(arrival_times) and arrival_times[idx] < deadline:                    t = arrival_times[idx]                else:                    t = deadline                    t = self.dispatch(pending, t, results)                    pending = []                    batch_open = t        return results     def dispatch(self, batch, start_time, results):        finish = start_time + len(batch) * self.process_time_per_item        for req in batch:            results.append((req, start_time, finish))            self.latency_sum += finish - req        self.batch_count += 1        return finish  def generate_arrivals(rate, duration):    """以给定速率生成泊松到达的请求时间序列。"""    times = []    t = 0.0    while t < duration:        t += random.expovariate(rate)        if t <= duration:            times.append(t)    return times  if __name__ == "__main__":    random.seed(42)    requests = generate_arrivals(rate=5.0, duration=60.0)    batcher = DynamicBatcher(max_batch_size=4, timeout=0.4,                             process_time_per_item=0.08)    result_list = batcher.simulate(requests)    count = len(result_list)    avg_latency = batcher.latency_sum / count if count else 0.0    end_time = max(f for _, _, f in result_list) if result_list else 0.0    throughput = count / end_time if end_time else 0.0    print("请求总数:", count)    print("合批次数:", batcher.batch_count)    print("平均延迟:", round(avg_latency, 3))    print("吞吐量:", round(throughput, 3))

1. while idx < len(arrival_times) or pending:只要还有请求没到达或队列中还有请求，调度器就持续运转。
2. while idx < len(arrival_times) and arrival_times[idx] <= t:把当前时刻之前到达的请求全部收入待处理队列，等价于服务员把新到客人领到等位区。
3. batch_open = t记录当前批次开始攒批的时刻，超时窗口从这一刻开始倒计时。
4. if len(pending) >= self.max_batch_size:队列里的请求攒够了批次上限，立即发批，不再等待超时。
5. deadline = batch_open + self.timeout计算超时截止时间：从批次打开时刻加上超时窗口。
6. if idx < len(arrival_times) and arrival_times[idx] < deadline:下一个请求会在超时前到达，那就推进时间到它到达的时刻，继续攒批。
7. t = self.dispatch(pending, t, results)超时到期或批次已满，把当前攒的请求作为一批送进"GPU"处理。
8. finish = start_time + len(batch) * self.process_time_per_item批次处理耗时等于请求数乘以单个请求计算时间，模拟批内顺序计算。
9. req, start_time, finish每个请求记录到达时间、批次开始时间和完成时间，为后续延迟统计提供数据。
10. random.expovariate(rate)生成符合泊松过程的时间间隔，模拟真实世界中“偶然成群”的请求到达模式。

常见误区

面试题