PyTorch模型迁移昇腾NPU：torch_npu部署与调优指南

最近在搞昇腾NPU上跑小模型的推理部署，发现不少朋友还是习惯性地先把模型放GPU上跑通，再回头考虑NPU迁移。实际上只要你的模型是以PyTorch写的，迁移到昇腾NPU并没有想象中那么复杂，核心就是torch_npu这个适配层。这篇文章我会从环境准备、代码迁移、性能调优到问题排查，完整走一遍我在实际项目里用torch_npu把小模型部署到昇腾910B上的过程，给你一份能直接照着做的参考。

1. 迁移前先想清楚：torch_npu到底解决了什么问题

1.1 昇腾NPU部署小模型的现实需求

先说说什么场景下你会需要把模型迁到昇腾NPU。现在很多业务线在推理侧会用到embedding模型、reranker模型、一些小规模的分类模型或者生成模型，比如7B以下的LLM。这类模型的特点是单卡能放下、延迟要求高、并发量可能不小，而且往往是RAG链路里的一个环节。如果整条链路都跑在GPU上，成本压力会比较大，昇腾NPU作为国产算力，价格和采购渠道上有明显优势。所以很多团队会开始尝试把这类小模型迁移到昇腾环境上跑推理。

但说起“迁移”，不少人的第一反应是“又要改一堆代码”，实际上在PyTorch生态下，昇腾官方提供了torch_npu，它就是一个桥接层，把PyTorch的算子调用映射到NPU上。对于大部分标准模型结构，代码改动量很小，甚至只需要改几行设备指定相关的代码就能跑起来。

1.2 torch_npu是什么，它解决什么

torch_npu的核心作用可以理解为：让PyTorch在昇腾NPU上能像在CUDA上一样工作。它实现了一套NPU后端的算子库、内存管理、设备管理和图编译能力。你写的torch.nn.Module、torch.Tensor、torch.optim这些接口在NPU上依然可用，只需要把.cuda()换成.npu()，把device='cuda'换成device='npu'。

这里需要特别说明的是，torch_npu并不是把所有PyTorch算子都重新写了一遍，它底层依赖CANN（昇腾的异构计算架构）提供算子库和运行时。你的模型如果在GPU上用的是比较常规的算子，比如Linear、LayerNorm、Attention、GELU这些，大概率都能在CANN的算子库中找到对应实现。如果用到一些特别冷门的自定义算子，可能就需要走torch_npu.contrib或者自定义算子编译的路子，这个后面会讲到。

所以在迁移之前，我强烈建议你先做一次算子兼容性评估。如果你的模型代码里有大量自定义的CUDA算子、或者依赖了某个只在CUDA上实现的第三方库，那迁移成本会明显增加。但如果模型主体都是标准PyTorch算子，迁移就很顺。

1.3 迁移前必须确认的硬件与软件环境

昇腾NPU的部署和GPU有个很大的区别：它不是一个单纯的“插上卡装驱动”就能跑的环境，你必须要装一套完整的CANN软件栈，并且要确保CANN版本、PyTorch版本、torch_npu版本三者互相兼容。版本不匹配是新手最容易踩的坑，我遇到过很多次因为torch_npu和CANN版本对不上导致运行时报各种奇怪错误的情况。

在动手之前，建议你先确认好以下信息：

• NPU型号：昇腾310、910A、910B，不同型号对应的算力、显存、算子支持情况有差异
• CANN版本：8.0.RC1、8.0.RC2等，不同版本对PyTorch的支持有差异
• PyTorch版本：1.11.0、2.0.1、2.1.0、2.3.0等，不同PyTorch版本需要对应不同的torch_npu版本
• 操作系统：目前昇腾环境以openEuler、Ubuntu为主，CentOS也有支持，但建议优先用官方文档里列出的版本

我建议你直接把官方“版本配套表”打开，对着表来选版本。不要自己去“试试看”，这一步没有捷径。

2. 环境准备：CANN、PyTorch、torch_npu的版本搭配与安装

2.1 版本匹配关系

我目前用的比较稳的一套组合是：Ubuntu 22.04 + CANN 8.0.RC1 + Python 3.8 + PyTorch 2.1.0 + torch_npu 2.1.0.post5。这套组合在昇腾910B上跑过embedding模型、reranker模型、Stable Diffusion等，整体比较稳定。

torch_npu和PyTorch的版本对应关系比较严格，我整理了一个常用对照表：

需要注意，这个表不是官方完整版，只是我实测过或看社区反馈比较稳的组合。建议安装前一定去昇腾社区官网查一下最新的“CANN 版本配套表”和“torch_npu 版本配套表”，因为昇腾的迭代节奏很快，可能过几个月官方就推荐新的组合了。

2.2 安装步骤

昇腾NPU环境的安装流程大致是：先装NPU驱动和固件，再装CANN工具包，最后装PyTorch和torch_npu。驱动和固件一般由运维或基础设施团队搞定，如果是从零开始，建议严格按照官方文档操作，因为涉及到内核模块加载、重启等环节，每一步错了都可能导致NPU不可用。

我自己在开发机上安装的经验是，驱动和固件安装完成后，用npu-smi info命令能看到NPU卡的信息，就说明底层环境OK了。这一步确认很重要，如果npu-smi看不到卡，后面的所有操作都是白搭。

CANN的安装相对简单，就是解压后执行安装脚本，但要注意设置环境变量。通常需要把CANN的set_env.sh加到~/.bashrc里，这样每次登录终端就能自动加载CANN的路径和库。

bash复制# 以CANN 8.0.RC1安装到 /usr/local/Ascend 为例
source /usr/local/Ascend/ascend-toolkit/set_env.sh
echo "source /usr/local/Ascend/ascend-toolkit/set_env.sh" >> ~/.bashrc

然后是安装PyTorch和torch_npu。这里有个细节：torch_npu的安装包有两种方式，一种是从昇腾社区下载torch_npu的whl包直接安装，另一种是通过pip从华为云的镜像源安装。我建议直接按官方的安装命令来，因为不同版本的安装命令略有差异。

以torch 2.1.0和torch_npu 2.1.0.post5为例：

bash复制# 先安装PyTorch，注意要用官方指定的版本
pip3 install torch==2.1.0

# 再安装torch_npu，这里用华为云镜像
pip3 install torch_npu==2.1.0.post5 -i https://repo.huaweicloud.com/repository/pypi/simple

有一些版本还需要额外的依赖，比如decorator、numpy、psutil这些常规库，以及可能需要的aitransfer、opbay等CANN自带的组件。如果安装过程中报缺少依赖，用pip直接装就行。

2.3 验证安装是否成功

装完后一定不要急着跑模型，先跑一个最简单的验证脚本，确认torch_npu能正常调用NPU。否则后面出问题了，你会分不清是环境问题还是代码问题。

python复制import torch
import torch_npu

# 检查NPU是否可用
print(torch.npu.is_available())

# 查看NPU数量
print(torch.npu.device_count())

# 查看NPU名称
print(torch.npu.get_device_name(0))

# 创建一个在NPU上的tensor，跑一个简单的矩阵乘法
a = torch.randn(3, 4).npu()
b = torch.randn(4, 5).npu()
c = torch.matmul(a, b)
print(c)

如果这段代码能正常输出结果，说明环境OK了。输出torch.npu.is_available()为True，device_count()大于0，就说明你已经在NPU环境下跑通了最基本的计算。我每次在新机器上配置环境，都会用这个脚本来做冒烟测试，能省很多排查时间。

3. 代码迁移三步走：device、数据和模型加载

3.1 最小改动：从CUDA到NPU的device适配

环境就绪后，迁移的核心就是改代码了。对于大多数PyTorch模型，迁移其实就是“查找替换”式的改动，把cuda相关的地方替换成npu相关的地方。我总结了一个最小的改动清单：

第一步，导入torch_npu：

python复制import torch
import torch_npu

之后，在你通常设置device的地方，从cuda改成npu：

python复制# 原来
# device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

# 现在
device = torch.device("npu" if torch.npu.is_available() else "cpu")

第二步，把模型和数据从GPU搬到NPU：

python复制# 原来
# model.to(device)
# inputs = inputs.cuda()

# 现在
model.to(device)
inputs = inputs.npu()
labels = labels.npu()

第三步，如果你的代码里有显式判断CUDA情况的逻辑，比如torch.cuda.set_device(0)、torch.cuda.get_device_name(0)之类的，统一替换为torch.npu.set_device(0)、torch.npu.get_device_name(0)。

这里有一个比较实用的细节：如果你的代码里大量使用了inputs.cuda()这种写法，可以通过自定义一个工具函数来统一处理设备迁移，避免在几十个地方做同样的改动：

python复制def to_device(batch, device):
    if isinstance(batch, torch.Tensor):
        return batch.to(device)
    elif isinstance(batch, dict):
        return {k: to_device(v, device) for k, v in batch.items()}
    elif isinstance(batch, list):
        return [to_device(v, device) for v in batch]
    else:
        return batch

这样在训练或推理循环里只用改一行：batch = to_device(batch, device)。

3.2 数据加载与Dataset的适配

数据加载这一块，如果你的代码用的是torch.utils.data.DataLoader，在NPU上基本不用改。但我实际使用中发现，有一个问题需要特别注意：NumPy和PyTorch之间的数据转换，在某些情况下会隐式把数据放到CPU上，导致后续NPU计算时报错。

比如在自定义Dataset的__getitem__里返回了NumPy数组，DataLoader的collate_fn默认会把它转成torch.Tensor，这个Tensor是在CPU上的，然后你在训练循环里再调用.npu()搬到NPU。这个流程正常来说没问题，但如果collate_fn写的是自定义逻辑，比如直接对NumPy数组做一些操作后再转Tensor，就要确保最终返回的是Tensor对象。

我建议在自定义Dataset的__getitem__里就直接返回Tensor，不要返回NumPy数组，这样能减少一层隐式转换：

python复制class MyDataset(torch.utils.data.Dataset):
    def __getitem__(self, index):
        # 直接把图片或文本转成Tensor返回
        input_ids = torch.tensor(self.input_ids[index], dtype=torch.long)
        attention_mask = torch.tensor(self.attention_mask[index], dtype=torch.long)
        labels = torch.tensor(self.labels[index], dtype=torch.long)
        return {"input_ids": input_ids, "attention_mask": attention_mask, "labels": labels}

还有一个容易踩坑的地方：torch.utils.data.DataLoader的num_workers参数。在昇腾NPU环境下，num_workers设置过大可能会导致数据加载线程频繁切换，甚至出现内存拷贝错误。我实测下来，小模型推理场景下num_workers=2或4就够了，不需要盲目拉高。

3.3 模型保存加载与权重转换

模型保存和加载这一块，大部分情况下可以直接沿用PyTorch的state_dict方式。你在GPU上训练好的模型权重，在NPU上直接加载也是能用的，因为都是浮点数值，不存在格式转换问题。

有一个注意事项：如果你是在GPU上保存的模型，权重里有model.xxx.weight这种格式，直接torch.load到NPU环境时，要确保加载时不指定map_location='cpu'或map_location='cuda'，最好是先加载到CPU，再显式model.to(device)搬到NPU。这样可以避免一些因为设备不匹配导致的加载异常。

python复制model = MyModel()
state_dict = torch.load("model.pt", map_location="cpu")
model.load_state_dict(state_dict)
model.to(device)

我遇到过一种情况：同一个模型在GPU上保存时，因为model被放在DataParallel或DistributedDataParallel包装下，state_dict的key前面多了一个module.前缀。加载到NPU环境之前，需要先去掉这个前缀：

python复制state_dict = torch.load("model.pt", map_location="cpu")
new_state_dict = {}
for k, v in state_dict.items():
    if k.startswith("module."):
        new_state_dict[k[len("module."):]] = v
    else:
        new_state_dict[k] = v
model.load_state_dict(new_state_dict)

3.4 关于动态shape与静态shape

这是我在迁移过程中花了最多时间调的一个点。昇腾NPU和GPU在架构上有很大差异，其中一个核心差异在于：NPU对动态shape的支持不如GPU那么“顺滑”。GPU上动态shape很常见，你随时可以喂不同长度的输入；但NPU如果频繁出现shape变化，可能会导致算子重新编译、图重建，推理延迟显著上升。

所以我强烈建议：在小模型部署到NPU之前，先把输入padding到固定长度，或者在推理前设置好静态shape。比如一个文本分类模型，可以把max_length固定为128或256，所有batch内的样本都padding到这个长度。这样做的好处有两个：一是算子可以预先编译成最优的二进制，推理延迟更稳定；二是可以避免因输入shape变化导致的一些兼容性报错。

如果你的业务确实需要处理不同长度的输入，有一个折中的做法：把输入按长度分批，比如长度在0-128的一批，128-256的一批，每批内用固定shape。这样在性能和灵活性之间做了一个平衡。

4. 推理性能调优：从能跑到跑得快

4.1 使用图模式提升执行效率

代码迁移跑通之后，大多数人会遇到的问题是：为什么在NPU上的推理比GPU慢？这个问题很可能不是NPU本身算力不行，而是你没有启用图模式。

PyTorch默认是动态图（Eager模式），每个算子单独调度执行。在GPU上，CUDA的算子执行开销相对较小，差距不那么明显。但在NPU上，算子调度的开销占比会更高，尤其是小模型场景下，单算子执行时间短，调度开销就成为了主要瓶颈。

torch_npu提供了图模式支持，可以把整个模型编译成一个静态计算图，一次性执行。我建议用torch_npu.contrib里提供的pytorch_ascend模块，或者直接用torch.compile配合npu后端：

python复制import torch
import torch_npu

model = MyModel().to("npu")
model.eval()

# 方式一：使用图模式编译
model = torch.compile(model, backend="torch_npu")

# 方式二：如果模型比较简单，可以用AOE辅助调优
# 通过grep torch_npu源码里提供的graph模式接口

我实测过，在一个BERT-base规模的文本分类模型上，启用图模式后推理延迟能降低30%-50%。不过需要提醒的是，torch.compile对模型代码有一定要求——如果你的模型里有动态控制流（比如循环次数取决于输入长度、条件分支），编译过程可能会失败或性能不升反降。

如果没有用torch.compile成功，还有另一个方式：用CANN的aclgrph接口做手动图编译。不过这需要你对CANN的底层API有一定了解，上手门槛略高。对于大多数场景，torch.compile已经够用了。

4.2 混合精度与INT8量化

NPU上有专门的AI Core处理单元，对低精度计算有硬件的加速支持，所以在NPU上做混合精度推理，收益比GPU上更明显。

最直接的方式是启用FP16推理。在PyTorch里，最简单的做法是：

python复制model.half()  # 或者 model.to(torch.float16)

然后把输入也都转成FP16：

python复制inputs = inputs.half().npu()

实测下来，FP16推理在昇腾910B上的速度大约是FP32的1.5-2倍，显存占用也几乎减半。如果你的模型对精度要求不是极高，FP16是一个性价比很高的选择。

进一步还可以考虑INT8量化。torch_npu本身提供了量化支持，可以通过torch_npu.quantization模块来做PTQ（训练后量化）。我处理过一个7B左右的模型，INT8量化后显存占用从原来的约15G降到约8G，推理速度提升明显。

不过量化需要格外注意精度损失，如果模型输出的结果和FP16有明显的质量差异，建议做量化前后对比测试。尤其是reranker这类对排序精度敏感的模型，量化不当会导致排序效果下降，直接影响RAG的检索质量。

4.3 批量推理与数据搬运优化

小模型部署时，很多人会忽略批量推理的收益。因为模型本身小，单条样本的推理延迟可能只有几毫秒，但吞吐量往往不需要太高。如果你的场景是离线批量处理，比如知识库里的文档向量化，那批量推理能让NPU的利用率大幅提升。

我实践下来的一个经验是：在embedding模型上，把batch size从1提升到32，吞吐量能提升10倍以上，而且单条延迟不会明显增加。原因在于批量推理时矩阵乘法的计算密度更高，NPU的AI Core利用率更充分。

python复制# 批量推理示例
batch_size = 32
all_embeddings = []
for i in range(0, len(input_ids), batch_size):
    batch_input_ids = torch.tensor(input_ids[i:i+batch_size], dtype=torch.long).npu()
    batch_attention_mask = torch.tensor(attention_mask[i:i+batch_size], dtype=torch.long).npu()
    with torch.no_grad():
        embeddings = model(input_ids=batch_input_ids, attention_mask=batch_attention_mask)
    all_embeddings.append(embeddings.cpu().numpy())

数据搬运优化也值得关注。NPU和CPU之间的数据拷贝带宽是有限的，如果每次推理都频繁把数据从CPU搬到NPU再搬回来，会成为性能瓶颈。我建议尽量把数据准备工作放在批量维度上完成，而不是每一条单独搬运。

如果你用FastAPI做服务化部署，可以考虑在请求进来后先攒一个小batch（比如4-8条）再处理，用时间换吞吐量。虽然单条请求的等待时间会略有增加，但整体QPS能提升不少。

4.4 使用Profiling工具定位性能瓶颈

调优不能靠猜，一定要用工具。CANN自带的Profiling工具是msprof，通过它可以获取NPU上的算子耗时、CPU耗时、数据传输耗时等。用法大概是：

bash复制# 启动某个python脚本并采集profiling数据
msprof --output=./prof_data --application="python3 infer.py"

采集完成后会生成一个文件夹，里面有算子耗时统计、NPU利用率、内存占用等信息。你可以通过工具把这些数据可视化，直观看到哪个算子耗时最长，然后针对性地优化。

我遇到过一种情况：模型里有一个LayerNorm算子耗时异常高，后来发现是因为我把模型放在了torch.compile的图模式里，但LayerNorm被拆分成了多个小算子，导致执行开销增加。后来换成了融合版本（比如把LayerNorm替换成RmsNorm的融合算子），性能就上来了。

另外，torch_npu自带了一些性能分析的接口，比如torch.npu.profile，用法和torch.profiler类似，也可以用来定位CPU和NPU之间的时间线。

python复制import torch
import torch_npu

with torch.npu.profile(activities=[torch.profiler.ProfilerActivity.CPU,
                                   torch.profiler.ProfilerActivity.NPU]):
    for _ in range(10):
        output = model(inputs)

4.5 多卡部署与并发

小模型单卡一般就能放下，但如果并发量很高，就需要考虑多卡负载均衡。昇腾NPU的多卡部署方式相对灵活，你可以用torch.nn.DataParallel或分布式推理在多张NPU上并行处理不同的请求。

我建议用更轻量的方式：在服务化部署时，启动多个进程，每个进程绑定一张NPU卡，然后通过负载均衡把请求分发到不同进程。这样实现简单，而且隔离性好，单卡故障不会影响其他卡上的服务。

bash复制# 在启动服务前指定使用哪张NPU卡
export ASCEND_RT_VISIBLE_DEVICES=0
python3 serve.py --port 8000

# 另一个进程用卡1
export ASCEND_RT_VISIBLE_DEVICES=1
python3 serve.py --port 8001

这种多进程方式比多线程在NPU上更可靠，因为NPU资源的调度和线程的绑定关系处理起来更复杂，进程级隔离更省心。

5. 常见问题与排查实录

5.1 torch_npu与CANN版本不匹配导致加载失败

这个是最常见的问题，报错通常是类似于：

code复制ImportError: libascendcl.so: cannot open shared object file

或者：

code复制RuntimeError: Failed to initialize the runtime: 501001

遇到这种问题，先检查CANN的set_env.sh是否真的生效了，再检查torch_npu的版本是否和CANN配套。我建议在安装torch_npu之前，先把CANN环境变量打印出来看看：

bash复制echo $ASCEND_HOME_DIR
echo $LD_LIBRARY_PATH

如果LD_LIBRARY_PATH里没有包含CANN的lib64目录，说明环境变量没生效，你需要手动source或检查是否写错了路径。

如果确认环境变量没问题但还是报错，那就是版本不配套。建议去昇腾社区查对应的版本配套关系，然后重装torch_npu到匹配的版本。

5.2 算子不支持或编译失败

如果你的模型在GPU上能跑，但迁移到NPU时出现了类似：

code复制NotImplementedError: The operator 'xxx' is not supported

或者：

code复制RuntimeError: PTA op xxx: not support on NPU

说明有算子不兼容。解决方案有几个：

第一个方案：替换成支持算子。比如某些模型用了torch.where、torch.gather等算子，可能有兼容性问题。可以用更基础的算子组合实现同样的逻辑，或者用CANN算子库中对应的替代算子。

第二个方案：使用torch_npu.contrib里提供的一些兼容性module。比如某些第三方库（如transformers）里的模型，如果直接用可能会触发不支持的算子，可以先尝试引入torch_npu.contrib.transformer相关模块。

第三个方案：如果是自研的模型，考虑把不支持的算子合并到支持算子中。比如把自定义的F.silu替换成CANN支持的F.silu版本，或者用F.gelu(approximate='tanh')代替一些特殊的激活函数实现。

我建议尽量沿着第一个和第三个方案走，因为torch_npu.contrib目前覆盖的模型类型还不够全面，依赖它可能会限制模型的灵活性。

5.3 显存不足（NPU OOM）

小模型虽然单卡一般能放下，但如果你用的是批量推理或者长序列输入，还是可能遇到显存不足的问题。NPU上显存不足的报错通常是：

code复制RuntimeError: NPU out of memory. Tried to allocate ... bytes

排查思路和GPU差不多：先看有没有其他进程占用了NPU显存。用npu-smi info查看每张卡的显存使用情况，确认自己用的卡是否有足够空闲显存。

如果确认显存足够但还是OOM，大概率是模型的中间激活值占用了大量显存。可以尝试以下方法：

• 降低batch size
• 使用混合精度（model.half()）
• 启用torch.no_grad()和不保存梯度
• 如果你做了INT8量化，检查一下量化后的模型是否真的加载成功

另外有一个NPU特有的点：NPU的显存碎片化问题比GPU更明显。如果你频繁创建和释放Tensor，可能导致显存碎片化加剧，最终OOM。我建议推理场景尽量复用Tensor缓冲区，避免频繁的torch.tensor(...).npu()操作。

5.4 CPU与NPU数据搬运速度慢

数据搬运慢在NPU上是个常见的性能瓶颈。你可能发现模型在NPU上算得很快，但整体推理延迟还是很高，这时候就要检查是不是CPU到NPU的数据搬运时间占比太大。

一个典型的场景是：每次推理前，都需要把输入从CPU搬到NPU。如果你的输入本身就很大（比如长文本的token IDs），搬运时间会很明显。我建议把输入数据做成固定size的批量Tensor，一次性搬运，或者把数据预处理（比如tokenizer）放在独立的线程里，与NPU计算并行。

另外一个优化思路是：在服务启动时就把tokenizer和模型都初始化好，避免推理过程中反复加载。很多新手会在每个请求里创建tokenizer实例，这是非常影响性能的坏习惯。

5.5 输出结果与GPU不一致（精度问题）

如果你发现模型在NPU上的输出和GPU上略有不同，多数情况下是正常的。原因是不同硬件上的算子实现可能有微小差异，尤其是浮点运算顺序不同会带来精度损失。

但如果你发现输出差异很大，或者某个任务效果明显变差，需要检查以下几点：

• 是否用了混合精度？FP16的动态范围小，可能在大数值场景下溢出。尝试用FP32比较一下
• 是否用了量化？INT8量化可能对某些层影响较大，尝试只量化部分层
• 是否有随机行为？dropout在推理模式下应该关闭，确认model.eval()是否调用

我建议在部署前做一个“黄金测试”：准备一批固定的测试样本，在GPU上用FP32跑一遍，保存输出作为基准，然后在NPU上分别用FP32、FP16跑一遍，对比输出差异。如果FP16的差异在可接受范围内（比如余弦相似度大于0.99），就可以放心用。

5.6 常见问题速查表

6. 给新人的几条实操建议

6.1 先从最简单的模型开始练手

如果你是第一次接触昇腾NPU，不要一上来就迁移一个复杂的生成式大模型。建议先从BERT、RoBERTa之类的文本分类模型，或者一个简单的CNN图像分类模型开始，用官方文档里的示例跑通一遍，体会从安装环境到代码迁移的完整流程。

我自己第一次迁移时就是从一个小规模的embedding模型入手的。当时也踩了不少坑，但因为有GPU上的实现作参照，出了错能对比排查，很快就能定位问题。等你熟悉了这套流程，再迁移更复杂的模型，会顺手很多。

6.2 性能调优要有基准

迁移代码跑通只是第一步，性能是否能满足上线要求是另一回事。我建议在开始调优之前，先记录一份基准数据：当前模型的单次推理延迟、吞吐量、显存占用。然后每一次优化动作（比如开图模式、开混合精度、改静态shape）都重新测一次，记录下来进行对比。这样做有一个好处：你能清楚知道每一种优化手段的实际收益是多少，不会被一些“玄学调优”带偏方向。

我经常用的测试方法是：用相同的输入跑100次推理，取平均延迟，同时记录profiling数据。在对比优化前后时，保证输入数据、batch size、并发数完全一致，这样结果才有参考价值。

6.3 服务化部署时注意进程和线程的差异

如果你使用FastAPI之类的框架做服务化部署，我建议用进程级别而不是线程级别的并发。因为NPU设备的上下文管理比较复杂，多线程共享一个NPU上下文时，容易出现资源竞争和不可预期的错误。

我目前的项目架构是：每个Worker进程绑定一张NPU卡，进程内单线程处理请求。前面用Nginx或内部负载均衡器做请求转发。这样既简单又稳定，而且横向扩展也很方便——增加Worker进程数量就能提高吞吐量。

6.4 日志与监控要及时加上

部署上线前，记得加上日志和监控。NPU的实时状态可以通过npu-smi info查看，但你需要一个自动化的监控方案，定期采集NPU利用率、显存使用量和温度。

bash复制# 用crontab定时采集NPU状态
*/1 * * * * npu-smi info >> /var/log/npu_smi.log 2>&1

另外，代码里建议为每一次推理记录延迟和输入shape，方便后续排查问题。如果某个请求延迟突然异常，可以通过日志快速定位，而不是靠猜。

最后分享一点我的实际体会

昇腾NPU的生态和CUDA相比确实还有差距，但在小模型推理这个场景里，它已经是一个可以稳定运行的选项了。迁移过程没有想象中那么可怕，核心就是理解好device管理、算子兼容性、性能调优这几件事。我见过不少项目从一开始“觉得NPU这不行那不行”，到后面跑得顺顺当当，差别就在于愿不愿意花时间去踩坑和总结。如果你正在做小模型在NPU上的部署，遇到问题不要慌，先把版本关系理清楚，把最小验证跑通，再逐步加复杂度，这个思路能让你少走很多弯路。