1. 一张24GB的推理卡先搞清楚它能干什么先回答那个被反复问到的问题Atlas 300V 24G确实是运算加速卡而且不是那种插在个人电脑里跑游戏的显卡它的定位是数据中心和边缘服务器里的AI推理加速卡。很多朋友看到“300V”“24G”第一反应是拿它和RTX 4090、A5000比显存、比算力这其实是把方向搞偏了。我最初接触这张卡时也犯过同样的迷糊后来才发现它的设计逻辑和GPU完全是两个路子。这张卡的核心任务是跑推理Inference也就是把已经训练好的模型部署到生产环境里对接真实的视频流、图片请求、结构化数据在毫秒级内给出检测、分类、分割结果。它不承担模型训练这种重负载任务更不是用来做图形渲染的。所以你会发现它没有显示输出接口不需要风扇主动散热大多数型号是被动散热靠服务器风道带走热量外形也是一张标准的半高半长PCIe卡插在服务器里非常低调。从关键词里的“atlas部署yolo”来看绝大多数人拿这块卡的第一件事就是跑目标检测模型YOLO系列是绝对的刚需。24GB这个显存容量在推理卡里其实相当奢侈了按我的实测经验跑YOLOv5s或YOLOv8s这种量级的模型单卡并行处理十几二十路1080p视频流毫无压力如果只是处理单帧图片请求吞吐量更是能到上千FPS的级别。大显存带来的直接好处是你可以把更多路视频、更大batch塞进去不用频繁做显存换入换出这在视频分析场景里是实打实的优势。但这里要纠正一个误区大显存不等于高性能更不等于“插上就能用”。Atlas系列的软件栈和CUDA生态不是一回事你需要重新理解它的驱动、算子库、模型转换工具链和推理框架。这篇文章我会把从硬件选型到环境搭建、从模型转换到性能调优的完整链路讲一遍重点放在YOLO系列模型的实际部署上包括那些文档里不会明说、只有踩过坑才知道的细节。2. 硬件底细300V Pro的架构、算力和显存设计2.1 昇腾310P芯片与Atlas 300V Pro的核心规格Atlas 300V Pro搭载的是昇腾310P系列芯片这颗芯片是专门为推理场景设计的。整卡标称INT8算力大约在140-240 TOPS区间不同功耗版本有差异FP16算力大约在70-120 TFLOPS左右。说实话只看数字它并不比旗舰游戏卡夸张但推理场景的关键指标从来不是峰值算力而是算力利用率、单位功耗算力和显存带宽的匹配度。拿YOLOv8s举例一张输入分辨率640x640的图片模型本身的计算量大约16 GFLOPs左右。用300V Pro跑单次推理延迟大约在2-4ms区间配合batch处理和多路并发整卡的图片吞吐能做到非常可观的数值。这里面的核心逻辑是推理任务的计算密度相对固定显存带宽决定了数据搬运的上限算力决定了计算的上限只有两者匹配才能把卡喂饱。我整理了一份这卡和常见GPU推理方案的粗略参数对比方便理解它的定位项目Atlas 300V Pro 24GB中端推理GPU如L4高端游戏卡如RTX 4090核心定位AI推理加速AI推理加速兼顾训练/图形/推理INT8算力约140-240 TOPS约242 TOPS约660 TOPSTensorRT优化后显存容量24GB24GB24GB显存带宽约200-300GB/s级别约300GB/s约1008GB/s功耗约72W约72W约450W软件栈CANN/昇腾生态CUDA/TensorRTCUDA/TensorRT典型场景视频分析/边缘推理云推理/边缘推理训练/图形/推理混合2.2 那张24GB显存到底意味着什么24GB显存是我认为这张卡最值得关注的一点因为在推理场景里显存容量在很大程度上决定了你的方案上限。我之前用8GB显存的卡跑YOLOv8x单路视频流勉强能跑但一旦需要同时处理多路视频流或者做大batch推理显存立刻见底程序直接报错。换成24GB之后同样是YOLOv8x我可以放心地把batch设到8甚至16推理吞吐直接翻倍。大显存的另一个用途是缓存模型权重和中间特征图。YOLO系列模型虽然权重不大v8s大约22MBv8x大约130MB但在多路视频流的场景下每一路都需要独立的预处理缓冲区和后处理队列。如果显存不足系统会频繁在CPU内存和显存之间拷贝数据这个拷贝过程对延迟的影响远比你想象的大得多。24GB意味着只要你逻辑写得不离谱基本不用担心显存瓶颈。不过我还是要提醒一句不要因为显存大就无脑往上塞任务。芯片的算力上限摆在那里你把20路视频流全部塞进一个stream里即使显存够用单卡的算力也可能成为瓶颈导致整体延迟飙升。正确的做法是先用小batch测试单次推理延迟算清楚一秒钟能处理多少帧再反推能接多少路视频流而不是拍脑袋决定路数。2.3 缓存一致性和数据传输的隐藏细节这个点很多初次接触昇腾的开发者会忽略。Atlas 300V Pro作为PCIe设备和CPU之间通过PCIe总线通信数据从CPU内存搬到卡上显存的过程是明摆着的开销。但昇腾的软件栈里还有一种被称为“算子上板”的模式部分算子的计算会被拆分成多个子任务下发到芯片的不同AI Core上执行中间的中间结果尽可能留在卡上避免反复搬运。实际部署中你会发现如果预处理逻辑写得不好比如把图片缩放、归一化全部放在CPU上用Python做那么CPU占用率会居高不下卡的算力却有大量空闲。这个问题的根源是数据搬运和预处理把host端堵死了。把预处理挪到卡上做或者用C实现高效的数据管线往往是性能优化里收益最大的一步。我后面在YOLO部署章节会专门讲这块。3. 环境搭建顺序驱动、固件、CANN、PyTorch适配层一个都不能乱3.1 为什么说版本匹配是第一天就该解决的问题Atlas生态最让人头疼的地方也是所有新手第一个劝退点就是软件栈的版本匹配。CUDA生态虽然也讲究版本但整体的宽容度比昇腾好很多。昇腾的软件栈分为几个层级从上到下大致是应用层PyTorchtorch_npu适配、MindSpore、MindX SDK、AscendCL接口算子层CANN的算子库GE、TBE、AIV等运行层AI处理器的驱动和固件driver firmware硬件层Atlas 300V Pro物理卡和服务器主板这几个层级之间互相有严格的版本对应关系尤其是驱动固件需要和CANN版本匹配CANN版本又决定了torch_npu的兼容范围。我曾经在一次部署中因为固件版本过旧导致CANN新版工具链在模型转换阶段频繁报算子编译错误排查了大半天才发现是固件不匹配升级固件后问题直接消失。所以我的建议是动手第一步就去查阅官方文档中的“版本配套表”确定好一套组合拳比如驱动版本号 固件版本号 CANN版本号 PyTorch版本号 torch_npu版本号。把这套组合记录下来以后每次升级都整套走不要单独升级某一个组件。我目前用的比较顺手的组合是组件推荐版本区间备注服务器系统Ubuntu 20.04/22.04 x86_64ARM服务器需要装ARM版软件包驱动固件对应CANN版本的配套版本必须查配套表CANN Toolkit6.3.x或7.0.x越新对PyTorch支持越好PyTorch1.11.0或2.1.0取决于torch_npu版本torch_npu与PyTorch严格对应千万不要混用3.2 安装流程和验证命令具体安装步骤其实官方文档写得很详细我不再抄一遍只说几个容易踩坑的点。第一安装CANN Toolkit时建议顺手安装完CANN ToolKit、CANN Kernels和CANN NNAE三个组件。很多人只装了ToolKit以为就够了结果跑模型转换时提示找不到算子的编译工具链又得返工。Kernels包里是预编译的算子实现NNAE包含模型转换和推理运行时需要的库三件套缺一不可。第二环境变量的source非常关键。安装完成后需要source/usr/local/Ascend/ascend-toolkit/set_env.sh这个脚本设置了LD_LIBRARY_PATH、ASCEND_HOME_PATH等一整套变量。如果漏了这一步你import torch_npu时会直接报找不到so文件的错误。建议把它写进~/.bashrc免得好不容易配好环境新开一个终端又全忘了。第三验证环境是否装好的最快方式是跑一个小脚本import torch import torch_npu # 检查NPU是否可用 print(torch.npu.is_available()) print(torch.npu.device_count()) print(torch.npu.get_device_name(0)) # 简单跑一个张量运算 a torch.randn(8, 3, 640, 640).npu() b a * 2 print(b.shape)如果这个脚本能正常打印出设备信息和张量形状说明环境基本就绪。注意安装完CANN和驱动后建议重启一次服务器让固件和驱动完全加载否则有些PCIe设备不会正确枚举出来npu-smi info命令会看不到卡。3.3 npu-smi你的第一排查工具工具链里最常用的是npu-smi info命令它和NVIDIA的nvidia-smi功能类似能查看卡的实时利用率、温度、显存占用、功耗等关键指标。我每次跑推理测试的时候都会开一个终端挂着npu-smi info实时观察卡的使用状况。有个容易误读的地方要特别说明npu-smi里的“利用率”指的是AI Core的平均利用率不是整卡的负载率。在跑YOLO这类算子密集程度高的模型时利用率一般会比较高但如果你的脚本频繁做数据处理或者后处理AI Core大多时间在等待数据利用率数字就会很低这时候问题多半出在host端的数据管线而不是卡本身。学会看这个数字能帮你快速定位性能瓶颈在哪一侧。还有个容易被忽略的是温度监控。300V Pro大多数是半高被动散热设计依赖服务器内部风道散热。我之前在一台散热设计不佳的机器上测试卡的温度飙到85度以上推理速度明显下降。这时候需要检查服务器风扇转速设置或者把卡插在风道通畅的槽位长时间高温运行不仅降频还会缩短硬件寿命。4. YOLO模型迁移核心链路从PyTorch权重到OM离线模型4.1 两条技术路线AscendCL直调还是MindX SDK把YOLO模型跑在昇腾卡上本质上只有两条路要么用底层一点的AscendCL接口自己写推理流水线要么用MindX SDK里的组件搭一个推理pipeline。两者没有绝对的优劣看你的场景复杂度。AscendCL适合已经有NI栈的团队。比如你有一套基于FFmpeg的视频拉流框架只需要把推理部分替换成NPU调用那用AscendCL嵌入你的既有代码是最灵活的方案。代价是需要自己处理模型加载、输入输出内存管理、预处理后处理等细节开发量相对大。MindX SDK则适合从零搭建一个视觉推理服务。它内置了视频解码、图像缩放、模型推理、目标框后处理等一系列插件化组件你只需要定义一串pipeline配置就能把“视频流进、检测结果出”的完整链路搭起来。快速出Demo的话我强烈推荐用它打底。不管走哪条路核心的模型转换环节是一样的PyTorch权重必须先转成ONNX或Caffe格式再用ATC工具转换成昇腾的OM离线模型。4.2 PyTorch导出ONNX的坑很多人在导出ONNX这一步就卡住了常见问题包括模型里用了自定义算子导出时报错或不支持。YOLOv5/v8的老版本里有用到一些自定义C算子在PyTorch导出ONNX之前需要先关闭或替换掉这些实现。opset版本不兼容。昇腾的ATC工具对不同opset版本的支持度不完全一样我建议统一用opset 11或13来导出太高版本的算子容易导致ATC转换时报不支持。动态维度让转换变得复杂。YOLO的输入通常是NCHW格式N是batch维度H和W是图像尺寸。如果你希望一个模型能跑不同分辨率的图像需要在导出时设置动态轴但这会让ATC转换后的模型性能变差因为NPU无法针对固定shape做极致优化。我的建议很简单能固定shape就固定shape。推理场景里视频流的分辨率本身就是固定的比如1080p640x640输入没必要为了灵活牺牲性能。如果实在需要适应不同分辨率可以把动态范围设定得窄一点比如只支持640和1280两种尺寸用两个模型来兜底。具体的导出参考命令PyTorch侧import torch from ultralytics import YOLO model YOLO(yolov8s.pt) # 设置模型为推理模式 model.model.eval() # 构造固定shape的示例输入 dummy_input torch.randn(1, 3, 640, 640) # 导出ONNX torch.onnx.export( model.model, dummy_input, yolov8s.onnx, opset_version11, input_names[images], output_names[output0], dynamic_axesNone, # 固定shape )这里有一个YOLOv8独有的注意点新版本Ultralytics框架在导出ONNX时会默认把后处理NMS、解码一起导出这会导致ONNX模型里包含NMS算子。昇腾NPU不是不能跑NMS类算子但整体性能不如直接在CPU或者用MindX SDK的专用插件做。实际操作中如果你打算用MindX SDK的模型推理插件建议导出ONNX时排除后处理只保留模型原始的检测头输出通常是三个尺度的特征图。不同版本的Ultralytics有不同的导出参数控制这个行为建议导出后检查输出节点个数来确认是否只导出了主干网络。4.3 ATC转换从ONNX到OM拿到ONNX模型之后下一步就是用ATC工具做模型转换。命令的大致形态如下atc --modelyolov8s.onnx \ --framework5 \ --outputyolov8s_om \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp_yolov8.cfg \ --output_typeFP16参数解释一下--framework5表示ONNX格式的模型这个数字别记错。--soc_version要填你的芯片型号对应的字符串Ascend310P系列的芯片需要根据具体型号选查官方文档确认最稳妥。填错了转换会直接失败。--input_shape要和导出ONNX时的输入shape完全一致。--output_typeFP16很关键可以让模型以FP16精度推理。YOLO系列模型从FP32转成FP16后精度损失基本可以忽略但推理性能会有明显提升。--insert_op_conf是AIPP配置文件用于把预处理算子融合进模型里。转换成功后目录里会出现一个yolov8s_om.om文件这才是最终在NPU上跑的模型格式。OM文件不能用PyTorch直接加载必须通过AscendCL接口或者MindX SDK来加载。这里说下AIPP的作用因为很多初次接触的朋友会懵。正常情况下你的输入图片在进模型之前需要做resize、归一化、通道转换RGB到BGR等这些操作如果在CPU上做会消耗大量CPU资源而且每张图都要做一次延迟上去了。AIPP的思路是把这个预处理步骤配置进OM模型里让NPU在数据进入AI Core之前用硬件完成这些操作CPU那边直接扔原始图片数据就行。配置方法是在cfg文件里指定aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 1920 src_image_size_h: 1080 crop: 1 load_start_pos_h: 0 load_start_pos_w: 0 resize: 1 resize_w: 640 resize_h: 640 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 }这个配置的意思是输入是1920x1080的RGB图像硬件先做crop和resize到640x640再做像素值归一化乘以1/255。有了这个配置你在推理代码里只需要把原始图像数据按二进制形式传给NPU即可CPU端的预处理压力几乎为零。如果不用AIPP纯靠CPU做预处理在高帧率视频流场景下CPU很容易成为瓶颈卡的利用率反而不高。4.4 MindX SDK部署实操MindX SDK的方式比较适合快速落地。配置一个pipeline文件然后写一小段Python代码调用。核心的pipeline配置如下pipeline: streamName: yolov8_app components: - componentName: appsrc componentType: AppSrc - componentName: image_decoder componentType: ImageDecoder - componentName: model_inference componentType: ModelInference properties: modelPath: ./yolov8s_om.om 等待完成 - componentName: tensor_postprocess componentType: TensorPostProcessor - componentName: appsink componentType: AppSink代码方面的工作主要是把图片数据送入appsrc再从appsink拿结果。MindX SDK内部已经做了内存池管理和数据复用性能比你自己用AscendCL裸写要好。这个路径最适合第一次接触昇腾的开发者你可以先跑通SDK的全套流程理解数据是怎么流转的再考虑是否要下沉到AscendCL做更精细的控制。5. 推理性能分析吞吐、延迟、资源占用怎么读才靠谱5.1 单卡YOLO推理性能参考很多朋友关心的“Atlas 300V Pro跑YOLO能跑多少帧”这个问题我给一组基于我个人测试和社区中常见数据的参考值具体数字会因软件版本、模型精度、输入分辨率、batch大小而浮动模型输入分辨率batch1延迟单卡吞吐batch8备注YOLOv5s640x640约2-3ms约500-800 FPSFP16 AIPPYOLOv8s640x640约2-4ms约400-700 FPSFP16 AIPPYOLOv8m640x640约5-7ms约200-350 FPSFP16 AIPPYOLOv8l640x640约8-12ms约100-200 FPSFP16 AIPP这些数据不是跑分软件出来的理论值而是实际推理框架里能拿到的可用性能。个人感受是YOLOv8s这个档位的模型和300V Pro的适配度最好性能和精度比较平衡如果做视频分析项目我一般首推它。5.2 为什么单独的“延迟”和“吞吐”都容易误导人看性能数据时最容易踩的坑是只盯着单次推理延迟。延迟低不代表整卡吃满比如batch1时延迟2ms看起来单帧很快但卡上绝大部分AI Core是闲着的完全没有发挥整卡算力。反过来看吞吐batch16时吞吐很高但每一帧的端到端延迟可能已经到了20ms以上对实时性要求很高的场景就不适用了。所以正确评估一张卡能不能扛住你的业务要看你的实际负载模型如果是在线推理服务用户请求一张图等结果返回那么你需要关注的是单次请求的P99延迟此时batch不能开太大因为batch1的延迟往往最优如果是离线批量分析比如对一批历史视频做检测结果不要求实时返回那么batch可以开大追求吞吐最大化。这两个场景对batch、线程数、内存池的配置要求完全相反用错配置会带来大幅性能损失。5.3 多路视频流的显存占用估算关于24GB能跑多少路视频我做了一个比较粗略的估算方法。以YOLOv8s 640x640为例单路视频流在NPU上的显存占用由几部分组成输入输出缓冲区约几十MB、模型权重约几百MB、中间特征图缓冲区根据batch分配每路几MB到几十MB不等、后处理缓冲区。实际观察下来单路1080p视频流的显存开销大约在200-500MB左右24GB的卡同时跑20-30路视频流显存上是绰绰有余的。但要注意多路视频流跑得起来不代表每一路的延迟都能接受。如果你用单个stream顺序处理所有路那么总吞吐等于单路吞吐每路的实时性会随路数增加线性恶化。正确的做法是用多线程或多stream的方式让各个stream并行跑充分利用整卡的并行能力。昇腾CANN支持创建多个推理stream每个stream可以绑定不同的线程或进程配合数据预取和结果异步回调才能把多路视频流的性能榨干。5.4 host端优化把CPU从数据搬运里解放出来之前反复提到预处理放CPU会拖后腿这里具体展开下怎么优化。假设你的输入是视频流每一帧都是1920x1080的RGB数据如果松手直接在Python端做resize、归一化、BGR转换Python的GIL和多层封装会让这个过程异常缓慢CPU占用轻松拉满帧率却上不去。推荐的做法是解码用硬件解码器如果服务器有昇腾卡配套的硬件解码能力DVPP模块尽量用它解码视频不要把原始视频流丢给FFmpeg软解。DVPP输出的数据可以直接被AIPP消费这条路是数据管线性能最优解。批量预处理如果你的推理框架直接从内存里拿原始帧做推理可以先把一批图片的原始数据攒在一起交给AIPP统一做resize和归一化。内存拷贝尽量用内存拷贝指令做对齐拷贝减少CPU非对齐访问。后处理不要贪多NMS这类操作本来就是计算密集的如果放在CPU上跑且你的检测目标特别多比如一张图有几百个检测框CPU会瞬间成为瓶颈。这种情况建议把NMS搬到NPU侧实现或者用MindX SDK内置的TensorPostProcessor插件来处理。我实际测过自定义的后处理插件在CPU上跑detect任务时消耗的CPU核数可能比解码还高。6. 踩坑实录算子兼容、动态shape、多卡调度里的隐性问题6.1 算子不支持不等于模型不能跑第一个坑永远是算子兼容性。ONNX转换成OM时ATC工具会逐个算子检查是否有对应实现。遇到不支持的情况千万不要慌也不要立刻放弃。我记得第一次转一个稍微改了检测头的YOLOv5变体时ATC报了一个ScatterND算子不支持尝试了很多办法最后发现这个算子出现在模型的后处理解码部分完全可以绕过——把模型里那段逻辑放到host端去处理而不是强行让NPU支持它。处理算子不支持问题我的思路是从这几个方向排查算子在ONNX里是哪个模块产生的能否在导出时绕过或改写。算子是否可以被等价组合替换比如某些不常见的激活函数可以用几个基础算子的组合替代。新版本CANN是否已经支持如果ATC版本太老升级CANN往往能直接解决问题。社区里常提到的“ONNX Simplifier”这类工具也有帮助它可以把一些冗余或难以转换的算子结构简化掉提升ATC转换成功率。但注意简化工具可能改变模型的数值精度转完最好用若干张真实图片做对比验证确保精度损失在可接受范围内。6.2 动态shape模型转换后的隐藏性能损耗让模型支持动态输入shape是个很诱人的需求因为业务里图片尺寸可能千变万化。但昇腾的执行方式是离线编译针对特定shape做算子调优。如果你把模型的shape设成动态范围ATC在编译时会退化成用通用的保守策略很多算子的计算效率会大幅下降。实测下来动态shape模型的推理性能可能只有固定shape模型的50%-70%差距非常明显。所以我的建议是尽可能地收窄shape范围。比如你可以设定输入宽度和高度在[640, 1280]之间取固定步长然后在应用层先对输入图片做letterbox让图片尺寸对齐到模型支持的固定尺寸。这种“有限动态”的思路牺牲了一点点灵活性却保住了大部分性能。在CV领域letterbox是业内成熟的做法基本无损检测精度。6.3 多卡调度不是插上两张卡就自动并行一台服务器里插多张Atlas 300V Pro时很多人第一反应是“CANN会自动帮我负载均衡”其实完全不是这样。CANN的调度粒度是设备维度你需要显式指定每张卡执行哪个任务。简单场景下可以用多进程的方式每个进程绑定一张卡通过环境变量ASCEND_DEVICE_ID或者代码里的npu.set_device()指定各自独立跑推理任务。个别场景会用到多卡协同跑一个大模型的编排模式比如把一个模型切到两张卡上并行执行但那是相对高级的用法对YOLO这类中小型模型来说没有必要。多卡实际项目里最常见的还是多路视频流分摊到多张卡上。这时候负载均衡的策略得自己写比如按照视频路数的奇偶分配或者实现一个简单的按卡占用率动态分配的逻辑。我见过不少项目在单卡上跑得很顺一上多卡反而频繁出现内存异常或推理超时大概率是没注意PCIe带宽的竞争。多卡同时跑起来后每张卡都要通过PCIe总线搬运数据如果主板PCIe通道数量不够或者插槽速率不一致数据搬运会互相抢带宽延迟飙升。所以在服务器选型阶段就要确认清楚PCIe拓扑结构尽量把卡插在直连CPU的x16槽位上。6.4 固件升级和驱动重装导致的环境“精神分裂”最后一个容易被忽视的坑是升级带来的环境不一致。昇腾的驱动和固件更新不是“覆盖安装”那么简单旧版本的驱动模块如果没有卸载干净新驱动加载时会和旧的固件版本互相纠缠出现各种莫名其妙的错误。比如程序运行时突然报device error、mcu reset或者NPU利用率显示异常很多时候不是代码问题而是驱动固件层面“新旧共存”导致的不稳定。我的经验是遇到版本升级计划先记下当前运行的完整版本号包括驱动、固件、CANN、torch_npu然后走标准卸载流程把旧组件清理干净再安装新版本。装好后用npu-smi info确认固件和驱动版本都为预期值再跑一遍之前的验证脚本。不要为了省时间跳过卸载直接覆盖安装这个习惯能帮你避开大部分环境相关的诡异问题。另外给服务器做好散热规划这件事我再强调一遍。Atlas 300V Pro是被动散热依赖服务器内部的风道设计。如果不确定你的服务器风道能不能压住它开机跑一次高负载推理用npu-smi info观察温度稳定在什么区间。如果环境温度接近80度以上就要考虑加强机箱风扇转速或调整卡的位置。高温环境下的持续运行会严重缩短硬件寿命推理性能也会因为降频明显波动这个问题在我之前给客户做方案时遇到过好几次都是机箱风道设计不合理导致的。部署这类推理卡我最大的体会是别把硬件当黑盒也别被软件栈吓退。昇腾的生态和CUDA比起来还年轻很多坑需要自己踩但一旦把模型转换、数据管线和版本管理这三件事理顺后面的日常维护会非常稳定。YOLO只是起点同样的流程稍微改一改就能迁移到姿态估计、分割、OCR、行为识别这些模型上。如果你刚开始接触Atlas 300V Pro我建议第一步不要急着跑复杂的业务老老实实把环境搭好、把官方Demo跑通再逐步替换成自己的模型和代码。磨刀不误砍柴工这个顺序能帮你省下大量后面排查问题的时间。