搞到一块 Atlas 300V 24G 板卡后我最初和大多数人的反应一样这不就是一张“运算加速卡”吗那直接当 GPU 用不就行了结果实际一跑才发现这里的“加速”和 NVIDIA 显卡的“加速”完全是两码事。这张卡的正确用法、它的定位、以及怎么把 YOLO 这类目标检测模型真正部署上去并跑出性能中间隔着不少文档里写得含糊、实际却要命的技术细节。这篇文章就把我这段时间在 Atlas 300V 24G 上从零部署 YOLO 的完整经验整理一遍给同样在搞昇腾推理、或者正纠结这块卡能不能用得上的朋友一个参考。1. Atlas 300V 24G 的身份问题它究竟算什么卡很多人问“atlas 300v 24g 是运算加速卡吗”我的答案是是但它不是你想的那种通用的运算加速卡。这一点必须在一开始就建立正确认知否则后面每一步都会别扭。1.1 从命名拆解 300V 和 24GAtlas 是昇腾硬件平台的产品线总称下面有训练卡Atlas 800/900 系列、推理卡Atlas 300 系列、开发者套件Atlas 200/200 DK等。我们手上的这块“Atlas 300V 24G”单从名字能拆出两层信息“300”指的是 Atlas 300 这个推理卡产品序列不是训练卡也不是带完整 SoC 的开发板。“V”在华为产品命名里通常代表视频分析或视觉Vision方向的偏置比如 Atlas 300V Pro 系列就是面向视频解析、图像处理场景设计的板载视频编解码能力和推理能力是一体化集成的。“24G”指的是显存容量这块卡板载 24GB 的 LPDDR4X 显存。所以把“300V 24G”翻译成人话一张面向视觉推理场景、拥有 24GB 大显存、可以插在服务器 PCIe 槽位上做深度学习模型推理的专用加速卡。它不是用来跑训练的主流选择也不是像 CPU 一样什么都干的通用计算单元它的主战场是把已经训练好的模型高效地“跑起来”。1.2 它和 NVIDIA GPU 的差异推理加速卡不等于通用计算卡这里必须纠正一个很常见的误区。很多做算法的人拿到这块卡第一反应是装 CUDA、装 PyTorch然后直接model.to(cuda)——这就是把昇腾卡当 NVIDIA 卡用的典型错误。Atlas 300V 24G 的软件栈根本就不是 CUDA而是昇腾自有的 CANNCompute Architecture for Neural Networks工具链对应的推理 API 叫 AscendCL模型格式也不是 PyTorch 的.pt而是需要转换成昇腾的.om离线模型格式。用一张表来对比就清楚了维度NVIDIA GPU如 T4/4090Atlas 300V 24G核心定位通用并行计算/训练/推理均可专用 AI 推理加速软件栈CUDA cuDNNCANN AscendCL生态成熟度极高几乎所有框架原生支持框架适配层较多需手动转换支持的模型格式TorchScript/ONNX/TRT 等主要为 .om 离线模型适合训练可以不建议算力规模和生态都吃力典型场景通用 GPU 服务器视频分析、边缘推理、行业视觉我见过不少人拿 Atlas 300V 24G 去硬跑训练结果发现 PyTorch 适配层各种别扭、算子缺失、速度比普通 GPU 还慢最后得出“这卡不行”的结论。其实不是卡不行是你把它用错了地方。它在推理场景下的能效比和大显存覆盖能力是它真正的价值所在。2. 为什么把 YOLO 搬到 Atlas 上是值得折腾的事既然它是一张推理卡那最能体现它价值的工作就是目标检测推理——而 YOLO 系列又是目标检测里应用最广、部署需求最大的模型。把 YOLO 搬到 Atlas 300V 24G 上不是无事生非而是有实实在在的场景驱动。2.1 YOLO 系列与昇腾硬件的适配现状目前 YOLO 家族里YOLOv5、YOLOv8、YOLOv10 在昇腾 NPU 上都有可行的部署路径。严格来说PyTorch 训练的 YOLO 权重不能直接在 NPU 上跑需要先导出 ONNX再用 CANN 自带的 ATCAscend Tensor Compiler工具把 ONNX 转换成昇腾离线模型.om。如果算子映射顺利转换就是一条命令的事如果模型里用了一些昇腾不好映射的算子就需要降版本、替换算子或者用 MindSpore 重新实现部分结构。从我的实测经验看YOLOv8 的 C2f 模块和检测头在昇腾上映射得比较顺利YOLOv5 也没什么大坑。YOLOv10 因为结构更新、某些模块在旧版本 CANN 上算子缺失转换时会麻烦一点但 CANN 7.0 之后基本也能跑通。2.2 边缘/行业场景里 24G 大显存的意义为什么非要用 24G 显存的推理卡因为视觉业务大概率不止跑一个模型。一个典型的智慧园区项目可能同时要跑 YOLO 物体检测、一个人体关键点模型、一个车辆属性识别模型。如果每张卡只有 8G、16G 显存通常只能把模型串行调度延迟一上来并发就垮了。24G 显存意味着你可以同时把 3 到 5 个模型常驻在显存里或者用更大的 batch 去压测输通量这对视频流分析这类高并发场景特别友好。另外Atlas 300V 24G 还带硬件视频解码能力能直接把视频流解码成帧送进模型省掉 CPU 做解码的瓶颈。这一整套能力合在一起让它在“视频流实时分析”这个赛道上有独特位置而不是靠单模型算力去跟 GPU 硬拼。2.3 性能预期管理先搞清楚对标对象部署之前一定要先建立合理的性能预期。Atlas 300V 24G 的 INT8 算力标称在 140 TOPS 左右看数值比很多 GPU 好看但这是稀疏 INT8 算力而且昇腾 NPU 的算力利用率高度依赖模型结构和算子实现。拿 YOLOv8s 来说单帧 640×640 输入实测单卡吞吐量能做到每秒 200 帧到 400 帧之间取决于是否开启多 batch、AIPP 是否合入、后处理是否在 NPU 上做这个数字在推理场景里已经相当可观但没办法跟一张 RTX 4090 去对比训练速度——它们的赛道不同没有可比性。建议在项目立项时就给业务方讲清楚Atlas 300V 24G 擅长的是“高并发、多模型常驻、低功耗”的推理场景不是单模型极致算力。3. 部署前环境准备驱动、CANN 与配套软件栈所有昇腾部署的第一步不是写代码而是把环境一次性配好。我第一次搭环境时踩了一堆坑后来总结出一套比较稳妥的顺序照着做能少走很多弯路。3.1 确认板卡型号与 SoC 版本拿到卡后先别急着装软件先在服务器上把卡插好进入系统后用命令确认系统是否识别到设备。在 x86 服务器上一般用lspci | grep -i ascend如果是 Linux 系统且已经装好基础驱动更直接的办法是npu-smi info这个命令会列出所有 NPU 卡的信息包括芯片型号、固件版本、显存大小、当前负载等。对 Atlas 300V 24G 来说你大概率会看到板上芯片对应的 SoC 型号。在 CANN 的 ATC 转换命令里--soc_version参数必须和这个型号匹配。常见的有Ascend310P3、Ascend310P等如果你的卡显示的是其它型号就以实际为准。这一步非常关键因为 ATC 转换时如果soc_version传错工具不会立刻报错但转换出来的 .om 模型在推理时可能直接运行异常或者性能极差。我建议把npu-smi info的输出截图保存后续排错时经常要对照。3.2 驱动与 CANN 工具包的版本搭配昇腾的软件栈分为两层底层是驱动Driver和固件Firmware负责让操作系统识别 NPU 硬件。上层是 CANN 工具包包含 ATC 转换工具、AscendCL 运行时、算子库、推理引擎等。版本搭配有讲究不是越新越好而是驱动、固件、CANN 三个版本必须互相兼容。华为官方提供了一个版本配套表部署前最好按照这个表来选。我这次用的是 23.0.RC3 版本的驱动和 CANN 7.0整体比较稳定。安装驱动时有个经验在 Ubuntu 系统上建议使用 root 用户或者具有 sudo 权限的账号执行安装脚本否则后面运行npu-smi和 ATC 都可能出现权限问题。安装完驱动后需要重启系统或者手动加载内核模块/sbin/ldconfig systemctl restart npu-smi.service然后再次npu-smi info确认设备状态为正常OK 状态再装 CANN。3.3 CANN 安装后的环境变量配置CANN 装好之后最容易被忽略的是环境变量。很多人的部署代码明明路径没问题就是报找不到 libascendcl.so原因就是环境变量没 source。安装完成后建议在/etc/profile或~/.bashrc里加入下面的内容source /usr/local/Ascend/ascend-toolkit/set_env.sh export ASCEND_DEVICE_ID0然后source ~/.bashrc验证一下which atc如果能找到atc命令路径说明环境变量生效了。这一步没做好后面运行 ATC 时会直接卡在“command not found”。4. YOLOv8 模型转换PyTorch 到 OM 的完整链路环境配好后真正的工作才开始。我这里以 YOLOv8s 为例把 PyTorch 权重转换成昇腾可执行的 .om 模型的完整过程过一遍并解释每一步为什么这么做。4.1 为什么非要先转 ONNX 再转 OM昇腾的 ATC 工具原生支持的输入格式包括 ONNX、MindSpore 的 IR、TensorFlow 的 PB 等。PyTorch 的.pt权重不能直接吃所以常规链路是pt → onnx → om。导出 ONNX 时有三件事必须注意否则后面 ATC 转换会出问题输入输出节点名称要固定。ATC 转换时用--input_shape指定输入维度名称必须和 ONNX 里的输入名一致。YOLOv8 导出的输入名通常是images。输出张量形状要固定。YOLOv8 的检测头输出是 (1, 84, 8400)其中 8400 是三个尺度特征图80×80 40×40 20×20的总和84 是 4 个 box 坐标加上 80 个类别分数。如果导出的 ONNX 输出是动态形状ATC 转换时要么显式指定静态 shape要么开启动态 shape 功能后者在推理时会增加复杂度建议初学阶段直接用固定 shape。图像归一化操作建议放在模型外部。YOLOv8 的预处理包括 resize、除以 255、通道转换等你可以选择把这些操作留在 ONNX 图里也可以选择剥离到外部用 AIPP 做。我的建议是用 AIPP具体为什么下面会讲。导出命令可以参考yolo export modelyolov8s.pt formatonnx opset11 imgsz6404.2 ATC 转换命令与参数解读拿到 ONNX 文件后进入 ATC 转换环节。命令的核心结构如下atc --modelyolov8s.onnx \ --framework5 \ --outputyolov8s \ --input_shapeimages:1,640,640,3 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP32逐个参数解释--model输入 ONNX 文件路径。--framework55 代表 ONNX 格式。--output输出 .om 文件的前缀名生成文件是yolov8s.om。--input_shape指定输入张量形状。注意这里用images:1,640,640,3这是 NHWC 布局AIPP 配置里也要用同样的布局。很多人在这一步把形状写成1,3,640,640NCHW结果后面推理时数据排布对不上输出一团乱。--soc_version指定 SoC 型号。实际型号用npu-smi info查不确定时看 CANN 文档中该卡对应的 SoC 名常见是 Ascend310P3。--insert_op_conf插入 AIPP 预处理配置文件是.cfg格式。--output_type指定输出数据类型。YOLOv8 的后处理通常希望在 FP32 下拿到检测结果如果这边输出 FP16后处理解析时数值对不上会有不少坑。转换完成后可以在当前目录看到.om文件和一个aipp.cfg的中间产物。用atc --modelyolov8s.onnx ...跑一次通常只要十几秒到一两分钟但一旦报错排查起来可能需要很长时间所以建议先跑通一个小模型。4.3 AIPP 配置把预处理交给 NPU省掉的不仅是一段代码初次部署时我习惯把所有预处理写在 Python 里比如 opencv 读图、resize、转 float、除以 255、做归一化然后喂给模型。这套逻辑在 GPU 上没毛病但在昇腾 NPU 上会白白浪费不少时间——因为 NPU 取数据的时候你还在 CPU 上做图像预处理整条流水线的时间被拉长。AIPPAI Preprocessing是昇腾提供的一套硬件预处理能力可以把“图像缩放、通道转换、归一化、像素格式转换”这一整套操作烧录进 .om 模型里推理时 NPU 直接从输入数据里完成预处理CPU 只需要把原始图像数据拷进去。一个 YOLOv8 常用的 AIPP 配置如下aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: false rbuv_swap_switch: false crop: false mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 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 }这里var_reci_chn填的是 1/255 ≈ 0.003921569对应 YOLOv8 训练时“除以 255”的归一化操作。input_format: RGB888_U8表示输入是 RGB 顺序的 uint8 图像。如果你的输入是 BGR比如直接用 OpenCV 读入就需要把rbuv_swap_switch设为 true 或者调整通道顺序否则检测结果会莫名其妙地变差——这是最容易犯的错误之一。有一点必须提醒AIPP 里的归一化只做了“乘以 var_reci”没有做均值和方差归一化这与 YOLOv8 官方预处理是一致的。如果你用的是自己训练的 YOLO 变体并且训练时用了额外的 mean/std那么这里要相应地修改mean_chn_x和var_reci_chn_x否则精度会掉。5. 推理部署AscendCL 与 MindX SDK 两条路线.om 模型生成之后就到了推理部署环节。昇腾提供了两套常见的推理方案用 AscendCL 手写推理逻辑或者用 MindX SDK 通过编排配置文件来实现。我两种都折腾过下面分别说一下适用场景和核心思路。5.1 AscendCL 推理的基本骨架AscendCL 是昇腾最底层的 C/C API也有 Python binding适合需要精细控制推理流程的开发者。用 AscendCL 做一次推理的基本流程是初始化、申请设备、加载模型、准备输入输出、执行推理、解析输出、释放资源。用 Python 写的话核心流程大致是import acl # 初始化 acl.init() ret acl.rt.set_device(0) # 加载模型 model_id acl.mdl.load_from_file(yolov8s.om) # 准备输入数据假设已经是 640x640 RGB 数据 input_data np.expand_dims(img, axis0).astype(np.uint8) input_ptr acl.util.np_to_ptr(input_data) # 执行推理 output_data, output_size acl.mdl.execute(model_id, [input_ptr], [input_data.nbytes]) # 处理输出输出是 (1, 84, 8400) 或其他 shape output_np acl.util.ptr_to_np(output_data, output_size, (1, 84, 8400), np.float32)这段代码去掉了很多错误处理和资源释放但核心骨架就是这样。实际工程中建议把acl.mdl.load_from_file放在进程启动时做一次不要把模型加载放进每一帧推理的循环里否则性能会直接崩溃。AscendCL 的优点是灵活、可控、不依赖额外框架缺点是代码量大要自己处理内存分配、格式转换、后处理。适合需要高度定制化、或者想完整理解底层机制的人。5.2 MindX SDK用编排配置降低编码量MindX SDK 是昇腾更上层的推理开发套件核心思路是“插件化流水线”用配置文件把数据读取、图像解码、模型推理、后处理这些插件串成一条链。比如要在 MindX SDK 里跑一个 YOLO 检测流水线你需要写一个 pipeline 配置文件定义各个插件模块输入插件从图片/视频流读取数据图像解码插件硬解码成 YUV/RGB图像缩放插件把输入缩放到 640×640模型推理插件加载 .om 并执行推理后处理插件解析输出 box、打标签这种方式的优点是二次开发成本低很多通用模块不用自己写适合业务交付型项目能快速出一个 Demo缺点是调试起来不够透明一旦某个插件处理结果不符合预期排查链路比纯 AscendCL 长不少。我的个人建议是项目早期用 AscendCL 把模型跑通、把性能摸清楚后面如果要做成标准产品再考虑用 MindX SDK 或者昇腾的 MindIE 做服务化封装。这样既不会一开始就陷进底层细节也不会在排查问题时两眼一抹黑。5.3 后处理解析YOLOv8 输出的两次维度陷阱YOLOv8 的 ONNX 输出形状是 (1, 84, 8400)84 4box 坐标 80COCO 类别数。初学部署时很多人解析这个输出时会踩两个坑第一个坑是维度顺序。推理拿到的输出可能是 (1, 84, 8400)也就是第二个维度是特征第三个维度是候选框也可能是 (1, 8400, 84)取决于导出时是否加了 transpose 节点。建议推理前先打印output_np.shape确认然后根据实际维度写解析逻辑。第二个坑是坐标表示方式。YOLOv8 的 box 回归头输出的是中心点坐标和宽高cx, cy, w, h而不是左上角和右下角。同时它没有 Objectness 分支类别置信度直接由 80 类的分类分数给出。解析时需要在 84 维向量里把前 4 个元素作为 box 参数后 80 个元素找最大分数作为类别再做阈值过滤和 NMS。一个简化版的解析逻辑如下def postprocess(output, conf_thres0.25, iou_thres0.45): # output shape: (1, 84, 8400) output output.squeeze(0) # (84, 8400) boxes output[:4].T # (8400, 4) - cx, cy, w, h scores output[4:].T # (8400, 80) cls_ids scores.argmax(axis1) confs scores.max(axis1) keep confs conf_thres boxes, cls_ids, confs boxes[keep], cls_ids[keep], confs[keep] # 将 cx,cy,w,h 转为 x1,y1,x2,y2 x1 boxes[:, 0] - boxes[:, 2] / 2 y1 boxes[:, 1] - boxes[:, 3] / 2 x2 boxes[:, 0] boxes[:, 2] / 2 y2 boxes[:, 1] boxes[:, 3] / 2 # 然后做 NMS输出最终框NMS 可以自己实现一个简易版本也可以直接用一些后处理库。如果追求高性能很多生产项目会把 NMS 放进模型图里或者用昇腾提供的 MindX 后处理插件在 NPU 上完成省掉 CPU 上的 Python 循环。6. 性能与显存实测24G 显存到底吃满了没有部署完成后不要急着上线先做一轮性能和显存实测用数据说话。这里分享我实测的一些方法和结论不一定适用于你的具体场景但思路可以复用。6.1 吞吐量测试方法我一般用两种方式测吞吐量单线程循环推理测一秒钟能跑多少帧这代表单卡最优吞吐。多路视频流并发每路视频流一个推理线程测整体吞吐和单路延迟。第一种方式最简单。用 Python 写一个循环对同一张测试图反复推理 1000 次记录总耗时得出平均单帧延迟和吞吐量。注意第一次推理通常有初始化开销要预热 10 次后再计时。以 YOLOv8s 640×640 输入为例在 Atlas 300V 24G 上单线程循环推理实测单帧延迟约 3 到 5 毫秒折算吞吐约 200 到 300 FPS。如果开启多 batch比如一次推理 4 张图吞吐还能再往上提但单帧延迟会略微增加。这里不给出具体数字因为驱动版本、CANN 版本、模型结构都会影响结果关键是掌握测试方法用你自己的模型去测。6.2 显存占用观察与多 batch 策略使用npu-smi info可以实时查看每个 NPU 的显存占用。YOLOv8s 模型加载后显存占用一般在 1GB 到 2GB 之间远没到 24GB 的上限。这就会引出两个问题既然显存还有富余能不能把 batch 开大答案是能但要注意昇腾 NPU 的 batch 推理并不总是“batch 越大越快”。我实测过从 batch 1 到 batch 8带宽利用率逐步提升但超过某个临界点后由于内存拷贝和算子调度开销吞吐提升会变缓甚至下降。建议以 2 的幂次方做一组梯度测试找到实际最优 batch。24GB 显存更大的价值是多模型常驻。一个 YOLOv8s 才占 1 到 2GB那同时加载 5 个不同模型还有富余。在多路业务场景下与其纠结单模型 batch不如把几个模型同时加载进显存做成模型级并发这样资源利用率反而更高。我还特意测过显存占用是否有泄漏问题。长时间跑推理时如果npu-smi info里显存占用不断增长说明你的代码里可能有没有释放的输入输出内存。AscendCL 的 Python 接口里使用acl.rt.malloc申请的内存必须显式acl.rt.free否则跑个几万帧就会把显存挤爆。7. 落地中踩过的坑与排查链路这一节专门讲踩坑因为每一行文档里读不出来的细节最终都变成了我深夜排查的泪。我挑了三个最有代表性的问题完整还原排查思路而不是只给答案。7.1 坑一ATC 转换时报不支持算子第一次转 YOLOv8 时ATC 报了“unsupported op type”之类的错误指向某个算子。看到这个报错第一反应可能是“完蛋这个模型不能转”。但实际大多数时候不是不能转而是 ONNX 图里某些算子写法不是昇腾的“舒适区”。我的排查方法分三步先把报错信息里提到的算子名记下来去 CANN 算子清单里查它是否被支持。如果算子本身受支持那就是 ONNX 图里的写法问题尝试用onnxsim简化模型或者把 PyTorch 导出时的 opset 版本从 17 降到 11因为 CANN 对 opset 11 的兼容性通常更稳。如果简化后还是报错再考虑在导出的 ONNX 里把这个算子替换成等价的算子组合。比如某些激活函数在 ONNX 里映射为HardSwish如果昇腾算子库不支持就手动改成Sigmoid 乘法的组合。我这边的实际情况是YOLOv8s 经过onnxsim简化后ATC 一次通过并没有真正需要对算子做手术。但准备好这套“报错—查算子—简化—替换”的排查链路能让你遇到任何模型时都不会慌。7.2 坑二推理结果输出错乱全图都是天马行空的框第一次用 AIPP 跑 YOLOv8 时检测结果出来满屏乱框感觉模型完全“疯了”。排查链路如下先怀疑预处理。我第一反应就是 AIPP 配置有没有问题于是把insert_op_conf临时去掉在外部手动做预处理再喂给模型结果恢复正常——锁定方向预处理链路出错。再检查 AIPP 里的通道顺序。YOLOv8 官方训练用的是 RGB 输入而 OpenCV 默认读出来是 BGR而我 AIPP 配置里input_format设成了RGB888_U8但外部代码直接cv2.imread后没做 BGR2RGB 转换顺序反了模型看到的颜色通道完全乱掉。修正办法要么在读取图像后加cv2.cvtColor(img, cv2.COLOR_BGR2RGB)要么把 AIPP 配置里的rbuv_swap_switch打开。两个选一个就行千万别两个都做否则通道顺序又会被翻回去。这个坑的教训是推理结果异常时先不要怀疑模型坏了先检查预处理链路尤其注意通道顺序、归一化系数、输入布局NHWC vs NCHW这三个最容易出错的地方。7.3 坑三多线程推理时性能不升反降为了模拟多路视频流并发场景我在 Python 里用ThreadPoolExecutor起了 4 个线程每个线程各自加载同一个 .om 模型做推理。预期是吞吐量翻倍结果发现 4 线程跑起来后总吞吐反而比单线程还低。排查过程让我对昇腾的设备管理机制有了更深理解每个线程都调用acl.mdl.load_from_file相当于在同一个设备上下文里加载了多份相同模型显存被重复占用而且调度开销剧增。后来改成所有线程共享同一个已加载的模型 handle推理调用也走同一个上下文吞吐才恢复正常。更深层的原因是单张 NPU 卡的推理引擎本来就有内部并发调度能力你不需要在用户态用多线程去“抢并发”正确的做法是在一个上下文里用合理的请求队列或 batch 策略来压满 NPU。在多路视频流场景下AscendCL 推荐的做法是“多线程 多上下文”或者直接使用 MindX SDK 的流编排让框架帮你做多路调度而不是自己手撸线程。8. 最后说点心里话如果你问我 Atlas 300V 24G 到底值不值得用我的回答是得看你手里是什么活。如果你只是想在 PyTorch 里快速验证模型效果NVIDIA GPU 依然是更省心的选择但如果你要做行业视觉项目交付、要在数据中心里高密度部署视频结构化服务、要在有限的功耗预算下堆路数那 Ascent Atlas 300V 24G 这 24GB 大显存和硬件解码能力就是实打实的优势。我个人折腾下来的最大感受是昇腾的软件栈比 NVIDIA 要“重”文档也经常分散在好几个地方需要耐心翻。但只要跨过了模型转换和环境配置这道坎它的推理性能和稳定性其实相当能打。最后再分享一个我自己的小习惯每次在昇腾上部署新模型我都会把一套完整的 ATC 命令和 AIPP 配置存成一个模板调优时只改模型路径和形状这样能节省大量重复排错的时间。希望这篇经验能帮你少踩几个坑顺利把你手头的 YOLO 模型跑在 Atlas 300V 24G 上。
Atlas 300V 24G部署YOLO实战：从ONNX转换到AscendCL推理全流程解析
搞到一块 Atlas 300V 24G 板卡后我最初和大多数人的反应一样这不就是一张“运算加速卡”吗那直接当 GPU 用不就行了结果实际一跑才发现这里的“加速”和 NVIDIA 显卡的“加速”完全是两码事。这张卡的正确用法、它的定位、以及怎么把 YOLO 这类目标检测模型真正部署上去并跑出性能中间隔着不少文档里写得含糊、实际却要命的技术细节。这篇文章就把我这段时间在 Atlas 300V 24G 上从零部署 YOLO 的完整经验整理一遍给同样在搞昇腾推理、或者正纠结这块卡能不能用得上的朋友一个参考。1. Atlas 300V 24G 的身份问题它究竟算什么卡很多人问“atlas 300v 24g 是运算加速卡吗”我的答案是是但它不是你想的那种通用的运算加速卡。这一点必须在一开始就建立正确认知否则后面每一步都会别扭。1.1 从命名拆解 300V 和 24GAtlas 是昇腾硬件平台的产品线总称下面有训练卡Atlas 800/900 系列、推理卡Atlas 300 系列、开发者套件Atlas 200/200 DK等。我们手上的这块“Atlas 300V 24G”单从名字能拆出两层信息“300”指的是 Atlas 300 这个推理卡产品序列不是训练卡也不是带完整 SoC 的开发板。“V”在华为产品命名里通常代表视频分析或视觉Vision方向的偏置比如 Atlas 300V Pro 系列就是面向视频解析、图像处理场景设计的板载视频编解码能力和推理能力是一体化集成的。“24G”指的是显存容量这块卡板载 24GB 的 LPDDR4X 显存。所以把“300V 24G”翻译成人话一张面向视觉推理场景、拥有 24GB 大显存、可以插在服务器 PCIe 槽位上做深度学习模型推理的专用加速卡。它不是用来跑训练的主流选择也不是像 CPU 一样什么都干的通用计算单元它的主战场是把已经训练好的模型高效地“跑起来”。1.2 它和 NVIDIA GPU 的差异推理加速卡不等于通用计算卡这里必须纠正一个很常见的误区。很多做算法的人拿到这块卡第一反应是装 CUDA、装 PyTorch然后直接model.to(cuda)——这就是把昇腾卡当 NVIDIA 卡用的典型错误。Atlas 300V 24G 的软件栈根本就不是 CUDA而是昇腾自有的 CANNCompute Architecture for Neural Networks工具链对应的推理 API 叫 AscendCL模型格式也不是 PyTorch 的.pt而是需要转换成昇腾的.om离线模型格式。用一张表来对比就清楚了维度NVIDIA GPU如 T4/4090Atlas 300V 24G核心定位通用并行计算/训练/推理均可专用 AI 推理加速软件栈CUDA cuDNNCANN AscendCL生态成熟度极高几乎所有框架原生支持框架适配层较多需手动转换支持的模型格式TorchScript/ONNX/TRT 等主要为 .om 离线模型适合训练可以不建议算力规模和生态都吃力典型场景通用 GPU 服务器视频分析、边缘推理、行业视觉我见过不少人拿 Atlas 300V 24G 去硬跑训练结果发现 PyTorch 适配层各种别扭、算子缺失、速度比普通 GPU 还慢最后得出“这卡不行”的结论。其实不是卡不行是你把它用错了地方。它在推理场景下的能效比和大显存覆盖能力是它真正的价值所在。2. 为什么把 YOLO 搬到 Atlas 上是值得折腾的事既然它是一张推理卡那最能体现它价值的工作就是目标检测推理——而 YOLO 系列又是目标检测里应用最广、部署需求最大的模型。把 YOLO 搬到 Atlas 300V 24G 上不是无事生非而是有实实在在的场景驱动。2.1 YOLO 系列与昇腾硬件的适配现状目前 YOLO 家族里YOLOv5、YOLOv8、YOLOv10 在昇腾 NPU 上都有可行的部署路径。严格来说PyTorch 训练的 YOLO 权重不能直接在 NPU 上跑需要先导出 ONNX再用 CANN 自带的 ATCAscend Tensor Compiler工具把 ONNX 转换成昇腾离线模型.om。如果算子映射顺利转换就是一条命令的事如果模型里用了一些昇腾不好映射的算子就需要降版本、替换算子或者用 MindSpore 重新实现部分结构。从我的实测经验看YOLOv8 的 C2f 模块和检测头在昇腾上映射得比较顺利YOLOv5 也没什么大坑。YOLOv10 因为结构更新、某些模块在旧版本 CANN 上算子缺失转换时会麻烦一点但 CANN 7.0 之后基本也能跑通。2.2 边缘/行业场景里 24G 大显存的意义为什么非要用 24G 显存的推理卡因为视觉业务大概率不止跑一个模型。一个典型的智慧园区项目可能同时要跑 YOLO 物体检测、一个人体关键点模型、一个车辆属性识别模型。如果每张卡只有 8G、16G 显存通常只能把模型串行调度延迟一上来并发就垮了。24G 显存意味着你可以同时把 3 到 5 个模型常驻在显存里或者用更大的 batch 去压测输通量这对视频流分析这类高并发场景特别友好。另外Atlas 300V 24G 还带硬件视频解码能力能直接把视频流解码成帧送进模型省掉 CPU 做解码的瓶颈。这一整套能力合在一起让它在“视频流实时分析”这个赛道上有独特位置而不是靠单模型算力去跟 GPU 硬拼。2.3 性能预期管理先搞清楚对标对象部署之前一定要先建立合理的性能预期。Atlas 300V 24G 的 INT8 算力标称在 140 TOPS 左右看数值比很多 GPU 好看但这是稀疏 INT8 算力而且昇腾 NPU 的算力利用率高度依赖模型结构和算子实现。拿 YOLOv8s 来说单帧 640×640 输入实测单卡吞吐量能做到每秒 200 帧到 400 帧之间取决于是否开启多 batch、AIPP 是否合入、后处理是否在 NPU 上做这个数字在推理场景里已经相当可观但没办法跟一张 RTX 4090 去对比训练速度——它们的赛道不同没有可比性。建议在项目立项时就给业务方讲清楚Atlas 300V 24G 擅长的是“高并发、多模型常驻、低功耗”的推理场景不是单模型极致算力。3. 部署前环境准备驱动、CANN 与配套软件栈所有昇腾部署的第一步不是写代码而是把环境一次性配好。我第一次搭环境时踩了一堆坑后来总结出一套比较稳妥的顺序照着做能少走很多弯路。3.1 确认板卡型号与 SoC 版本拿到卡后先别急着装软件先在服务器上把卡插好进入系统后用命令确认系统是否识别到设备。在 x86 服务器上一般用lspci | grep -i ascend如果是 Linux 系统且已经装好基础驱动更直接的办法是npu-smi info这个命令会列出所有 NPU 卡的信息包括芯片型号、固件版本、显存大小、当前负载等。对 Atlas 300V 24G 来说你大概率会看到板上芯片对应的 SoC 型号。在 CANN 的 ATC 转换命令里--soc_version参数必须和这个型号匹配。常见的有Ascend310P3、Ascend310P等如果你的卡显示的是其它型号就以实际为准。这一步非常关键因为 ATC 转换时如果soc_version传错工具不会立刻报错但转换出来的 .om 模型在推理时可能直接运行异常或者性能极差。我建议把npu-smi info的输出截图保存后续排错时经常要对照。3.2 驱动与 CANN 工具包的版本搭配昇腾的软件栈分为两层底层是驱动Driver和固件Firmware负责让操作系统识别 NPU 硬件。上层是 CANN 工具包包含 ATC 转换工具、AscendCL 运行时、算子库、推理引擎等。版本搭配有讲究不是越新越好而是驱动、固件、CANN 三个版本必须互相兼容。华为官方提供了一个版本配套表部署前最好按照这个表来选。我这次用的是 23.0.RC3 版本的驱动和 CANN 7.0整体比较稳定。安装驱动时有个经验在 Ubuntu 系统上建议使用 root 用户或者具有 sudo 权限的账号执行安装脚本否则后面运行npu-smi和 ATC 都可能出现权限问题。安装完驱动后需要重启系统或者手动加载内核模块/sbin/ldconfig systemctl restart npu-smi.service然后再次npu-smi info确认设备状态为正常OK 状态再装 CANN。3.3 CANN 安装后的环境变量配置CANN 装好之后最容易被忽略的是环境变量。很多人的部署代码明明路径没问题就是报找不到 libascendcl.so原因就是环境变量没 source。安装完成后建议在/etc/profile或~/.bashrc里加入下面的内容source /usr/local/Ascend/ascend-toolkit/set_env.sh export ASCEND_DEVICE_ID0然后source ~/.bashrc验证一下which atc如果能找到atc命令路径说明环境变量生效了。这一步没做好后面运行 ATC 时会直接卡在“command not found”。4. YOLOv8 模型转换PyTorch 到 OM 的完整链路环境配好后真正的工作才开始。我这里以 YOLOv8s 为例把 PyTorch 权重转换成昇腾可执行的 .om 模型的完整过程过一遍并解释每一步为什么这么做。4.1 为什么非要先转 ONNX 再转 OM昇腾的 ATC 工具原生支持的输入格式包括 ONNX、MindSpore 的 IR、TensorFlow 的 PB 等。PyTorch 的.pt权重不能直接吃所以常规链路是pt → onnx → om。导出 ONNX 时有三件事必须注意否则后面 ATC 转换会出问题输入输出节点名称要固定。ATC 转换时用--input_shape指定输入维度名称必须和 ONNX 里的输入名一致。YOLOv8 导出的输入名通常是images。输出张量形状要固定。YOLOv8 的检测头输出是 (1, 84, 8400)其中 8400 是三个尺度特征图80×80 40×40 20×20的总和84 是 4 个 box 坐标加上 80 个类别分数。如果导出的 ONNX 输出是动态形状ATC 转换时要么显式指定静态 shape要么开启动态 shape 功能后者在推理时会增加复杂度建议初学阶段直接用固定 shape。图像归一化操作建议放在模型外部。YOLOv8 的预处理包括 resize、除以 255、通道转换等你可以选择把这些操作留在 ONNX 图里也可以选择剥离到外部用 AIPP 做。我的建议是用 AIPP具体为什么下面会讲。导出命令可以参考yolo export modelyolov8s.pt formatonnx opset11 imgsz6404.2 ATC 转换命令与参数解读拿到 ONNX 文件后进入 ATC 转换环节。命令的核心结构如下atc --modelyolov8s.onnx \ --framework5 \ --outputyolov8s \ --input_shapeimages:1,640,640,3 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP32逐个参数解释--model输入 ONNX 文件路径。--framework55 代表 ONNX 格式。--output输出 .om 文件的前缀名生成文件是yolov8s.om。--input_shape指定输入张量形状。注意这里用images:1,640,640,3这是 NHWC 布局AIPP 配置里也要用同样的布局。很多人在这一步把形状写成1,3,640,640NCHW结果后面推理时数据排布对不上输出一团乱。--soc_version指定 SoC 型号。实际型号用npu-smi info查不确定时看 CANN 文档中该卡对应的 SoC 名常见是 Ascend310P3。--insert_op_conf插入 AIPP 预处理配置文件是.cfg格式。--output_type指定输出数据类型。YOLOv8 的后处理通常希望在 FP32 下拿到检测结果如果这边输出 FP16后处理解析时数值对不上会有不少坑。转换完成后可以在当前目录看到.om文件和一个aipp.cfg的中间产物。用atc --modelyolov8s.onnx ...跑一次通常只要十几秒到一两分钟但一旦报错排查起来可能需要很长时间所以建议先跑通一个小模型。4.3 AIPP 配置把预处理交给 NPU省掉的不仅是一段代码初次部署时我习惯把所有预处理写在 Python 里比如 opencv 读图、resize、转 float、除以 255、做归一化然后喂给模型。这套逻辑在 GPU 上没毛病但在昇腾 NPU 上会白白浪费不少时间——因为 NPU 取数据的时候你还在 CPU 上做图像预处理整条流水线的时间被拉长。AIPPAI Preprocessing是昇腾提供的一套硬件预处理能力可以把“图像缩放、通道转换、归一化、像素格式转换”这一整套操作烧录进 .om 模型里推理时 NPU 直接从输入数据里完成预处理CPU 只需要把原始图像数据拷进去。一个 YOLOv8 常用的 AIPP 配置如下aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 csc_switch: false rbuv_swap_switch: false crop: false mean_chn_0: 0 mean_chn_1: 0 mean_chn_2: 0 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 }这里var_reci_chn填的是 1/255 ≈ 0.003921569对应 YOLOv8 训练时“除以 255”的归一化操作。input_format: RGB888_U8表示输入是 RGB 顺序的 uint8 图像。如果你的输入是 BGR比如直接用 OpenCV 读入就需要把rbuv_swap_switch设为 true 或者调整通道顺序否则检测结果会莫名其妙地变差——这是最容易犯的错误之一。有一点必须提醒AIPP 里的归一化只做了“乘以 var_reci”没有做均值和方差归一化这与 YOLOv8 官方预处理是一致的。如果你用的是自己训练的 YOLO 变体并且训练时用了额外的 mean/std那么这里要相应地修改mean_chn_x和var_reci_chn_x否则精度会掉。5. 推理部署AscendCL 与 MindX SDK 两条路线.om 模型生成之后就到了推理部署环节。昇腾提供了两套常见的推理方案用 AscendCL 手写推理逻辑或者用 MindX SDK 通过编排配置文件来实现。我两种都折腾过下面分别说一下适用场景和核心思路。5.1 AscendCL 推理的基本骨架AscendCL 是昇腾最底层的 C/C API也有 Python binding适合需要精细控制推理流程的开发者。用 AscendCL 做一次推理的基本流程是初始化、申请设备、加载模型、准备输入输出、执行推理、解析输出、释放资源。用 Python 写的话核心流程大致是import acl # 初始化 acl.init() ret acl.rt.set_device(0) # 加载模型 model_id acl.mdl.load_from_file(yolov8s.om) # 准备输入数据假设已经是 640x640 RGB 数据 input_data np.expand_dims(img, axis0).astype(np.uint8) input_ptr acl.util.np_to_ptr(input_data) # 执行推理 output_data, output_size acl.mdl.execute(model_id, [input_ptr], [input_data.nbytes]) # 处理输出输出是 (1, 84, 8400) 或其他 shape output_np acl.util.ptr_to_np(output_data, output_size, (1, 84, 8400), np.float32)这段代码去掉了很多错误处理和资源释放但核心骨架就是这样。实际工程中建议把acl.mdl.load_from_file放在进程启动时做一次不要把模型加载放进每一帧推理的循环里否则性能会直接崩溃。AscendCL 的优点是灵活、可控、不依赖额外框架缺点是代码量大要自己处理内存分配、格式转换、后处理。适合需要高度定制化、或者想完整理解底层机制的人。5.2 MindX SDK用编排配置降低编码量MindX SDK 是昇腾更上层的推理开发套件核心思路是“插件化流水线”用配置文件把数据读取、图像解码、模型推理、后处理这些插件串成一条链。比如要在 MindX SDK 里跑一个 YOLO 检测流水线你需要写一个 pipeline 配置文件定义各个插件模块输入插件从图片/视频流读取数据图像解码插件硬解码成 YUV/RGB图像缩放插件把输入缩放到 640×640模型推理插件加载 .om 并执行推理后处理插件解析输出 box、打标签这种方式的优点是二次开发成本低很多通用模块不用自己写适合业务交付型项目能快速出一个 Demo缺点是调试起来不够透明一旦某个插件处理结果不符合预期排查链路比纯 AscendCL 长不少。我的个人建议是项目早期用 AscendCL 把模型跑通、把性能摸清楚后面如果要做成标准产品再考虑用 MindX SDK 或者昇腾的 MindIE 做服务化封装。这样既不会一开始就陷进底层细节也不会在排查问题时两眼一抹黑。5.3 后处理解析YOLOv8 输出的两次维度陷阱YOLOv8 的 ONNX 输出形状是 (1, 84, 8400)84 4box 坐标 80COCO 类别数。初学部署时很多人解析这个输出时会踩两个坑第一个坑是维度顺序。推理拿到的输出可能是 (1, 84, 8400)也就是第二个维度是特征第三个维度是候选框也可能是 (1, 8400, 84)取决于导出时是否加了 transpose 节点。建议推理前先打印output_np.shape确认然后根据实际维度写解析逻辑。第二个坑是坐标表示方式。YOLOv8 的 box 回归头输出的是中心点坐标和宽高cx, cy, w, h而不是左上角和右下角。同时它没有 Objectness 分支类别置信度直接由 80 类的分类分数给出。解析时需要在 84 维向量里把前 4 个元素作为 box 参数后 80 个元素找最大分数作为类别再做阈值过滤和 NMS。一个简化版的解析逻辑如下def postprocess(output, conf_thres0.25, iou_thres0.45): # output shape: (1, 84, 8400) output output.squeeze(0) # (84, 8400) boxes output[:4].T # (8400, 4) - cx, cy, w, h scores output[4:].T # (8400, 80) cls_ids scores.argmax(axis1) confs scores.max(axis1) keep confs conf_thres boxes, cls_ids, confs boxes[keep], cls_ids[keep], confs[keep] # 将 cx,cy,w,h 转为 x1,y1,x2,y2 x1 boxes[:, 0] - boxes[:, 2] / 2 y1 boxes[:, 1] - boxes[:, 3] / 2 x2 boxes[:, 0] boxes[:, 2] / 2 y2 boxes[:, 1] boxes[:, 3] / 2 # 然后做 NMS输出最终框NMS 可以自己实现一个简易版本也可以直接用一些后处理库。如果追求高性能很多生产项目会把 NMS 放进模型图里或者用昇腾提供的 MindX 后处理插件在 NPU 上完成省掉 CPU 上的 Python 循环。6. 性能与显存实测24G 显存到底吃满了没有部署完成后不要急着上线先做一轮性能和显存实测用数据说话。这里分享我实测的一些方法和结论不一定适用于你的具体场景但思路可以复用。6.1 吞吐量测试方法我一般用两种方式测吞吐量单线程循环推理测一秒钟能跑多少帧这代表单卡最优吞吐。多路视频流并发每路视频流一个推理线程测整体吞吐和单路延迟。第一种方式最简单。用 Python 写一个循环对同一张测试图反复推理 1000 次记录总耗时得出平均单帧延迟和吞吐量。注意第一次推理通常有初始化开销要预热 10 次后再计时。以 YOLOv8s 640×640 输入为例在 Atlas 300V 24G 上单线程循环推理实测单帧延迟约 3 到 5 毫秒折算吞吐约 200 到 300 FPS。如果开启多 batch比如一次推理 4 张图吞吐还能再往上提但单帧延迟会略微增加。这里不给出具体数字因为驱动版本、CANN 版本、模型结构都会影响结果关键是掌握测试方法用你自己的模型去测。6.2 显存占用观察与多 batch 策略使用npu-smi info可以实时查看每个 NPU 的显存占用。YOLOv8s 模型加载后显存占用一般在 1GB 到 2GB 之间远没到 24GB 的上限。这就会引出两个问题既然显存还有富余能不能把 batch 开大答案是能但要注意昇腾 NPU 的 batch 推理并不总是“batch 越大越快”。我实测过从 batch 1 到 batch 8带宽利用率逐步提升但超过某个临界点后由于内存拷贝和算子调度开销吞吐提升会变缓甚至下降。建议以 2 的幂次方做一组梯度测试找到实际最优 batch。24GB 显存更大的价值是多模型常驻。一个 YOLOv8s 才占 1 到 2GB那同时加载 5 个不同模型还有富余。在多路业务场景下与其纠结单模型 batch不如把几个模型同时加载进显存做成模型级并发这样资源利用率反而更高。我还特意测过显存占用是否有泄漏问题。长时间跑推理时如果npu-smi info里显存占用不断增长说明你的代码里可能有没有释放的输入输出内存。AscendCL 的 Python 接口里使用acl.rt.malloc申请的内存必须显式acl.rt.free否则跑个几万帧就会把显存挤爆。7. 落地中踩过的坑与排查链路这一节专门讲踩坑因为每一行文档里读不出来的细节最终都变成了我深夜排查的泪。我挑了三个最有代表性的问题完整还原排查思路而不是只给答案。7.1 坑一ATC 转换时报不支持算子第一次转 YOLOv8 时ATC 报了“unsupported op type”之类的错误指向某个算子。看到这个报错第一反应可能是“完蛋这个模型不能转”。但实际大多数时候不是不能转而是 ONNX 图里某些算子写法不是昇腾的“舒适区”。我的排查方法分三步先把报错信息里提到的算子名记下来去 CANN 算子清单里查它是否被支持。如果算子本身受支持那就是 ONNX 图里的写法问题尝试用onnxsim简化模型或者把 PyTorch 导出时的 opset 版本从 17 降到 11因为 CANN 对 opset 11 的兼容性通常更稳。如果简化后还是报错再考虑在导出的 ONNX 里把这个算子替换成等价的算子组合。比如某些激活函数在 ONNX 里映射为HardSwish如果昇腾算子库不支持就手动改成Sigmoid 乘法的组合。我这边的实际情况是YOLOv8s 经过onnxsim简化后ATC 一次通过并没有真正需要对算子做手术。但准备好这套“报错—查算子—简化—替换”的排查链路能让你遇到任何模型时都不会慌。7.2 坑二推理结果输出错乱全图都是天马行空的框第一次用 AIPP 跑 YOLOv8 时检测结果出来满屏乱框感觉模型完全“疯了”。排查链路如下先怀疑预处理。我第一反应就是 AIPP 配置有没有问题于是把insert_op_conf临时去掉在外部手动做预处理再喂给模型结果恢复正常——锁定方向预处理链路出错。再检查 AIPP 里的通道顺序。YOLOv8 官方训练用的是 RGB 输入而 OpenCV 默认读出来是 BGR而我 AIPP 配置里input_format设成了RGB888_U8但外部代码直接cv2.imread后没做 BGR2RGB 转换顺序反了模型看到的颜色通道完全乱掉。修正办法要么在读取图像后加cv2.cvtColor(img, cv2.COLOR_BGR2RGB)要么把 AIPP 配置里的rbuv_swap_switch打开。两个选一个就行千万别两个都做否则通道顺序又会被翻回去。这个坑的教训是推理结果异常时先不要怀疑模型坏了先检查预处理链路尤其注意通道顺序、归一化系数、输入布局NHWC vs NCHW这三个最容易出错的地方。7.3 坑三多线程推理时性能不升反降为了模拟多路视频流并发场景我在 Python 里用ThreadPoolExecutor起了 4 个线程每个线程各自加载同一个 .om 模型做推理。预期是吞吐量翻倍结果发现 4 线程跑起来后总吞吐反而比单线程还低。排查过程让我对昇腾的设备管理机制有了更深理解每个线程都调用acl.mdl.load_from_file相当于在同一个设备上下文里加载了多份相同模型显存被重复占用而且调度开销剧增。后来改成所有线程共享同一个已加载的模型 handle推理调用也走同一个上下文吞吐才恢复正常。更深层的原因是单张 NPU 卡的推理引擎本来就有内部并发调度能力你不需要在用户态用多线程去“抢并发”正确的做法是在一个上下文里用合理的请求队列或 batch 策略来压满 NPU。在多路视频流场景下AscendCL 推荐的做法是“多线程 多上下文”或者直接使用 MindX SDK 的流编排让框架帮你做多路调度而不是自己手撸线程。8. 最后说点心里话如果你问我 Atlas 300V 24G 到底值不值得用我的回答是得看你手里是什么活。如果你只是想在 PyTorch 里快速验证模型效果NVIDIA GPU 依然是更省心的选择但如果你要做行业视觉项目交付、要在数据中心里高密度部署视频结构化服务、要在有限的功耗预算下堆路数那 Ascent Atlas 300V 24G 这 24GB 大显存和硬件解码能力就是实打实的优势。我个人折腾下来的最大感受是昇腾的软件栈比 NVIDIA 要“重”文档也经常分散在好几个地方需要耐心翻。但只要跨过了模型转换和环境配置这道坎它的推理性能和稳定性其实相当能打。最后再分享一个我自己的小习惯每次在昇腾上部署新模型我都会把一套完整的 ATC 命令和 AIPP 配置存成一个模板调优时只改模型路径和形状这样能节省大量重复排错的时间。希望这篇经验能帮你少踩几个坑顺利把你手头的 YOLO 模型跑在 Atlas 300V 24G 上。