“Atlas 300V 24G 到底是不是运算加速卡”——如果你是因为搜到这个词、又在考虑把它和 YOLO 部署放在一起那么这篇文章你应该能直接拿去用。先回答这个热搜问题对也不完全对。Atlas 300V 24G 和很多人熟悉的游戏显卡长得像、插槽也像但它的定位不是“图形加速”而是专为 AI 推理设计的运算加速卡。它里面跑的芯片是昇腾系列 NPU不是 GPU 核心。它不是一张显卡而是一张“专门用来跑神经网络模型”的加速卡。这篇文章我会从硬件架构讲起再到如何在它上面把 YOLO 目标检测模型完整部署起来包括模型转换、推理代码、性能调优、踩坑记录。不管是刚入门的算法工程师还是已经在做边缘计算落地的运维同学都能照着走一遍。我一直觉得对 AI 工程师来说学会在 NPU 上部署模型正在变成和当年学会用 GPU 跑训练一样的基础技能。GPU 时代我们习惯了“模型拿过来就能用”但到了昇腾这类 NPU 平台上整个流程多了一个关键的“模型转换”环节这也是大部分人卡住的地方。1. 先搞清楚 Atlas 300V 24G 到底是什么加速卡1.1 一张容易被“外貌”欺骗的卡很多第一次拿到 Atlas 300V 的人都会先愣一下它和常规显卡长得太像了。全长全高、PCIe 接口、正面覆盖着大块散热鳍片插进服务器里毫无违和感。但它机身背板上的标注写得清清楚楚——Atlas 300V Pro / Atlas 300V Standard。这里面“300V”的 V 指的是“视频分析Video Analysis”方向的推理场景24G 是指板载显存 24GB。注意这里的“显存”严格来说是 NPU 的专用缓存/内存和 GPU 的显存工作方式不完全一样但对使用者来说作用类似——决定你一次能塞多大的模型、多长的输入序列。产品线里还有个容易混淆的点Atlas 300T 系列是训练卡Atlas 300V / 300I 系列主攻推理。训练卡和推理卡在设计理念上完全不同——训练卡更关注“怎么把大模型快速训练出来”算力要猛、存储带宽要高推理卡更关注“模型已经训练好了我该怎么低成本、低延迟地跑起来”。Atlas 300V 24G 就是后者。所以如果有人问“它是运算加速卡吗”准确回答是它不是图形渲染加速卡而是神经网络推理加速卡主要工作是代替 CPU 去高速运行已训练好的深度学习模型比如目标检测网络 YOLO。1.2 NPU 到底比 GPU 强在哪为什么跑 YOLO 这么合适先打一个不太严谨但很好懂的比方GPU 像一辆跑车速度快但油耗高NPU 更像一台专用加工机床不够“万能”但加工特定零件神经网络算子效率极高、功耗低、故障率也低。具体到 YOLO 这种卷积神经网络它的大量计算集中在卷积算子、BatchNorm 算子、激活函数和矩阵乘上。Ascend 310P 芯片内部有专门的计算单元对卷积运算做了深度优化在 INT8 精度下算力非常可观。再加上 NPU 的能耗比优势Atlas 300V 24G 做推理时整卡功耗一般能控制在几十瓦的水平同等工作量下功耗往往是 GPU 的几分之一。这也是为什么很多做安防、智慧园区、工业质检的项目最终都选了 NPU 板卡而不是 GPU——性能够用功耗和散热压力小很多运维成本也更可控。另一个关键点是 YOLO 这类单阶段目标检测模型结构相对固定算子类别不算复杂。NPU 对这类“结构稳定的卷积网络”支持度非常高只要把权重转换格式推理速度完全可以赶上甚至超过同价位的入门级 GPU。1.3 这张卡适合谁不适合谁我用过一段时间后总结下来它的适用人群和场景非常清晰适合做边缘侧/单机服务器推理部署的团队视频流分析、人脸检测、工业缺陷检测、智慧交通基本是它的主场。适合需要低功耗、高密度算力的机房场景一台服务器能插多张卡单路功耗低不需要改造机房供电方案。适合已经完成模型训练希望在国产平台上做落地的业务方CANN 工具链成熟度这几年提升很快已经到可以正常工程化使用的阶段。但它不是万能的不适合做模型训练尤其不适合做大模型预训练。它的芯片设计就是面向推理优化的反向传播支持度有限。不适合跑动态图、控制流很复杂的模型。虽然新版 CANN 对动态 shape 支持越来越好但和 GPU 上“什么模型都敢丢进去跑”的生态比仍有差距。不适合需要大规模算子自定义的项目。如果模型里有一堆深度定制的 CUDA 算子迁移到 NPU 的成本会很高。2. 部署 YOLO 的整体路线从 PyTorch 权重到 NPU 能跑的模型2.1 为什么不能直接拿 PyTorch 权重去运行这是新手最常见的疑问。在 GPU 上我们通常直接加载.pt/.pth权重就能跑推理因为 PyTorch 的运行时直接调用了 CUDA 库GPU 和框架之间是无缝衔接的。但 NPU 不一样。昇腾平台的核心推理框架是 CANNCompute Architecture for Neural Networks它和 PyTorch 的前向计算实现是不同的。它不认识torch.onnx.export之前那种由“Python 对象 动态图机制”表示的模型它需要的是一个静态的、结构清晰的中间表示经过编译优化后变成 NPU 可执行的文件格式——OMOffline Model。这个流程很像程序员把 C/C 源码编译成某个 CPU 架构的机器码PyTorch 权重是“源码”ONNX 是“跨平台汇编”OM 是“当前主机的可执行文件”。中间的转化工具就是 ATCAscend Tensor Compiler。2.2 一整条链路看着很长但核心就三步整个部署链路我拆解下来就三步把训练好的 PyTorch YOLO 模型导出成 ONNX 格式。用 ATC 工具把 ONNX 转换成昇腾的 OM 离线模型。在目标环境下用 AscendCL或者配套的 Python 接口加载 OM 模型传图片进去拿输出结果。后面所有的安装、环境变量、依赖处理都是为这三步服务。理解了这条主线回头再看官方文档就不会觉得杂乱。2.3 官方文档看不清的版本匹配问题我必须提醒一点昇腾的软件栈非常吃版本匹配。驱动、固件、CANN Toolkit、Python 版本甚至操作系统版本任何一个偏差都可能导致安装失败或者推理结果莫名其妙出错。以我踩过坑的教训来说常用的稳定组合是操作系统Ubuntu 20.04 / 22.04 x86_64部分团队用 openEuler也可以CANN Toolkit6.x 以上版本新项目建议直接用 7.0 稳定版Python3.8 / 3.9 / 3.10 均可具体看 CANN 配套说明模型版本YOLOv5 v6.0 以上或者 YOLOv8 官方仓库最新版注意安装驱动的版本号要大于或等于固件版本号两者需要一起配套升级不能只升其中一个。这个顺序错了npu-smi 里很可能看不到设备。3. 环境准备把 CANN 软件栈完整铺起来3.1 驱动、固件、Toolkit 的安装顺序这一步很多人上来就装顺序错了又全部卸载重来。你只要记住一条规则先用 root 用户安装驱动和固件然后创建普通用户再在普通用户下安装 CANN Toolkit。第一步在安装前先检查系统是否已有昇腾相关环境lspci | grep -i ascend如果有输出说明硬件已被识别可以继续装软件。如果没输出先检查卡是否插到位、服务器是否开启了 PCIe 设备枚举。第二步下载对应版本的驱动和固件包。以 CANN 7.0 为例通常需要两个文件Ascend-hdk-version_linux-arch.run驱动和固件合包Ascend-cann-toolkit_version_linux-arch.run执行安装# 以 root 执行安装驱动固件 ./Ascend-hdk-version_linux-x86_64.run --full # 验证是否安装成功 npu-smi info看到板卡信息列表就说明驱动固件OK。然后切到普通用户安装 Toolkit./Ascend-cann-toolkit_version_linux-x86_64.run --install安装完成后会提示你 source 环境变量脚本一般是source /usr/local/Ascend/ascend-toolkit/set_env.sh强烈建议把这条命令写进~/.bashrc因为每次新开终端忘记 source就找不到atc和msopst工具了容易误判工具没安装。3.2 建立 Python 虚拟环境避免“污染全局”搭建 Python 环境时不要图省事直接往系统 Python 里装包。CANN 自带的配套组件有时会和 conda 里的依赖冲突我建议先建一个干净的虚拟环境conda create -n atlas_yolo python3.9 -y conda activate atlas_yolo pip install numpy opencv-python这里numpy版本很关键。CANN 的接口内部依赖 numpy如果你装了最新版 numpy比如 2.x可能会遇到二进制兼容问题。稳妥做法是安装 1.24.x 左右的版本pip install numpy1.253.3 npu-smi 必须会看的两项内容npu-smi info输出里我最常盯的是两个指标一个是HugePages-Total。如果数值为 0说明系统没预留大页内存NPU 上跑较大模型时会很容易失败。可以在/etc/sysctl.conf里加vm.nr_hugepages4096然后执行sysctl -p生效。每页默认 2MB4096 页就是约 8GB 的大页内存对部署 YOLO 来说完全够用。另一个是Temperature。Atlas 300V 是无风扇被动散热设计机柜风道不顺畅时很容易过热降频推理延迟会翻倍。如果发现温度长期超过 75℃优先检查服务器风道方向而不是找软件问题。这个坑我遇到过两次一开始以为是程序写得不对结果纯粹是散热问题。4. 模型转换实操从 ONNX 到 OM 的完整流程4.1 导出 ONNX 文件并检查算子版本以 YOLOv5 为例导出 ONNX 非常简单import torch from models.experimental import attempt_load model attempt_load(yolov5s.pt, map_locationcpu) model.eval() dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axes{images: {0: batch}, output: {0: batch}} ) print(export done)注意这里我把opset_version11固定下来而不是用默认的最新版。CANN 对 ONNX 算子支持是逐步追平的较新的 opset如 17、18里一些不常用算子可能还没覆盖全。opset 11 是经过大量验证的稳定档位兼容性和算子覆盖率最好。导出后用官方工具看一眼python -m onnxruntime.tools.check_onnx_model yolov5s.onnx也可以直接用 Python 加载 ONNX 检查节点import onnx model onnx.load(yolov5s.onnx) onnx.checker.check_model(model) print(len(model.graph.node), ops)如果模型里出现了Multinomial、NonMaxSuppression这类算子请务必先确认 CANN 是否支持不支持就回退到导出前的模型把后处理放到 NPU 外面用 Python 做。这算是 YOLO 部署里最常见的一个坑在 GPU 上跑 ONNX Runtime 没问题但 ATC 转换时报“Unsupported Op”。我一般遇到底层算子不支持时优先考虑把该算子对应操作改到后处理里而不是强行换模型结构。4.2 ATC 转换参数选型与 soc_version 判断执行 ATC 转换前你必须知道自己的卡对应什么soc_version。查询方法有很多最稳妥的是看npu-smi info里的芯片型号然后对照文档。Atlas 300V 用的昇腾 310P 系列芯片在 ATC 里一般填Ascend310P3、Ascend310P1或者统一的Ascend310P不同 CANN 版本写法略有差异实际用Ascend310P3覆盖较广社区里多数成功案例也是这个值。转换命令模板atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_om \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp.cfg \ --output_typeFP32逐个说说参数含义--framework5固定值表示输入模型是 ONNX 格式。--output输出文件名不带.om后缀也会自动补。--input_shape输入张量的固定 shape。这里如果你在导出 ONNX 时用了动态 batch可在转换时指定images:1,3,640,640让模型编译成 batch1 的固定版本为性能和稳定性考虑。--soc_version和芯片型号严格对应填错会报“RuntimError: soc version is invalid”。--insert_op_confAIPP 预处理配置文件AI Preprocessing简称 AIPP用于把图像的缩放、减均值、除方差、通道变换等预处理下沉到 NPU 上完成省掉 CPU 上的预处理时间。--output_typeFP32指定输出层数据类型一般保持 FP32 足够部分模型用 FP16 可减少带宽占用。一个完整的 AIPP 配置文件aipp.cfg内容大致是这样的aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_h: 640 src_image_size_w: 640 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 }这里var_reci_chn_0 1/255相当于把像素从 0-255 归一化到 0-1。如果你的训练代码里用的是 ImageNet 的 mean/std 归一化也要在 AIPP 里配置对应数值否则 NPU 上跑出的检测框位置、置信度会和 GPU 上对不上。4.3 shape 策略固定 shape 与动态 shape 的取舍很多人问我“YOLO 能不能支持任意分辨率输入” 能但要付出性能代价。固定 shapeATC 编译时会做极致优化比如算子融合、内存复用、静态调度。推理速度最快但输入分辨率不能变。对大多数固定相机场景如 1080p 视频流裁剪缩放、固定业务系统推荐直接固定 shape。动态 shape设置input_shape为images:-1,3,-1,-1并用--dynamic_shapeTrue编译灵活度高但推理前 NPU 需要重新进行 shape 推导和内存规划延迟明显上升占用也变大。如果业务对延迟敏感不建议开。我个人的项目里如果是工业质检这种固定视野场景直接用固定 shape如果是通用安防平台要兼容多种码流分辨率就按项目里最大分辨率来固定必要时再换模型版本而不是全流程动态。4.4 转换后怎么检查 OM 是否正常转换成功后会生成yolov5s_om.om文件。先不要急着写代码用 CANN 自带的msopst工具检查模型信息msopst info --modelyolov5s_om.om输出里能看到模型输入输出的张量名、shape、数据类型这些信息必须和后面写推理代码时保持一致。我之前遇到过输出维度是[1, 25200, 85]还是[1, 25200, 580]的差异通过这个命令一眼就能看明白。5. 推理代码实现在 NPU 上跑起 YOLO 检测5.1 AscendCL 编程流程全梳理CANN 的应用编程接口叫 AscendCLAscend Computing Language官方提供了 C 接口和 Python 的pyacl绑定接口。整个推理流程的固定套路是acl.init()初始化资源acl.rt.set_device(0)指定设备acl.mdl.load_from_file(om_path)加载模型acl.mdl.create_desc()获取模型描述信息申请输入、输出内存acl.mdl.execute()执行推理解析输出acl.mdl.unload()释放模型acl.rt.reset_device(0)释放设备acl.finalize()收尾这个套路和 CUDA 的cudaSetDevice - cudaMemcpy - kernel launch - cudaMemcpy back高度相似写过 GPU 推理代码的人很容易迁移。5.2 数据预处理必须在 CPU 上做还是可以下沉前面 AIPP 已经能做不少预处理比如 resize、归一化、通道交换。但有一个预处理它做不了letterbox保持宽高比的缩放填充。因为 YOLO 训练时通常把输入图缩放到 640x640同时保持原始宽高比不变剩余部分用灰色填充。这个操作包含动态计算缩放比例、计算填充边距AIPP 做不来需要在主机侧用 OpenCV 算好。正确的顺序是import cv2 import numpy as np def letterbox(img, new_shape(640, 640), color(114, 114, 114)): shape img.shape[:2] 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]) / 2 dh (new_shape[0] - new_unpad[1]) / 2 if shape[::-1] ! new_unpad: img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, valuecolor) return img然后把 BGR 转 RGB、HWC 转 CHW、转 float32、归一化如果没下沉到 AIPP 的话最后np.ascontiguousarray确保内存连续再喂给 ACL 接口。数据格式最容易出错我列一张对照表方便自查步骤输入形状数据类型含义原始帧H, W, 3uint8 BGRcamera 输出letterbox 后640, 640, 3uint8 BGR保持宽高比缩放BGR转RGB640, 640, 3uint8 RGB符合模型通道顺序HWC转CHW1, 3, 640, 640float32NPU 输入格式千万不要漏掉np.ascontiguousarray()。PyTorch 训练时模型内部自动处理了张量连续性但 numpy 经过 transpose、切片后经常产生不连续内存直接传给 ACL 会导致数据读取错误推理结果会变得非常诡异。5.3 Python 推理核心代码参考下面是一段简化但结构完整的 Python 推理代码用的就是 CANN 自带的pyacl绑定不同版本包名可能有acl或pyaclimport acl import cv2 import numpy as np class YoloNpu: def __init__(self, om_path, device_id0): self.device_id device_id ret acl.init() ret acl.rt.set_device(self.device_id) self.context, ret acl.rt.create_context(self.device_id) self.model_id, ret acl.mdl.load_from_file(om_path) self.model_desc acl.mdl.create_desc() ret acl.mdl.get_desc(self.model_desc, self.model_id) # 获取输入输出尺寸 self.input_size acl.mdl.get_input_size_by_index(self.model_desc, 0) self.output_size acl.mdl.get_output_size_by_index(self.model_desc, 0) self.input_dim acl.mdl.get_input_dims(self.model_desc, 0)[1] self.output_dim acl.mdl.get_output_dims(self.model_desc, 0)[1] self.input_data None self.output_data None def _prepare_buffer(self): self.input_data acl.util.numpy_to_ptr(np.zeros((self.input_size,), dtypenp.uint8)) self.output_data acl.util.numpy_to_ptr(np.zeros((self.output_size,), dtypenp.int8)) def infer(self, input_np): # input_np: 已做过 letterbox、归一化、CHW 的 float32 numpy 数组 if self.input_data is None: self._prepare_buffer() acl.util.numpy_to_ptr(input_np, ptrself.input_data) ret acl.mdl.execute(self.model_id, self.input_data, self.input_size, self.output_data, self.output_size) output_np acl.util.ptr_to_numpy(self.output_data, (self.output_size,), np.int8) return output_np def release(self): if self.model_desc: acl.mdl.destroy_desc(self.model_desc) if self.model_id: acl.mdl.unload(self.model_id) if self.context: acl.rt.destroy_context(self.context) acl.rt.reset_device(self.device_id) acl.finalize() # 使用示例 model YoloNpu(yolov5s_om.om) img cv2.imread(test.jpg) img_letterboxed letterbox(img, (640, 640)) img_rgb cv2.cvtColor(img_letterboxed, cv2.COLOR_BGR2RGB) blob np.transpose(img_rgb, (2, 0, 1)).astype(np.float32) / 255.0 blob np.ascontiguousarray(blob[np.newaxis, :, :, :]) output model.infer(blob) # 后续从 output 里解析检测框 model.release()注意输出数据的解析依赖模型的输出格式。YOLOv5 原始导出的 ONNX 一般输出是[1, 25200, 85]其中 85 4个坐标 1个置信度 80个类别。你需要把二进制的 output 重新 reshape 成对应维度再做 Decode 和 NMS。整个后处理如果在 CPU 上完成耗时大约 5-10ms基本不构成瓶颈如果你追求极致延迟可以考虑分出一部分算子下沉到 NPU 做但复杂度会明显上升建议先跑通 CPU 后处理再优化。5.4 后处理最终解码含坐标缩放还原后处理里最容易被忽略的是坐标缩放还原。NPU 输出坐标是基于 640x640 输入图坐标系必须按 letterbox 的缩放比例反向映射回原始图片坐标系否则画出来的框会整体偏移。核心公式x_scale orig_w / 640.0 y_scale orig_h / 640.0 # 但如果做了 letterbox 填充要先减去 padding x1 int((cx - w / 2 - left) / r) y1 int((cy - h / 2 - top) / r) x2 int((cx w / 2 - left) / r) y2 int((cy h / 2 - top) / r)其中left、top是 letterbox 填充的宽度和高度r是缩放比例。如果把这几个参数忘了检测框位置会系统性偏移特别容易出现在图像边缘目标上。6. 性能实测参考与问题排查实录6.1 跑 YOLOv5s 在 300V 上的性能预期很多人在选型前都会问“这张卡跑 YOLO 到底实时不实时”。我整理了多次实测的平均数据基于 YOLOv5s 640x640 输入、固定 shape、AIPP 预处理下沉 NPU、后处理在 CPU 的场景配置端到端耗时FPS说明YOLOv5s 640x640单batch15-25 ms40-60正常水平温度低时接近前者YOLOv5s 640x640多batch(4)40-60 ms60-80总吞吐更高适合批量离线处理YOLOv8s 640x640单batch20-30 ms30-50模型稍重参会多YOLOv5s INT8 量化后5-10 ms100性能翻倍但精度需评估说明具体延迟受模型版本、CANN 版本、服务器 CPU、内存带宽影响很大上面的数字只是一个工程参考范围。如果你的延迟明显偏高第一个要查的是 NPU 有没有满负荷跑起来。可以用npu-smi info watch实时刷新看 AICore 的利用率如果利用率只有 20% 而延迟又高大概率问题出在数据预处理或 Host 侧拷贝瓶颈而不是模型本身慢。6.2 常见报错与排查速查表我在实际部署中遇到过的、以及身边同事反复踩到的坑整理如下错误现象可能原因解决办法ACL_ERROR_RT_PARAM_INVALID输入 shape 与实际张量不一致用msopst info检查 OM 输入确保 numpy 数组 shape 完全一致Unsupported OpONNX 算子超出 CANN 支持范围升级 CANN 版本或把算子改到后处理中推理结果全为 0 或全 NaN输入数据没有做归一化/通道顺序错误对照 5.2 节的预处理自查表逐步检查检测框整体偏移letterbox 填充未还原检查后处理中是否减去了 padding 再换算坐标设备初始化失败驱动和固件版本不匹配重装驱动固件确认版本配套mkdir /dev/shm failed容器内存设置过小启动容器时加--shm-size8g模型加载慢首次加载需要内存映射第二次加载会快很多可在服务启动时预加载6.3 几个隐藏很深的工程坑第一个坑HugePages 不足导致模型加载失败。如果你加载 OM 模型时提示内存分配失败先看npu-smi info里的 HugePages-Total用free -h查看系统大页内存预留。前面在第 3.3 节里配置过的vm.nr_hugepages在这里就起作用了。第二个坑不要把 OM 模型放到 NFS 挂载盘上运行。我们当时图省事把模型文件放在共享存储里结果 NPU 加载模型时频繁超时后来拷到本地盘就一切正常。原因可能与文件锁和网络延迟有关虽然不是绝对但在生产环境尽量避免。第三个坑CPU 后处理线程不要混在 GPU/NPU 主线程里导致周期抖动。YOLO 后处理里的 NMS 是单线程 CPU 密集操作如果主进程里同时有别的 Python 计算任务推理延迟会明显波动。建议把推理进程和业务逻辑分离用消息队列传递输入输出。第四个坑reset 上下文和释放内存的时机。AscendCL 要求所有acl操作都在同一个线程里完成。如果折腾多线程推理一定要保证acl.init()和最后的acl.finalize()在同一个线程执行否则会出现诡异的段错误排查起来非常浪费时间。7. 最后的经验分享坦白讲Atlas 300V 24G 在国产 AI 推理加速卡里已经算生态比较成熟的一张卡了。用下来的整体感受是它需要的不是更高的理论知识而是耐心把“转换-适配-调优”这条链路走通。只要第一步环境装对、第二步模型转换通过、第三步预处理对齐剩下的事情就是不断压榨性能和稳定性。很多人初次接触时觉得 ONNX 转了 OM 就等于大功告成结果在预处理上翻车检测框一会儿对一会儿错。我自己也有一次排查了整整一天最后发现只是 BGR 和 RGB 顺序搞反了。所以如果你也遇到类似问题建议先做一张颜色鲜明的纯色图片、打印输入张量的第一个像素值用最笨的办法定位数据流到底哪一步不对。最后再分享一个小技巧CANN 环境变量里有一个ASCEND_GLOBAL_LOG_LEVEL0可以打开 full 日志报错时把/root/ascend/log/plog下的日志拉出来搜一下大多数问题的真正原因都在里面比在网上盲搜效率高得多。遇到不懂的算子或报错也可以直接去昇腾社区提交 issue附上完整日志和最小复现代码官方响应速度还挺让人意外的。希望这篇长文能让你少走弯路。接下来就动手跑一张 YOLO 测试图试试看吧把第一个推理框调出来后后面的事情会顺利很多。
