3. Batch维度优化
在BM1688的推理性能优化中，Batch维度是最直接、最容易被误解的调优杠杆。Batch Size不仅决定了单次前向计算处理多少张图像或多少帧数据，还深刻影响着TPU（张量处理器）的算力利用率、DDR带宽占用、多核调度效率以及流水线排布方式。很多工程师在优化时只关注“把Batch调大”，却忽略了BM1688的算力特性、内存带宽限制以及业务延迟约束，导致性能不升反降。本章将系统拆解Batch Size对推理性能的影响机制，给出动态Batch与静态Batch的选型判断方法，并深入讲解Batch合并与拆分的实用技巧。
3.1 Batch Size对推理性能的影响机制
BM1688的TPU架构采用SIMD（单指令多数据）与脉动阵列混合设计，其计算单元在执行矩阵乘法和卷积运算时，天然适合将多个输入样本打包成张量进行批量计算。Batch Size对性能的影响可以从三个层面理解：算力利用率、内存带宽和调度开销。
从算力利用率角度看，当Batch Size=1时，TPU的脉动阵列往往只能利用到峰值算力的20%~40%。这是因为单样本推理时，卷积核的复用率低，计算单元在等待数据加载的过程中大量空闲。以BM1688的INT8算力（约32 TOPS）为例，实际测试中Batch=1的ResNet50推理仅能达到约8~12 TOPS的有效算力。当Batch Size提升到4时，有效算力可提升至20 TOPS以上；Batch=8时接近25 TOPS；继续增大到16以上，算力利用率趋于饱和，提升幅度明显放缓。
内存带宽方面，Batch Size增大意味着权重数据可以在多个样本间复用。以YOLOv8s模型为例，模型权重约22MB，若Batch=1，每处理一张图像都需要从DDR读取全部权重；Batch=8时，权重只需读取一次即可服务8张图像，等效带宽消耗降低为原来的1/8。但需要注意，Batch增大也会增加中间特征图的存储需求，可能触发DDR写回和重读，反而增加带宽压力。
调度开销是另一个容易被忽视的因素。BM1688的推理引擎在每次启动推理任务时，需要完成输入DMA搬运、任务下发、中断处理等操作，这些固定开销约为200~500μs。Batch=1时，这部分开销占单次推理总时长的比例可能高达15%~25%；Batch=8时，固定开销被摊薄到每个样本上，占比降至3%~5%。
核心结论：Batch Size对性能的影响呈“先陡升、后平缓、再下降”的曲线。陡升阶段（1→4）来自算力利用率提升；平缓阶段（4→16）是算力与带宽的平衡区；下降阶段（>32）通常由内存容量不足或DDR带宽饱和引起。实际调优时应通过实验找到拐点，而非盲目追求大Batch。
3.2 动态Batch与静态Batch的选择策略
静态Batch（Static Batch）指在模型编译时固定Batch维度，生成专用二进制。动态Batch（Dynamic Batch）则允许在运行时指定任意Batch大小，通常通过padding到固定上限或使用可变shape图实现。两者的选择取决于业务场景的输入到达模式。
静态Batch的适用条件：
- 输入均匀到达：例如离线批量处理、固定帧率的视频流分析，每帧间隔稳定，可以精确控制攒批数量。
- 延迟要求严格：静态Batch的编译优化更充分，算子融合和内存布局可以做到最优，单次推理延迟波动小。
- 吞吐优先：在离线评测、数据标注、批量审核等场景中，不关心单帧延迟，只关心每秒处理帧数（FPS）。
动态Batch的适用条件：
- 突发流量：例如安防监控中，白天多路视频并发，夜间只有少量通道活跃，动态Batch可以按需调整。
- 多路视频汇聚：不同通道的帧到达时间不同，动态Batch允许“来几帧算几帧”，避免等待。
- 混合负载：同时处理检测、分类、分割等不同模型，各模型的Batch需求不同。
判断方法上，建议先统计业务输入的到达间隔分布。若间隔的变异系数（CV = 标准差/均值）小于0.3，可视为均匀到达，优先考虑静态Batch；若CV大于0.5，则动态Batch更合适。此外，还需评估延迟预算：若单帧延迟要求小于50ms，动态Batch的攒批等待时间（通常5~20ms）可能不可接受，此时应使用静态Batch=1或小Batch。
| 对比维度 | 静态Batch | 动态Batch |
|---|---|---|
| 编译优化 | 充分，算子融合彻底 | 需保留可变维度，优化受限 |
| 延迟波动 | 低，P99稳定 | 高，受攒批等待影响 |
| 内存占用 | 固定，可精确预算 | 需预留最大Batch的buffer |
| 实现复杂度 | 低，编译时确定 | 高，需处理padding和调度 |
| 典型场景 | 离线批处理、固定帧率 | 多路视频、突发流量 |
经验建议：在BM1688上，动态Batch的实现通常采用“固定上限+padding”策略。例如设置最大Batch=8，实际到达5帧时，padding 3个空帧参与计算，但通过mask机制忽略padding帧的输出。这种方式比完全动态shape的实现更高效，因为TPU的编译优化可以针对最大shape进行。
3.3 Batch合并与拆分技巧
Batch合并（Batching）与拆分（Splitting）是解决“算力利用率”与“延迟约束”矛盾的核心手段。合并的目标是凑足足够的样本量以提升算力利用率；拆分的目的是将过大的Batch切分为多个子Batch，以降低单次推理的延迟和内存峰值。
Batch合并的三种典型模式：
- 时间维度合并：将时间上接近的多个请求攒在一起处理。例如视频分析中，等待5ms收集到4帧后一起推理。攒批时间（Batching Time）需要根据延迟预算动态调整。
- 空间维度合并：将多路输入拼接成一个大张量。例如4路1080P图像，每张缩放到640×640后，拼接为[4, 3, 640, 640]的张量一次推理。
- 模型维度合并：将多个小模型合并为一个大模型。例如将人脸检测和人体检测合并为一个多任务模型，共享Backbone，减少重复计算。
Batch拆分的应用场景：
- 内存限制：当Batch=16时，中间特征图占用超过可用SRAM，需要拆分为两个Batch=8的子任务。
- 延迟约束：某些实时交互场景要求单帧延迟小于20ms，Batch=8的推理延迟为35ms，需拆分为Batch=4。
- 多核并行：BM1688拥有多核TPU，将大Batch拆分为多个子Batch分配到不同核上并行执行，可进一步降低延迟。
实际操作中，合并与拆分需要结合BM1688的硬件特性。BM1688的TPU支持多核并行，但核间通信开销较大。当Batch较大时，建议将Batch维度切分到不同核上，每个核处理Batch的一部分，而不是将整个Batch串行处理。例如Batch=8时，可拆分为2个Batch=4分别在不同核上执行，理论上延迟可降低约40%，但需注意核间同步开销。
3.4 实战案例：多路视频分析平台的Batch调优
某智慧园区项目需要在BM1688上部署16路视频流分析，每路视频25FPS，使用YOLOv8s模型进行人员检测。初始方案采用静态Batch=1，每路视频独立推理，实测整体FPS仅为45，远低于16路×25FPS=400FPS的目标。
初始现象与关键指标：
- 单路推理延迟：28ms（Batch=1）
- TPU算力利用率：23%
- DDR带宽占用：4.2GB/s（峰值约12GB/s）
- CPU占用率：65%（主要消耗在DMA搬运和任务调度）
分析判断过程：通过性能分析工具发现，算力利用率过低是主要瓶颈。Batch=1时，脉动阵列大量空闲。同时，CPU占用率偏高，说明调度开销占比大。进一步统计16路视频的帧到达时间，发现各通道帧间隔均匀（CV=0.2），适合采用静态Batch合并策略。
实际操作步骤：
- 将16路视频分为4组，每组4路，每组内使用静态Batch=4合并推理。
- 设置攒批窗口为10ms，即每10ms收集各组的4帧图像，不足4帧时等待或padding。
- 将输入分辨率统一为640×640，拼接为[4, 3, 640, 640]张量。
- 使用BM1688的TPU多核特性，将4组推理任务分配到不同核上并行执行。
结果对比：
| 指标 | 优化前（Batch=1） | 优化后（Batch=4×4组） | 提升幅度 |
|---|---|---|---|
| 整体FPS | 45 | 380 | 744% |
| 算力利用率 | 23% | 78% | +55% |
| 单帧延迟 | 28ms | 32ms | +4ms（可接受） |
| CPU占用率 | 65% | 38% | -27% |
风险与代价：优化后单帧延迟增加了4ms，主要来自攒批等待。对于人员检测场景，32ms延迟仍满足实时性要求。但若未来接入延迟更敏感的交互应用，需将攒批窗口缩短至5ms，或改用动态Batch策略。此外，内存占用从优化前的1.2GB提升至1.8GB，仍在BM1688的4GB内存预算内。
常见误区提醒：
- 误区一：认为Batch越大越好。当Batch超过16后，DDR带宽可能成为新瓶颈，性能反而下降。
- 误区二：忽略padding开销。动态Batch中padding的空帧仍会参与计算，浪费算力。建议padding比例控制在20%以内。
- 误区三：静态Batch与动态Batch非此即彼。实际工程中常采用“静态Batch上限+动态调整”的混合策略。
- 误区四：只调Batch不调其他参数。Batch优化需与线程数、内存分配、视频解码参数协同调整，才能发挥最大效果。
复盘总结：Batch优化的本质是在算力利用率、延迟约束和内存带宽之间寻找平衡点。对于BM1688平台，建议先通过profiling工具获取算力利用率和DDR带宽数据，再结合业务延迟要求确定Batch策略。多路视频场景优先考虑静态Batch合并，突发流量场景则需动态Batch配合padding机制。Batch合并与拆分不是一次性的调优动作，而应随着业务负载变化持续迭代。