干了这么多年AI部署，说实话被各种推理卡折磨过不少回，Atlas 300V 24G 这张卡算是让我印象比较深的一张。一开始单纯以为它就是一张普通的 PCIe 加速卡，结果从驱动到算子适配到模型转换，每一步都有它自己的脾气。这篇文章就围绕 Atlas 300V（特别是 24G 版本）跑 YOLO 目标检测的完整流程来写，把我踩过的坑、验证过的命令、以及最终能稳定跑起来的部署方案都整理出来，希望能让后来的人少走几个礼拜弯路。
先说明一下适用对象：手里正好有 Atlas 300V / Atlas 300V Pro 这张卡，想在 x86 服务器上做 YOLOv5/YOLOv8 推理，或者正在 Atlas 和 GPU 之间纠结选型的同学，这篇文章可以直接当操作手册看。
1. 项目概述：24G 推理卡到底能做什么，不能做什么
1.1 硬件规格拆解，先搞清楚手里是什么卡
Atlas 300V 系列是华为昇腾生态里的推理加速卡，走 PCIe 接口，属于典型的“插到普通服务器上就能用”的产品形态。24G 版本用的是 LPDDR4X 显存（对，不是 GDDR6，也不是 HBM），整卡功耗不算高，散热设计也比较友好，半高卡可以直接塞进 2U 机箱。
这张卡的定位非常明确：推理，不是训练。昇腾 310P 芯片本身的算力结构就是为推理设计的，INT8 算力远高于 FP16，所以你要是拿它去跑训练，那基本属于“杀鸡用牛刀但牛刀还不够快”的状态。实际项目中，它最常见的场景就是视频流分析、工业质检、安防巡检这类需要长时间在线跑目标检测模型的任务。
有一个容易混淆的点需要注意：Atlas 300V 和 Atlas 300I Pro 虽然长得像，但 300V 系列更强调低功耗和边缘部署，两者在 CANN 算子支持、AI Core 数量上略有差异。买卡之前务必确认你的型号，因为后面所有环境配置、算子适配都要跟着具体型号走。
1.2 为什么 YOLO 部署会选 Atlas 300V
说句实在话，如果只是图省事，YOLO 部署直接上 NVIDIA 的卡是很多人闭眼选的方案，毕竟生态成熟、资料多。但 Atlas 300V 在一些特定场景下确实有其不可替代的优势：
第一是成本。24G 显存做推理，单卡价格相比同显存的 GPU 推理卡有明显优势，而且功耗低，机房散热压力小，长期跑电费能省不少。第二是供应稳定。国产化项目里，Atlas 系列几乎是绕不开的选项，很多项目的招标要求就是“支持昇腾生态”。第三是算力利用率。YOLO 这类模型在推理阶段对 INT8 量化非常友好，Atlas 300V 的 INT8 算力可以充分发挥，实测在 batch size 足够大的情况下，吞吐量并不比同价位的 GPU 差。
但它的劣势也很明显：算子生态不如 CUDA 完善、调试工具相对简陋、踩坑之后能找到的参考资料少。这意味着用这张卡部署 YOLO，不能照搬 GPU 上的经验，必须重新走一遍“模型转换—算子适配—推理代码编写”的流程，也就是这篇博文要解决的核心问题。
2. 环境搭建：驱动、固件与 CANN 工具链的版本对齐
2.1 安装前必须搞清楚的三个概念
Atlas 300V 的环境比普通 GPU 复杂，因为软件栈分了三层：Driver（驱动）、Firmware（固件）、CANN（异构计算架构）。很多人第一次装环境就把这三者混为一谈，结果驱动装好了但固件版本不对，或者 CANN 版本和驱动不匹配，导致模型加载失败。
可以这么理解：Driver 是操作系统认识这张卡的“桥梁”，Firmware 是卡上芯片自己跑的基础程序，CANN 则是开发者直接调用的工具库和运行时。三者必须形成一个版本组合，不是随便装最新的就行。我的建议是直接用华为官方发布的“Ascend HDK”配套包，里面会标明与 CANN 的兼容版本组合。
以我用的组合为例：Driver 版本 23.0.3，CANN 版本 6.3.RC2，配套的固件也是 23.0.3。这个组合在 x86_64 的 Ubuntu 20.04 上很稳定，如果你用的是其他组合，安装后最好先跑一下官方自带的环境检查脚本。
2.2 一步步装环境的实操记录
安装过程其实不复杂，但有几个细节容易卡住。整体步骤是这样：
# 检查操作系统架构，Atlas 300V 支持 x86 和 ARM，但命令和包名不同 uname -m # 安装依赖，Ubuntu 系统需要这些基础库 apt-get update apt-get install -y gcc g++ make cmake zlib1g zlib1g-dev openssl libsqlite3-dev然后下载 Ascend HDK 和 CANN 的安装包，这里要特别注意：安装驱动和固件必须在 root 权限下执行，而且安装驱动时会自动加载内核模块，如果服务器里有其他 NVIDIA 卡或 GPU 驱动，理论上不冲突，但建议还是先确认内核版本和 gcc 版本兼容。
# 安装驱动和固件（run 包方式） chmod +x Ascend-hdk-23.0.3_linux-aarch64.run ./Ascend-hdk-23.0.3_linux-aarch64.run --full # 安装 CANN 工具包 chmod +x Ascend-cann-toolkit_6.3.RC2_linux-aarch64.run ./Ascend-cann-toolkit_6.3.RC2_linux-aarch64.run --install安装完 CANN 后一定要执行环境变量配置，否则找不到 atc、npu-smi 这些命令：
source /usr/local/Ascend/ascend-toolkit/set_env.sh这个 source 命令最好写进~/.bashrc里，不然每次开新终端都要手动执行一次。另外，CANN 安装目录下还有ascend-toolkit/latest软链接，可以方便地确认当前激活的版本。
2.3 环境验证：npu-smi 信息怎么看
装完之后别急着跑模型，先用官方工具确认卡的状态是否正常。npu-smi info是最常用的命令，输出里重点看几项：
Chip那一行会显示芯片型号，比如 Ascend 310P，确认和你的卡一致。Memory显示显存总量和已使用量，24G 版本的卡正常应该显示约 24GB（实际可用略小）。Hugepages和Temperature也要留意，温度过高会触发降频，影响推理延迟。
如果执行npu-smi info提示找不到设备，优先检查驱动是否加载成功：
ls /dev/davinci_manager ls /dev/davinci*正常情况下/dev/davinci0应该存在，同时/dev/davinci_manager也要存在。如果只有 manager 没有 davinci0，说明驱动加载了但设备没被识别，大概率是固件版本和驱动不匹配，或者卡没插好。另外，你还可以跑一下官方自带的样例程序来验证 CANN 环境完整性，一般在工具包自带的 samples 目录下就有，能跑通就意味着环境基本没问题了。
3. 模型转换：从 YOLOv5 到 OM 的全流程
3.1 为什么不能直接跑 PyTorch
这是 Atlas 新人最容易困惑的点：明明在 GPU 上 PyTorch 直接加载权重就能推理，为什么到了 Atlas 这里非要转成 OM 格式？
原因在于 Atlas 300V 的芯片架构不是通用的 GPU，它内部是 AI Core + 专用加速单元，CANN 的算子库无法像 CUDA 那样直接兼容 PyTorch 所有算子。运行时需要把模型编译成芯片能高效执行的指令序列，也就是 OM（Offline Model）文件。OM 文件除了包含网络结构，还记录了算子调度顺序、内存分配方案和量化信息，相当于一张“定制化的执行图纸”。
所以整个流程是：PyTorch 权重 → ONNX 中间格式 → 通过 ATC 工具转成 OM → 用 ACL（AscendCL）接口加载推理。这个链路里的每一步都有坑，尤其是 ONNX 导出环节，很多算子不支持的问题都是从这里埋下的。
3.2 PT 转 ONNX：导出时的关键细节
YOLOv5 官方代码自带了导出脚本，python export.py --weights yolov5s.pt --include onnx就能直接导出。但直接导出有一个隐藏问题：默认会带上 NMS（非极大值抑制）后处理逻辑，而 NMS 这类动态算子往往是昇腾不支持的重灾区。
我推荐的做法是改一下导出脚本的配置，把端到端的后处理剥离出去，只保留模型本身的推理部分：
python export.py --weights yolov5s.pt --include onnx \ --opset 11 --batch-size 1 \ --simplify--simplify会调用 onnx-simplifier 做计算图优化，这个步骤强烈建议加上，能消除很多冗余算子。导出后务必用onnx.checker.check_model做一次完整性校验，或者直接用 Netron 打开看一下计算图，确认 NMS 没有被包含在模型里。如果你想用 batch size 大于 1 的配置，建议固定为一个值，不要动态 batch，因为后续 ATC 转换时--input_shape必须写死维度，动态 shape 会带来额外的算子适配风险。
YOLOv8 的导出也类似：yolo export model=yolov8s.pt format=onnx opset=11 dynamic=False simplify=True。v8 的检测头是解耦头（Decoupled Head），输出张量的结构跟 v5 差别比较大，转换后需要对应调整解码逻辑，这个我在后文推理部分会详细讲。
3.3 ONNX 转 OM：ATC 工具完整命令
ATC（Ascend Tensor Compiler）是 CANN 自带的模型转换工具，核心命令如下：
atc --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_320 \ --input_shape="images:1,3,320,320" \ --soc_version=Ascend310P3 \ --insert_op_conf=aipp.cfg \ --log=info几个参数逐个解释：
--framework=5：5 表示 ONNX 格式，不能写错。--output：输出 OM 文件的路径前缀，会自动加上.om后缀。--input_shape：必须和导出 ONNX 时的输入维度一致，通常 YOLOv5 默认是[1, 3, 640, 640]，但是出于性能考虑可以换成 320 或 416，模型会重新推理对应尺寸的结果。--soc_version：这里最关键，要填你芯片对应的版本。Atlas 300V 24G 通常对应Ascend310P3，但不同型号可能有所不同，可以用npu-smi info查看芯片型号，或者查官方兼容列表。填错了会直接报错，而且报错信息还不直接。--insert_op_conf：AIPP 配置文件，用来做图像预处理（如缩放、归一化），能省掉推理代码里的部分预处理工作量，但也会带来灵活性下降的问题，我会在推理部分讨论。--log=info：转换日志级别，建议第一次转换用 info，方便定位错误。
转换成功的标志是看到屏幕上出现AICoreTime相关的统计信息，并且生成了.om文件。如果转换过程中报算子不支持的错误，不要慌，重点看是哪个算子，然后回到 ONNX 导出阶段做调整。
3.4 转换结果检查
很多人转换成功就立刻跑推理，其实应该先检查一下 OM 文件的信息，避免后面排查问题时无从下手。用 CANN 自带的工具可以查看 OM 的概要信息：
omg --model=yolov5s_320.om --output_type=1或者更简单的方式，直接看转换日志里的输出维度。YOLOv5 单尺度输出通常是一个(1, 25200, 85)的 Tensor，如果输入是 320x320，那 25200 是三个尺度输出格子数的总和（40x40 + 20x20 + 10x10 再乘以 3 个 anchor）。如果日志里输出的维度和你预期不一致，先检查 ONNX 导出是否正常，再检查 ATC 的--input_shape是否填对了。
有一个很容易被忽略的点：ATC 转换时显存分配方案也会被固化进 OM，如果后续推理时申请的设备内存小于模型要求，加载就会报错。建议转换时不要手动指定内存大小，让工具自行分配。
4. 推理落地：写一个最小可用的 ACL 推理程序
4.1 图像预处理：顺序比想象中重要
OM 模型输入约定是[N, C, H, W]，并且默认是 RGB 顺序、浮点类型（如果没启用 AIPP）。我自己在实际编写时发现，很多人在这里会翻车，原因在于飞桨和 PyTorch 的预处理差异，以及在代码运行时预处理导致 CPU 和 NPU 管线不匹配。
推荐做法是：用 OpenCV 读取图像（BGR 格式），先做 letterbox 等比缩放填充，再转换颜色空间为 RGB，然后归一化到 0~1，最后将 HWC 转成 CHW 并扩展 batch 维度。具体流程如下：
import cv2 import numpy as np def letterbox(img, new_shape=(320, 320)): shape = img.shape[:2] # H, W r = min(new_shape[0] / shape[0], new_shape[1] / shape[1]) new_unpad = int(round(shape[1] * r)), int(round(shape[0] * r)) dw = new_shape[1] - new_unpad[0] dh = new_shape[0] - new_unpad[1] top, bottom = dh // 2, dh - dh // 2 left, right = dw // 2, dw - dw // 2 img = cv2.resize(img, new_unpad, interpolation=cv2.INTER_LINEAR) img = cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, value=(114, 114, 114)) return img, r, (left, top) img = cv2.imread("test.jpg") img, ratio, (left, top) = letterbox(img, (320, 320)) img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB).astype(np.float32) / 255.0 img = img.transpose(2, 0, 1)[None] # -> 1,3,320,320这里的关键是 letterbox 填充时记录缩放比例和偏移量，解码输出框时需要还原坐标。
4.2 核心推理逻辑：ACL 的 Python 封装
直接用 ACL 的 C++ 接口写代码相对繁琐，项目里我一般先用 Python 封装做快速验证，确认模型和预处理没问题后再用 C++ 做上线版本。Python 调用 ACL 的核心流程是：初始化、设置设备、加载模型、创建输入输出数据、执行推理、解析结果。
import acl def init_acl(device_id=0): acl.init() ret = acl.rt.set_device(device_id) context, ret = acl.rt.create_context(device_id) return context def load_model(om_path): model_id, ret = acl.mdl.load_from_file(om_path) return model_id # 取模型的输入输出描述信息 desc = acl.mdl.create_desc() acl.mdl.get_desc(desc, model_id) input_size = acl.mdl.get_input_size_by_index(desc, 0) output_size = acl.mdl.get_output_size_by_index(desc, 0)执行推理时需要把数据拷贝到设备侧。这里有个容易踩的坑：ACL 默认输入要求是np.float32类型且内存连续，预处理完的数据最好做一次np.ascontiguousarray()，否则拷贝数据时会报数据长度不匹配的莫名其妙的错。
# 输入输出数据申请设备内存 in_data = acl.util.np_to_ptr(img_np) # 把 numpy 数据转为 device 指针 out_data = np.zeros(output_size, dtype=np.float32) out_ptr = acl.util.np_to_ptr(out_data) ret = acl.mdl.execute(model_id, [in_data], [out_ptr]) # 将结果拷贝回 host result_np = acl.util.ptr_to_np(out_ptr, (output_size,), np.float32)需要注意的是，acl.mdl.execute是同步接口，如果希望提升吞吐，可以用acl.mdl.execute_async配合 stream 做多 batch 并发，但代码复杂度会上升不少。第一次调试建议先用同步接口把整条链路跑通。
4.3 后处理：解码、NMS、画框
模型输出的原始张量不能直接用，需要解码。YOLOv5 的输出 shape 是(1, 25200, 85)，其中 85 = 4 个坐标 + 1 个置信度 + 80 个类别概率。解码时先通过置信度阈值过滤低分框，然后把中心点坐标还原成原图坐标（乘以 letterbox 的缩放比例并减去偏移），再做类的 NMS。
def decode_yolov5(output, conf_thres=0.25, iou_thres=0.45, ratio=1.0, (left, top) = (0, 0)): pred = output.reshape(-1, 85) scores = pred[:, 4] # objectness mask = scores > conf_thres pred = pred[mask] if pred.shape[0] == 0: return [] boxes = pred[:, :4] # 中心点格式 (cx, cy, w, h) -> 角点格式 (x1, y1, x2, y2) box_xyxy = np.concatenate([ boxes[:, :2] - boxes[:, 2:] / 2, boxes[:, :2] + boxes[:, 2:] / 2 ], axis=1) # 还原到原始图像坐标 box_xyxy = (box_xyxy - np.array([left, top, left, top])) / ratio scores = scores[mask] * pred[:, 5:].max(axis=1) # 类别置信度 class_ids = pred[:, 5:].argmax(axis=1) # NMS 排序处理 keep = nms(box_xyxy, scores, iou_thres) ...如果你用的是 YOLOv8，解码就差很多：v8 的输出是(1, 84, 8400)（80 类别版本），直接解耦了 objectness，每个候选框的类别分数就是对应位置的类别概率，而且没有 anchor。reshape 时需要注意索引的排序，v8 的 8400 是按三个尺度展平的，和 v5 的 25200 类似，都是一个一维数组包含全部候选框。
NMS 我建议直接用 OpenCV 的cv2.dnn.NMSBoxes，比自己写要稳得多。Atlas 上别指望用模型里的 NMS 算子，现在不支持的网络结构很多。
4.4 与模型输出对齐
后处理第一个要确认的就是输出维度。很多人在解码时报ValueError: cannot reshape array of size xxx，基本都是模型输出维度和预期不一致。最直接的排查方式：先把模型输出打出来，看 shape 再决定怎么 reshape，不要想当然按 YOLOv5s 的 25200 写死。
还有一个细节：ATC 转换时如果不指定 AIPP，模型输出是 FP32 的，解码时直接转 float 就行；如果配置了 AIPP 做归一化，模型的输入图层会自动插入预处理算子，输出结构不变，但需要确认图像输入的通道顺序是 RGB 还是 BGR，这个写错会导致检测准确率大幅下降，但模型不会报错，属于最隐蔽的坑。
5. 性能优化与常见问题实操记录
5.1 推理吞吐上不去，先看这几个指标
Atlas 300V 跑 YOLO 的吞吐瓶颈通常不在芯片算力上，而在于数据流。第一步看板卡利用率，用npu-smi info看 AI Core 的占用率，如果长期不到 50%，说明瓶颈在数据搬运或预处理上。
典型调优思路有几个：
一是开启多线程预处理和推理流水线。图像读取、缩放、填充、颜色转换这些操作在 CPU 上耗时很大，如果每张图都是同步处理完再推理，AI Core 必然有很多时间在空转。把预处理放到线程池里，提前把 batch 的输入准备好，推理线程只负责上传和下载数据，吞吐能提升 30% 以上。
二是增加 batch size。ATC 转换时输入 shape 如果写的是1,3,320,320，那每次推理就固定一张图。改成4,3,320,320或者8,3,320,320，然后把多张图组成一个 batch 再推理，能充分利用板卡的多核并行能力。不过 batch 越大，单张延迟也会增加，线上服务时要根据 RT 要求权衡。
三是使用多路 stream 并发。ACL 支持多 stream 并发执行，相当于把不同的推理请求分配到不同队列。我在项目中测试过，两个 stream 跑 YOLOv5s 320 输入，吞吐能提升接近 1.8 倍，收益非常明显。
四是关闭模型中不必要的算子。YOLOv5 导出 ONNX 时如果保留了某些训练相关的输出（比如 p6 大尺度输出层），会白白增加计算量。只保留推理需要的分支即可。
5.2 常见报错和解决办法速查
下面几个错误是我在 Atlas 300V 部署 YOLO 过程中遇到最多的，整理成一个速查表格：
| 报错信息 | 原因 | 解决办法 |
|---|---|---|
E10020: The model is invalid | OM 文件与当前 CANN/驱动版本不匹配 | 确认 ATC 版本与运行环境一致，重新转换 |
E40011: Device memory allocation failed | 显存不足 | 降低 batch size，或者检查是否存在内存泄漏 |
E19999: Unsupported operator | ONNX 里的算子昇腾不支持 | 回导出阶段调整模型，或者用 AIPP 替代部分操作 |
acl.mdl.load_from_file failed | OM 文件路径错误或文件损坏 | 确认文件存在，重新转换 |
Init resource failed | 设备初始化失败，驱动或固件异常 | 检查/dev/davinci0是否存在，重装驱动 |
np_to_ptr data type not support | 输入数据不是 float32 | 转成np.float32且内存连续 |
对于Unsupported operator，我可以给一个方向性的排查方法：先用 Netron 打开 ONNX 模型，定位报错的算子节点，然后搜索华为 CANN 的算子支持列表（官方文档有完整列表），看这个算子属于“完全支持”“部分支持”还是“不支持”。如果是“部分支持”，往往是因为算子参数中包含了不支持的属性，需要在导出源码里修改。
5.3 我的踩坑记录，说几个别人很难帮你定位的问题
第一个坑：AIPP 配置了归一化，但代码里也做了一遍归一化，结果检测框数量骤减，准确率几乎为零。原因是 AIPP 会在输入芯片前自动把图像数据做归一化，代码里如果再除一遍 255，等于输入变成了原来的 1/255，特征自然全乱套。排查了大半天才发现是双重重处理。建议策略：要么完全用 AIPP 做预处理（省 CPU），要么完全不用 AIPP，在代码里做（灵活，方便调试），不要混合使用。
第二个坑：ONNX 导出的模型输入名不是images。ATC 命令里写的--input_shape="images:1,3,320,320"中的images必须和 ONNX 模型输入节点的名字一模一样，否则 ATC 会报找不到输入张量。这个用 Netron 打开 ONNX 文件就能看到，名字可能是images、input或者其他自定义名称，转换前一定要确认。
第三个坑：NMS 在 CPU 上跑实在是太慢了。YOLOv5 的 25200 个候选框在 CPU 上做 NMS，一次大概要几毫秒到十几毫秒，如果每帧都做，瓶颈就转移到 CPU 了。批量处理时建议用向量化的方式实现 NMS，避免 Python 循环；或者先用类别置信度阈值把候选框压到几百个，再做 NMS，速度会快很多。
第四个坑：运行环境的 Linux 内核版本和驱动不兼容。我曾在内核 5.15 的系统上装驱动失败，换到 5.4 内核后一次通过。华为官方的兼容性列表里对内核版本有明确要求，装系统之前先查一下，省得装到一半卡住。
6. 模型选型与输入分辨率：你也需要想清楚的事
6.1 YOLOv5s 和 YOLOv8s 在 Atlas 上的实际差异
这两代模型我都跑过，简单说下实测感受。YOLOv5s 导出 ONNX 时，计算图相对简单，算子类型少，ATC 转换几乎没有卡过；YOLOv8s 因为有解耦头和更复杂的结构，转换时偶尔会碰到不支持的算子，需要调整导出参数。推理速度上，同分辨率下 v5s 比 v8s 快 10%~20%，但 v8s 的精度通常略高一些。
实际项目里我一般这样选：如果对延迟敏感（比如实时视频流分析），用 YOLOv5s，配合 320 或 416 分辨率，单卡轻松跑满几十路；如果更看重精度，且视频路数不多，可以用 YOLOv8s，分辨率提高到 640，换一张卡几张卡也能跑得动。
6.2 输入分辨率对吞吐的影响
这个影响比很多人想象的大。拿 YOLOv5s 举例，同一张 Atlas 300V 上，输入 320x320 和 640x640 的耗时大概差 3~4 倍，但精度提升可能只有几个点。如果业务场景是检测小目标，分辨率不能降；如果场景是大的障碍物或人车检测，320 或 416 分辨率往往就够了。
有一个常见的量化方法：先把模型测试集在不同分辨率下的 mAP 跑出来，再乘以目标帧率，算出每路需要的推理次数，最后对比 Atlas 300V 在不同分辨率下的吞吐指标，就能找到性价比最高的配置。
6.3 多模型并发：一张卡同时跑多个模型
通过 ACL 的 context 和 stream 机制，Atlas 300V 可以同时加载多个 OM 模型。这个功能在做业务时很有用，比如一路视频流先跑一个轻量模型做区域筛选，命中后再跑精细模型。一张卡上如果两个模型都不大，共存的显存占用一般都能接受，但要注意模型并发时 AI Core 是分时复用的，理论上性能会互相影响，需要测试确认。
7. 最后的经验总结，关于 Atlas 部署 YOLO 的三句实在话
我个人实际操作下来，最深的体会是：用 Atlas 300V 部署 YOLO，最大的成本不是卡，而是软件链路的熟悉过程。从驱动到 CANN 到 ATC 到 ACL，每一层都有自己的一套术语和工具，没有 GPU 那种“pip install + import torch”的顺畅感。但一旦把链路跑通，后续的迭代和优化就顺理成章了，尤其是性能调优的空间其实比很多人的预期要大。
再分享一个小技巧：在开发和调试阶段，尽量把模型转换、推理、后处理三个环节解耦，每个环节单独写成脚本，出了问题可以直接定位。等全流程稳定后，再考虑用 C++ 重写推理部分，Python 做业务逻辑，既能保证性能，又能兼顾开发效率。
这个内容后续还可以这样扩展：同一套环境也可以用来跑其他检测模型（比如 RT-DETR、PicoDet），甚至可以做简单的图像分类任务。关键是先把“转换 + 推理”这套骨架搭好，换模型的时候只是换个 ONNX 和 OM 文件的问题。希望这篇 Atlas 部署 YOLO 的实操笔记能帮你省下几天的查资料时间。
