1. 项目概述与平台选型思路1.1 为什么是Orin Nano 2入门级边缘AI的性价比之选做边缘AI和实体AI也就是机器人、机械臂、移动小车这类真正跑在物理世界里的智能设备这一年多我身边不少朋友都在纠结到底用哪块板子起步。有人一开始就上AGX Orin结果预算超了不说功耗和散热在原型阶段也是个麻烦。有人图便宜选了树莓派加USB加速棒跑个MobileNet还行一上YOLOv8s就卡得没法看。我的结论是在入门级这个档位上NVIDIA Jetson Orin Nano 2确实是当前综合成本、生态、算力三者平衡得最舒服的一块板子。先说个容易被忽略的点。Orin Nano 2这一代把内存带宽和AI算力都做了明显升级官方标称的稀疏算力能到40 TOPS左右但真正值钱的不只是这个峰值数字而是它把“能跑Transformer类模型”这件事拉到了入门价位。以前这个档位的板子跑视觉Transformer基本是PPT上的故事现在至少能在TensorRT优化下做实时推理了这对做实体AI的人来说是实质性的变化。适合谁参考这篇内容呢我默认的读者是这三类人第一刚拿到Orin Nano 2开发套件想从刷机到部署完整跑通一遍的嵌入式开发者第二已经在用Jetson旧平台比如Xavier NX或Nano老款正在评估要不要迁移的团队第三做机器人、无人机、工业质检项目需要把视觉模型部署到设备端的算法工程师。无论你是哪一类这篇文章都会围绕实际踩坑和工程落地来写而不是念规格表。1.2 实体AI对硬件平台的差异化要求实体AI和纯云端AI有个本质区别你的模型推理结果要直接驱动物理设备这就对平台的端到端时延、稳定性、外设接口和功耗提出了完全不同的要求。我做一个简单的拆解。云端AI你只要把RTX 4090插在机房里网络延迟几十毫秒都能接受反正画面来回传。但实体AI不一样你的一台差速底盘小车如果靠无线图传把画面送到服务器做目标检测再把结果传回来控制电机这个闭环打下来少说200毫秒以上在稍微快一点的场景里小车已经撞上去了。所以实体AI一定要强调“端侧推理闭环”也就是感知、决策、执行全部在设备本地完成。而Orin Nano 2的价值就在于它能在很小的体积和功耗范围内把这个闭环里的“感知轻量决策”部分扛下来。再一个就是接口的丰富度。实体AI设备的传感器和执行器五花八门相机CSI/USB、激光雷达Ethernet/UART、电机驱动PWM/GPIO/CAN、IMUI2C/SPI。Orin Nano 2的IO配置在同级产品里算是齐全的CSI接口能直接接摄像头传感器支持40-pin GPIO扩展千兆网口也能接工业相机和雷达。这块板子做原型验证是非常顺手的基本不需要做一堆转接板。还有一点必须提就是软件生态的成熟度。Jetson平台跑的是Ubuntu系统这意味着你平常用的apt、Docker、Python环境管理工具在Jetson上基本都能复用。这个优势看起来不起眼但真做项目时能省掉大量时间。我自己就经历过在别的嵌入式平台上折腾交叉编译的痛苦而Jetson上改代码、跑调试、看日志的体验和开发机几乎一样这种“无感切换”的体验对团队上手非常重要。2. 开发环境搭建与基础配置2.1 刷机与系统初始化从零到可用的完整要点拿到开发套件之后第一步是刷机这一步看似简单但恰恰是很多人耗掉一整天的环节。Orin Nano 2开发套件使用SDK ManagerJetPack 6.x系列进行刷机。我建议直接使用SDK Manager而不是手动下载驱动包刷原因是它会自动把版本匹配关系处理好省掉很多麻烦。刷机时注意以下几个要点开发板进入恢复模式按住板子上的Recovery按钮再插入USB-C线连接到Ubuntu宿主机。这时在宿主机执行lsusb能看到一个NVIDIA Corp的设备说明识别到了。电源问题Orin Nano 2开发者套件的USB-C供电口有个坑一定要用原装电源适配器或者PD协议能正确握手的适配器否则系统在高负载时会出现莫名重启。存储与系统盘如果只有一张自带的SD卡我强烈建议至少配一块NVMe SSD因为跑Docker镜像和模型权重文件时SD卡的速度和寿命都是瓶颈。JetPack 6.x之后SDK Manager支持直接把系统装到NVMe上选“Other”存储介质时选择NVMe即可。JetPack版本的选择我个人建议直接上最新的JetPack 6.2及以上版本截至当前Orin系列都得到了完整支持。这代JetPack默认带了CUDA 12.x、TensorRT 8.x以及cuDNN 8.x新项目直接用新版本别回头选老版本后面跑新模型时框架兼容性会让你头疼。刷完系统进入桌面之后老规矩先做三件事换软件源在/etc/apt/sources.list里把Ubuntu源换成国内源然后把NVIDIA的apt源repo.download.nvidia.com能不用尽量不用太慢了。装包时如果卡在下载阶段直接换个时间段重试。装基础工具sudo apt update sudo apt install -y python3-pip cmake git vim net-tools htop。确认硬件状态运行sudo jetson_release能看到SoC型号、JetPack版本、CUDA版本等信息。再跑一下jtop用pip install jetson-stats安装进一步确认所有模块状态正常。2.2 CUDA与TensorRT环境配置的实操要点Orin Nano 2上的CUDA环境是JetPack自带的但它的路径跟我们熟悉的x86桌面版不一样很多新手会在这里翻车。JetPack安装完成后CUDA目录在/usr/local/cuda但如果你直接执行nvcc --version大概率会报“command not found”原因很简单——环境变量没配置。你需要把以下内容加到~/.bashrc里export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATHTensorRT的Python API比较特殊。如果你直接pip install tensorrt往往会装到x86架构的wheel包在ARM平台上会直接报错。正确做法是使用JetPack预装的TensorRT它的Python模块路径在/opt/nvidia/tensorrt/python下你需要把/opt/nvidia/tensorrt/python加入PYTHONPATH或者直接进入该目录执行pip install ./tensorrt-*-cp3x-linux_aarch64.whl。这里有个容易忽视的细节JetPack自带的Python包管理器可能因为系统pip版本过老导致安装失败。我的建议是创建一个独立的虚拟环境来做AI项目用python3 -m venv或者conda在Jetson上推荐用Miniforge而不是Anaconda因为Anaconda不再提供ARM版。在干净的环境里安装依赖能避免很多依赖冲突并且升级pip是必须的python3 -m venv ~/envs/jetson-ai source ~/envs/jetson-ai/bin/activate pip install --upgrade pip setuptools wheel pip install ultralytics roboflow onnx onnxruntime-gpu另外一个非常关键的动作是扩大交换空间swap。Orin Nano 2的内存是8GB更准确的说是LPDDR5内存与显存共享跑大一点的模型时内存很容易爆。默认的zram交换空间不够用建议先禁用zram再用交换文件扩到8GB的swap。具体操作sudo systemctl disable nvzramconfig sudo fallocate -l 8G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile echo /var/swapfile none swap defaults 0 0 | sudo tee -a /etc/fstab这个配置在做模型编译和推理时能救你命实测跑YOLOv8s训练迁移学习时不扩swap直接OOM扩完之后稳定跑完。3. 核心应用场景与推理管线设计3.1 视觉检测应用场景从目标检测到姿态估计Orin Nano 2最常见的落地场景就是视觉检测无论是工业场景里检测工件缺陷还是机器人领域的人形识别、抓取定位本质上都是在跑一套“图像输入到结构化输出”的推理流水线。我在一个移动抓取机器人项目里用Orin Nano 2跑了三个视觉任务全局目标检测YOLOv8s、机械臂手眼标定后的目标位姿估计基于AprilTag、以及抓取点计算一个轻量的分割模型。三路模型全部用TensorRT FP16精度部署后在Orin Nano 2上单帧总时延能控制在35ms以内也就是整个感知循环接近28FPS对于抓取场景足够用了。这里要说一下模型选型的门道。很多新手一上来就在YOLOv8和YOLOv5之间纠结实际跑下来我更推荐YOLOv8s甚至YOLOv8n。Orin Nano 2的算力跑YOLOv8s的FP16 TensorRT引擎实测推理时延大概在15ms左右如果换YOLOv8n时延能降到8ms以下。对于入门级项目我建议优先保证分辨率和帧率的平衡不要盲目追求大模型模型大小对精度的影响远没有你调好预处理、用好TensorRT来的大。姿态估计方面MoveNet或者轻量版的MediaPipe Pose在Orin Nano 2上跑起来也很轻松不过如果你的项目需要做三维姿态估计可能要考虑两个模型串联或者直接用基于Transformer的方案这时Orin Nano 2的内存带宽优势就体现出来了跑起来比老Nano平台顺畅太多。3.2 从PyTorch模型到TensorRT部署的完整链路这一个段落是全文的核心我尽量把每一步的关键操作和易错点都说透。在Jetson上部署深度学习模型正确流程一般是PyTorch训练或微调 - 导出ONNX - 构建TensorRT引擎 - 运行时推理。第一步导出ONNX。在PyTorch侧导出时一定要指定opset_version17或更高TensorRT 8.6之后对ONNX opset支持更好并且把动态维度固定下来或者显式声明动态轴。如果模型里只有固定尺寸输入建议直接固定尺寸TensorRT优化会更激进。import torch from ultralytics import YOLO model YOLO(yolov8s.pt) model.model.eval() dummy_input torch.randn(1, 3, 640, 640).cuda() torch.onnx.export( model.model, dummy_input, yolov8s.onnx, opset_version17, input_names[images], output_names[output0], dynamic_axes{images: {0: batch}, output0: {0: batch}} ) print(ONNX exported)但这里有个超级常见的坑torch.onnx.export的模型来源必须是model.model而不是model对象因为Ultralytics的YOLO类外面包了一层训练逻辑。如果导出的是整个model对象ONNX图里会多出来很多没用的节点TensorRT解析时大概率失败。第二步用trtexec做ONNX到TensorRT的转换这是最直接也最可靠的方式。有些同学喜欢在Python中用TensorRT的Python API来构建engine我建议新手先不用trtexec的参数更透明调试信息也更清晰。我的常用参数如下/usr/src/tensorrt/bin/trtexec \ --onnxyolov8s.onnx \ --saveEngineyolov8s_fp16.engine \ --fp16 \ --minShapesimages:1x3x640x640 \ --optShapesimages:1x3x640x640 \ --maxShapesimages:4x3x640x640这里重点说一下这几个shape参数。动态batch在部署时很有用但如果你的应用场景不会同时处理多个batch我建议直接把batch固定为1也就是只保留--optShapes不要声明min和max这样TensorRT会额外做一批batch维度上的优化引擎体积更小加载也更快。第三步推理时的实现。我强烈推荐用TensorRT的Python API配合PyCuda来做显存管理而不是直接用torch加载ONNX。原因是PyTorch在Jetson上的推理路径没有经过TensorRT优化速度差距能有2-3倍。一个精简的推理代码如下import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit import numpy as np class TRTInference: def __init__(self, engine_path): logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f, trt.Runtime(logger) as runtime: self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.allocate_buffers() def allocate_buffers(self): self.inputs [] self.outputs [] self.bindings [] for binding in self.engine: shape self.engine.get_binding_shape(binding) size trt.volume(shape) * self.engine.max_batch_size dtype trt.nptype(self.engine.get_binding_dtype(binding)) allocate memory and copy... self.stream cuda.Stream() def infer(self, input_image): # 在GPU上拷贝输入、执行推理、取回输出 ...在Orin Nano 2上做推理时有一个重要的性能调优点尽量把前处理resize、归一化、BGR2RGB也放到GPU上做。用OpenCV在CPU上做前处理推理时会有明显停顿用CUDA核函数或者cuDNN的预处理操作能把整体端到端时延压下去好几个毫秒。第四步后处理也是很多人忽略的优化点。YOLO输出层的解码、NMS这些操作如果在CPU上用Python for循环逐框处理会严重影响帧率。我的建议是用torchvision.ops.nms或NumPy向量化操作把NMS提速更极致的做法是用TensorRT的EfficientNMS ONNX插件把NMS也塞进TensorRT图里这样GPU上一次性输出最终检测结果CPU侧只需解析少量框帧率能进一步提升20%左右。4. 性能调优与工程化落地经验4.1 显存与推理时延的平衡策略Jetson平台的内存是CPU和GPU共享的这个架构有优点也有代价。8GB内存看起来不少但系统开机占用1GB左右CUDA上下文几百MBDocker基础镜像再占一部分留给模型的实际空间并没有想象中那么宽裕。跑推理时我遇到过好几次一个模型编译好后加载时直接报CUDA out of memory。解决思路分几个方向第一优先使用FP16精度。Orin Nano 2的Tensor核心对FP16有专门优化比起FP32推理速度几乎翻倍显存占用也能减半。除非你的模型在FP16下精度掉得非常厉害比如某些语义分割任务否则无脑选FP16。INT8量化能进一步提速但需要标定数据而且调起来麻烦建议项目稳定之后再考虑。第二控制模型输入分辨率。以YOLOv8为例输入从640降到512推理时延能降低约35%精度损失在很多场景下可以忽略。如果你只是在固定距离下做检测比如机械臂工作台、考勤机前方甚至可以降到416。做项目时先用640跑通再逐步调低找到你能接受的精度下限即可。第三小心Docker的内存限制。如果你在Jetson上用Docker跑推理服务一定记得加--shm-size8g参数否则多个进程共享内存交互时会因为/dev/shm太小而报错。同时用--ipchost能省掉很多麻烦。4.2 功耗管控与散热设计实测Orin Nano 2的功耗模式需要认真对待。默认情况下它可能跑在最高性能模式但如果你给设备做的是移动机器人项目电池供电时就得考虑功耗和性能的平衡。NVIDIA在Jetson上提供了几种预设功耗模式通过nvpmodel命令切换sudo nvpmodel -m 0 # 最高性能功耗约25W sudo nvpmodel -m 1 # 平衡模式约15W sudo nvpmodel -m 2 # 低功耗约10W我的实测数据是这样的跑YOLOv8s推理任务25W模式下GPU频率维持在1.3GHz左右推理时延约15ms15W模式下GPU频率降到900MHz左右推理时延约22ms10W模式下时延会进一步到30ms以上。如果你的项目对时延要求没那么苛刻用15W模式能显著降低电池压力。散热方面是Orin Nano 2比较值得关注的问题。官方开发套件的被动散热片在25W持续负载下核心温度能达到85℃以上长时间满负载运行有降频风险。我自己加装了一个5V的小风扇从GPIO取电或用USB供电温度能稳定在65℃-70℃性能释放更稳定。这里提个建议如果你是做工业级产品设计一定要算清楚密封外壳下的散热方案否则高温降频会让你在室外场景下吃大亏。还有一个容易踩的坑是某些劣质USB-C电源线电压压降大导致高负载时供电不足主板直接重启。做室外移动项目时最好通过DC电源模块给开发板供电不要在同一个电源上混接电机驱动和开发板这会导致电压骤降。5. 常见问题与排查技巧实录5.1 驱动与运行环境的典型故障这里盘点一下Orin Nano 2上最常出现的几类问题以及排查思路。如果你用的是JetPack自带的系统镜像驱动层面问题相对较少但偶尔也会遇到一、nvidia-smi不可用。有些教程会让你在Jetson上装nvidia-smi发现装不上。原因很简单——Jetson的GPU驱动不是桌面版NVIDIA驱动nvidia-smi在Jetson上默认不安装。你可以用tegrastats查看GPU和CPU频率、温度、负载等信息用jtop查看更直观的实时指标。如果一定要用nvidia-smi可以安装nvidia-jetpack中的cuda-toolkit并手动加上软链接但实际没必要tegrastats是完全够用的。二、python3 -c import torch报导入错误。JetPack自带的PyTorch是通过NVIDIA的专有wheel安装的不要想着在官网PyTorch下载页面找arm64 wheel那是不存在的。正确做法是在NVIDIA的官方索引源安装pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128 # 或者在JetPack上用NVIDIA给出的本地wheel三、运行Docker容器时GPU不可用。Docker在Jetson上要使用GPU必须安装nvidia-container-toolkit并且容器的runtime要用nvidia。一个标准的启动命令docker run --runtime nvidia --network host --ipchost \ -v /path/to/workspace:/workspace \ -it nvcr.io/nvidia/l4t-pytorch:r36.2.0如果你在容器里跑深度学习模型发现速度很慢大概率是没有指定--runtime nvidia导致CUDA没有直通到GPU。5.2 部署场景中的几个教训项目做多了积累了一些很实在的教训分享出来希望能帮大家少踩坑。第一不要迷信Jetson上一个环境里装所有项目的东西。我见过有人把PyTorch、TensorRT、多个版本的OpenCV全部装在系统Python环境里最后因为OpenCV版本冲突导致DeepStream起不来。正确的做法是每个独立项目建一个虚拟环境系统环境里只装最基础的运行依赖。第二模型编译好后一定要测试批量场景。TensorRT引擎有个特性你在--optShapes里指定了4的batch那么推理时连续塞4张图是最优的但如果你只塞1张实际速度并不会快4倍反而可能比固定batch1的引擎还慢。因为动态shape引擎在每次推理时要重新计算一些优化参数。所以如果你的业务形态是并发多路视频流建议按实际业务并发数来构建引擎不要贪多。第三文件系统性能会直接影响推理服务的稳定性。我之前把模型权重文件和推理日志放在SD卡上跑的时间一长SD卡写满或者IO阻塞推理服务的时延就会抖动。后来全部迁移到NVMe SSD上这个问题就消失了。做产品化部署时系统盘和数据盘最好分开数据盘的写入压力大要选可靠的工业级存储。第四别忽视/dev/shm大小的问题。在运行多进程推理比如GStreamer采集 模型推理 控制输出时进程间通过共享内存传输图像帧如果/dev/shm空间不足图像传输会失败或者卡死。临时解决方法是挂载时加大在/etc/fstab里为/dev/shm单独分配空间或者系统启动后执行sudo mount -o remount,size4G /dev/shm。第五电源稳定性的问题要前置考虑。我在实验室里的Orin Nano 2开发套件最初用的是买板子附带的电源适配器一切正常后来为了桌面整洁换了一根USB-C延长线结果在高负载推理时频繁重启。用万用表测了才发现延长线有压降启动瞬间电压跌到了4.8V。这个教训是Jetson供电线一定要短、要粗别省这个钱。6. 从开发板到产品化落地一个真实的项目复盘6.1 场景还原室内巡检机器人的感知系统为了把这篇文章讲得更具体我拿一个去年做的室内巡检机器人项目来复盘。这个项目的要求是机器人在办公楼走廊自动巡检需要识别门牌号、检测地面障碍物比如箱子、垃圾桶、识别房间内是否亮灯。之前团队的做法是Robot Operating System电控由STM32负责上位机是Intel NUC跑YOLOv5整体功耗高而且NUC的体积塞不进机器人底盘里。换到Orin Nano 2之后整个上位机模块缩小到一张卡片大小功耗也降下来了。硬件方案上我用了一个USB广角摄像头做全局障碍物检测640x480输入YOLOv8n再用一个USB长焦摄像头做门牌OCR512x512输入PaddleOCR部署成TensorRT。两个模型同时跑在Orin Nano 2上总时延控制在20ms以内CPU占用率不到40%。从Intel NUC方案迁移过来之后感知模块的整体功耗从40W降到了12W续航翻了一倍还多。6.2 部署中的性能与稳定性取舍这个项目里最有价值的经验是学到了如何做多模型并行时的资源分配。两个模型如果都用TensorRT默认配置它们会争抢GPU资源导致推理时延抖动。我最后的解法是给每个模型指定不同的CUDA stream并且用cudaEventSynchronize来控制时序。同时把YOLOv8n的输入分辨率降到480把PaddleOCR的分辨率保持512这样两个模型在时间上错峰运行帧率更稳定。多模型并行时显存也更紧张。我的经验是8GB内存场景下同时加载两个中等模型是可行的但如果要跑三个模型就一定要考虑用INT8量化或者直接把不同模型按需加载——比如平时只跑障碍物检测检测到特定物体时才加载OCR模型。毕竟模型加载本身也是耗时操作按需加载虽然增加了延迟但换来了显存的充裕整体稳定性反而更好。6.3 远程运维与日志记录的最佳实践在设备长期运行过程中远程运维能力非常关键。Jetson设备部署在不太容易接近的地方如果没有可靠的远程调试手段出了问题会非常被动。我推荐在Jetson上使用frp或zerotier做远程网络访问但考虑到额外的网络要求在实际项目中更稳妥的方式是设备端把关键运行状态温度、显存占用、推理时延、模型置信度定时写入本地SQLite数据库并通过MQTT推送到运维平台。这样即使设备断网本地数据也不会丢失恢复网络后会自动续传。日志方面Python标准库的logging配合RotatingFileHandler按文件大小轮转避免单个日志文件无限膨胀导致磁盘写满。这里特别提醒系统在长时间运行后Zram或Swap交换文件可能会因为异常进程而占满。建议写一个简单的看门狗脚本每分钟检查一次free -m如果可用内存小于500MB就自动重启失控的Python进程。这个方法听起来粗糙但是在无人值守的长期部署里能有效避免很多“设备跑挂了但没人知道”的尴尬情况。7. 扩展方向从Orin Nano 2到产品化的两条路径7.1 轻量化量产方案与NVMe存储优化如果项目验证成功要往量产走一般有两条路径。第一条是把整个系统从Orin Nano 2开发套件迁移到生产级模块上。Jetson系列里有对应加固的模组外形尺寸和接口做过工业级优化更适合嵌入式设备集成。开发套件上的代码基本不需要改动这就避免了从开发环境到量产环境的重新适配。量产方案中存储介质的选择要非常谨慎。开发时用SD卡方便量产出货如果也用SD卡你会收到大量售后投诉。SD卡在设备持续写入日志、模型缓存时寿命很短。我在几个项目里换用了eMMC或者工业级NVMe SSD之后存储相关的故障基本清零。系统镜像也可以用nvbuild或者balena-etcher做批量烧录几分钟就能准备好一台设备的系统盘提升量产效率。7.2 多模态模型与边缘部署的下一步Orin Nano 2这个平台还有一个优势是它对多模态模型的支持潜力比很多人预期的要好。随着最近这段时间视觉语言模型小型化的发展像3B到4B参数规模的多模态模型经过AWQ或GPTQ量化之后是有可能在Orin Nano 2上做实时推理的。这就为实体AI带来一个新方向机器人不仅能“看见”目标还能“理解”场景语义。比如我最近在测试的一个室内导航项目以前是用YOLO检测“门”“走廊”“楼梯”代码里写死规则做路径决策。换了轻量多模态模型之后机器人可以直接输入一张前方图像输出“前方是会议室门开着可以通过”这样的结构化语义描述决策泛化能力提升了一截。当然这种模型在端侧跑帧率目前还比较低做不到实时决策更多是“每隔几秒做一次全局理解”局部避障仍然靠轻量目标检测。但这条技术路线的趋势已经很明显了。在Orin Nano 2上跑这类模型的调优经验是优先用量化模型并且开启Flash Attention需要CUDA能力支持同时把上下文长度尽量限制在很小范围比如128个token推理速度会有量级提升。这个方向我相信后续会有更多人陆续跟进现在提前把平台和流水线能力准备好后面出成果的速度会快很多。8. 写在最后的经验与建议做了这么多Jetson项目我最深的体会是Orin Nano 2这个平台真正的价值不是“开发板有多强”而是它把一套能平滑迁移到产品线的技术栈给了入门开发者。你在这个板子上写的推理代码、调的TensorRT引擎、积累的调优参数后续迁移到生产级模组时几乎不用改这种软硬件协同的衔接能力是其他嵌入式方案很难比拟的。最后再分享一个个人经验别总盯着每一帧的推理时延先跑通整个系统的闭环更重要。很多初学者拿到板子后第一件事就是跑demo测FPS这没有错但真正做项目时感知环节的时延只是整个系统时延的一部分从图像采集、前处理、推理、后处理、控制指令下发到执行器响应每个环节的时延都要优化。先把闭环跑起来再分析瓶颈在哪里这样的节奏会舒服很多。如果你正在考虑用Orin Nano 2做你的第一个边缘AI项目我的建议很简单先照这篇文章把环境搭好再找一个你熟悉的模型完整跑一遍部署链路。等这条链路跑通你对这个平台的把握就有了后面无论是做机器人还是工业视觉心里都有底。