端侧推理批处理优化策略

可视化演示

交互展示动态批调度、请求合并和小batch高效推理等端侧批处理优化策略，理解如何在资源受限设备上提升推理效率。

端云批处理差异

阿杰的餐车只有一个灶，中央厨房却有二十口锅。中央厨房的做法是：积压两三百份订单后一次性开火，每份订单分摊的燃料成本微乎其微；餐车要是照抄，别说锅放不下，光等两三百人到齐，客人早就走光了。小锅永远不可能用大锅的玩法。

把多个推理请求放进同一次前向计算，就叫批处理（Batch），一次放入的数量叫批量（batch size）。云端 GPU 显存大、功耗预算足，批量动辄 64、128；端侧手机、摄像头只有几 GB 内存共享给系统和各种 App，批量上限常常只有 1 到 8。这不是不想用大批量，而是“锅”真的只有这么大。

端侧与云端的根本差异，藏在每次推理的固定开销里。每次开火都有所谓的启动成本：加载算子、搬运权重、预留激活内存。批量越大，这笔成本被摊得越薄，云端的做法是用大 B 把均摊成本压到可以忽略；端侧则必须面对“小 B 摊不动”的残酷现实，把每一分固定开销都用在刀刃上。

$$\displaystyle T_{avg}(B) = \frac{C_{fixed}}{B} + C_{per}$$

1. 固定开销$C_{fixed}$：每次推理启动都要付出的一次性成本，与批量无关，包括加载算子、搬运权重、初始化内存等。

$$C_{fixed}$$

2. 批量均摊：把固定成本除以批量 B，得到每个请求分到的开火份额。

$$\frac{C_{fixed}}{B}$$

3. 单请求增量$C_{per}$：每个请求本身消耗的计算时间，随模型大小和输入长度增长，与批量关系不大。

$$C_{per}$$

4. 汇总公式：单请求均摊耗时等于平摊后的固定开销，再加上每个请求自身的计算量。

$$T_{avg}(B) = \frac{C_{fixed}}{B} + C_{per}$$

所以阿杰从不贪心：一锅四份，刚刚好。端侧工程师的原则同样是“小锅出精品”——与其盲目追求大批量，不如先把固定开销的账算清楚，等学会了攒单和融合，小锅也能转出大厨房的效率。

请求合并机制

阿杰最头疼的是订单稀稀拉拉地来：这个客人刚走，下一个五分钟后才到。若来一份炒一份，开火成本高得吓人。他学聪明了：立一块“正在备餐，30 秒内继续接单”的牌子，把同一时段内的订单凑成一锅炒，既不让灶台频繁空烧，也不让客人等太久。

这就是请求合并（Request Batching）：服务层不立刻推理每个请求，而是把它们放进等待队列，攒够一定数量或等满一个时间窗口再统一处理。端侧引擎常用“窗口 + 上限 + 超时”三件套：窗口决定攒单时长（如 30ms），上限决定一锅最多几份（如 4），超时兜底保证窗口到了哪怕没凑满也必须开火。三者共同构成一个最朴素的队列调度模型。

合并的收益可以用到达速率与窗口估算。请求到达越快、窗口越长，攒到的批量越大，均摊越划算；但窗口过长又会拖长每个请求的等待。因此窗口、上限、超时三个旋钮必须一起调，让灶台“恰好接住”客流，而不是等着等着把客人都等跑了。

$$\displaystyle E[B] = \lambda \times W$$

1. 到达速率$\lambda$：单位时间内到达合并队列的平均请求数，如每秒 100 个请求。

$$\lambda$$

2. 窗口时长$W$：引擎愿意等待合并的最长时间，也就是“继续接单”的牌子挂多久。

$$W$$

3. 期望批量：窗口内平均攒到的请求数，等于到达速率乘以窗口时长。

$$E[B] = \lambda \times W$$

4. 上限约束：实际批量还要被最大批量钳制，超过锅的容量就得分锅。

$$B_{actual} = \min\left(\lambda \times W,\ B_{max}\right)$$

就像餐车的“继续接单”牌既不让客人干等太久、又让灶台尽量少空烧，端侧引擎通过窗口与超时的配合，在“等得起”与“多接单”之间找到了平衡点。

小批量高效推理

就算一锅只有四份，阿杰还是觉得亏：每次开火都要先烧油预热。于是他干脆把洗菜、切菜、炒菜合并成一道流水工序——同一个灶台，边切边炒。省掉一次“重新点火”，就省下一大笔固定成本，出餐速度肉眼可见地快了。

端侧推理里的“重新点火”就是算子启动开销：每执行一个算子，都要分配内存、搬运数据、启动计算内核。当 batch=1 时，固定开销可能占总耗时的 60% 以上，锅几乎都在“烧油”而不是“炒菜”。改善方向有两个：一是凑小批量把开销摊薄，二是算子融合——把“卷积 + 归一化 + 激活”这类连续算子合并成一个复合算子，一次启动完成多步计算，大幅减少内存读写次数。

此外，端侧还常配合内存复用：让多个算子在同一个暂存区上接力，避免反复申请、释放内存。小批量、算子融合、内存复用三者叠加，即使每个 batch 只有 2 到 4 个请求，也能把算力利用率拉得很高。

$$\displaystyle \eta_{overhead}(B) = \frac{C_{fixed}}{C_{fixed} + B \times C_{per}}, \quad T_{fused} = C_{fused} + B \times C_{per}$$

1. 总耗时构成：一次推理总时长由固定启动开销加上批量计算量组成。

$$T = C_{fixed} + B \times C_{per}$$

2. 开销占比：固定开销在总时长中的比例，B 越小占比越高。

$$\eta(B) = \frac{C_{fixed}}{C_{fixed} + B \times C_{per}}$$

3. 最坏情形：当 B=1 时占比达到最大，逐条推理最浪费。

$$\eta(1) = \frac{C_{fixed}}{C_{fixed} + C_{per}}$$

4. 融合之后：多个算子合并后启动开销从 $C_{fixed}$ 降到 $C_{fused}$，远小于原值。

$$T_{fused} = C_{fused} + B \times C_{per},\quad C_{fused} \ll C_{fixed}$$

阿杰的灶不再频繁“冷启动”，端侧模型也不再为每个算子支付启动税。记住：端侧优化的重点不是把锅换大，而是让每一次开火都物尽其用。

性能指标评估

阿杰开始给自己记账：一分钟出了几份餐（吞吐量），客人平均等了几分钟（延迟），灶台有多少时间在真正炒菜（利用率）。没有账本，改火候全凭拍脑袋，生意越做越糊涂。记账之后，他才明白哪些调整真的有用。

端侧批处理的核心指标同样是这三样：吞吐量指单位时间完成的请求数，端到端延迟指请求从进入排队到返回结果的全程耗时，资源利用率看算力、内存和电耗的忙碌比例。其中吞吐和延迟是一对天生的冤家——批量 B 增大，吞吐上升、均摊开销下降，但每个请求要排队等更久，峰值内存也更高。

从公式看，端到端延迟等于排队等待加上均摊计算时间；吞吐等于批量除以每批耗时。调参的实质就是：在延迟红线内把吞吐推到最高。比如产品要求最大 100ms 延迟，那窗口就得定在 20ms 以下，给计算留 80ms 的余量。

$$\displaystyle L(B) = L_{wait} + \frac{C_{fixed}}{B} + C_{per}, \qquad \Phi(B) = \frac{B}{C_{fixed} + B \times C_{per}}$$

1. 等待延迟$L_{wait}$：请求在合并队列中等待的时间，平均约为窗口时长的一半。

$$L_{wait} \approx \frac{W}{2}$$

2. 均摊计算：合并后每个请求分到的固定开销部分。

$$\frac{C_{fixed}}{B}$$

3. 端到端延迟：总延迟等于等待时间加均摊计算时间加单请求计算量。

$$L(B) = L_{wait} + \frac{C_{fixed}}{B} + C_{per}$$

4. 吞吐量：单位时间完成的请求数，等于批量除以每批总耗时，B 增大时整体上先升后稳。

$$\Phi(B) = \frac{B}{C_{fixed} + B \times C_{per}}$$

阿杰的账本让“何时开火、一锅几份”有了依据；端侧工程师也依靠这三项指标，把 batch 调优从玄学变成了一门可以复盘的工程学。

端侧调优实践

阿杰后来发现：高峰时段客人多，一锅四份不够用；深夜客人少，四份又凑不齐。于是他给灶台装了档位——人多时一锅六份，人少时一锅两份，火候跟着订单走。灵活，才是小锅的生存之道。

这就是动态批大小（dynamic batching）：根据实时排队长度、内存余量、延迟水位，动态调整批量与合并窗口。排队多且内存够，就加大批量；排队少，就缩短窗口、尽快开火。实现上要求模型支持 1 到 N 的任意批量，用动态 batch 维度而非固定 padding，避免无效计算浪费。请求还要有优先级：实时交互请求排前面，优先被包进下一锅；后台批量任务排后面，有空位再补。

端侧调优离不开性能剖析工具：profiling 能展示每个算子的耗时与内存峰值，帮工程师找出“烧油最狠”的环节。一套完整的调参流程是：先定延迟预算，再选初始批量与窗口，然后实测吞吐与内存，接着调旋钮，最后回归验证。每一步都要拿数据说话，循环迭代直到达标。

$$\displaystyle B_{max} = \left\lfloor \frac{M_{avail}}{M_{model} + M_{act}} \right\rfloor$$

1. 可用内存$M_{avail}$：端侧设备当前能分配给推理的内存余量。

$$M_{avail}$$

2. 单位需求：每个 batch 单位需要的内存，包含模型权重和激活值两部分。

$$M_{model} + M_{act}$$

3. 向下取整：用可用内存除以单位需求后向下取整，保证绝不超内存。

$$\left\lfloor \frac{M_{avail}}{M_{model} + M_{act}} \right\rfloor$$

4. 完整上限公式：实际批量不得超过这个内存上限，动态调整时先算它再定档位。

$$B_{max} = \left\lfloor \frac{M_{avail}}{M_{model} + M_{act}} \right\rfloor$$

火候跟着订单走，档次跟着现场调——端侧引擎的动态调度，让每一分算力都花在当下最需要的请求上，而不是被一套死参数绑住手脚。

部署落地场景

阿杰的餐车偶尔也会遇到“神仙单”：一单要十份，小锅实在接不住。他把单子转给隔壁中央厨房，代价是多几分钟配送时间。于是定下规矩：本地能做的本地做，本地做不动的再上云。这条规矩，也是端云协同推理的雏形。

端侧部署最常见的场景是端云协同：模型裁剪后跑在本地，轻量请求由本地小批量处理；重活、大批量请求通过网络抛给云端大厨房。选择的依据就是端到端延迟对比：本地延迟比“云加网络”延迟小就走本地，否则上云。弱网环境下端侧优先，强网环境下云端分担，两头都吃满。

另一个高频场景是流式合并：实时字幕、语音转写会源源不断产生碎片请求，端侧引擎按固定时间片把同一时间片内的碎片聚成微型 batch，逐段推理，既保持流式的低延迟感，又享受合并红利。多 App 并发时也一样，不同应用的请求可以在同一个模型服务里汇入同一个队列，统一合并推理，避免每个 App 各开一灶。

$$\displaystyle L_{hybrid} = \min\left(L_{edge},\ L_{cloud} + L_{net}\right)$$

1. 纯端延迟$L_{edge}$：请求在本地完成批处理等待与计算的总耗时。

$$L_{edge} = L_{wait} + L_{compute}^{(edge)}$$

2. 云侧方案$L_{cloud} + L_{net}$：请求上传到云端推理，再加上网络往返的时间。

$$L_{cloud} + L_{net}$$

3. 择优选择：实际延迟取本地与云端两条路中较小者。

$$L_{hybrid} = \min\left(L_{edge},\ L_{cloud} + L_{net}\right)$$

小锅有自己的边界，也有自己的智慧。端侧批处理不是云端的缩小版，而是一套围绕受限资源的完整生存哲学：能合并就合并，能本地就本地，剩下的交给云端接力。

AI 应用场景

Python 演示

import time FIXED_OVERHEAD = 0.02  # 每次推理启动固定开销 20msPER_REQUEST = 0.01     # 每个请求增量计算 10msBATCH_SIZE = 4  def infer_batch(batch):    # 模拟一次端侧批量推理：固定开销 + 随批量增长的计算量    time.sleep(FIXED_OVERHEAD + len(batch) * PER_REQUEST)    return [x + 1 for x in batch]  def run_standalone(requests):    start = time.time()    for req in requests:        infer_batch([req])    return time.time() - start  def run_merged(requests, max_batch=BATCH_SIZE):    start = time.time()    for i in range(0, len(requests), max_batch):        infer_batch(requests[i:i + max_batch])    return time.time() - start  def main():    requests = list(range(9))    t1 = run_standalone(requests)    t2 = run_merged(requests)    print("Standalone time: %.3f s" % t1)    print("Merged batch time: %.3f s" % t2)    print("Group sizes:", [len(requests[i:i + BATCH_SIZE]) for i in range(0, len(requests), BATCH_SIZE)])    print("Speedup: %.2f x" % (t1 / t2))  if __name__ == "__main__":    main()

1. FIXED_OVERHEAD = 0.02模拟每次推理开火的固定成本：加载算子、搬运权重，与批量无关。
2. time.sleep(FIXED_OVERHEAD + len(batch) * PER_REQUEST)一次推理耗时 = 固定开销 + 批量 × 单请求增量，正是均摊公式的核心。
3. infer_batch([req])逐条推理时每个请求单独开一次火，固定开销被重复支付。
4. range(0, len(requests), max_batch)按最大批量把请求切成若干组，模拟请求合并的凑批过程。
5. requests[i:i + max_batch]一组请求合并为同一个 batch 输入，一次前向计算完成多个请求。
6. (t1 / t2)计算逐条处理与合并处理的总耗时比，即加速比，代码直接印证理论值。

常见误区

面试题