3、batch size概念解析：batch size的定义、在推理中的角色、与吞吐量和延迟的关系
在深度学习推理的性能优化中，batch size（批大小）是最基础、也最容易被低估的杠杆。它直接决定了计算单元（如NPU的AI Core、向量单元）的利用率，进而影响推理服务的吞吐量（Throughput）和延迟（Latency）。理解batch size的本质，是进行后续实测分析和调优的前提。本节将从定义出发，厘清其在推理链路中的位置，并重点剖析它与吞吐量、延迟之间的“跷跷板”关系。
3.1 batch size的定义与本质
Batch size（批大小）在推理场景中，指的是一次前向传播（Forward Pass）中，NPU同时处理的样本数量。与训练阶段不同，推理时的batch size通常由服务端的请求聚合策略决定，而非由数据集预先划分。例如，当客户端并发发送32个推理请求时，服务端可以选择将它们打包为一个batch=32的输入张量（Tensor），一次性交给NPU计算。
从硬件视角看，NPU（如昇腾910B、英伟达A100等）内部包含大量并行计算单元（AI Core、Tensor Core）。这些单元擅长执行矩阵乘法和向量运算。当batch size=1时，计算单元往往处于“半饥饿”状态——因为单样本的矩阵维度可能不足以填满所有计算流水线。而增大batch size，本质上是将多个独立样本的相同计算图叠加，形成更高维度的矩阵运算，从而提升计算密度。
3.2 推理中batch size的角色定位
在推理服务链路中，batch size扮演着“计算打包器”的角色。它位于请求调度层与NPU执行层之间，是连接并发请求与硬件算力的桥梁。具体而言，其角色体现在以下三个层面：
- 计算密度提升器：将多个请求的相同算子（如MatMul、Conv2D）合并为批量运算，减少算子启动开销和内核（Kernel）调度次数。
- 内存带宽利用调节器：较大的batch size可以更好地复用权重数据（Weight），降低权重从HBM/DDR加载到片上SRAM的重复开销。
- 延迟与吞吐的权衡杠杆：batch size增大时，单个请求的排队时间增加，但整体吞吐量上升；反之，batch size减小则延迟降低，但吞吐量下降。
在NPU推理框架（如MindSpore、TensorRT、ONNX Runtime）中，batch size通常作为动态维度（Dynamic Shape）或静态维度（Static Shape）存在。静态batch size便于编译器做极致优化（如算子融合、内存复用），但灵活性差；动态batch size则更适应真实业务波动，但可能损失部分优化空间。
3.3 与吞吐量的关系：非线性增长与拐点
吞吐量（Throughput）通常定义为单位时间内完成的推理请求数（单位：req/s或samples/s）。在理想情况下，吞吐量应随batch size线性增长——因为计算资源被更充分地利用。然而，实际NPU系统中，这种增长是非线性的，并存在明显的收益递减拐点。
其背后的机制包括：
- 计算资源饱和：当batch size达到NPU计算单元的最大并行度后，继续增大batch只会增加内存访问压力，而计算时间不再显著缩短。
- 内存带宽瓶颈：NPU的HBM带宽有限。当batch size过大时，数据搬运时间（DMA）成为主要矛盾，计算单元开始等待数据。
- 算子融合失效：部分融合算子（如Conv+BN+ReLU）在超大batch下可能因中间结果存储压力而被迫拆分为多个小算子，增加额外开销。
| Batch Size | 计算时间 (ms) | 吞吐量 (samples/s) | 单样本平均延迟 (ms) | 备注 |
|---|---|---|---|---|
| 1 | 2.0 | 500 | 2.0 | 计算单元利用率低 |
| 4 | 4.5 | 889 | 1.125 | 利用率显著提升 |
| 8 | 7.2 | 1111 | 0.9 | 接近最优区域 |
| 16 | 13.0 | 1231 | 0.8125 | 吞吐增速放缓 |
| 32 | 25.6 | 1250 | 0.8 | 拐点出现，收益递减 |
| 64 | 52.0 | 1231 | 0.8125 | 吞吐量开始下降 |
上表展示了一个典型NPU推理场景的实测数据（假设模型为ResNet-50，输入224x224x3）。可以看到，当batch size从1增加到16时，吞吐量提升明显；但超过16后，吞吐量增长趋于平缓，甚至在batch=64时出现下降。这是因为内存带宽已饱和，且计算单元利用率达到上限。
3.4 与延迟的关系：排队论与P99指标
延迟（Latency）通常指单个请求从提交到返回结果的完整时间，包括网络传输、排队等待、NPU计算和后处理。batch size对延迟的影响是双重的：
- 计算延迟（Compute Latency）：增大batch size后，单个样本的平均计算时间会缩短（因为分摊了固定开销），但整个batch的总计算时间会增加。
- 排队延迟（Queueing Latency）：当服务端为了凑齐一个较大的batch而等待更多请求时，先到的请求必须等待后到的请求，导致排队延迟增加。
在实时推理场景（如在线推荐、自动驾驶）中，我们更关注P99延迟（即99%的请求延迟低于该值）。如果盲目增大batch size，虽然平均延迟可能下降，但P99延迟会急剧恶化——因为尾部请求需要等待更长时间才能凑齐batch。
3.5 案例拆解：图像分类服务的batch size调优
背景与约束：某AI安防平台部署了一个基于昇腾310B NPU的图像分类服务，输入为1080P视频帧，模型为ResNet-18。业务要求：吞吐量不低于800 FPS（帧/秒），且P99延迟不超过50ms。当前服务使用batch size=1，实测吞吐量仅420 FPS，P99延迟为22ms，吞吐量不达标。
初始现象与目标：工程师决定通过增大batch size来提升吞吐量，但担心延迟超标。目标是在满足P99≤50ms的前提下，将吞吐量提升至800 FPS以上。
关键输入数据：通过NPU Profiler工具采集到以下数据：
- batch=1时：AI Core利用率仅35%，内存带宽利用率28%，算子启动开销占比15%。
- batch=4时：AI Core利用率升至62%，带宽利用率45%，算子启动开销降至6%。
- batch=8时：AI Core利用率78%，带宽利用率70%，算子启动开销降至3%。
分析判断过程：从数据看，batch=4和batch=8都能显著提升计算密度。但需要评估排队延迟的影响。服务端采用动态batching策略，最大等待时间为10ms。在batch=8时，凑齐8个请求的平均等待时间为8ms（假设请求到达率为1000 req/s），加上计算时间12ms，总延迟约20ms，P99可能达到45ms，接近上限。
实际操作步骤：
- 将batch size从1调整为4，并设置最大排队等待时间为5ms。
- 重新编译模型，开启算子融合（如Conv+BN+ReLU融合）。
- 使用NPU Profiler验证AI Core利用率提升至65%以上。
- 进行压测：模拟1000并发请求，持续10分钟。
结果对比：
| 指标 | Batch=1（原） | Batch=4（优化后） | 变化 |
|---|---|---|---|
| 吞吐量 | 420 FPS | 860 FPS | ↑104.8% |
| P99延迟 | 22 ms | 38 ms | ↑16 ms（仍达标） |
| AI Core利用率 | 35% | 65% | ↑30% |
风险与代价：P99延迟从22ms升至38ms，虽然仍低于50ms阈值，但余量变小。如果未来请求量波动增大，可能导致P99超限。为此，团队设置了动态batching开关：当P99延迟超过45ms时，自动将batch size降为2，以牺牲部分吞吐量换取延迟稳定。
复盘经验：batch size调优不是一次性工作，而是需要结合实时流量特征和硬件性能计数器持续调整。最优batch size通常位于“AI Core利用率接近80%但内存带宽未饱和”的区域。
3.6 常见误区与总结复盘
在实际项目中，工程师对batch size的理解常存在以下误区：
- 误区一：认为batch size越大越好。实际上，超过拐点后，吞吐量不再增长，反而因内存压力导致性能下降。
- 误区二：只关注平均延迟，忽略P99延迟。在交互式应用中，P99延迟决定了用户体验的“最差情况”，比平均值更重要。
- 误区三：静态设置batch size，不随负载变化。真实业务的请求到达率是波动的，固定batch size要么导致延迟超标，要么导致吞吐量浪费。
- 误区四：忽略NPU与GPU的差异。NPU的调度粒度、内存层次（如昇腾的L2 Buffer）与GPU不同，最优batch size的规律可能不同，必须基于实测数据。