NPU推理性能影响因素：计算单元利用率、内存带宽、数据搬运开销、算子调度等关键因素
在分析batch size对NPU推理吞吐量的影响之前，必须先建立对NPU性能决定因素的系统性认知。与CPU追求单线程低延迟、GPU擅长大规模并行计算不同，NPU（神经网络处理单元）的架构设计围绕“数据流驱动计算”展开，其性能表现由计算单元利用率、内存带宽、数据搬运开销和算子调度效率四个核心维度共同决定。这四个因素相互耦合，任何一个成为瓶颈都会限制整体吞吐量，而batch size的变化恰恰会同时作用于这四个维度，产生复杂的非线性影响。本章将逐一拆解这些关键因素，为后续batch size调优实验提供理论支撑。
上图展示了NPU推理性能的四个核心影响因素及其与计算核心的关系。在实际推理任务中，这四个因素并非独立作用，而是通过数据流和任务流紧密耦合。例如，增大batch size可以提升计算单元利用率（因为权重复用次数增加），但同时也会增加内存带宽压力和DMA搬运的数据量。理解这种耦合关系，是分析batch size对吞吐量影响的前提。
4.1 计算单元利用率：NPU效率的第一道闸门
核心原理
NPU的计算单元通常由大量MAC（乘累加）阵列组成，例如昇腾310P芯片集成了约24个AI Core，每个AI Core包含多个MAC单元。计算单元利用率（Compute Utilization Ratio）定义为实际生效的MAC操作次数与理论最大MAC操作次数之比。在理想情况下，每个时钟周期所有MAC单元都应执行有效计算，但实际中由于数据依赖、流水线停顿、控制开销等因素，利用率往往无法达到100%。
对于卷积层而言，计算单元利用率主要取决于输入特征图（IFM）和权重（Weight）的数据复用模式。当batch size=1时，每个输入特征图仅与权重做一次卷积运算，权重从片上缓存（如L1 Buffer）加载后仅被使用一次，导致权重加载开销占比高。而增大batch size后，同一份权重可以被多个输入样本复用，权重加载成本被摊薄，MAC单元的激活率显著提升。
判断方法
- 硬件计数器监控：使用NPU厂商提供的Profiling工具（如华为MindStudio Profiler、昇腾CANN的msprof）读取AI Core的MAC利用率、流水线空泡率等硬件计数器。
- 理论峰值对比：计算理论峰值算力（MAC数×频率），与实际吞吐量对比，估算利用率。例如某NPU理论算力为22 TOPS（即11 TMAC/s），若实测推理吞吐量为5.5 TMAC/s，则利用率为50%。
- 算子级分析：通过算子耗时占比反推——若某个卷积算子耗时远高于理论计算时间，说明计算单元利用率不足。
案例拆解：batch size从1到4的利用率变化
在某边缘推理场景中，使用ResNet-50模型在昇腾310P上测试。当batch size=1时，Profiling显示AI Core平均利用率仅为38%，大量时钟周期处于等待数据状态。将batch size提升至4后，利用率跃升至72%。关键变化在于：权重在L1 Buffer中的驻留时间延长，同一权重被连续用于4个输入样本的卷积计算，权重加载次数从原来的每样本一次降为每4样本一次。这直接减少了约60%的权重搬运指令，MAC阵列的空泡率从41%降至18%。
复盘要点：计算单元利用率与batch size并非线性关系。当batch size从1增至2时，利用率提升最明显（约20-30个百分点）；继续增大至8、16时，提升幅度逐渐收窄，因为其他因素（如内存带宽）开始成为新瓶颈。因此，调优时应先找到利用率曲线的“拐点”。
常见误区
误区1：认为利用率越高越好。实际上，当利用率超过90%后，继续增大batch size可能引发片上缓存溢出，导致数据被频繁换入换出，反而降低效率。误区2：忽略算子间的利用率差异。Conv3x3层通常利用率较高，而Depthwise卷积或全连接层利用率较低，应分别分析。
4.2 内存带宽：数据供给的“高速公路”
核心原理
NPU的内存层次通常包括：寄存器文件（RF）→ L0 Buffer → L1 Buffer → L2 Cache → 片外DRAM（HBM或DDR）。内存带宽决定了数据从片外DRAM搬运到片上缓存的速率。对于推理任务，权重和中间激活值都需要频繁访问内存。当batch size增大时，虽然权重复用率提升，但激活值（Activation）的数据量也随batch size线性增长——每个样本的中间特征图都需要独立存储和计算。
内存带宽瓶颈的典型表现是：计算单元等待数据的时间占比增加，即“算等数”现象。以ResNet-50为例，单张224×224×3输入图像，经过第一层卷积后产生112×112×64的特征图，约800KB数据。若batch size=16，则第一层激活值总量达12.8MB，远超L2 Cache容量（通常为几MB），必须频繁从DRAM读取。
判断方法
- 带宽利用率计算：通过Profiling获取实际DRAM读写字节数，除以推理耗时，得到实际带宽。与理论峰值带宽（如310P的HBM带宽为51.2GB/s）对比。
- 访存密集度分析：计算算子的算术强度（Arithmetic Intensity）= 计算量（FLOPs）/ 访存量（Bytes）。若算术强度低于NPU的“拐点强度”（通常为10-20 FLOPs/Byte），则属于访存密集型算子，受带宽限制。
- 缓存命中率监控：查看L2 Cache命中率，若低于70%，说明数据局部性差，带宽压力大。
案例拆解：带宽瓶颈下的batch size选择
在视频流分析场景中，使用YOLOv5s模型，输入为640×640×3。测试发现：当batch size从1增至8时，吞吐量从120 FPS提升至380 FPS，但继续增至16时，吞吐量仅微增至395 FPS。Profiling显示，batch size=8时DRAM带宽利用率已达92%，接近饱和。此时计算单元利用率虽仍有提升空间（约65%），但数据供给速度已跟不上计算速度。进一步分析发现，YOLOv5s的检测头（Detect Head）包含大量1×1卷积，算术强度仅约4 FLOPs/Byte，属于典型的访存密集型算子，严重依赖带宽。
调优启示：对于访存密集型模型，batch size并非越大越好。应通过带宽利用率曲线找到“饱和点”，在该点附近选择batch size。若需继续提升吞吐量，可考虑模型剪枝、量化或算子融合来降低访存量。
常见误区
误区：只关注DRAM带宽，忽略片上缓存带宽。实际上，L1/L2 Buffer的带宽同样有限。当batch size过大导致L2 Cache溢出时，数据在L2和DRAM之间频繁换入换出，产生“颠簸”现象，此时即使DRAM带宽未饱和，整体性能也会下降。
4.3 数据搬运开销：被忽视的“隐形杀手”
核心原理
数据搬运开销包括：DMA（Direct Memory Access）传输时间、片内缓存与计算单元之间的数据移动时间、以及数据格式转换（如NHWC转NCHW）的额外开销。在NPU推理中，数据搬运往往占据总耗时的30%-50%，甚至超过计算时间。batch size直接影响搬运的数据量和搬运次数。
具体而言，当batch size=1时，每个样本的输入数据、中间激活值、输出结果都需要单独搬运，搬运次数多但单次数据量小。增大batch size后，单次搬运的数据量增大，但搬运次数减少，DMA的启动开销（通常为微秒级）被摊薄。然而，若batch size过大，单次搬运的数据量超过DMA最大传输长度（如64KB），则需要分多次搬运，反而增加开销。
判断方法
- DMA耗时占比：通过Profiling查看DMA引擎的忙碌时间占总推理时间的比例。
- 搬运数据量统计：统计每个算子的输入/输出张量大小，计算总搬运字节数。
- 缓存复用分析：检查相邻算子之间是否存在数据复用——若算子A的输出是算子B的输入，且数据量小于L2 Cache容量，则可通过“就地计算”避免重复搬运。
案例拆解：数据搬运优化前后对比
在Transformer-based的NLP推理任务中（如BERT-base），原始实现中每个Transformer层包含多次矩阵乘法，每次矩阵乘法前后都有数据搬运。初始测试中，数据搬运耗时占总耗时的47%。通过以下优化：①将QKV投影矩阵合并为一个大矩阵，减少一次搬运；②使用算子融合（如将LayerNorm与残差相加融合），减少中间结果的写回和读取；③调整数据布局为连续内存块，提高DMA效率。优化后，数据搬运耗时占比降至29%，整体推理延迟降低22%。
关键经验：batch size对数据搬运的影响具有“双面性”。一方面，增大batch size可摊薄DMA启动开销；另一方面，若batch size导致中间激活值超出片上缓存容量，则会产生额外的搬运流量。因此，最优batch size往往与片上缓存容量密切相关。
常见误区
误区：认为数据搬运只与模型大小有关，与batch size无关。实际上，激活值数据量随batch size线性增长，当激活值超过L2 Cache容量时，搬运开销会急剧增加。建议通过计算“激活值总量 = 单样本激活值 × batch size”来预估缓存压力。
4.4 算子调度：多核并行与流水线编排
核心原理
NPU通常包含多个AI Core（如昇腾310P有24个AI Core），算子调度决定了如何将计算任务分配到各个核心上，以及如何安排算子之间的执行顺序。调度策略直接影响计算单元利用率和数据搬运效率。常见的调度方式包括：
- 数据并行：将batch维度的数据切分到不同核心，每个核心处理部分样本。适合batch size较大的场景。
- 算子并行：将单个算子拆分为多个子任务，分配到不同核心并行执行。适合单样本计算量大的场景。
- 流水线并行：将不同算子分配到不同核心，形成流水线，核心间通过片上网络传递中间结果。
batch size对调度的影响体现在：当batch size较小时，数据并行度不足，部分核心可能空闲；当batch size增大时，数据并行度提升，但核心间的同步开销和通信开销也随之增加。
判断方法
- 核心利用率均衡性：通过Profiling查看各AI Core的忙碌时间，若核心间利用率差异超过20%，说明调度不均衡。
- 同步等待时间：检查算子间是否存在同步屏障（Barrier），等待时间过长说明调度策略需优化。
- 任务粒度分析：计算每个算子的计算量（MAC数）与核心数的比值，若比值过小，则任务粒度太细，调度开销占比高。
案例拆解：调度策略调整带来的吞吐量提升
在图像分类任务中，使用EfficientNet-B0模型，初始调度策略为“算子级串行+数据并行”。当batch size=8时，24个AI Core中仅有16个核心参与计算（因为模型中间层特征图较小，数据切分后部分核心任务量不足），核心利用率仅为67%。通过调整调度策略为“算子级流水线+数据并行”，将Conv层和Pooling层分配到不同核心组，形成两级流水线。调整后，核心利用率提升至85%，吞吐量从210 FPS提升至275 FPS，提升31%。
调度调优建议：①对于小模型（如MobileNet），优先使用数据并行，增大batch size以填满核心；②对于大模型（如ResNet-152），可考虑算子并行与数据并行混合；③使用NPU厂商提供的自动调度器（如CANN的Auto Schedule），但需手动调整关键参数（如分块大小、流水线深度）。
常见误区
误区：认为增大batch size一定能提升核心利用率。实际上，当batch size超过核心数时，每个核心需要处理多个样本，若样本间存在数据依赖（如BatchNorm的全局统计量计算），则会产生额外的同步开销。此外，某些NPU的AI Core间通信带宽有限，过度并行可能导致通信成为新瓶颈。
4.5 四因素耦合分析与调优优先级
在实际推理系统中，四个因素往往同时作用，且存在复杂的耦合关系。下表总结了各因素在不同batch size阶段的主导地位：
| batch size范围 | 主导瓶颈 | 次要瓶颈 | 典型表现 |
|---|---|---|---|
| 1-2 | 计算单元利用率低 | 算子调度开销 | MAC空泡多，核心空闲 |
| 4-8 | 内存带宽 | 数据搬运 | DRAM带宽接近饱和 |
| 16-32 | 数据搬运/缓存容量 | 调度同步 | L2 Cache溢出，DMA频繁 |
| >32 | 调度通信开销 | 内存带宽 | 核心间通信延迟增加 |
调优优先级建议：首先通过Profiling确定当前batch size下的主要瓶颈因素，然后针对性地调整。例如，若计算单元利用率低于50%，优先增大batch size；若带宽利用率超过90%，则考虑模型压缩或算子融合；若核心利用率不均衡，则调整调度策略。
综合调优框架：①使用Profiling工具获取四类指标（MAC利用率、带宽利用率、DMA耗时占比、核心均衡度）；②绘制各指标随batch size的变化曲线；③找到“交叉点”——即计算单元利用率与带宽利用率同时较高（如均超过70%）的batch size区间；④在该区间内微调，结合延迟约束选择最优值。