本文目录一、问题背景二、调优全流程1.初步问题定位2.采集Profiling数据采集方法3.用MindStudio分析数据4.根因分析5.针对性优化方案5.1换框架5.2PyTorch原地优化三、优化效果四、经验总结工具推荐一、问题背景最近做了个模型迁移的项目遇到了个典型的性能问题。原本在英伟达GPU上跑得好好的小模型推理时间稳定在1秒左右结果迁移到华为昇腾300I Duo卡后整个流程耗时飙到了1.5秒。具体场景是这样的原环境NVIDIA GPU vLLM框架端到端推理时间 ~1.0s新环境昇腾300I Duo PyTorch迁移方案推理数据下发总耗时 ~1.5s核心差异昇腾推理结果默认留在NPU设备上需要额外调用.to(cpu)把数据搬到主机内存50%的性能倒退显然不能接受于是开始了这次调优之旅。二、调优全流程1.初步问题定位一开始的思路很直接——既然多了个.to(cpu)操作那性能损失肯定在这儿。于是我分别统计了两段耗时importtime# 推理阶段starttime.time()outputmodel(input_ids)infer_timetime.time()-start# 数据下发阶段starttime.time()output_cpuoutput.to(cpu)transfer_timetime.time()-startprint(f推理耗时:{infer_time:.3f}s)print(f下发耗时:{transfer_time:.3f}s)窗口上显示的结果让我更确信了这个判断transfer_time占了大头。基于这个错误的定位我尝试了几种优化手段用异步拷贝减少等待时间调整数据传输的batch size换了几种不同的tensor格式结果全都效果不佳甚至有的方案反而更慢了。这时候意识到可能方向搞错了。2.采集Profiling数据既然凭感觉不靠谱那就上工具。昇腾提供了PyTorch Profiler接口可以精确记录每个算子的执行时间。采集方法在推理代码里插入profiling代码参考官方文档importtorchimporttorch_npufromtorch_npu.profilerimportprofile# 在推理代码外层包裹profilerwithprofile(activities[torch_npu.profiler.ProfilerActivity.CPU,torch_npu.profiler.ProfilerActivity.NPU],record_shapesTrue,profile_memoryTrue,with_stackTrue)asprof:# 你的推理代码withtorch.no_grad():outputmodel(input_ids)output_cpuoutput.to(cpu)# 确保数据同步重要torch_npu.npu.synchronize()# 导出profiling结果prof.export_chrome_trace(./profiling_result.json)采集时的两个坑采集不到数据原因CPU和NPU是异步执行的你打印时间戳的时候NPU可能还在跑解决在prof.stop()之前加上torch_npu.npu.synchronize()强制同步循环场景下数据丢失原因prof.step()是用来标记每轮迭代的如果只跑一次推理可能触发不了采集解决单次推理场景下直接删掉prof.step()3.用MindStudio分析数据采集完数据后用MindStudio打开profiling_result.json下载地址见官方文档。打开Timeline视图后有了关键的发型.to(cpu)算子本身只花了约20ms并且真正的时间黑洞在推理阶段的几个核心算子上之前的下发耗时其实包含了NPU推理的等待时间——因为Python层面打印时间戳的时候NPU还没跑完也就是说问题不是数据传输慢而是推理本身变慢了。4.根因分析通过对比Timeline上的算子执行情况定位到几个性能瓶颈算子调度开销大小模型的单个算子执行时间短微秒级但PyTorch调度overhead相对明显内存拷贝碎片化频繁的小tensor拷贝导致带宽利用率低动态编译损耗首次推理时算子需要JIT编译即使是第二次推理也有编译缓存查询的开销5.针对性优化方案基于上面的分析有两条路可以走5.1换框架昇腾针对小模型场景优化了专用推理框架1. TorchAIR框架仓库地址https://gitee.com/ascend/torchair核心优势图编译优化将PyTorch动态图编译成静态执行图减少调度开销适用场景模型结构固定batch size变化不大2. MindIE-Torch框架文档地址https://www.hiascend.com/document/detail/zh/mindie/20RC2/mindietorch/Torchdev/mindie_torch0002.html核心优势算子融合内存优化针对Transformer类小模型有专项优化适用场景Encoder-only或小型生成模型这两个框架的改造成本都不高基本只需要替换推理入口即可。5.2PyTorch原地优化如果业务限制不能换框架可以试试下面几个调优开关1. 启用流水优化针对Host-bound场景# 在启动脚本中设置环境变量exportTASK_QUEUE_ENABLE2这个参数让NPU的任务队列管理更激进减少CPU-NPU之间的同步等待。实测在小batch场景下能提速15%-20%。2. 禁用算子在线编译importtorch_npu# 在模型加载后、推理前设置torch_npu.npu.set_compile_mode(jit_compileFalse)torch_npu.npu.config.allow_internal_formatFalse原理解释第一行关闭JIT编译强制使用预编译算子库第二行禁止算子内部格式转换比如自动转NZ格式减少不必要的layout变换版本要求驱动固件23.0.3CANN工具包8.0.RC1⚠️ 老版本设置这两个参数无效必须先升级3. 完整优化代码示例importtorchimporttorch_npuimportos# 1. 设置环境变量os.environ[TASK_QUEUE_ENABLE]2# 2. 模型加载modelYourModel().to(npu:0)model.eval()# 3. 编译优化torch_npu.npu.set_compile_mode(jit_compileFalse)torch_npu.npu.config.allow_internal_formatFalse# 4. Warmup重要让算子预热充分withtorch.no_grad():dummy_inputtorch.randn(batch_size,seq_len).to(npu:0)for_inrange(10):_model(dummy_input)torch_npu.npu.synchronize()# 5. 正式推理withtorch.no_grad():outputmodel(input_ids)output_cpuoutput.to(cpu)三、优化效果经过上述优化我们最终采用了方案B的组合优化性能数据如下阶段优化前优化后提升幅度NPU推理~1.3s~0.65s50%数据下发~0.2s~0.05s75%总耗时1.5s0.7s53%最终的0.7秒不仅达到了迁移前的水平甚至还快了30%证明昇腾硬件在小模型场景下的潜力其实不错关键是要用对方法。四、经验总结不要相信第一感觉最开始觉得是.to(cpu)的问题结果profiling后发现完全不是。性能问题一定要用工具定位不能靠猜。Profiling是必备技能MindStudio的Timeline视图非常直观能精确到每个算子的微秒级耗时。建议每个做昇腾开发的同学都学会用。Warmup很重要昇腾NPU首次推理会慢很多算子编译缓存预热线上服务一定要做充分的warmup。版本很关键很多优化特性只在新版本CANN里支持升级驱动和工具包往往能直接解决问题。工具推荐MindStudio性能分析必备Timeline Operator视图能覆盖90%的调优场景npu-smi类似nvidia-smi实时查看NPU利用率和显存占用AscendCL Profiler底层算子级profiling适合深度优化这次调优让我对昇腾生态有了新的认识。坦白说工具链确实没有CUDA那么成熟踩了不少坑但整体体验在快速变好。特别是CANN 8.0之后很多之前需要手动hack的地方都有了官方方案。如果你也在做昇腾迁移或者性能调优欢迎交流经验。遇到问题先查官方文档文档没有的话社区论坛响应也挺快。