Atlas 300V 24G部署YOLO实战：从硬件到模型转换与调优全指南

做了好几个月的边缘端目标检测项目，我一直想把这套完整的部署经验记录下来。正好最近看到有人问“atlas 300v 24g 是运算加速卡吗”，又有不少人在搜“atlas部署yolo”，就干脆把这块卡的定位、硬件细节、模型转换流程和实际踩坑经验全部整理成一篇实操向的博文。

先说结论：Atlas 300V 24G确实是一张运算加速卡，但它不是显卡。它是华为昇腾系列里面向推理场景的PCIe加速卡，核心芯片是昇腾310P，24GB显存版本非常适合做YOLO系列的边缘端推理部署。下面我按实际项目的推进顺序，把完整过程拆开来讲。

1. Atlas 300V 24G的硬件定位与选型分析

1.1 这块卡到底是什么

很多人第一次接触Atlas 300V，会下意识拿它和NVIDIA的RTX系列显卡作对比，因为它同样是插在服务器PCIe插槽上的板卡。但实际上，Atlas 300V的设计目标和GPU完全不同。

Atlas 300V 24G基于昇腾310P芯片，这颗芯片是纯推理芯片，不支持训练。它有两个Die，每个Die集成了AI Core和矢量计算单元，整卡显存24GB，使用的是LPDDR4X内存颗粒而不是GDDR6。它的典型功耗在72W左右，被动散热，计算能力方面，INT8精度下整卡算力大约能到140TOPS。

我项目里用的是Atlas 300V 24G版本，这个24G显存是它非常大的优势。因为一开始我评估过Atlas 300V Pro系列，那个没有24G版本，显存只有8G-16G。在跑大分辨率视频流或多路并发时，显存直接决定了你能塞进多少路模型实例。

注意：Atlas 300V 24G不支持训练。如果你想做模型微调或训练，这张卡完全派不上用场。它的定位就是“训完之后的部署环节”。

1.2 和GPU方案的差异对比

我在选型阶段其实做过一轮GPU和NPU的对比，结论非常明确：如果你的核心场景是固定的YOLO模型推理、长期稳定运行、对单卡功耗有要求，而不是频繁切换模型做实验，那Atlas 300V 24G比GPU更合适。

从表格里能看出来，Atlas 300V在INT8推理算力上甚至超过T4，功耗却只有T4的水平甚至更低。但它的代价是生态不通用，不能直接跑PyTorch模型，必须走CANN工具链做模型转换。

我个人对这个差异的理解是：如果你做的是标准化产品，比如面向智慧园区、工厂质检、安防监控，输出的是固定版本的检测服务，那Atlas 300V完全够用且成本优势明显。如果你做的是算法研发为主、部署为辅的工作，那明显GPU更顺手。

1.3 为什么选择24G版本

选24G版本的决定，我复盘下来有三个关键原因：

一是多路视频流的显存需求。我用YOLOv5s做1280x1280分辨率的检测，单路视频流在Atlas 300V上做全流程处理（解码+缩放+推理+NMS），大约占用3.5GB到4GB显存。24G显存理论上可以同时跑6路，虽然实际项目中我跑到4路就保持了比较稳妥的余量，但显存大就是底气。

二是大模型的可能性。24G版本可以加载更大的模型，比如YOLOv5m、YOLOv8m这些中等规模模型，甚至在不极致压缩的情况下跑一些带Transformer结构的检测头。

三是batch size和动态shape。跑视频分析时，我最怕因为显存不够导致无法开多batch。24G让我在同一个进程里可以开batch=4的推理请求，大大提升了并行吞吐。

2. 部署前必须搞懂的基础架构与工具链

2.1 CANN到底是什么

Atlas 300V的软件栈核心是CANN（Compute Architecture for Neural Networks），它是昇腾处理器的软件栈，类似CUDA对于NVIDIA GPU的地位。CANN涵盖了驱动、运行时、算子库、图编译器和应用开发接口。

我第一次部署时最容易搞混的是CANN和MindSpore的关系。MindSpore是深度学习训练框架，类似PyTorch；而CANN是底层计算架构。MindSpore可以基于CANN运行，但CANN不依赖MindSpore。在这套部署流程里，我根本不需要装MindSpore，只需要装CANN toolkit和对应的驱动固件。

完整的软件栈从上到下是：应用代码 -> ACL（AscendCL）运行时 -> CANN图编译器 -> 驱动 -> 硬件。

2.2 版本选型和配套关系

版本匹配是我这次部署过程中最痛苦的一环。昇腾对版本匹配的敏感度非常高，驱动、固件、CANN Toolkit版本必须严格对应，否则会出现各种莫名其妙的问题。

我最终采用的版本组合是：

这个版本组合在实际运行中比较稳定。注意驱动和固件的版本号必须保持一致，不能只升级其中一个。

另一个重要细节是：昇腾的软件驱动分为两个部分，一个叫driver（驱动），一个叫firmware（固件），它们分别通过.run文件安装。驱动负责操作系统与硬件的交互，固件负责硬件芯片内部的微指令和启动流程，缺一不可。

2.3 从PyTorch到OM的模型转换路径

在Atlas 300V上运行YOLO，核心路径是：PyTorch模型 -> ONNX -> OM（昇腾离线模型） -> ACL推理。

最终在卡上跑的是OM格式的模型，它不是直接读取PyTorch的.pt文件，也不能直接吃ONNX。转换过程的工具叫ATC（Ascend Tensor Compiler）。

这里要特别强调一点：YOLOv5的官方代码库里有export.py，可以直接导出ONNX，但导出的ONNX如果直接扔给ATC转换，会遇到几个常见障碍，比如动态shape问题、transpose算子不支持问题、NMS算子缺失问题。后面我详细展开。

CANN对不同框架导出的ONNX兼容性有差异。我个人经验：如果Capture，尽量避免使用model.export(format='onnx')，因为在YOLOv8的官方导出流程中，它的onnx导出带了非常多的后处理逻辑，transpose、sigmoid都包含在里面，这样转换OM时会有一段额外的适配工作量。

3. 环境准备：从裸机到能跑ATC转换

3.1 硬件安装和系统识别

Atlas 300V是一张标准的PCIe 3.0 x16接口板卡，物理安装上没什么特别要求，插进服务器PCIe插槽，接上辅助供电（部分型号需要6pin电源）。

装好系统后，用lspci命令查看设备能否被识别：

lspci | grep -i ascend

正常情况下能看到类似下面的输出：

05:00.0 Processing accelerators: Huawei Technologies Co., Ltd. Ascend 310P

如果lspci里看不到设备，先检查是不是主板设置里把PCIe插槽禁用了，或者BIOS没有开启Above 4G Decoding（这个功能在某些服务器上必须要开，否则NPU的PCIe BAR空间无法正确映射）。

还有一个我踩过的坑：安装驱动前如果系统已经自带nouveau驱动（NVIDIA显卡的开源驱动），会干扰Ascend驱动的insmod加载。解决办法是在/etc/modprobe.d/blacklist.conf里写入blacklist nouveau，重启后再安装。

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

安装顺序非常重要，正确的顺序是：驱动driver -> 固件firmware -> CANN Toolkit。

# 以root身份执行 ./Ascend-hdk-310p-npu-driver_23.0.3_linux-aarch64.run --full ./Ascend-hdk-310p-npu-firmware_23.0.3.run --full

安装完成后，用npu-smi info查看卡的状态：

npu-smi info

如果输出正常，你能看到类似这样的信息：

+----------------------------------------------------------------------------+ | npu-smi 23.0.3 Version: 23.0.3 | +-------------------+---------------+-----------------------------------------+ | NPU Name | Health | Power | Temp | | 0 310P | OK | 32W | 42C | +-------------------+---------------+-----------------------------------------+

这个命令就好比NVIDIA的nvidia-smi，是整个部署过程中最常用的调试命令。它能显示每张NPU卡的温度、功耗、健康状态和当前的计算负荷。

CANN Toolkit安装就相对常规：

chmod +x Ascend-cann-toolkit_7.0.RC1_linux-aarch64.run ./Ascend-cann-toolkit_7.0.RC1_linux-aarch64.run --install

安装完成后，需要source环境变量：

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

3.3 常见安装报错与处理

安装过程中最容易出现的几个问题：

第一，安装sshd工具时提示缺包。CANN Toolkit里的部分工具依赖libtinfo5和libnuma-dev，OpenEuler和Ubuntu 20.04的安装包源里可能没有，需要apt install libtinfo5 libnuma-dev手动补齐。

第二，npu-smi info卡住不动。这个多半是固件和驱动版本不匹配导致的，卸载重装时一定要确保两个包用同一个版本号。

第三，运行ATC时报libascendcl.so找不到。这个问题通常是因为set_env.sh没有被正确source，或者PATH环境变量被覆盖了。检查一下：

echo $LD_LIBRARY_PATH | grep -i ascend

如果不为空但仍有报错，可能是把/usr/local/Ascend/ascend-toolkit/latest软链接指向了错误的地方。检查软链接指向是否和装的版本一致。

4. YOLOv5模型转换的完整实操过程

4.1 导出适配的ONNX模型

这是整个流程中变数最大的一步。YOLOv5的官方export.py导出的ONNX包含完整的后处理逻辑（NMS和detect层），但如果直接喂给ATC转换，会有两个大问题：一是NMS层的实现是组合算子，ATC对它的支持不够好；二是动态batch和动态分辨率会导致转换失败。

我建议采用轻量级导出方案：只导出模型前向推理部分，也就是到输出三个尺度的特征图为止，把后处理从模型里拆出来，放到应用层用Python处理。

具体操作是修改YOLOv5源码中的export.py，或者在导出时配置--include onnx --opset 11，同时让模型切换到eval模式并固定shape。

我实际使用的导出思路是直接继承YOLOv5的Detect模块，把forward里decode部分注释掉，只保留原始的特征图输出。因为YOLOv5的模型输出是三个尺度的tensor：80x80、40x40、20x20。

转换前最好用Python工具检查一下导出的ONNX是否包含动态维度：

import onnx model = onnx.load("yolov5s.onnx") for input in model.graph.input: print(input.name, input.type.tensor_type.shape.dim)

如果dim里的dim_param是None，说明是动态维度，需要在导出时固定。

4.2 ATC转换命令与关键参数解析

得到固定shape的ONNX后，用ATC工具做转换。我用的完整命令参考如下：

atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs1 \ --input_shape="images:1,3,640,640" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp_yolov5.cfg \ --output_type=FP32 \ --input_format=NCHW

每个参数我都解释一下：

• --model：输入ONNX路径。
• --framework=5：5表示ONNX框架。
• --output：输出OM文件名。
• --input_shape：固定输入shape，这里固定为batch=1、3通道、640x640。
• --soc_version：必须是Ascend310P3，这里踩过坑，写成Ascend310或Ascend310P都会报不支持。
• --insert_op_conf：插入AIPP预处理配置文件，用来做图像缩放、归一化、色域转换。
• --output_type：输出数据类型，一般用FP32。
• --input_format：输入格式NCHW。

关于soc_version这个参数，ATLAS 300V 24G对应的是310P3。如果你用的是Atlas 300V Pro，对应的可能是310P1或310P2，具体可以用npu-smi info查看芯片的具体型号后确认。

4.3 AIPP预处理配置的细节

AIPP（Ascend Image Preprocessing）是昇腾的硬件级图像预处理单元，可以在数据送入NPU计算前完成mean/std归一化、图像缩放、格式转换等操作。合理配置AIPP能大大简化应用层的预处理逻辑。

我的aipp配置文件这样写：

aipp_op { aipp_mode: static input_format: YUV420SP_U8 src_image_size_h: 640 src_image_size_w: 640 csc_switch: true rbuv_swap_switch: false matrix_r0c0: 256 matrix_r0c1: 0 matrix_r0c2: 359 matrix_r1c0: 256 matrix_r1c1: -88 matrix_r1c2: -183 matrix_r2c0: 256 matrix_r2c1: 456 matrix_r2c2: 0 input_bias_0: 0 input_bias_1: 128 input_bias_2: 128 mean_chn_0: 123.675 mean_chn_1: 116.28 mean_chn_2: 103.53 var_reci_chn_0: 0.01712475 var_reci_chn_1: 0.017507 var_reci_chn_2: 0.01742918 }

这段配置的核心是让YUV图像在进网络前完成YUV到RGB的颜色空间转换、减均值除方差归一化。mean和var的数值是YOLOv5的COCO预训练权重对应的标准归一化参数。

注意：这里矩阵参数是按YUV420SP格式来配置的。如果你的输入是RGB图像，就不需要配csc_switch和matrix，只需配mean和var即可。最怕的是输入格式和AIPP配置不符，会导致出图颜色错乱、检测结果完全不对。

4.4 模型转换失败的常见报错

ATC转换失败是新手最头疼的问题，这里列出几个我实际遇到的问题：

第一个报错是E10001: Input shape does not match that in the model。这个是因为ONNX里模型输入是动态shape，需要用input_shape显式固定。

第二个报错是E10018: The node type of Transpose is not supported。老版本YOLO导出的ONNX里有一些特殊transpose算子，CANN还不支持。我的解决思路是升级CANN版本，或者在模型导出时用onnx-simplifier简化图结构。

第三个报错是E40001: The shape of output is inconsistent。通常发生在多输出模型上，ATC要求所有输出的batch必须一致。检查一下是不是在导出时Batch维度没有对齐。

5. 用ACL接口实现YOLOv5推理

5.1 ACL推理的完整代码流程

模型转换完成后，就到了应用开发阶段。使用ACL（AscendCL）编程接口是在CANN上做推理最直接的方式。

我把整个推理流程拆成几个步骤：初始化 -> 加载模型 -> 准备输入输出内存 -> 执行推理 -> 获取结果 -> 后处理。

下面是一个经典的ACL调用流程：

import acl # 1. 初始化 ACL ret = acl.init() ret = acl.rt.set_device(0) # 2. 加载模型 model_id, ret = acl.mdl.load_from_file("yolov5s_bs1.om") model_desc = acl.mdl.create_desc() ret = acl.mdl.get_desc(model_desc, model_id) # 3. 准备输入输出数据 input_size = acl.mdl.get_input_size_by_index(model_desc, 0) output_size = acl.mdl.get_output_size_by_index(model_desc, 0) input_data, input_ptr = acl.util.np_to_ptr(input_np) output_data, output_ptr = acl.util.np_to_ptr(output_np) # 4. 创建数据集描述 input_dataset = acl.mdl.create_dataset() output_dataset = acl.mdl.create_dataset() input_buffer = acl.mdl.create_data_buffer(input_ptr, input_size) acl.mdl.add_dataset_buffer(input_dataset, input_buffer) output_buffer = acl.mdl.create_data_buffer(output_ptr, output_size) acl.mdl.add_dataset_buffer(output_dataset, output_buffer) # 5. 执行推理 ret = acl.mdl.execute(model_id, input_dataset, output_dataset) # 6. 获取输出结果 result_np = acl.util.ptr_to_np(output_ptr, output_dimensions, output_size) # 7. 释放资源 acl.mdl.destroy_data_buffer(input_buffer) acl.mdl.destroy_data_buffer(output_buffer) acl.mdl.destroy_dataset(input_dataset) acl.mdl.destroy_dataset(output_dataset) acl.mdl.unload(model_id) acl.rt.reset_device(0) acl.finalize()

这段代码是ACL推理的最小骨架，在实际项目中我把它封装成了一个AscendInfer类，初始化时就加载模型、创建输入输出buffer、打开device，然后对外暴露一个infer(input_np)方法，业务侧只需要调用这一个方法就能完成前向推理。

5.2 多batch和多路并发的实现要点

Atlas 300V 24G在跑YOLO时最舒服的模式就是多batch推理。开启多batch的方式非常简单：在ATC转换时把input_shape的batch从1改成4即可。

atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs4 \ --input_shape="images:4,3,640,640" \ --soc_version=Ascend310P3

但要注意：batch和并发不是一回事。batch是单次推理处理4张图，并发是同时处理多个独立请求。在实际项目中，我采用了“batch排队”策略：每来4帧图像，凑满一个batch后统一推理，这样能将AI Core的利用率拉满。

我的实测数据：用batch=4跑YOLOv5s 640x640，单卡整体吞吐能达到120FPS以上；如果只用batch=1，大概只有40FPS左右。差距非常显著。

5.3 多卡配置和指定设备

Atlas 300V支持单机多卡，如果你插了两张甚至四张卡，需要在代码里指定使用哪张device。

ret = acl.rt.set_device(0) # 使用第一张卡

另一个值得注意的点是设备和设备ID的关系。在npu-smi里看到的NPU ID，和在代码里acl.rt.set_device里使用的device ID不一定完全对应。我遇到过在服务器上插了两张卡，npu-smi显示NPU 0和NPU 1，但代码里set_device(1)仍然用的第一张卡的情况。这时需要用acl.rt.get_device_count()确认实际的设备数量，然后用acl.rt.set_device逐个加载测试。

5.4 后处理的优化思路

YOLOv5的原始输出是三组特征图，形状分别是bs x 255 x 80 x 80、bs x 255 x 40 x 40、bs x 255 x 20 x 20。255的来源是3个anchor乘以(5+80个类别)。在ACL拿到这三组tensor后，还需要做解码坐标、过滤低置信度、NMS三个步骤。

我的经验是，在NPU上只做网络推理，把解码和NMS放在CPU侧，但为了提升后处理的效率，可以使用多线程并发处理。因为Atlas 300V的推理速度很快，单张640x640图像前向推理只需要约10ms，但Python侧后处理如果没有优化，最多可能耗时15ms以上，瓶颈就转移到了CPU侧。

NMS这步我做过优化，用torchvision.ops.nms替换手写的循环NMS，在处理大量目标时快很多。另外前期过滤confidence阈值不能设太低，我一般设为0.35，不仅不影响测试集精度，在工程上还能有效减少NMS的计算量。

6. 性能调优与上线部署的避坑经验

6.1 内存管理与显存复用

在我的项目中，处理视频流任务时会反复申请和释放输入输出buffer。如果每次推理都新建np_to_ptr，会不断积累内存碎片，跑一段时间后可能出现内存申请失败。

解决方法是启动时一次性创建好所有需要的buffer，推理过程中只对buffer做数据拷贝，用完不释放，直接复用。这个做法在长时间运行的任务中非常关键，我的服务从最初每4小时内存增长500MB，优化后稳定在固定水位运行一周不重启。

6.2 数据预处理效率和格式选择

YOLO推理前的图像处理包括读图、缩放、letterbox、BGR转RGB、归一化等。如果全部在Python里做，耗时较大。我的建议是：尽量使用jpg解码库和numpy批量操作，也可以考虑把预处理的一部分流程放到AIPP里做。

但在使用AIPP时要注意一个细节：如果视频流输入已经解码成NV12格式，使用AIPP会非常高效；如果是从摄像头拿到RGB或BGR数据，那AIPP就不太适用，你需要在CPU侧完成大部分预处理后再喂给模型。

6.3 线程池和队列长度设置

实际部署时，我用了生产者-消费者模式：采集线程负责解码取帧，推理线程负责推理并后处理。关键参数是队列长度，如果队列太短，会在视频码率波动时丢失帧；如果队列太长，实时性会变差。我实测下来，对1080p30视频流，队列长度设置为10帧左右比较均衡。

还有一点值得提醒：Atlas 300V的推理接口是同步的，即acl.mdl.execute会阻塞到推理完成才返回。要提升效率，需要使用多个线程同时提交推理任务，或者用AscendCL提供的stream机制。我实际项目中使用stream异步推理后，整体吞吐比同步模式提升了接近30%。

6.4 长时间运行的服务稳定性

服务稳定性是边缘部署最重要的指标。我在上线前做过72小时压力测试，期间遇到过几个问题：

第一个是内存泄漏。通过排查发现，问题出在acl.util.np_to_ptr反复调用时没有同步释放底层指针。解决方案是记录所有创建过的pointer，并在不再使用时调用acl.rt.free。

第二个是设备异常导致推理失败。某个版本驱动在长时间多路解码+推理高负载时，偶尔会出现任务下发失败。后来通过升级驱动版本和降低后端线程数解决。

第三个是链路监控。我用npu-smi info定期采集卡的温度和功耗，结合Grafana展示，当显存占用超过90%或温度高于85度时触发告警。

7. 常见问题排查与操作禁忌

7.1 基于实际的排障记录

7.2 禁止做的事

实测下来有几个操作是绝对不能碰的：

第一，不要在驱动加载期间直接拔卡或重启卡，可能导致设备固件异常。在更换硬件后需要先执行npu-smi stop任务，再下电更换。

第二，不要随意修改老版本驱动对应的/etc/ascend_install.info，这个文件内容与固件升级强相关，写错了会导致驱动无法加载。

第三，不要在没有干净环境的情况下反复升级CANN版本。旧版本的libascendcl.so如果残留在系统路径里，会和新版本冲突，最后只能靠重装系统解决。

7.3 AI Core利用率过低怎么办

如果你发现推理速度远低于预期，首先排查AI Core利用率。使用npu-smi info查看算力时，如果利用率长期低于50%，说明算力没有充分使用。此时应该检查的优先级：

1. 是否开了多batch（batch=1利用率通常低）
2. 是否用了异步推理（同步推理时CPU处理耗时掩盖了设备推理时间）
3. 模型转换时是否关闭了融合优化（通过--enable_small_channel=1等参数控制）

CANN对模型的图优化有两种模式：一种是算子融合，一种是小channel优化。对YOLOv5来说，小channel优化能进一步减少低算力场景下的内存搬运开销。我在模型转换时开启--optimize_level=1后，单batch推理延迟又降低了约3ms。

8. 扩展：Atlas上跑YOLOv8和自定义模型

8.1 YOLOv8的转换兼容性

很多人已经切换到了YOLOv8，它的检测头结构比YOLOv5复杂一些，但转换到OM仍然可行。

核心注意点是YOLOv8的输出格式和YOLOv5不同。YOLOv8在导出ONNX时通常是1x84x8400的输出（COCO 80类），包括cx、cy、w、h和类别分数，不需要像YOLOv5那样分别处理三个尺度的特征图。这种结构反而更容易转OM，因为输出tensor数量少。

实测转换YOLOv8s的流程和YOLOv5类似，唯一在ATC得到的输出是一个扁平的tensor，后处理时需要reshape成box 4x8400和cls 80x8400。

8.2 自定义训练模型的转换注意事项

如果你的模型不是标准YOLO，而是自定义的检测头结构，转换时必须自己检查ONNX图的输出节点名称。ATC的input_shape参数里的名字要和ONNX输入名一一对应，不一致会直接报错。

我建议在转换前先用Netron打开ONNX文件，记录输入tensor的名字和维度。然后在ATC指定--input_shape="input_name:1,3,640,640"。不少新手容易忽略这一点，直接拿官方命令改一改，结果卡在名字不对上。

8.3 推理结果的精度验证方法

模型转换后必须做精度对齐验证。做法很简单：用一张测试图在PyTorch上推理得到结果，再分别从ONNX Runtime和Atlas 300V上拿结果，对比输出tensor的余弦相似度。

from numpy.linalg import norm def cos_sim(a, b): return np.dot(a, b) / (norm(a) * norm(b))

我的经验标准是：最后输出的全部tensor余弦相似度大于0.99，说明转换基本无精度损失；如果在0.95-0.99之间，需要注意是否开启了过多的量化优化；如果低于0.95，基本可以确定是转换流程中某一步出了偏差，优先检查AIPP的归一化参数。

注意：ATC默认不做量化，但如果你的应用追求极致性能，可以考虑用ATC的--precision_mode参数配合校准集做INT8量化。量化后推理速度可以提升一倍以上，但精度需要自己验证，尤其是小目标检测场景，量化掉点可能比较严重。

9. 这一路走下来，我的一点经验总结

Atlas 300V 24G这张卡，本质上是一个面向特定场景的专用计算工具，它的优势远不止于浮点算力。24GB大显存、低功耗、成熟稳定的CANN工具链、丰富的部署案例，加上昇腾社区这些年持续迭代的算子支持，让它在边缘端目标检测部署场景里有着非常强的竞争力。

从我做了几个月的项目来看，最有价值的经验是提前建立一套标准化的模型转换和验证流程。不要每次换模型时都从零开始踩坑，而是把ATC转换脚本、AIPP配置、精度验证脚本、性能测试方法沉淀成模板。YOLOv5s、YOLOv8s、自研模型都在这套模板上跑通了，后续再接入新模型，转换加精度对齐基本一天内就能完成。

如果你正打算用Atlas 300V跑YOLO，我的建议是：硬件安装和驱动配置这部分多花点时间确认版本匹配，模型转换部分严格按照固定shape导出ONNX并验证精度，应用层一开始就设计好多batch和异步推理。这三步做扎实了，后面整个部署周期会顺利很多。

几张卡在不同版本驱动下的表现会有差异，如果条件允许，硬件到位后先用官方的sample跑一遍全流程，再进入自己的模型适配，能省掉大量排查时间。