1. 一张Atlas 300V先搞懂它到底是什么手里拿着一张Atlas 300V推理卡的时候我第一反应也是去翻各种资料结果越翻越乱。论坛上有人叫它“AI加速卡”有人叫“NPU算力卡”还有人直接说“这就是个显卡”。这些说法都不太准确但也不完全错。卡上印着昇腾310P芯片默认24GB显存看起来确实像一块“大显存的显卡”可它实际干的事、用的驱动、写的代码跟普通GPU完全是两套逻辑。先说结论Atlas 300V是一张推理加速卡不是训练卡更不是图形卡。它的核心芯片是昇腾310P专攻深度学习模型的在线推理场景比如目标检测、图像分类、语义分割这类任务。你拿它跑YOLO推理没问题跑得还很快但你要是想用它从头训练一个YOLO模型那就要慎重了因为训练场景需要的算子支持、显存频繁读写、梯度计算这些能力310P设计时就没往那个方向倾斜。很多人问“atlas 300v 24g 是运算加速卡吗”我用一句话回答它是运算加速卡但它加速的是“推理运算”不是“训练运算”。这个定位决定了后面所有环境配置、模型转换、代码写法都要跟着变。它的24GB显存是个亮点。在同类推理卡里这个容量属于比较大的意味着你可以加载更大的模型或者在显存里缓存更多的预处理数据。实测下来YOLOv5s、YOLOv8s这类模型加载进去显存占用也就3到6GB剩下的空间完全够开多个推理流或者做批量推理。有同行问我“这卡能不能跑YOLOv8x”我说能但推理延迟会上去如果对实时性要求不高跑一跑没问题。还有一点要提前说清楚Atlas 300V不是插上就能用的。你需要配置完整的昇腾软件栈包括固件、驱动、CANN工具包然后用ATC工具把PyTorch模型转成OM格式最后用ACL或者MindSpore Lite的接口写推理代码。这个过程比GPU环境要繁琐一些但流程走通之后稳定性和推理性能都让人满意。所以在动手之前先把概念理清Atlas 300V是华为昇腾产品线里的AI推理加速卡芯片方案是310P24GB显存定位是数据中心的在线推理和边缘计算的更高性能场景。它的软件生态叫CANN核心开发语言是Python和C跟CUDA生态完全不一样所以GPU的代码不能直接跑需要你做模型转换和代码适配。这篇文章我就围绕“Atlas 300V YOLO部署”这条主线把从硬件认知、环境搭建、模型转换到推理代码的整个流程写一遍。写的过程中我会把那些文档里不会写、但实际部署经常踩的坑也一并说出来毕竟这类卡不像GPU那样资料满天飞能少走弯路就少走弯路。2. 拆解Atlas 300V的硬件底细芯片、显存和算力参数想用好一张卡最好先了解它内部的“脾气”。我花了几天时间翻遍了能找到的资料又自己跑了一些简单的压力测试把Atlas 300V的关键参数整理成表参数项Atlas 300V配置备注NPU芯片昇腾310P华为自研AI推理芯片AI算力INT8约140 TOPSFP16约70 TFLOPS官方标称值实际使用依频率而定显存24GB业界少见的大显存推理卡显存带宽约204.8GB/s实测多路视频流没问题接口PCIe 4.0 x16老主板也能用但速度会受限功耗最大功耗约72W无外接供电直接从PCIe取电这张表里最需要注意的就是两个数字140 TOPS的INT8算力和204.8GB/s的显存带宽。TOPS这个单位代表每秒钟能执行的万亿次整数运算INT8也就是8位整数的运算模式这种模式在推理场景里非常常见因为推理任务通常不需要FP32那么高的精度用INT8做量化之后在视觉模型上精度损失非常小但速度能翻好几倍。那这个140 TOPS是个什么水平我用一个直观的方式解释一下如果你在一块主流GPU上用FP16跑YOLOv5s单帧推理延迟大约是3到8毫秒用Atlas 300V跑转换并完成INT8量化之后的YOLOv5s延迟可以压到2到5毫秒左右。这不是说Atlas比GPU强多少而是因为INT8计算单元多而且它专门为推理场景做了优化。再看显存带宽。深度学习推理中很多时候瓶颈不是算力而是数据搬运。模型权重要从显存里来回读取中间特征图也要频繁读写如果带宽不够算力再高也要等数据。204.8GB/s这个数字在推理卡里属于中高水平实测跑多路1080p视频流做目标检测时没有出现明显的带宽瓶颈。再说24GB显存。为什么Atlas要上这么大的显存一个原因是现在的视觉模型越来越大YOLOv8l、YOLOv8x这些大模型的参数量已经超过6000万单张图片推理时需要缓存的特征图也越来越多。另一个原因是很多实际项目里不止跑一个模型比如要同时跑目标检测和车牌识别或者要在一个卡上部署多个模型实例来提升吞吐量。24GB在这个场景下就很从容。不过有一点要提醒Atlas 300V是没有显示输出接口的它不负责把画面输出到显示器。它是一张纯计算卡所有的输入输出都靠PCIe总线和主机CPU交互。所以别指望拿它来打游戏或者做图形渲染那不是它的活儿。关于“运算加速卡”这个词我的理解是它确实是一张运算加速卡但它加速的领域是AI推理运算。你可以把它理解成一个“会做数学题的专家”但这个专家只会做推理题而且只能回答标准格式的问题。你给它的模型和输入数据处理成它认识的格式它就能以非常高的效率把结果算出来。3. 部署YOLO前的环境准备固件、驱动和CANN的搭配方案Atlas 300V最劝退新人的地方就是环境配置。GPU环境装个CUDA、cuDNN就有很多变数昇腾环境更“讲究”固件、驱动、CANN三者必须版本匹配差一个版本都可能让你在编译模型的时候遇到一些奇怪的报错。我先说一下这套环境分几层。最底层是固件Firmware它管理硬件本身的基础功能比如电源管理、温度控制。固件之上是驱动Driver驱动让操作系统能识别这张卡并在应用层调用硬件能力。再往上是CANNCompute Architecture for Neural Networks这是昇腾AI处理器的软件栈它包含算子库、运行时、图编译器等组件相当于CUDA工具包的角色。最上层才是你写的推理代码。装这三样东西第一步是确认操作系统和内核版本。支持的OS主要包括几个主流版本比如Ubuntu 20.04/22.04、CentOS 7.6以上。我现在用的就是Ubuntu 22.04。内核版本别乱动因为驱动会针对特定内核版本编译一旦升级了内核驱动可能就加载不起来了。很多人问我用的哪个版本的CANN我用的是7.0.0版本对应的驱动和固件也有配套版本。我发现昇腾社区发布的配套表更新频率挺高的每次大版本升级都有对应的适配关系。所以在装之前先到相关技术社区或官网查清楚“当前CANN版本对应的驱动版本和固件版本”照着这个组合来装能省很多事。安装顺序是先装固件再装驱动最后装CANN。装固件和驱动的时候我记得需要用root权限跑一个升级脚本。这里有个细节要注意安装前确认服务器上没有其他昇腾设备正在使用否则固件升级可能会中断正在运行的推理任务。装完之后用npu-smi info命令可以查看卡的状态。这个命令的作用相当于GPU里的nvidia-sminpu-smi info输出结果会显示设备编号、芯片温度、当前功耗、显存占用等信息。看到设备状态是“OK”的时候说明驱动和固件基本没问题了。CANN的安装相对简单按官方文档下载包之后默认解压安装即可。装完之后记得设置环境变量把CANN的bin目录和lib目录加到PATH和LD_LIBRARY_PATH里。这一步很容易被遗漏漏了之后会报一些找不到so文件的错误。我还强烈建议在正式部署YOLO之前先运行CANN自带的样例程序比如跑一个图像分类的例子验证环境是否完全打通。这个验证步骤虽然多花几分钟但能把“环境问题”和“后续应用问题”隔离开排障会容易得多。3.1 驱动、固件版本不匹配真的是最常见的坑版本不匹配这个问题我踩过不止一次。有一次我装好了CANN但驱动版本不够新结果跑模型转换工具ATC时直接报了一个模糊的“E10001”错误。后来查了CANN的版本发布说明才发现驱动版本需要高于某个阈值。所以我的建议是说装之前做个表格把固件版本、驱动版本、CANN版本对应关系写清楚一条一条对着装。有人觉得先装驱动再装固件也行我劝你别这么干还是按官方要求的顺序固件、驱动、CANN来这个顺序是有道理的因为每一层依赖下一层的接口稳定。另外装驱动和固件之前建议先把系统里已有的旧驱动卸载干净。之前我遇到过一台机器上残留了旧版NVIDIA驱动虽然两者互不干扰但有些系统服务会冲突最保险的做法是在一个相对干净的环境里装昇腾软件栈。3.2 没有root权限怎么办容器方案了解一下在实际工作环境里不一定每台服务器都有root权限。这种情况下可以考虑用容器来跑昇腾环境社区也提供了一些昇腾容器镜像。容器方案的好处是宿主机只需要装上固件、驱动和容器引擎CANN和开发环境都打包在镜像里换机器部署很方便。但容器方案也有坑容器启动的时候必须把宿主机的NPU设备映射进去这需要用到昇腾专门的容器运行时。如果不做这一步容器里跑npu-smi info会提示找不到设备。具体映射方法在文档里有标准操作照着做就行。我当时为了省事没有用容器直接在宿主机上配的环境。如果你有root权限直接安装也完全没问题。用容器的好处主要是隔离性和可移植性如果你要经常在多个服务器之间迁移部署容器方案值得优先考虑。4. 把PyTorch的YOLO模型转成OM模型ATC工具使用实录环境搭好之后最核心的一步就是把PyTorch训练好的YOLO模型转换成昇腾平台能直接加载的OM模型Offline Model。这个转换过程依靠的其实是CANN里的ATC工具全称是Ascend Tensor Compiler。不少第一次接触昇腾的人会问“为什么不能直接加载PyTorch的.pt文件”原因在于昇腾NPU的底层指令集、计算单元和GPU的CUDA核心完全不一样PyTorch的模型是为GPU或CPU环境设计的NPU没法直接识别。ATC工具的作用就是把PyTorch的计算图翻译成NPU能理解的指令序列同时在翻译过程中还能做一些图优化比如算子融合、内存复用、量化等让最终生成的OM模型在NPU上跑得更快。ATC工具支持多钟输入形式。PyTorch的模型通常先用torch.onnx.export导出成ONNX格式再从ONNX转OM。因为ONNX是一种开放格式转起来兼容性最好。如果你的模型本身已经是mindspore格式那可以省掉ONNX这一步但大部分人的YOLO模型都是PyTorch训练出来的所以走ONNX是主流路线。以YOLOv8为例我在转模型之前会在PyTorch环境里做一步非常重要但要小心的事把模型的输出结构固定下来。YOLOv8的原始输出是一个包含多个层的结构有的层输出用于边界框回归有的层输出用于类别概率还有的层做DFL解码。这种结构化输出在PyTorch里很灵活但onnx.export导出时可能得不到预期结构。所以我一般会在导出前用Model(nn.Module)的接口把forward函数修改成输出已经解码后的边界框格式。这样转换之后的OM模型在推理时直接输出边界框坐标、置信度和类别ID省得在NPU侧再做复杂的后处理。导出ONNX的命令大概是这样的import torch from ultralytics import YOLO model YOLO(yolov8s.pt) model.model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model.model, dummy_input, yolov8s.onnx, opset_version11, input_names[images], output_names[boxes, scores, class_ids], dynamic_axes{images: {0: batch}} )这里有个细节dynamic_axes里面只把batch维度设成动态宽高我固定为640×640。为什么因为YOLO模型在ONNX转换时如果宽高也设为动态ATC工具在优化时能做的算子融合就会少很多导致最终OM模型的推理性能下降。大多数部署场景下输入分辨率是固定的所以我不建议把宽高设成动态。导出ONNX之后接下来就轮到ATC出马了。我用的命令是atc --modelyolov8s.onnx \ --framework5 \ --outputyolov8s_om \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --input_formatNCHW \ --output_typeFP16 \ --buffer_optimizeoff_optimize参数说明我做个注释--framework55代表ONNX格式1代表MindSpore2代表TensorFlow别填错。--soc_versionAscend310P3当前Atlas 300V对应310P芯片具体是P3还是P系列的其他型号用npu-smi info查到的芯片版本为准。--input_shape固定输入形状这里必须跟导出ONNX时的dummy input一致。--output_typeFP16把模型权重和中间计算精度设为FP16推理速度会明显提升。如果担心精度下降可以先用FP32试跑再对比FP16的结果。--buffer_optimize这个参数涉及图优化的策略如果转出来的模型推理结果异常或者某些算子运行时报错可以尝试关掉优化。转换完成后会生成一个yolov8s_om.om文件。这个文件就是NPU能直接加载的离线模型。转换过程中ATC会在屏幕上打印详细的日志包括每个算子的转换情况算子融合的情况以及内存分配情况。如果某个算子不支持转换会在日志里明确报错提示你查看算子清单。从实操来看YOLOv8的模型整体算子比较新早期版本在ATC转换时确实会遇到几个不支持的算子。我的解决办法有两种一种是升级CANN版本新版本会持续补充算子支持另一种是改模型结构把不支持的算子替换成等价但更基础的算子组合。新手如果遇到算子不支持优先考虑升级CANN这条路通常最快。4.1 动态batch和动态分辨率到底怎么选动态输入这个概念用大白话说就是让模型能够接受不同大小、不同数量的输入不用为每种情况单独转一个模型。听起来很方便但ATC里动态输入真的要看清楚用。如果你在ATC转换时使用动态shape确实可以支持batch大小在1到16之间变化分辨率也能变。但代价是ATC无法提前把内存布局优化到最优状态也无法把一些依赖固定shape的算子做融合。性能上基本要打八折以上延迟也会高一些。我的做法是生产环境里固定输入分辨率为640×640batch大小设为1。推理性能最优代码也简单。如果真要支持多路并行我在应用层并发起多个推理实例而不是靠动态batch。这个方案的好处是每个实例都不需要动态shape模型可以优化到极致。4.2 用ATC转出来的模型精度会不会变这是被问得最多的问题。ATC转换本身是“无损”的它只是把计算图翻译了一遍理论上精度和PyTorch上跑ONNX模型一致。但由于转换时通常会设置FP16精度FP16的表示范围比FP32小在数值上会有极小误差。对于YOLO这类视觉模型来说FP16带来的精度损失通常可以忽略。我在COCO验证集上做过对比FP16 OM模型和FP32 PyTorch模型的mAP差距一般不超过0.5个百分点。如果实在不放心可以在ATC转换时不设output_type保持FP32但因为FP32的算力比FP16低很多推理速度会下降。我建议先在开发环境对比测试一下再决定上线用哪个精度。如果你跑的是OCR模型、关键点检测这类对数值精度比较敏感的模型建议多测几组数据确认FP16的误差在可接受范围内再上生产。5. 推理代码实战用Python调用ACL接口完成YOLO推理模型转换完成之后真正的重头戏来了——写推理代码。昇腾推理有两个主流方案一个是用CANN底层的ACLAscend Computing Language接口另一个是用MindSpore Lite的Python接口。我日常用得比较多的是ACL的Python接口它更接近C语言的接口风格逻辑清晰排查问题也比较直接。ACL Python接口编程有个固定的“五步走”模板我简单拆解一下第一步初始化ACL环境。调用acl.init()然后设置推理所需的工作目录比如acl.set_device(0)指定使用第0张NPU卡。第二步加载OM模型。用acl.mdl.load_from_file_with_mdl_desc接口加载之前转换生成的.om文件得到model_id。第三步准备输入输出内存。这一步跟GPU的cudaMalloc类似需要为输入和输出分别分配device内存然后用acl.mdl.create_desc创建模型描述符并获取模型对输入输出的规格要求。第四步执行推理。把输入数据拷贝到device内存调用acl.mdl.execute执行模型然后从device内存把结果拷贝回host端。第五步释放资源。依次释放输入输出内存、模型描述符、模型句柄、设备资源。我把一个YOLOv5或YOLOv8通用的推理框架代码贴出来大家可以直接参考import numpy as np import acl from PIL import Image # 初始化ACL ret acl.init() ret acl.rt.set_device(0) context, ret acl.rt.create_context(0) # 加载OM模型 model_path yolov8s_om.om model_id, ret acl.mdl.load_from_file(model_path) # 创建模型描述符获取输入输出大小和个数 model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(model_desc, model_id) input_num acl.mdl.get_num_inputs(model_desc) output_num acl.mdl.get_num_outputs(model_desc) # 为输入/输出分配device内存 input_sizes [] output_sizes [] for i in range(input_num): size acl.mdl.get_input_size_by_index(model_desc, i) input_sizes.append(size) for i in range(output_num): size acl.mdl.get_output_size_by_index(model_desc, i) output_sizes.append(size) input_buffers [acl.rt.malloc(size, 2) for size in input_sizes] output_buffers [acl.rt.malloc(size, 2) for size in output_sizes] # 准备输入数据预处理图像 def preprocess(image_path, size(640, 640)): img Image.open(image_path).convert(RGB) img img.resize(size) img_array np.array(img, dtypenp.float32) / 255.0 img_array img_array.transpose(2, 0, 1) img_array np.expand_dims(img_array, axis0) return np.ascontiguousarray(img_array) input_data preprocess(test.jpg) # 拷贝输入数据到device acl.rt.memcpy(input_buffers[0], input_sizes[0], input_data.tobytes(), input_sizes[0], 1) # 执行推理 ret acl.mdl.execute(model_id, input_buffers, output_buffers) # 拷贝输出回host output_data b for i in range(output_num): out acl.rt.memcpy_d2h(output_sizes[i], output_buffers[i]) output_data out # 解析输出根据模型定义解析boxes/scores/class_ids # 这里省略详细后处理读者根据模型输出结构调整这段代码看起来不长但中间的坑不少。第一个常见问题是输入数据的格式。ATC转换时设置的input_format如果是NCHW那你在host端预处理就要把图像从HWC格式转成CHW同时把维度顺序调整为NCHW。如果你搞混了模型输出会非常奇怪比如检测结果错位、坐标全为0。第二个常见问题是数据对齐。ACL对输入数据的内存起始地址有对齐要求通常是32字节或64字节对齐。我们用的np.ndarray默认不一定满足对齐要求解决办法是用np.ascontiguousarray它会把数组在内存里重新排列成连续存储同时确保我们后续传入的字节流是连续完整的。第三个问题是model.execute的参数类型。ACL的Python接口对参数类型很严格输入必须是一个listlist里每个元素是device内存的指针。如果你只是把input_buffers直接传进去而不加中括号很可能会报类型错误。输出解析部分这里需要着重说一下。如果你在导出ONNX时已经把模型输出改成了解码后的boxes、scores、class_ids那么输出解析相当简单把device内存拷贝回来之后用np.frombuffer把字节流转成float数组然后根据输出tensor的形状去reshape就行。但很多人的模型是原始YOLO输出还需要做NMS。这时我建议后处理不要放在NPU上跑而是把原始输出拉回到CPU上用OpenCV或者NumPy实现后处理。因为NPU是专门做卷积、矩阵运算的非极大值抑制这种逻辑分支很多的操作在CPU上写反而更高效。我之前试过把NMS放到NPU上用MindSpore算子实现性能并不理想后来还是老老实实用CPU做。推理执行完之后别忘了释放资源。即使Python有垃圾回收机制ACL的设备侧内存不手动释放的话长时间跑会发生设备内存泄漏最终导致推理失败。这个问题在长时间运行的服务上尤其严重我在写服务代码的时候会把分配、推理、释放的逻辑写成一个上下文管理类确保每次推理都走到释放逻辑。5.1 用npu-smi实时监控显存和算力写推理代码的过程中我习惯开着另一个终端用npu-smi info实时观察卡片状态。这个习惯帮我排查过好几次问题。比如有一次推理报错说内存不足我一看npu-smi输出发现显存占用几乎满了原因是我在循环里反复加载模型而没释放。npu-smi还能看到NPU的实时利用率和温度如果温度超过85度就要注意机箱风道是不是有问题了。npu-smi的用法很简单npu-smi info npu-smi info -t board -i 0后一条命令可以看到板卡更详细的信息包括固件版本、芯片序列号等。排查硬件问题的时候这两条命令基本够用。5.2 推理性能优化的三板斧很多人在Atlas 300V上跑YOLO一开始性能不理想第一个想法就是“这卡不行”其实往往是用法不对。我根据自己的实践总结了三个最有效的优化方向第一开启昇腾的推理引擎动态分流。CANN里有一个叫做“多进程单设备”的模式意思是你可以启动多个进程每个进程都加载同一个OM模型共享一张卡上的算力。实测四路视频流并行推理的时候单路的平均延迟几乎不受影响。第二用异步推理接口。ACL除了同步model.execute还有异步版本。异步接口可以在等待NPU计算的同时让CPU去准备下一帧的输入数据实现计算和预处理的流水线并行。这一步做好端到端吞吐量能提升30%以上。第三预处理放在NPU上。CANN提供AIPPAI Preprocessing功能可以把图像的缩放、归一化、格式转换放到NPU上完成CPU只负责读取图像文件。这样能释放CPU资源降低整体延迟。但这个配置有点繁琐需要熟悉ATC工具的一些配置语法一旦配好效果非常明显。6. 常见问题与排查技巧实录用Atlas 300V部署YOLO从环境配置到推理运行能遇到的问题真不少。我把实际踩过的、以及跟同行交流收集到的典型问题整理成一张速查表方便大家遇到问题时快速定位。报错信息或问题现象可能原因解决办法运行npu-smi info找不到设备驱动没加载或内核版本变了检查驱动模块加载状态必要时重装驱动E10001 / E10002范式错误驱动版本和CANN版本不匹配按官方配套版本组合重新安装模型转换时算子不支持OM生成失败算子超出CANN支持范围升级CANN版本或修改模型算子模型加载失败显存不足上次推理未释放设备内存检查代码释放逻辑重启服务释放显存推理结果全为0或坐标偏移输入数据格式不是NCHW修正预处理流程用np.ascontiguousarray确保内存连续推理速度较慢小于预期未开启FP16或启用了动态shape用FP16重转模型固定分辨率检查CPU预处理是否阻塞温度过高导致降频机箱散热不良或卡上积灰清理灰尘改善机箱风道必要时降低环境温度报错“找不到设备”这个最常见于驱动装了但没加载的场景。可以先用lsmod检查驱动模块名确认模块有没有被加载。如果发现内核升级了驱动模块需要重新编译安装。有些系统的安全设置也会阻挡驱动加载需要看下内核参数。模型转换时报算子不支持YOLO系列用到的算子大多是标准卷积、CBS结构、SPPF结构等等整体兼容性比较好。但如果你用的YOLO版本比较新引入了自定义算子那ATC就不认识了。我的排查思路是看日志里具体是哪个算子不支持然后去理解这个算子的数学逻辑看看能不能用几个基础算子组合替代。如果改动太大就直接升级CANN版本很多新版算子都会在新版本里补充上。推理结果异常把模型部署完之后用一张标注明确的测试图跑一遍如果检测框错位或者类别全错我第一个检查的就是输入的图像预处理。分辨率、归一化方式、通道顺序任何一个参数不对都会导致无法推理的结果。对比参考代码里的预处理流程是排查这类问题最快的方式。性能问题很多人跑出第一版推理代码发现延迟很高便开始怀疑卡不行。但我在优化之前也是先跑个性能基线用npu-smi看NPU利用率。如果NPU利用率不到50%CPU利用率却满了说明瓶颈在预处理环节。这个时候去优化图像的缩放和归一化代码比调整NPU参数更有效。7. 落盘之后的几点心得代码跑通模型部署上线这只是开始。在一张Atlas 300V上部署YOLO模型整个过程走下来我的体会是这类卡的逻辑和GPU很不一样不能从GPU环境平移过来而是要有“为了推理服务一切”的思维。模型转换是绕不开的坎环境配置必须按版本匹配来推理代码要遵循ACL的规范性能调优又要从全链路角度去思考。如果你想在生产环境长期稳定使用这张卡我建议你在部署之初就把以下三件事做扎实第一件事建立一个完整的部署文档模板。记录硬件型号、CANN版本、驱动版本、模型转换参数、推理代码依赖库版本等等。下次换机器、迁移环境的时候有一份详尽的文档会让你省下大把的时间。第二件事给推理服务单独开监控。除了一般的CPU、内存监控还要重点盯NPU温度和显存占用。NPU长期高温运行会加速硬件老化显存泄漏会导致推理进度停滞这些都要提前配置告警。第三件事做一个精度回归测试集。每次升级CANN或者换模型版本之后用同一批测试图重新跑一遍推理对比前后结果是否一致。很多诡异的问题都是在升级之后才暴露的。最后再分享一个小技巧把整个Atlas 300V YOLO的部署环境做成一个Docker镜像包括CANN环境、模型文件和推理代码全部打进去。这样在新服务器上部署的时候只装固件驱动然后把镜像拉起来就能用。我后来在五台服务器上部署同一个推理服务每台只花了不到半小时这就是容器化的红利。如果你只需要在一台机器上跑不折腾容器也行但只要涉及多机部署这步钱花得值。