作者：昇腾实战派
性能优化专栏导航：Ascend（昇腾）性能优化文章导航

背景概述

在大语言模型（LLM）推理场景中，Qwen2-1.5B模型在Atlas 800I A2单卡部署下，P99端到端延迟（E2EL）未达预期，存在明显性能瓶颈。

为定位并解决该问题，本文围绕NPU推理性能展开系统性分析与调优，重点聚焦于算子执行效率、主机下发延迟及系统资源调度等关键环节，最终实现推理性能的显著提升。

• CANN：8.3.RC1
• PyTorch Adaptor: 2.1.0.post17

问题定位：性能瓶颈初步分析

在单机单卡环境下部署Qwen2-1.5B模型，分析显示，存在两个核心瓶颈：

1. 下发延迟问题：设备执行算子时，近50%的耗时因主机侧任务下发缓慢导致，表现为大量空泡（Free Time）；
2. 算子性能瓶颈：PpMatMul算子需深入分析其执行路径与资源占用情况。

算子级性能分析：聚焦关键路径

对A2平台的profiling数据进行深入分析，发现在硬件资源调度或数据搬运环节存在一定瓶颈。

复现与验证：跨平台性能一致性分析

为验证测试环境的可复现性，借用4090平台复现相同服务化配置（并发32/1200），使用sglang-0.4.5框架进行测试，初步判断为主机下发延迟导致的host-bound问题。

主机侧调优实践：KAT与KSYS协同分析

1. KAT自动调优尝试

使用鲲鹏自动调优工具KAT对TPOT指标进行调优，配置如下：

• 测试目标：TPOT
• 调优轮次：300
• 测试脚本：ais_bench

首次调优后TPOT优化34%。不过经复测发现，连续运行20轮后性能出现一定劣化，推测为系统参数扰动导致。

2. KSYS系统级分析

启用鲲鹏系统性能分析工具KSYS，采集多维度性能数据，包括Cache Miss、NUMA访问、微架构事件、热点函数等。

• Top-down分析显示：大部分时间消耗于backend bound，frontend bound较低，且ITLB miss较高，提示存在缓存或页表访问瓶颈；
• NUMA访问分析发现存在跨NUMA节点内存访问，导致延迟增加。

结合绑核方式分析，仅使用taskset绑核无法保证内存访问在同一NUMA节点，建议使用numactl -C [cpu] --membind [cpu] <exe_command>命令，实现CPU与内存的统一绑定。由于无法绑定已运行进程，采用Docker容器化部署方式实现相同效果。

优化建议与总结

1. 优先解决下发瓶颈：当前性能瓶颈主要源于主机侧算子下发延迟，建议通过CPU_AFFINITY_CONF=2开启细粒度绑核，将任务绑定至NPU对应NUMA节点的固定核心，减少调度开销与跨NUMA访问；
2. 优化内存绑定策略：使用numactl或容器化部署方式，确保CPU与内存绑定在同一NUMA节点，降低内存访问延迟；
3. 持续监控与调优：结合KSYS定期采集系统性能数据，关注Cache Miss、ITLB Miss等关键指标，及时发现潜在瓶颈；
4. 算子级优化：对PpMatMulBf16NdNzNdKernel等算子，可进一步分析其输入输出数据布局、分块策略与硬件资源利用率，探索算子融合或内存复用优化路径。

综上，通过系统性分析与多维度调优，可有效缓解NPU推理中的host-bound问题，显著提升大语言模型推理性能。后续建议结合模型结构与算子特性，开展更深层次的算子级优化与编译器调优。