疑问描述
一、基础环境信息
1.CANN 版本：商用版
2.测试芯片（两款均复现同一现象）
￮场景 1（工单原始日志）：Ascend310P3 单卡
￮场景 2（本地自测）：Ascend950PR_9579 单卡
3.工具链：ATC + ais_bench 0.2-py3-none-any
4.模型：医学影像 ConvNeXtV2 分类模型，FP32 固定 Batch 编译，无动态 shape；输入规格 N, 3, 1024, 1024
5.ATC 编译命令示例（Batchsize=8）：atc --model patch_cls_convnextv2_1024.onnx --framework 5 --output patch_cls_convnextv2_b8_1024 --soc_version Ascend950PR_9579 --input_shape="input:8,3,1024,1024"
6.性能测试命令：python3 -m ais_bench --model xxx.om --debug 1
二、问题现象 & 两组实测数据
1）Ascend310P3（工单采集数据）
固定 Batch 编译 OM，单轮 NPU 纯计算耗时随 BatchSize 近似线性增长，吞吐几乎无提升：
BatchSize 单轮 NPU 计算耗时 (ms) 理论线性倍数 (相对 B1) 实测耗时倍数 (相对 B1) 吞吐 imgs/s
1 54.72 1x 1x 18.28
4 228.41 4x(54.724=218.88) 4.17x 17.51
8 465.73 8x(54.728=437.76) 8.51x 17.182）Ascend950PR_9579（本地自测 512 分辨率同结构模型）
输入N,3,512,512，同样出现线性耗时增长，单图平均延迟几乎不变，吞吐持平：
BatchSize NPU 纯计算耗时 (ms) 单图平均耗时 (ms / 张) 吞吐 imgs/s
1 3.42 3.42 292.14
4 9.89 2.47 404.65
8 19.93 2.49 401.36
统一核心现象
1.Batch 翻倍，整批总推理耗时近乎同步翻倍，单张图片分摊计算延迟几乎无下降；
2.模型整体吞吐基本持平，单纯扩大 Batch 无法提升单位时间处理图片总量；
3.ais_bench --debug 1 日志中 model aclExec cost 与输出NPU_compute_time完全匹配，瓶颈为 NPU 硬件纯计算，排除 CPU 数据拷贝、主机调度干扰；
三、已完成排查与调优验证（均无法解决 Batch 线性扩展问题）
1.性能 Profiling：使用 ms-prof 采集 NPU 流水、算子耗时明细，未发现单算子严重阻塞，但无法定位 Batch 无法并行加速的底层根因；
2.算子融合优化：ATC 开启全量融合策略，仅小幅降低基础单 Batch 延迟，不能改善多 Batch 并行利用率；
3.场景排除说明：纯图像分类 CNN 模型，无 LLM/Prefill 预填充流水逻辑，不存在大模型调度瓶颈；全程单卡运行，无多卡 HCCL 通信开销；
4.全量常规调优验证：模型量化、ATC 优化等级调整、输入输出内存复用、关闭 AIPP、动态 Gear 编译、算子单独重编译等手段均验证，Batch 线性耗时增长问题无改善；
5.分辨率对照测试：512/1024 两种高分辨率输入均复现问题，低分辨率小模型无此线性瓶颈。
四、诉求与咨询问题
1.底层根因咨询
高分辨率 ConvNeXtV2 含大量 Depthwise 卷积，在 310P3/950PR 芯片上扩展 Batch 时无法充分利用 NPU 多核并行算力，出现完美线性耗时增长，想确认根因归属：
•算子硬件并行度上限约束？
•片上缓存 / 外部 DDR 带宽跑满？
•ATC 编译调度策略未做多 Batch 并行切分？
•模型特征图尺寸过大带来的访存瓶颈？
2.针对性解决方案需求
不同batchsize对比.txt
前置检查
疑问描述
一、基础环境信息
1.CANN 版本：商用版
2.测试芯片（两款均复现同一现象）
￮场景 1（工单原始日志）：Ascend310P3 单卡
￮场景 2（本地自测）：Ascend950PR_9579 单卡
3.工具链：ATC + ais_bench 0.2-py3-none-any
4.模型：医学影像 ConvNeXtV2 分类模型，FP32 固定 Batch 编译，无动态 shape；输入规格 N, 3, 1024, 1024
5.ATC 编译命令示例（Batchsize=8）：atc --model patch_cls_convnextv2_1024.onnx --framework 5 --output patch_cls_convnextv2_b8_1024 --soc_version Ascend950PR_9579 --input_shape="input:8,3,1024,1024"
6.性能测试命令：python3 -m ais_bench --model xxx.om --debug 1
二、问题现象 & 两组实测数据
1）Ascend310P3（工单采集数据）
固定 Batch 编译 OM，单轮 NPU 纯计算耗时随 BatchSize 近似线性增长，吞吐几乎无提升：
BatchSize 单轮 NPU 计算耗时 (ms) 理论线性倍数 (相对 B1) 实测耗时倍数 (相对 B1) 吞吐 imgs/s
1 54.72 1x 1x 18.28
4 228.41 4x(54.724=218.88) 4.17x 17.51
8 465.73 8x(54.728=437.76) 8.51x 17.182）Ascend950PR_9579（本地自测 512 分辨率同结构模型）
输入N,3,512,512，同样出现线性耗时增长，单图平均延迟几乎不变，吞吐持平：
BatchSize NPU 纯计算耗时 (ms) 单图平均耗时 (ms / 张) 吞吐 imgs/s
1 3.42 3.42 292.14
4 9.89 2.47 404.65
8 19.93 2.49 401.36
统一核心现象
1.Batch 翻倍，整批总推理耗时近乎同步翻倍，单张图片分摊计算延迟几乎无下降；
2.模型整体吞吐基本持平，单纯扩大 Batch 无法提升单位时间处理图片总量；
3.ais_bench --debug 1 日志中 model aclExec cost 与输出NPU_compute_time完全匹配，瓶颈为 NPU 硬件纯计算，排除 CPU 数据拷贝、主机调度干扰；
三、已完成排查与调优验证（均无法解决 Batch 线性扩展问题）
1.性能 Profiling：使用 ms-prof 采集 NPU 流水、算子耗时明细，未发现单算子严重阻塞，但无法定位 Batch 无法并行加速的底层根因；
2.算子融合优化：ATC 开启全量融合策略，仅小幅降低基础单 Batch 延迟，不能改善多 Batch 并行利用率；
3.场景排除说明：纯图像分类 CNN 模型，无 LLM/Prefill 预填充流水逻辑，不存在大模型调度瓶颈；全程单卡运行，无多卡 HCCL 通信开销；
4.全量常规调优验证：模型量化、ATC 优化等级调整、输入输出内存复用、关闭 AIPP、动态 Gear 编译、算子单独重编译等手段均验证，Batch 线性耗时增长问题无改善；
5.分辨率对照测试：512/1024 两种高分辨率输入均复现问题，低分辨率小模型无此线性瓶颈。
四、诉求与咨询问题
1.底层根因咨询
高分辨率 ConvNeXtV2 含大量 Depthwise 卷积，在 310P3/950PR 芯片上扩展 Batch 时无法充分利用 NPU 多核并行算力，出现完美线性耗时增长，想确认根因归属：
•算子硬件并行度上限约束？
•片上缓存 / 外部 DDR 带宽跑满？
•ATC 编译调度策略未做多 Batch 并行切分？
•模型特征图尺寸过大带来的访存瓶颈？
2.针对性解决方案需求
不同batchsize对比.txt
前置检查