企业官网建设流程全解析

1. 先搞清楚Atlas 300V 24G到底是张什么卡

最近好几个做视觉检测的朋友来问我同一个问题：Atlas 300V 24G是运算加速卡吗？能不能用来部署YOLO？我猜你们多半是在选型阶段看到了这张卡，被"24G"这个数字吸引了，但又拿不准它和GPU到底有什么区别。先说结论：Atlas 300V 24G确确实实是一张AI运算加速卡，但你要把它当成普通显卡来用，那后面的坑一个接一个。

它本质上是华为昇腾系列里的一块推理卡，核心芯片是昇腾310P系列，整卡走PCIe接口插到服务器上，24G指的是板载内存容量。注意关键词是"推理"——官方定位就是做AI推理加速，不是拿来跑训练，也不是拿来当显示输出卡用。这和NVIDIA的RTX系列、A100这类训练/通用计算卡有本质区别，但和你熟悉的T4、A10这类推理卡定位是同一个赛道。

24G容量能干什么？说直白点，绝大多数CV模型、NLP模型的推理部署都能覆盖。比如YOLOv5s、YOLOv7-tiny这类轻量模型，单张卡甚至可以塞下好几个实例；即便是YOLOv8m、YOLOv8l这种中等体量的模型，24G也完全够用，还能留出余量开大batch。我做过的实际案例里，一张卡同时部署两个YOLOv5s模型加上一个OCR检测模型，内存占用也就刚过半。

但是要提醒一句：这块卡不是拿到手装上驱动就能像CUDA那样直接跑PyTorch。它的计算架构是达芬奇架构，软件栈走的是CANN（Ascend Computing Language）体系，模型要先转换成OM格式才能高效运行。这意味着你的部署链路会多出不少工作——模型转换、算子适配、推理代码重写。很多人第一次接触时觉得麻烦，但一旦把流程走通，后面换模型其实就是改改转换参数的事，并没有想象中那么难。

从适用人群来说，如果你正在做工业质检、智慧安防、视频结构化这类偏推理侧的视觉项目，或者你在做边缘服务器的算力选型，这块卡是值得认真考虑的。它的功耗控制相当出色，整卡功耗在72W左右，比同等级GPU低不少，对机房散热和电费都友好。下面我把从环境搭建到YOLO模型跑通的全过程拆开讲，你跟着走一遍基本能少踩九成的坑。

2. 部署前的关键认知：为什么你不能直接用PyTorch

在开始动命令之前，必须先把Atlas这代的"游戏规则"搞清楚。很多人拿到卡第一步就是用pip装个torch，然后想跑model.cuda()，不好意思，这条路在Atlas上行不通。

2.1 达芬奇架构和CUDA的差异

NVIDIA的GPU走的是大规模并行CUDA核心路线，软件层面你写的PyTorch代码通过CUDA直接就能调用。而昇腾芯片用的是达芬奇架构，内部是AI Core计算单元，配合Cube、Vector、Scalar三类流水线工作。这种架构在跑卷积、矩阵乘这类算子时效率很高，但代价是它不认识PyTorch的模型格式，也不知道什么是.pt权重文件。

所以Atlas的部署链路里有一个强制性的中间步骤：模型转换。你手里无论是PyTorch的YOLO还是TensorFlow的模型，都要先导出成ONNX，再用华为自带的ATC（Ascend Tensor Compiler）工具转成OM格式。只有OM格式的模型才能在NPU上跑。这个转换过程类似于你把一份文档从Word格式转成PDF——格式变了，但内容保留，只是对方只能读PDF。

这听起来麻烦，但好处是转换后的OM模型已经做了算子级优化和内存布局调整，实际推理效率其实不低。我实测下来，YOLOv5s在Atlas 300V 24G上单张640×640图像的推理耗时能控制在5毫秒以内，跟同档位GPU比并不落下风，后面我会贴详细数据。

2.2 CANN软件栈到底管哪几层

和CUDA要把驱动、运行时、cudnn一层层配好类似，Atlas平台的软件栈也分了好几层，名字叫CANN。全称是Ascend Computing Language，它是连接上层AI框架和底层NPU芯片的桥梁。

从下往上大致是这么四层：

• 驱动层：负责管理NPU硬件设备，相当于显卡驱动；
• 固件层：芯片内部的底层系统，一般和驱动打包升级；
• CANN Toolkit：包含ATC转换工具、AscendCL推理API、算子库、调试工具等，这是你用得最多的一层；
• 框架适配层：通过MindSpore或者PyTorch的Ascend插件把框架算子调度到NPU上。

如果你只是做纯推理部署，用不到框架适配层，直接调用AscendCL就够了，也就是ACL接口。这个接口和CUDA Runtime API的角色很像，负责显存管理、模型加载、推理执行这些活。后面写推理程序时你就会跟它打交道。

2.3 为什么选ONNX作为中间格式

做模型转换时，中间格式目前最通用的选择就是ONNX。原因很直接：PyTorch的导出链路最成熟，YOLO系列基本都是PyTorch权重，转ONNX时能保留完整的计算图结构。TensorFlow的模型也可以先用tf2onnx转一道，再走ATC，但流程会长一些，而且算子兼容性不如PyTorch顺利。

ONNX在这个过程里扮演的是"通用交换格式"的角色，它把模型的网络结构、权重、计算流程都打包在一个文件里。ATC读到ONNX后，会分析里面的每个算子，把能在NPU上执行的算子映射成昇腾算子，把不支持的算子报出来让你改。所以ONNX文件的质量直接决定了转换能不能成功，这也是后面我要重点讲导出注意事项的原因。

3. 环境部署：一整套CANN工具链的安装与验证

这一部分我按自己在全新服务器上的实操顺序来写，只要版本和系统对得上，基本可以直接照抄。

3.1 硬件检查与宿主系统要求

Atlas 300V 24G是标准全高半长PCIe卡，插到服务器的PCIe x16插槽就行。安装前先在BIOS里确认PCIe链路正常，然后在系统里用lspci | grep -i ascend或者看硬件厂商给的识别信息，确认卡已经被系统直接识别到了。我在测试机上用的是官方驱动包自带的npu-smi info命令来检测，这个命令类似NVIDIA的nvidia-smi，能列出卡的温度、利用率、内存占用，安装完驱动后第一步就是跑它。

系统方面，官方支持openEuler、Ubuntu、CentOS等常见发行版。我建议用Ubuntu 20.04或22.04 x86_64，原因是社区资料最多，依赖问题最好查。内核版本也有要求，太新或太旧都可能导致驱动编译失败，装之前去昇腾社区查一下当前CANN版本配套的OS和内核列表，这是最稳妥的做法。

3.2 驱动、固件、Toolkit的安装顺序

CANN的安装顺序有讲究：必须先装驱动+固件，再装CANN Toolkit。如果顺序倒了，后面跑ATC工具时会报找不到驱动设备之类的错误。

我实际操作时的安装流程是这样：

1. 下载对应版本的驱动和固件安装包，昇腾官网上是分开的两个.run文件，有时候是合在一个HDK包里。以常用的的版本为例，文件名大概是Ascend-hdk-310p-npu-driver_24.0.0_linux-aarch64.run之类的形式，x86平台后缀对应x86_64。

2. 先安装固件，再安装驱动。严格来说先驱动后固件也行，但昇腾官方文档推荐用--full参数把两者一起搞定：

./Ascend-hdk-310p-npu-driver_24.0.0_linux-x86_64.run --full ./Ascend-hdk-310p-npu-firmware_24.0.0_linux.run --full

3. 安装完驱动后重启系统，或者执行npu-smi info验证是否识别到卡。如果输出能列出卡的状态、温度、内存型号，说明驱动正常。

4. 接下来安装CANN Toolkit，新版一般是.run包，比如：

./Ascend-cann-toolkit_7.0.0_linux-x86_64.run --install

默认安装到/usr/local/Ascend/ascend-toolkit目录。

这里有个小坑：安装Toolkit之前，一定要确认Python版本是3.7到3.11之间，且python3命令能正常执行。Toolkit安装脚本要调用Python做依赖检查，如果系统默认Python版本不符合要求，安装过程会直接中断，报的是很含糊的语法错误。我第一次装的时候没注意，排查了半天才发现是系统默认Python是3.6太老导致。

3.3 环境变量配置：source错了等于白装

CANN安装好之后，并不会自动生效。你需要手动把环境变量加载进来。每次开新终端都要执行：

source /usr/local/Ascend/ascend-toolkit/set_env.sh

这个脚本会把Toolkit路径、依赖库路径、ATC工具路径都加入到PATH和LD_LIBRARY_PATH里。如果你偷懒不source，后面运行atc命令就会提示command not found；运行推理程序时则会报找不到libascendcl.so这种动态库错误。

我一直是自己写个env.sh专门管理这些环境变量，内容如下：

export ASCEND_HOME=/usr/local/Ascend/ascend-toolkit/latest source $ASCEND_HOME/set_env.sh # 如果同时装了驱动和固件，再加下面这条 export LD_LIBRARY_PATH=/usr/local/Ascend/driver/lib64:$LD_LIBRARY_PATH

每次部署前先source env.sh，一键搞定。另外注意，不要在多个终端里反复source同一个脚本，偶尔会有重复追加环境变量导致路径过长的问题，出现奇怪的链接错误时先检查这里。

3.4 验证CANN工具链是否安装成功

装完之后不要急着跑YOLO，先做两个快速验证：

第一，检查驱动识别：

npu-smi info

正常会输出类似下表的信息：

第二，确认ATC工具可用：

atc --version

能输出版本号就说明CANN Toolkit装好了。这一步走通，硬件和基础软件栈就没什么问题了，可以进入模型转换环节。

4. YOLO模型转换实战：从PyTorch到OM的全流程

模型转换是整个部署链路里技术含量最高、也最让人头疼的环节。但不用怕，核心其实就是两步：导出ONNX、ATC转OM。我拿YOLOv5s做例子，YOLOv8流程几乎一样。

4.1 用PyTorch导出干净的ONNX文件

YOLOv5官方仓库里其实已经带了导出脚本，直接运行：

python export.py --weights yolov5s.pt --include onnx --opset 11

就会生成yolov5s.onnx。不过如果你是从其他途径拿到的YOLO权重，或者改过网络结构，就得自己写导出代码。我一般这么写：

import torch from models.experimental import attempt_load model = attempt_load("yolov5s.pt", map_location="cpu")["model"] model.eval() dummy_input = torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, "yolov5s.onnx", opset_version=11, input_names=["images"], output_names=["output"], dynamic_axes={"images": {0: "batch"}} )

这里有几个注意点：

• opset_version，我用11稳定，太高的版本虽然支持的算子多，但某些算子ATC反而适配不好，转换时报错率更高；
• input shape，固定成1×3×640×640，batch设为1。如果你后面想动态batch，可以在dynamic_axes里预留batch维度。注意ATC转换时动态shape支持有限，特别是H和W维度，尽量固定输入分辨率，否则转换时容易报静态shape不匹配的错误；
• 如果模型里包含了后处理（比如NMS），导出ONNX时建议把后处理剥离掉，只保留网络主体。因为NMS这类逻辑在NPU上反而不如CPU上处理得快，而且算子兼容性差。我的做法是只导出backbone+head的原始输出，NMS放到推理代码里用Python实现或调用OpenCV的库函数。

导出完成后，用onnx.checker验证一下文件完整性：

import onnx model = onnx.load("yolov5s.onnx") onnx.checker.check_model(model) print(onnx.helper.printable_graph(model.graph)[:500])

能打印出前500个字符的计算图说明结构完好。这一步能提前发现绝大多数导出异常。

4.2 ATC转换：关键参数一个都不能错

ONNX文件准备好之后，就可以用ATC工具转OM了。我用的命令长这样：

atc \ --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs1 \ --input_shape="images:1,3,640,640" \ --soc_version=Ascend310P3 \ --log=info

解释一下每个参数的含义：

• --framework=5：固定表示输入是ONNX格式。这个数字必须记牢，framework 5就是ONNX，其他数字如0是Caffe，1是MindSpore，2是TensorFlow；
• --input_shape：输入张量的形状，要和导出ONNX时的保持一致。如果你更改了模型输入尺寸，这里必须同步修改。我第一次转换的时候把尺寸写成了3,640,640，漏掉了batch维，结果ATC直接报维度错误；
• --soc_version：芯片型号。Atlas 300V 24G上用的昇腾310P，具体型号要看npu-smi info输出的芯片信息，一般写Ascend310P3或Ascend310P。写错了虽然也能转，但生成的om在卡上跑不起来，会报soc版本不匹配；
• --output：输出文件名前缀，生成的文件是yolov5s_bs1.om。

转换过程中日志会打印出每个算子的映射信息。如果某个算子不支持，会明确报出来。比如我遇到过一个GridSample算子ATC不支持，当时用的是YOLOv5改进版里的自定义上采样模块，后来通过把模型结构改成双线性插值替代才通过。

转换成功后，你会看到类似下面的输出：

[INFO] ATC run success, ret = 0

同时生成yolov5s_bs1.om文件。这个文件就是最终部署在NPU上的模型。

4.3 精度对比：转完必须验证差异

模型转完之后别急着部署，先做一步精度对比。方法很简单：用同一张测试图，分别在PyTorch里跑出原始结果，再用转换后的OM模型跑一遍，把两次检测结果的坐标和置信度对比一下。

我习惯写个小脚本，把OM推理结果输出到文件，然后和PyTorch的检测结果比对。一般来说，OM转换后精度损失非常小，置信度偏差在0.01以内属于正常范围。如果偏差太大，常见原因是转ONNX时某些算子在PyTorch和ONNX里的实现精度不一致，这时可以尝试换opset版本，或者把模型里的算子在导出前手工替换成等价实现。

这一步我强烈建议做，因为你后面做推理开发时，如果检测结果不对，很难判断是模型转换的问题还是推理代码的问题。提前排除转换因素，能省下大量排查时间。

5. 编写AscendCL推理代码：跑起你的第一个YOLO推理

模型转换完毕，接下来就是用AscendCL把模型跑起来。这一节我给你一套能直接改着用的Python推理代码骨架，以及代码里容易出错的坑。

5.1 初始化与模型加载

AscendCL的Python接口是官方提供的，安装CANN Toolkit之后自带，直接import acl就能用。基本的推理流程是：初始化设备 -> 加载模型 -> 准备输入输出内存 -> 执行推理 -> 解析结果。

初始化部分长这样：

import acl # 初始化ACL ret = acl.init() assert ret == 0, "acl.init failed" # 设置并激活设备，0表示第一张Atlas卡 ret = acl.rt.set_device(0) assert ret == 0, "acl.rt.set_device failed" device_id = 0 context, ret = acl.rt.create_context(device_id) assert ret == 0, "acl.rt.create_context failed"

这里要多说一句：ACL初始化必须在设置设备之前调用，如果顺序反了会报内部错误。如果你有多张卡，set_device可以传入卡号，后续所有操作都默认跑在这张卡上。如果希望多卡并行，可以每个进程绑定一张卡，或在一个进程里切换context，但后者复杂度高，实际项目中我更推荐进程绑卡的模式。

加载OM模型：

model_path = b"./yolov5s_bs1.om" model_id, ret = acl.mdl.load_from_file(model_path) assert ret == 0, "acl.mdl.load_from_file failed" # 获取模型描述信息 model_desc = acl.mdl.create_desc() ret = acl.mdl.get_desc(model_desc, model_id) # 获取输入输出维度 input_size = acl.mdl.get_input_size_by_index(model_desc, 0) output_size = acl.mdl.get_output_size_by_index(model_desc, 0) print(f"input_size={input_size}, output_size={output_size}")

这里的output_size就是模型输出的总字节数。YOLOv5s的原始输出shape是1×25200×85，float32每个元素占4字节，所以output_size = 25200×85×4，也就是8,568,000字节。你可以自己算一下，和get_output_size_by_index返回的值应该一致，这样可以提前验证模型是否加载正确。

5.2 数据传输与推理执行：避免踩内存拷贝的坑

图像数据要先放进NPU能访问的内存里才能参与推理。ACL提供了设备内存申请和H2D拷贝的接口：

# 申请设备侧内存 input_data, ret = acl.rt.malloc(input_size, 2) assert ret == 0, "acl.rt.malloc failed" # 把CPU上的图像数据拷到NPU设备内存 input_info = {"data": input_data, "size": input_size} ret = acl.rt.memcpy( input_data, input_size, img_bytes, input_size, acl.rt.MEMCPY_HOST_TO_DEVICE ) assert ret == 0, "acl.rt.memcpy failed" # 为输出申请设备内存 output_data, ret = acl.rt.malloc(output_size, 2) assert ret == 0, "acl.rt.malloc failed" output_info = {"data": output_data, "size": output_size}

执行推理：

# 动态batch时，需要设置输入对应的batch大小 ret = acl.mdl.set_dynamic_batch_size(model_id, input_info, 1) # 同步执行推理 ret = acl.mdl.execute(model_id, input_info, output_info) assert ret == 0, "acl.mdl.execute failed"

acl.mdl.execute是同步接口，调用后等推理计算完才返回。如果追求吞吐量，可以考虑异步接口acl.mdl.execute_async，配合stream使用，但代码复杂度要高不少。我的建议是：第一版先跑通同步模式，确认整体流程没问题，再考虑异步优化。

推理完把结果拷回CPU：

output_bytes = np.zeros(output_size, dtype=np.uint8) ret = acl.rt.memcpy( output_bytes.ctypes.data, output_size, output_data, output_size, acl.rt.MEMCPY_DEVICE_TO_HOST )

这里有个常见的坑：acl.rt.memcpy的H2D方向是从host到device拷贝数据，拷完再执行推理；D2H方向相反。方向写反了虽然不报错，但推理结果永远是0或乱码。我因为这个浪费过整整半天，后来排查时用打印确认，才发现是方向常量搞错了。

5.3 图像前后处理：LetterBox和NMS的实现细节

YOLO推理之前，输入图像要经过letterbox预处理，保证长宽比例不变的情况下缩放到640×640。这步和GPU部署时没什么区别，我用的是官方同款代码。唯一要注意的是，图像缩放后用np.ascontiguousarray()保证内存连续，否则拷贝数据时可能出现地址问题。

推理输出解析时，重点是理解YOLO输出的数据结构。YOLOv5s的输出是1×25200×85，25200表示3个尺度的候选框总数（80×80 + 40×40 + 20×20），85表示4个坐标 + 1个objectness + 80个类别概率。

后处理流程：

1. 遍历25200个候选框，过滤掉置信度低于阈值（比如0.25）的框；
2. 对剩余框做坐标解码，把相对于特征图的坐标映射回原图像坐标；
3. 做NMS（非极大值抑制），保留最终检测框。

NMS在Python里实现不复杂，但速度慢。如果追求性能，可以用numpy向量化处理，或用cv2.dnn.NMSBoxes。实测下来，单帧NMS耗时在2-3毫秒左右。如果你的项目对延迟比较敏感，可以考虑把NMS逻辑移植到C++实现，或者用FPN层的输出在NPU内部做部分筛选，但这些都是后话了。

6. 性能调优与常见问题排查：从跑通到跑得快

模型能跑通了，下面要解决的是性能问题。这一节是我在实际调优过程中总结出来的一套方法论，从容易上手的batch优化讲起，再到更细粒度的AIPP和内存复用。

6.1 该怎么理解Atlas 300V 24G的算力瓶颈

曾经有位做算法同学问我："你们这个Atlas卡是不是不如GPU？"我说你得先分清楚你在比什么场景。Atlas 300V 24G在推理场景下未必输，但在卷积层数量多且通道数大的模型上，它的Cube单元利用率如果上不去，吞吐量确实会打折。

判断卡是否吃饱，最直观的方法是看npu-smi info里显示的计算利用率。单张图推理时利用率往往很低，这是正常的，因为单次推理的数据量太小，流水线没有填满。只有加大batch、叠加多路视频流时，利用率才能提上来。如果你已经跑了多路视频推理，利用率还不到50%，就要检查是不是CPU前处理耗时太长，或者推理过程里大量时间花在H2D/D2H拷贝上了。

6.2 Batch Size和动态Shape的选择

Atlas 300V 24G的24G内存在推理卡里算大的，所以batch可以大胆往上调。用YOLOv5s做例子，我实测过不同batch在640×640输入下的表现，结果大概是这样：

注意这些数据在310P上会因驱动版本和散热状态有浮动，但趋势是明确的：batch越大，单帧均摊时间越短，吞吐越高。不过吞吐升到一定程度会开始受内存带宽或算子调度开销限制，收益递减。我一般建议在推理服务上把batch设在4到8之间，兼顾时延和吞吐。

如果你要做在线实时推理，响应时延要求高，那batch=1更好；如果做离线批量视频分析，batch调到16也完全没问题。动态batch在AscendCL里可以通过acl.mdl.set_dynamic_batch_size实现，但会稍微增加一点调度开销。你如果上面的batch=1场景都覆盖了，我的建议是模型转换时分别转一份bs1和bs8两个OM文件，部署时按需加载，比动态batch省心且调优透明。

6.3 使用AIPP加速图像预处理

Atlas提供了一种叫做AIPP（AI Preprocessing）的硬件预处理能力，可以把缩放、减均值、除以255这些操作直接编进OM模型里，在NPU内部完成。这样CPU端就不需要做图像resize和归一化，能明显降低前处理耗时和CPU占用。

ATC转换时加上AIPP配置，提供一个aipp.cfg文件：

aipp_op { aipp_mode: static input_format: RGB888_U8 csc_switch: true rbuv_swap_switch: false min_chn_0: 0 min_chn_1: 0 min_chn_2: 0 var_reci_chn_0: 0.003921569 var_reci_chn_1: 0.003921569 var_reci_chn_2: 0.003921569 }

这段配置的作用是把输入图像从RGB888格式归一化到0-1之间，相当于替了img / 255.0这一步。但要注意AIPP的缩放功能用的是固定插值方式，精度不如你自己用OpenCV做letterbox好。我的经验是：图像缩放留到CPU端做，归一化交给AIPP，这样既灵活又快。

6.4 内存管理：用内存池代替反复malloc

推理服务长期运行时，反复做acl.rt.malloc和acl.rt.free会产生不小的开销，甚至导致内存碎片化。我的做法是在服务启动时一次性申请好输入输出内存，整个生命周期里复用同一块内存。只有当batch大小变化或模型切换，才重新分配。

另外要注意推理前的图像张量，在CPU端尽量复用同一块numpy数组。比如视频流场景里，每帧图像从解码器出来直接np.copyto到预分配的缓冲区，避免反复创建新数组。这些看起来毫秒级的优化，在7×24小时跑的服务上累积起来就是可观的CPU占用差异。

6.5 常见报错速查表

在实际部署过程中，我遇到过不少报错，下面整理成速查表，方便你对照：

6.6 精度问题排查思路

模型在NPU上跑出来的检测框如果和GPU比有明显漂移，优先级这样排查：先看是不是图像预处理不一致，比如letterbox缩放方式差异；再看是不是归一化参数不对，YOLO系列通常用0-1归一化，而有些版本用0-255范围，这个最容易导致offset错误；最后才怀疑算子精度问题。

我处理过一个case：同一个YOLOv8模型，GPU上检测正常，Atlas上对小目标漏检严重。最后发现是CANN版本里某个自定义算子在推理时对边界填充默认值和PyTorch不一致导致。解决办法很简单——升级CANN版本，问题就消失了。所以遇到精度问题先别慌，按这个顺序排查，大部分情况是数据预处理或转换参数的问题，真正算子级精度差异非常少见。

7. 从单卡到多卡扩展：把吞吐打上去

前面讲的都是单张Atlas 300V 24G的场景。如果你的业务量继续涨，比如从几十路视频变成几百路，单卡就扛不住了。好在Atlas支持一台服务器插多张卡，扩展思路主要有两个方向。

第一个方向是进程绑卡模式。一个进程里初始化一张卡，CPU有几个核心就起几个进程，每个进程只处理一部分视频流。这是最简单最稳定的多卡方案，缺点是GPU内存无法跨进程共享，每张卡都要独立加载模型。我实际部署过8路视频结构化服务，一台机器插了4张Atlas 300V，起4个推理进程，每个进程绑一张卡，调度起来非常干净。

第二个方向是单进程多卡模式。在代码里维护多个模型ID，推理时根据负载均衡策略选择卡。这种方式内存利用率高，但代码复杂度也高，而且多线程调度NPU时需要处理好并发，否则会出现设备争抢。除非你真的一进程多流且追求极致内存共享，不然我更推荐进程绑卡。

多卡部署时还要注意PCIe带宽。Atlas 300V走PCIe 3.0 x16，单卡带宽足够，但多张卡同时传输大图像时，PCIe总线可能成为瓶颈。我的建议是：图像缩放等预处理尽量放到CPU端先处理好，减少通过PCIe传给NPU的数据量；如果CPU也紧张，再考虑用DVPP硬件编解码在卡上直接解码图像。On my current project, 我用的是FFmpeg做硬解，然后直接送numpy数组给ACL，PCIe带宽占用能控制在单卡30%以内。

8. 写在最后的经验谈

Atlas 300V 24G这套平台，我前后用了小半年，从一个完全陌生的生态，到现在能熟练完成模型转换、推理服务开发、性能调优，最大的体会是：这东西其实没有想象中难，但绝对不能用GPU的思维去套，必须接受"模型链路多一步转换"这个现实。

如果你也准备上手，我给你的建议是：先把环境装好，用官方samples里的resnet50推理demo跑通，感受一下ACL接口的工作方式；然后再上YOLO。直接一上来就部署YOLO，遇到算子不兼容、精度对不齐这些问题时，会很难定位。等你的YOLO在Atlas上跑出第一帧检测框，后面再换别的模型就会顺手很多。

还有一个实用经验：留一份导出ONNX和转OM的脚本模板，里面注释写清楚每个参数的意义。我自己的模板经历了多次迭代，现在基本是PyTorch模型拿来，改改输入输出名和shape就能用。团队里新同学上手时，看这份脚本比看文档快得多。

如果你后续遇到具体的部署问题，比如某个算子转换不过去、推理延迟达不到预期，可以在评论区交流。这类硬件生态的参数细节和坑，在官方文档里往往写得不够直观，实际踩过的经验反而更有参考价值。