过去一个月我一直在折腾一套移动机械臂的视觉抓取方案设备从树莓派换到x86工控机最后落在了NVIDIA Jetson Orin Nano上。朋友问我为什么选这个我说得很直接入门级边缘AI设备里它把算力、功耗、价格和生态这几个关键维度平衡得最好。尤其是Orin Nano Super发布之后16GB内存、最高67 TOPS算力、25瓦以内的功耗直接把实体AIPhysical AI项目的落地门槛拉下来一大截。这篇文章我不会去复述官方规格书而是从实际项目出发聊聊为什么这个平台适合入门级边缘AI和实体AI规模化落地怎么把环境搭起来、把模型跑起来以及我在过程中踩过的坑。无论你是准备入坑机器人、打算给产线加装视觉检测还是单纯想在移动设备上跑大模型推理这篇文章都能给你一个相对完整的参考。1. 为什么Orin Nano 2是入门级边缘AI的“甜点位”1.1 从参数看定位算力、功耗、价格三者如何平衡先说硬指标。Jetson Orin Nano系列最新的Super模式把AI算力推到了67 TOPSINT8稀疏内存也从8GB提升到16GB LPDDR5带宽从68GB/s涨到102GB/s。这是一个很微妙的分界线在它之前入门级设备要么是树莓派这种算力只有个位数TOPS的板子要么是动辄几万块的工业级GPU设备。Orin Nano刚好卡在中间让你能以两三千块的成本拿到一块能跑现代深度学习模型的完整计算平台。功耗方面Super模式下满载大约25瓦默认模式下7到15瓦。这意味着它不需要额外的主动散热方案就能稳定运行工业场景里塞进密封机箱也没问题。我用一个12V 5A的电源供一台带摄像头、激光雷达和机械臂控制板的整机实测下来还有超过20%的余量。这种能效比是x86方案很难做到的也是它在实体AI场景里受欢迎的根本原因。接口方面它提供PCIe、USB 3.2、MIPI CSI相机接口、千兆网口和40Pin GPIO基本覆盖了机器人、视觉检测和边缘网关的常见需求。尤其是MIPI CSI接口可以直接接全局曝光工业相机延迟比USB摄像头低一个量级。加上支持NVMe SSD启动系统的IO瓶颈也能得到缓解这对跑大模型和数据库类应用都有实际帮助。1.2 实体AI为什么需要这种“小盒子”实体AI或者叫Physical AI简单说就是让AI系统能在物理世界中感知、决策、行动。机械臂抓取、AGV导航、无人机巡检、产线缺陷检测这些都属于实体AI的范畴。这类场景有一个共同特点计算必须发生在设备本地不能依赖云端。原因有三个第一是延迟机械臂的抓取动作从相机取帧到发出控制指令端到端延迟必须控制在几十毫秒以内走云端来回一趟就超时了第二是带宽多路工业相机每秒产生几百兆数据全传到云端不现实第三是隐私和可靠性很多产线数据不能出车间网络断连的时候设备也必须能独立工作。但本地方案也有历史难题。工控机加独立显卡的方案性能足够但体积大、功耗高、价格贵一个机械臂项目光计算单元就要一两万。树莓派之类的方案便宜省电但跑不动现代模型一张640x640分辨率的YOLOv8推理都要几百毫秒根本做不到实时。Orin Nano的出现恰好补上了这个缺口性能能达到实时推理的要求功耗能承受价格也到了个人开发者和中小团队能接受的范围。我做了个简单的对比目前主流方案的实际情况大致是这样的方案算力INT8功耗参考价格适合场景树莓派50.5 TOPS左右5-10W500元左右原型验证、轻量控制Jetson Orin Nano Super67 TOPS7-25W2500元左右入门级边缘AI、机器人、视觉检测Jetson Orin NX100-157 TOPS10-25W6000-8000元多路视觉、SLAM、更复杂的AI负载x86工控机RTX显卡几十到上百TOPS150W1.5万元以上传统视觉、GPU通用计算从这个表能看出来Orin Nano 2的定位非常精准。它不是性能最强的也不是最便宜的但它在“能实时跑AI模型”和“个人/小团队买得起”这两个条件之间找到了平衡点这也是为什么它在入门级边缘AI和实体AI项目里被反复提及。2. 环境搭建刷机、驱动与系统调优2.1 刷机与启动SDK Manager和SD卡镜像两条路拿到板子第一件事是把系统刷进去。Jetson平台有两种主流刷机方式我两种都试过说下各自的特点。第一种是NVIDIA官方推荐的SDK Manager适合有Ubuntu主机x86环境的情况。它会自动下载JetPack SDK把系统镜像、CUDA、cuDNN、TensorRT、DeepStream这些组件一次装好。整个流程是板子进入Force Recovery模式按住Recovery键再通电用USB线连接主机SDK Manager识别到设备后选择要安装的组件和版本然后自动写系统、自动安装SDK。这种方式最省心不容易出错第一次玩Jetson的人建议直接用这个。第二种是直接烧录SD卡镜像适合Windows用户或者不想装SDK Manager的情况。到NVIDIA官方下载JetPack对应的SD卡镜像文件用balenaEtcher或Rufus把镜像写到至少64GB的高质量SD卡里插入板子启动即可。启动后系统自带CUDA和TensorRT但不包含DeepStream等额外组件需要手动用SDK Manager补装或者用apt命令安装。这个方式的优点是快缺点是缺少SDK Manager的组件管理功能后续增删组件比较麻烦。刷完系统开机之后第一件事是确认版本对应关系。在终端执行cat /etc/nv_tegra_release nvcc --version/etc/nv_tegra_release显示的是L4TLinux for Tegra版本nvcc --version显示CUDA版本。这两个版本必须和JetPack版本匹配比如JetPack 6.x对应CUDA 12.x和L4T 36.x。如果后面安装第三方库时出现编译错误八成就是版本对应关系出了问题。建议把这三者的对应关系记到项目README里省得过几个月回来维护时抓瞎。首次启动还有一个必做的操作把系统迁移到NVMe SSD。SD卡的随机读写性能太差跑大型模型加载权重或者读写日志时会明显卡顿。做法是用dd命令把SD卡系统克隆到NVMe硬盘或者直接用SDK Manager选择“Storage Device”为NVMe重新刷写。我用的是后者刷完后系统启动时间从40多秒缩短到了15秒左右模型加载时间也提升了近一倍。如果你要在板子上做正经项目这一步真不建议省。2.2 驱动验证Jetson上到底怎么确认GPU能用很多从PC转型过来的朋友习惯性地先查“nvidia-smi”结果在Jetson上发现直接报错就开始怀疑驱动没装好。其实Jetson的GPU驱动跟PC是完全不同的体系。Jetson底层使用的是集成在L4T内核里的NVIDIA GPU驱动不需要像台式机那样单独安装.deb驱动包也没有独立的nvidia-smi输出格式至少默认情况下是不同的。在Jetson上确认GPU工作状态用的是Jetson特有的工具。最常用的是sudo jetson_clocks sudo tegrastatstegrastats命令会实时输出CPU/GPU频率、内存使用、温度、功耗这些信息相当于Jetson版的“任务管理器”。如果你在终端看到类似GPU 1300MHz、CPU 42457MHz这样的输出就说明GPU驱动和频率调度都正常工作。jetson_clocks的作用是把CPU和GPU频率锁定在最高值避免系统在轻载时自动降频导致推理速度不稳定。在需要跑基准测试或者保证推理延迟稳定时这个命令非常有用。还有一个容易踩坑的点是CUDA Sample的验证。很多人想跑一下deviceQuery确认GPU可用但编译会报错。原因是新版JetPack里CUDA Sample不再预装源码需要手动从GitHub拉取git clone https://github.com/NVIDIA/cuda-samples.git cd cuda-samples/Samples/1_Utilities/deviceQuery make ./deviceQuery如果deviceQuery能正常显示你的GPU型号Orin Nano的GPU一般是Ampere架构说明CUDA环境没问题。看到类似CUDA Device Query ... PASSED的输出就可以放心继续往下走了。2.3 三大必备调优性能模式、SWAP和存储清理系统跑起来之后有三个调优动作我建议每个Orin Nano用户都做一遍都是影响实际使用体验的关键项。第一设置性能模式。默认情况下系统跑在15瓦的功耗档Super模式需要手动开启。执行sudo nvpmodel -m 0-m 0对应Super模式25瓦-m 1是15瓦模式-m 2是7瓦模式。改完用nvpmodel -q确认当前模式。注意Super模式对散热有要求如果你的板子是裸奔状态最好加一个主动散热风扇再开否则芯片在重载时过热降频实际性能反而比15瓦模式更差。我在实测中发现25瓦模式下如果散热不良跑推理任务时温度会迅速冲到80度以上然后频率从最高值掉下来整个推理速度反而波动很大。加了5V风扇之后温度稳定在60度左右推理帧率就非常稳定了。第二扩展SWAP。项目后面跑多路摄像头或者大模型时16GB内存很可能被吃满。这时候SWAP如果太小会导致OOM内存耗尽被杀进程。Jetson默认提供了zram但压缩后的交换空间只有大约3GB不够用。推荐的做法是在NVMe SSD上做一个8到16GB的swapfilesudo fallocate -l 12G /mnt/ssd/swapfile sudo chmod 600 /mnt/ssd/swapfile sudo mkswap /mnt/ssd/swapfile sudo swapon /mnt/ssd/swapfile为了重启后自动挂载还要在/etc/fstab里加一行。这个操作能显著减少OOM概率代价是SSD使用寿命和略微的性能下降但在实战中非常划算。我用的是三星980 500GB开机加载模型时系统内存占用经常到17GB左右没有大SWAP根本跑不起来。第三清理JetPack预装组件。JetPack默认安装了非常多的库和示例代码很多是日常用不到的。比如/opt/nvidia/vpi下的样例、/usr/src/tensorrt下的示例代码等。清理前先看清楚哪些是你需要的我从不建议新手一上来就删组件但等系统稳定后可以把apt list --installed里的非必要包筛一遍尤其是那些占用几个GB的示例和文档。空间有限的小容量SSD用户做这个清理能多出不少余量。3. 模型部署工作流从x86训练到Jetson推理3.1 模型导出与量化ONNX到TensorRT的关键跳板在Jetson上部署深度学习模型最绕不开的环节就是TensorRT。简单理解TensorRT是NVIDIA的推理优化引擎它能把训练框架产出的模型做层融合、精度校准、内核自动调优最终生成一个高度优化的推理引擎。同样的YOLOv8模型在PyTorch里跑一次推理可能需要60毫秒用TensorRT优化后能压到20毫秒以内提速效果非常明显。但TensorRT不能直接吃PyTorch的权重文件需要通过ONNX作为中间格式。整个链路是PyTorch模型 → 导出ONNX → ONNX优化 → TensorRT引擎构建 → 推理以YOLOv8为例导出ONNX的操作在训练主机上完成yolo export modelyolov8n.pt formatonnx opset13 simplifyTrue dynamicFalse有几个导出参数要注意。opset版本会影响算子兼容性Jetson上JetPack 6自带的TensorRT 10对ONNX opset 13到17都能支持建议用13以上。dynamicFalse表示固定输入尺寸尺寸固定对TensorRT构建引擎更友好性能也更高。我建议在部署阶段把所有输入分辨率固定下来比如统一用640x640不要图省事保留动态尺寸。拿到ONNX文件之后有两种方式转TensorRT。第一种是直接用trtexec命令行工具/usr/src/tensorrt/bin/trtexec --onnxyolov8n.onnx --saveEngineyolov8n.engine --fp16--fp16启用半精度推理这是性价比最高的一步。在Ampere架构上FP16的算力是FP32的两倍而精度损失对视觉检测任务来说基本可以忽略。如果用INT8量化还能再进一步提速但需要准备校准数据集流程相对复杂新手可以先跳过。第二种方式是用Python API在代码里动态构建引擎import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(yolov8n.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) engine builder.build_engine(network, config) with open(yolov8n.engine, wb) as f: f.write(engine.serialize())第一次构建引擎时耗时可能比较长几秒到几分钟不等之后再加载序列化的.engine文件就很快了。我在板子上构建YOLOv8n的FP16引擎大约花了20秒加载只需要不到1秒。3.2 推理框架选择直接用TensorRT还是套一层推理库很多初学者在部署时会纠结一个问题到底是用原生TensorRT API写推理代码还是用DeepStream、ONNX Runtime、TorchScript这些上层方案。我的建议分场景。如果你做的是以摄像头视频流为主的应用比如缺陷检测、安防监控、客流统计直接用DeepStream最合适。DeepStream是NVIDIA官方的视频流分析框架它把视频解码、批处理、推理、目标跟踪、物体分类这些环节都封装好了在Jetson上用硬件解码单元做视频解码CPU占用率极低。我在一个检测项目中用DeepStream跑四路1080p视频流CPU占用只有30%左右这在原生TensorRT方案里很难做到。如果你的应用不是视频流而是单帧图片、雷达点云或者其他传感器数据用原生TensorRT或者ONNX Runtime就够了。ONNX Runtime相对简单代码量少适合快速验证。我把YOLOv8转成ONNX后在Jetson上用ONNX Runtime加CUDA Execution Provider推理速度大约42毫秒每帧这个速度适合非实时任务。但同样的模型转到TensorRT FP16后只需要11毫秒差距确实很大。所以只要是追求实时性能的场景我都推荐直接用TensorRT。PyTorch的TorchScript方案我不太推荐。虽然Jetson上能装PyTorch但Python解释器的开销在边缘设备上会被放大推理速度和TensorRT不是一个量级。我的经验是PyTorch用来做“CPU上的后处理和业务逻辑”可以真正吃性能的推理环节一定要落到TensorRT引擎上。3.3 NIM与容器化部署把边缘AI服务化近几年NVIDIA在推NIMNVIDIA Inference Microservice在Jetson平台上也逐步支持。用一句话概括NIM就是把常见模型的推理服务打包成标准容器通过HTTP/GRPC接口对外提供服务。这样做的最大好处是你的应用代码和推理引擎解耦了。模型迭代时只替换NIM容器镜像不需要重新编译整个应用。我搭过一个基于NIM的视觉检测服务大致是这样的流程。先在Jetson上安装NVIDIA Container Toolkitsudo apt-get install nvidia-container-toolkit sudo systemctl restart docker然后拉取对应的NIM容器镜像启动容器时指定使用GPU和映射端口应用侧直接通过HTTP请求发送图片拿到检测结果。这种方式特别适合多人协作的项目算法同学负责训练和优化模型嵌入式同学负责业务逻辑和传感器接入两者通过接口对接互不阻塞。容器化还能解决环境依赖问题。Jetson上Python环境极其容易搞乱我见过不止一个人在Jetson上重装系统原因就是把conda环境搞崩了导致系统Python也被影响。用Docker隔离后宿主机环境可以保持干净出问题直接销毁容器重建就行。不过要注意映射GPU时用--gpus all参数Jetson上Docker的GPU支持依赖nvidia-container-toolkit如果容器内看不到GPU先查这个包是否正常安装。4. 实体AI落地案例与规模化实践4.1 一个机械臂视觉抓取项目的典型架构我最近帮朋友做的是一个桌面机械臂的视觉抓取项目硬件包括一台Orin Nano Super、一个USB工业相机、一台六自由度机械臂通过串口控制。任务是把传送带上的零件识别出来通过机械臂抓取到指定位置。这个项目非常有代表性算是实体AI入门级落地的经典组合。整体软件架构分成四层。第一层是感知层相机每100毫秒采集一帧图像送到TensorRT引擎做目标检测和位姿估计第二层是决策层根据检测结果计算目标的三维坐标通过标定把像素坐标转换成机械臂基座坐标系下的空间坐标第三层是控制层把目标坐标转换成机械臂的关节角度通过串口下发指令第四层是反馈层机械臂夹爪上的传感器检测是否抓取成功失败则触发重试逻辑。在Orin Nano上跑这个流程感知层的检测延迟大约15毫秒决策层计算大约5毫秒控制层机械臂动作一般需要200到500毫秒所以整体瓶颈在机械臂本体而不在计算平台。这也说明了为什么Orin Nano这种级别的算力对入门级实体AI项目已经足够。如果换成检测模型更大的YOLOv8s推理时间会到40毫秒左右依然在可接受范围内。这个项目里最有价值的经验是坐标系标定。很多新手在机械臂抓取项目里翻车不是模型精度不够而是像素坐标到空间坐标的变换没做好。我的做法是先用棋盘格标定相机内参再做手眼标定相机安装在机械臂外是“眼在外”模式把变换矩阵保存下来在决策层直接用矩阵运算完成坐标变换。整个过程用OpenCV的calibrateCamera和solvePnP就能实现不需要额外的标定设备。4.2 多机部署与远程管理规模化落地的关键一步当你的边缘AI项目从一个设备扩展到几十台甚至上百台时单机SSH管理的方式就不现实了。每台设备手动更新模型、手动改配置不仅效率低而且极容易出错。我第二次部署项目时就吃了这个亏用了整整两天在十几台板子上重复刷模型结果发现有两台的模型版本漏更新了产线上跑的还是旧版本。后来我采用了容器加轻量编排的方案。每台Jetson上安装Docker用K3s作为集群管理工具模型和业务应用都打包成镜像通过中央仓库统一分发版本。更新模型时只需要重新构建镜像并推送给K3s它会自动滚动更新所有节点。这个方案在几十台设备的规模下非常稳定我用它管理过一个18台Orin Nano的集群跑了一个多季度没出过版本混乱的问题。还有一个容易忽略的点是设备监控。我遇到过一台设备因为风扇停转导致芯片过热推理性能跌了一半但系统并没有崩溃线上业务还在跑只是追帧越来越严重。后来我在每台设备上加了一个轻量监控脚本定期采集tegrastats的关键指标包括温度、CPU/GPU占用率、内存余量上报到中央服务端设置温度超过75度就触发告警短信。这样的小工具成本很低但对规模化维护帮助巨大。4.3 数据回流与持续迭代让边缘AI越用越准实体AI项目上线只是开始模型在真实环境里的表现大概率低于实验环境持续迭代是必然的。这里的关键是数据回流。我在机械臂项目里做了一个简单但实用的闭环推理阶段把低置信度的检测结果和对应的原始图像自动保存到本地缓冲区每天通过定时任务压缩上传到训练服务器算法同学定期用这些难例数据训练新模型验证精度提升后发布新版本再通过K3s推送到设备端。整个周期从原来的一周缩短到一天模型的性能提升非常明显。在Jetson上做数据回流的硬件要求不高重点是存储策略。我建议在NVMe SSD上单独划一个目录存放原始数据每天压缩上传后清理避免SD卡或小容量SSD被塞满。另外上传数据必须脱敏去掉个人信息和敏感区域避免数据合规风险。Orin Nano的带宽虽然不大但上传典型的难例数据每天几百MB完全没有问题。5. 常见问题速查与避坑技巧实录5.1 驱动与容器运行时最容易被卡住的两个环节Jetson开发中遇到的坑很大一部分集中在驱动和容器运行时。先说一个非常典型的问题在x86 Ubuntu主机上卸载重装NVIDIA驱动后重启时偶尔会看到类似“an nvidia kernel module nvidia-uvm appears to be already loaded in your kernel”的提示。这个问题的本质是模块没有完全卸载干净。解决方法是进安全模式或字符界面先执行sudo rmmod nvidia-uvm nvidia-drm nvidia-modeset nvidia把旧的模块全部卸载再重新安装驱动。如果rmmod提示模块正被占用用lsof查一下是哪个进程在使用GPU关掉进程再卸载。另一个高频问题是nvidia-smi报错has failed because it couldnt communicate with the nvidia driver。这个错误在PC和Jetson上含义略有不同。在PC上基本可以确定是驱动和内核版本不匹配常见原因是系统内核升级后驱动没有跟着重新编译。解决办法是安装对应内核版本的headers然后重新执行sudo dkms install -m nvidia -v 版本号或者干脆用--no-opengl-files重新装一遍驱动。在Jetson上如果遇到这个报错一般不是驱动缺失而是当前环境里根本没有加载GPU模块执行sudo modprobe nvidia-uvm再验证即可。容器相关的坑也很多。最常见的是Docker容器里跑程序报找不到GPU但宿主机GPU明明正常。这通常是因为容器没有注入GPU设备启动容器时没有加--gpus all参数或者宿主机缺少nvidia-container-toolkit。有时候nvidia-container-toolkit装了但Docker运行时没有重启也需要执行sudo systemctl restart docker才能生效。还有个别情况是JetPack版本和容器镜像的CUDA版本不匹配比如JetPack 6自带的CUDA 12.x容器跑了CUDA 11.x的镜像大概率会报libcudart.so找不到重新选择匹配版本即可。5.2 性能与散热为什么你的Orin Nano跑不满很多用户看网上评测说Orin Nano Super能跑到67 TOPS自己实测跑模型却只有一半性能第一个反应是“买到假货”。其实大概率是散热和功耗设置的问题。先说散热。Super模式25瓦持续满载时芯片功耗密度很高如果只靠被动散热片温度会迅速攀升到85度以上然后触发频率下调。我在机械臂项目里一开始用自带的小散热片跑模型十几分钟后GPU频率从1.3GHz掉到800MHz左右推理延迟直接翻倍。换成5V主动风扇加加厚散热片之后温度稳定在60度附近帧率曲线变得非常平滑。如果你的设备要长时间满载运行散热设计绝对是第一优先级。其次是频率策略。jetson_clocks会把CPU和GPU频率锁到最高但有些版本的JetPack里运行jetson_clocks后如果系统进入低负载状态频率依然会被DVFS动态电压频率调整拉下去。解决办法是把nvpmodel和jetson_clocks组合使用并且用jetson_clocks --store保存当前配置必要时用jetson_clocks --restore恢复。在我实测的JetPack 6版本里nvpmodel -m 0加jetson_clocks的组合效果最稳定。还有一个导致性能不佳的隐藏原因是供电不足。Orin Nano的USB-C或DC电源接口如果接的是杂牌电源电压不稳定时系统会自动降频保护硬件。我建议选择官方电源适配器或者正规品牌的12V 4A以上电源尽量不用USB供电。有过一次在面包板上用劣质电源跑模型频繁卡顿且偶发重启换了电源后所有问题消失。5.3 网络与外设看似简单却频繁翻车的细节Jetson板卡的网络问题很让人头疼尤其是使用SD卡启动时首次开机经常连不上Wi-Fi。先检查是不是没有启用Wi-Fi用nmcli radio wifi on开启再用nmcli dev wifi list扫描热点最后用nmcli dev wifi connect SSID password 密码连接。如果信号弱或者掉线频繁建议直接用USB网卡或者千兆有线连接稳定性比板载Wi-Fi好很多。显示方面很多人在Orin Nano上接显示器没画面第一反应是板子坏了。其实Orin Nano的HDMI口对显示器的兼容性一般尤其是高分辨率高刷新率的显示器可能出现检测不到信号的情况。我遇到过一次相关的问题参考当时的网络热词“nvidia jetson orin nx 16gb 开发套件 如何连接显示器、鼠标和键盘”解决思路是按顺序排查电源、HDMI线、显示器接口、系统启动状态。多数情况是HDMI线质量差或者转接头兼容性问题换一根高质量的HDMI 2.0线就好了。如果没有显示器也可以直接用Headless模式通过SSH远程连接在路由器后台找到板子IP用ssh 用户名IP登录即可。入手Orin Nano后建议不要先用摄像头这种“看起来简单”的外设。摄像头在Jetson上的兼容性问题极多尤其是MIPI CSI接口的相机模块必须匹配官方支持的型号和JetPack版本。USB摄像头相对省心即插即用但部分工业相机需要安装厂商提供的V4L2驱动装之前一定要确认是否支持ARM64架构。很多厂家的SDK只提供x86版本在Jetson上根本装不了采购前一定要问清楚。最后的几点心得这个平台我前后用了一个多月整体体会是Jetson Orin Nano 2的定位确实精准它不一定是最强或最便宜的但绝对是最适合入门级边缘AI和实体AI项目规模化的选择之一。算力够用、功耗可控、生态完善、成本合理这四个条件在同一个板子上同时满足在当下的设备选择里很少见。如果你正准备上手我的建议是别急着跑大模型先把刷机、性能模式、SWAP基础三步做完用自带的示例程序确认GPU工作正常再去部署自己的模型。遇到问题先查驱动时区和网络这两个最基础的外部条件往往就是最坑人的元凶。等你的模型能在TensorRT上稳定实时推理再考虑多设备部署和设备群管理一步步来踩坑的概率会低很多。
Jetson Orin Nano实战：入门级边缘AI与实体AI部署指南
过去一个月我一直在折腾一套移动机械臂的视觉抓取方案设备从树莓派换到x86工控机最后落在了NVIDIA Jetson Orin Nano上。朋友问我为什么选这个我说得很直接入门级边缘AI设备里它把算力、功耗、价格和生态这几个关键维度平衡得最好。尤其是Orin Nano Super发布之后16GB内存、最高67 TOPS算力、25瓦以内的功耗直接把实体AIPhysical AI项目的落地门槛拉下来一大截。这篇文章我不会去复述官方规格书而是从实际项目出发聊聊为什么这个平台适合入门级边缘AI和实体AI规模化落地怎么把环境搭起来、把模型跑起来以及我在过程中踩过的坑。无论你是准备入坑机器人、打算给产线加装视觉检测还是单纯想在移动设备上跑大模型推理这篇文章都能给你一个相对完整的参考。1. 为什么Orin Nano 2是入门级边缘AI的“甜点位”1.1 从参数看定位算力、功耗、价格三者如何平衡先说硬指标。Jetson Orin Nano系列最新的Super模式把AI算力推到了67 TOPSINT8稀疏内存也从8GB提升到16GB LPDDR5带宽从68GB/s涨到102GB/s。这是一个很微妙的分界线在它之前入门级设备要么是树莓派这种算力只有个位数TOPS的板子要么是动辄几万块的工业级GPU设备。Orin Nano刚好卡在中间让你能以两三千块的成本拿到一块能跑现代深度学习模型的完整计算平台。功耗方面Super模式下满载大约25瓦默认模式下7到15瓦。这意味着它不需要额外的主动散热方案就能稳定运行工业场景里塞进密封机箱也没问题。我用一个12V 5A的电源供一台带摄像头、激光雷达和机械臂控制板的整机实测下来还有超过20%的余量。这种能效比是x86方案很难做到的也是它在实体AI场景里受欢迎的根本原因。接口方面它提供PCIe、USB 3.2、MIPI CSI相机接口、千兆网口和40Pin GPIO基本覆盖了机器人、视觉检测和边缘网关的常见需求。尤其是MIPI CSI接口可以直接接全局曝光工业相机延迟比USB摄像头低一个量级。加上支持NVMe SSD启动系统的IO瓶颈也能得到缓解这对跑大模型和数据库类应用都有实际帮助。1.2 实体AI为什么需要这种“小盒子”实体AI或者叫Physical AI简单说就是让AI系统能在物理世界中感知、决策、行动。机械臂抓取、AGV导航、无人机巡检、产线缺陷检测这些都属于实体AI的范畴。这类场景有一个共同特点计算必须发生在设备本地不能依赖云端。原因有三个第一是延迟机械臂的抓取动作从相机取帧到发出控制指令端到端延迟必须控制在几十毫秒以内走云端来回一趟就超时了第二是带宽多路工业相机每秒产生几百兆数据全传到云端不现实第三是隐私和可靠性很多产线数据不能出车间网络断连的时候设备也必须能独立工作。但本地方案也有历史难题。工控机加独立显卡的方案性能足够但体积大、功耗高、价格贵一个机械臂项目光计算单元就要一两万。树莓派之类的方案便宜省电但跑不动现代模型一张640x640分辨率的YOLOv8推理都要几百毫秒根本做不到实时。Orin Nano的出现恰好补上了这个缺口性能能达到实时推理的要求功耗能承受价格也到了个人开发者和中小团队能接受的范围。我做了个简单的对比目前主流方案的实际情况大致是这样的方案算力INT8功耗参考价格适合场景树莓派50.5 TOPS左右5-10W500元左右原型验证、轻量控制Jetson Orin Nano Super67 TOPS7-25W2500元左右入门级边缘AI、机器人、视觉检测Jetson Orin NX100-157 TOPS10-25W6000-8000元多路视觉、SLAM、更复杂的AI负载x86工控机RTX显卡几十到上百TOPS150W1.5万元以上传统视觉、GPU通用计算从这个表能看出来Orin Nano 2的定位非常精准。它不是性能最强的也不是最便宜的但它在“能实时跑AI模型”和“个人/小团队买得起”这两个条件之间找到了平衡点这也是为什么它在入门级边缘AI和实体AI项目里被反复提及。2. 环境搭建刷机、驱动与系统调优2.1 刷机与启动SDK Manager和SD卡镜像两条路拿到板子第一件事是把系统刷进去。Jetson平台有两种主流刷机方式我两种都试过说下各自的特点。第一种是NVIDIA官方推荐的SDK Manager适合有Ubuntu主机x86环境的情况。它会自动下载JetPack SDK把系统镜像、CUDA、cuDNN、TensorRT、DeepStream这些组件一次装好。整个流程是板子进入Force Recovery模式按住Recovery键再通电用USB线连接主机SDK Manager识别到设备后选择要安装的组件和版本然后自动写系统、自动安装SDK。这种方式最省心不容易出错第一次玩Jetson的人建议直接用这个。第二种是直接烧录SD卡镜像适合Windows用户或者不想装SDK Manager的情况。到NVIDIA官方下载JetPack对应的SD卡镜像文件用balenaEtcher或Rufus把镜像写到至少64GB的高质量SD卡里插入板子启动即可。启动后系统自带CUDA和TensorRT但不包含DeepStream等额外组件需要手动用SDK Manager补装或者用apt命令安装。这个方式的优点是快缺点是缺少SDK Manager的组件管理功能后续增删组件比较麻烦。刷完系统开机之后第一件事是确认版本对应关系。在终端执行cat /etc/nv_tegra_release nvcc --version/etc/nv_tegra_release显示的是L4TLinux for Tegra版本nvcc --version显示CUDA版本。这两个版本必须和JetPack版本匹配比如JetPack 6.x对应CUDA 12.x和L4T 36.x。如果后面安装第三方库时出现编译错误八成就是版本对应关系出了问题。建议把这三者的对应关系记到项目README里省得过几个月回来维护时抓瞎。首次启动还有一个必做的操作把系统迁移到NVMe SSD。SD卡的随机读写性能太差跑大型模型加载权重或者读写日志时会明显卡顿。做法是用dd命令把SD卡系统克隆到NVMe硬盘或者直接用SDK Manager选择“Storage Device”为NVMe重新刷写。我用的是后者刷完后系统启动时间从40多秒缩短到了15秒左右模型加载时间也提升了近一倍。如果你要在板子上做正经项目这一步真不建议省。2.2 驱动验证Jetson上到底怎么确认GPU能用很多从PC转型过来的朋友习惯性地先查“nvidia-smi”结果在Jetson上发现直接报错就开始怀疑驱动没装好。其实Jetson的GPU驱动跟PC是完全不同的体系。Jetson底层使用的是集成在L4T内核里的NVIDIA GPU驱动不需要像台式机那样单独安装.deb驱动包也没有独立的nvidia-smi输出格式至少默认情况下是不同的。在Jetson上确认GPU工作状态用的是Jetson特有的工具。最常用的是sudo jetson_clocks sudo tegrastatstegrastats命令会实时输出CPU/GPU频率、内存使用、温度、功耗这些信息相当于Jetson版的“任务管理器”。如果你在终端看到类似GPU 1300MHz、CPU 42457MHz这样的输出就说明GPU驱动和频率调度都正常工作。jetson_clocks的作用是把CPU和GPU频率锁定在最高值避免系统在轻载时自动降频导致推理速度不稳定。在需要跑基准测试或者保证推理延迟稳定时这个命令非常有用。还有一个容易踩坑的点是CUDA Sample的验证。很多人想跑一下deviceQuery确认GPU可用但编译会报错。原因是新版JetPack里CUDA Sample不再预装源码需要手动从GitHub拉取git clone https://github.com/NVIDIA/cuda-samples.git cd cuda-samples/Samples/1_Utilities/deviceQuery make ./deviceQuery如果deviceQuery能正常显示你的GPU型号Orin Nano的GPU一般是Ampere架构说明CUDA环境没问题。看到类似CUDA Device Query ... PASSED的输出就可以放心继续往下走了。2.3 三大必备调优性能模式、SWAP和存储清理系统跑起来之后有三个调优动作我建议每个Orin Nano用户都做一遍都是影响实际使用体验的关键项。第一设置性能模式。默认情况下系统跑在15瓦的功耗档Super模式需要手动开启。执行sudo nvpmodel -m 0-m 0对应Super模式25瓦-m 1是15瓦模式-m 2是7瓦模式。改完用nvpmodel -q确认当前模式。注意Super模式对散热有要求如果你的板子是裸奔状态最好加一个主动散热风扇再开否则芯片在重载时过热降频实际性能反而比15瓦模式更差。我在实测中发现25瓦模式下如果散热不良跑推理任务时温度会迅速冲到80度以上然后频率从最高值掉下来整个推理速度反而波动很大。加了5V风扇之后温度稳定在60度左右推理帧率就非常稳定了。第二扩展SWAP。项目后面跑多路摄像头或者大模型时16GB内存很可能被吃满。这时候SWAP如果太小会导致OOM内存耗尽被杀进程。Jetson默认提供了zram但压缩后的交换空间只有大约3GB不够用。推荐的做法是在NVMe SSD上做一个8到16GB的swapfilesudo fallocate -l 12G /mnt/ssd/swapfile sudo chmod 600 /mnt/ssd/swapfile sudo mkswap /mnt/ssd/swapfile sudo swapon /mnt/ssd/swapfile为了重启后自动挂载还要在/etc/fstab里加一行。这个操作能显著减少OOM概率代价是SSD使用寿命和略微的性能下降但在实战中非常划算。我用的是三星980 500GB开机加载模型时系统内存占用经常到17GB左右没有大SWAP根本跑不起来。第三清理JetPack预装组件。JetPack默认安装了非常多的库和示例代码很多是日常用不到的。比如/opt/nvidia/vpi下的样例、/usr/src/tensorrt下的示例代码等。清理前先看清楚哪些是你需要的我从不建议新手一上来就删组件但等系统稳定后可以把apt list --installed里的非必要包筛一遍尤其是那些占用几个GB的示例和文档。空间有限的小容量SSD用户做这个清理能多出不少余量。3. 模型部署工作流从x86训练到Jetson推理3.1 模型导出与量化ONNX到TensorRT的关键跳板在Jetson上部署深度学习模型最绕不开的环节就是TensorRT。简单理解TensorRT是NVIDIA的推理优化引擎它能把训练框架产出的模型做层融合、精度校准、内核自动调优最终生成一个高度优化的推理引擎。同样的YOLOv8模型在PyTorch里跑一次推理可能需要60毫秒用TensorRT优化后能压到20毫秒以内提速效果非常明显。但TensorRT不能直接吃PyTorch的权重文件需要通过ONNX作为中间格式。整个链路是PyTorch模型 → 导出ONNX → ONNX优化 → TensorRT引擎构建 → 推理以YOLOv8为例导出ONNX的操作在训练主机上完成yolo export modelyolov8n.pt formatonnx opset13 simplifyTrue dynamicFalse有几个导出参数要注意。opset版本会影响算子兼容性Jetson上JetPack 6自带的TensorRT 10对ONNX opset 13到17都能支持建议用13以上。dynamicFalse表示固定输入尺寸尺寸固定对TensorRT构建引擎更友好性能也更高。我建议在部署阶段把所有输入分辨率固定下来比如统一用640x640不要图省事保留动态尺寸。拿到ONNX文件之后有两种方式转TensorRT。第一种是直接用trtexec命令行工具/usr/src/tensorrt/bin/trtexec --onnxyolov8n.onnx --saveEngineyolov8n.engine --fp16--fp16启用半精度推理这是性价比最高的一步。在Ampere架构上FP16的算力是FP32的两倍而精度损失对视觉检测任务来说基本可以忽略。如果用INT8量化还能再进一步提速但需要准备校准数据集流程相对复杂新手可以先跳过。第二种方式是用Python API在代码里动态构建引擎import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(yolov8n.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) engine builder.build_engine(network, config) with open(yolov8n.engine, wb) as f: f.write(engine.serialize())第一次构建引擎时耗时可能比较长几秒到几分钟不等之后再加载序列化的.engine文件就很快了。我在板子上构建YOLOv8n的FP16引擎大约花了20秒加载只需要不到1秒。3.2 推理框架选择直接用TensorRT还是套一层推理库很多初学者在部署时会纠结一个问题到底是用原生TensorRT API写推理代码还是用DeepStream、ONNX Runtime、TorchScript这些上层方案。我的建议分场景。如果你做的是以摄像头视频流为主的应用比如缺陷检测、安防监控、客流统计直接用DeepStream最合适。DeepStream是NVIDIA官方的视频流分析框架它把视频解码、批处理、推理、目标跟踪、物体分类这些环节都封装好了在Jetson上用硬件解码单元做视频解码CPU占用率极低。我在一个检测项目中用DeepStream跑四路1080p视频流CPU占用只有30%左右这在原生TensorRT方案里很难做到。如果你的应用不是视频流而是单帧图片、雷达点云或者其他传感器数据用原生TensorRT或者ONNX Runtime就够了。ONNX Runtime相对简单代码量少适合快速验证。我把YOLOv8转成ONNX后在Jetson上用ONNX Runtime加CUDA Execution Provider推理速度大约42毫秒每帧这个速度适合非实时任务。但同样的模型转到TensorRT FP16后只需要11毫秒差距确实很大。所以只要是追求实时性能的场景我都推荐直接用TensorRT。PyTorch的TorchScript方案我不太推荐。虽然Jetson上能装PyTorch但Python解释器的开销在边缘设备上会被放大推理速度和TensorRT不是一个量级。我的经验是PyTorch用来做“CPU上的后处理和业务逻辑”可以真正吃性能的推理环节一定要落到TensorRT引擎上。3.3 NIM与容器化部署把边缘AI服务化近几年NVIDIA在推NIMNVIDIA Inference Microservice在Jetson平台上也逐步支持。用一句话概括NIM就是把常见模型的推理服务打包成标准容器通过HTTP/GRPC接口对外提供服务。这样做的最大好处是你的应用代码和推理引擎解耦了。模型迭代时只替换NIM容器镜像不需要重新编译整个应用。我搭过一个基于NIM的视觉检测服务大致是这样的流程。先在Jetson上安装NVIDIA Container Toolkitsudo apt-get install nvidia-container-toolkit sudo systemctl restart docker然后拉取对应的NIM容器镜像启动容器时指定使用GPU和映射端口应用侧直接通过HTTP请求发送图片拿到检测结果。这种方式特别适合多人协作的项目算法同学负责训练和优化模型嵌入式同学负责业务逻辑和传感器接入两者通过接口对接互不阻塞。容器化还能解决环境依赖问题。Jetson上Python环境极其容易搞乱我见过不止一个人在Jetson上重装系统原因就是把conda环境搞崩了导致系统Python也被影响。用Docker隔离后宿主机环境可以保持干净出问题直接销毁容器重建就行。不过要注意映射GPU时用--gpus all参数Jetson上Docker的GPU支持依赖nvidia-container-toolkit如果容器内看不到GPU先查这个包是否正常安装。4. 实体AI落地案例与规模化实践4.1 一个机械臂视觉抓取项目的典型架构我最近帮朋友做的是一个桌面机械臂的视觉抓取项目硬件包括一台Orin Nano Super、一个USB工业相机、一台六自由度机械臂通过串口控制。任务是把传送带上的零件识别出来通过机械臂抓取到指定位置。这个项目非常有代表性算是实体AI入门级落地的经典组合。整体软件架构分成四层。第一层是感知层相机每100毫秒采集一帧图像送到TensorRT引擎做目标检测和位姿估计第二层是决策层根据检测结果计算目标的三维坐标通过标定把像素坐标转换成机械臂基座坐标系下的空间坐标第三层是控制层把目标坐标转换成机械臂的关节角度通过串口下发指令第四层是反馈层机械臂夹爪上的传感器检测是否抓取成功失败则触发重试逻辑。在Orin Nano上跑这个流程感知层的检测延迟大约15毫秒决策层计算大约5毫秒控制层机械臂动作一般需要200到500毫秒所以整体瓶颈在机械臂本体而不在计算平台。这也说明了为什么Orin Nano这种级别的算力对入门级实体AI项目已经足够。如果换成检测模型更大的YOLOv8s推理时间会到40毫秒左右依然在可接受范围内。这个项目里最有价值的经验是坐标系标定。很多新手在机械臂抓取项目里翻车不是模型精度不够而是像素坐标到空间坐标的变换没做好。我的做法是先用棋盘格标定相机内参再做手眼标定相机安装在机械臂外是“眼在外”模式把变换矩阵保存下来在决策层直接用矩阵运算完成坐标变换。整个过程用OpenCV的calibrateCamera和solvePnP就能实现不需要额外的标定设备。4.2 多机部署与远程管理规模化落地的关键一步当你的边缘AI项目从一个设备扩展到几十台甚至上百台时单机SSH管理的方式就不现实了。每台设备手动更新模型、手动改配置不仅效率低而且极容易出错。我第二次部署项目时就吃了这个亏用了整整两天在十几台板子上重复刷模型结果发现有两台的模型版本漏更新了产线上跑的还是旧版本。后来我采用了容器加轻量编排的方案。每台Jetson上安装Docker用K3s作为集群管理工具模型和业务应用都打包成镜像通过中央仓库统一分发版本。更新模型时只需要重新构建镜像并推送给K3s它会自动滚动更新所有节点。这个方案在几十台设备的规模下非常稳定我用它管理过一个18台Orin Nano的集群跑了一个多季度没出过版本混乱的问题。还有一个容易忽略的点是设备监控。我遇到过一台设备因为风扇停转导致芯片过热推理性能跌了一半但系统并没有崩溃线上业务还在跑只是追帧越来越严重。后来我在每台设备上加了一个轻量监控脚本定期采集tegrastats的关键指标包括温度、CPU/GPU占用率、内存余量上报到中央服务端设置温度超过75度就触发告警短信。这样的小工具成本很低但对规模化维护帮助巨大。4.3 数据回流与持续迭代让边缘AI越用越准实体AI项目上线只是开始模型在真实环境里的表现大概率低于实验环境持续迭代是必然的。这里的关键是数据回流。我在机械臂项目里做了一个简单但实用的闭环推理阶段把低置信度的检测结果和对应的原始图像自动保存到本地缓冲区每天通过定时任务压缩上传到训练服务器算法同学定期用这些难例数据训练新模型验证精度提升后发布新版本再通过K3s推送到设备端。整个周期从原来的一周缩短到一天模型的性能提升非常明显。在Jetson上做数据回流的硬件要求不高重点是存储策略。我建议在NVMe SSD上单独划一个目录存放原始数据每天压缩上传后清理避免SD卡或小容量SSD被塞满。另外上传数据必须脱敏去掉个人信息和敏感区域避免数据合规风险。Orin Nano的带宽虽然不大但上传典型的难例数据每天几百MB完全没有问题。5. 常见问题速查与避坑技巧实录5.1 驱动与容器运行时最容易被卡住的两个环节Jetson开发中遇到的坑很大一部分集中在驱动和容器运行时。先说一个非常典型的问题在x86 Ubuntu主机上卸载重装NVIDIA驱动后重启时偶尔会看到类似“an nvidia kernel module nvidia-uvm appears to be already loaded in your kernel”的提示。这个问题的本质是模块没有完全卸载干净。解决方法是进安全模式或字符界面先执行sudo rmmod nvidia-uvm nvidia-drm nvidia-modeset nvidia把旧的模块全部卸载再重新安装驱动。如果rmmod提示模块正被占用用lsof查一下是哪个进程在使用GPU关掉进程再卸载。另一个高频问题是nvidia-smi报错has failed because it couldnt communicate with the nvidia driver。这个错误在PC和Jetson上含义略有不同。在PC上基本可以确定是驱动和内核版本不匹配常见原因是系统内核升级后驱动没有跟着重新编译。解决办法是安装对应内核版本的headers然后重新执行sudo dkms install -m nvidia -v 版本号或者干脆用--no-opengl-files重新装一遍驱动。在Jetson上如果遇到这个报错一般不是驱动缺失而是当前环境里根本没有加载GPU模块执行sudo modprobe nvidia-uvm再验证即可。容器相关的坑也很多。最常见的是Docker容器里跑程序报找不到GPU但宿主机GPU明明正常。这通常是因为容器没有注入GPU设备启动容器时没有加--gpus all参数或者宿主机缺少nvidia-container-toolkit。有时候nvidia-container-toolkit装了但Docker运行时没有重启也需要执行sudo systemctl restart docker才能生效。还有个别情况是JetPack版本和容器镜像的CUDA版本不匹配比如JetPack 6自带的CUDA 12.x容器跑了CUDA 11.x的镜像大概率会报libcudart.so找不到重新选择匹配版本即可。5.2 性能与散热为什么你的Orin Nano跑不满很多用户看网上评测说Orin Nano Super能跑到67 TOPS自己实测跑模型却只有一半性能第一个反应是“买到假货”。其实大概率是散热和功耗设置的问题。先说散热。Super模式25瓦持续满载时芯片功耗密度很高如果只靠被动散热片温度会迅速攀升到85度以上然后触发频率下调。我在机械臂项目里一开始用自带的小散热片跑模型十几分钟后GPU频率从1.3GHz掉到800MHz左右推理延迟直接翻倍。换成5V主动风扇加加厚散热片之后温度稳定在60度附近帧率曲线变得非常平滑。如果你的设备要长时间满载运行散热设计绝对是第一优先级。其次是频率策略。jetson_clocks会把CPU和GPU频率锁到最高但有些版本的JetPack里运行jetson_clocks后如果系统进入低负载状态频率依然会被DVFS动态电压频率调整拉下去。解决办法是把nvpmodel和jetson_clocks组合使用并且用jetson_clocks --store保存当前配置必要时用jetson_clocks --restore恢复。在我实测的JetPack 6版本里nvpmodel -m 0加jetson_clocks的组合效果最稳定。还有一个导致性能不佳的隐藏原因是供电不足。Orin Nano的USB-C或DC电源接口如果接的是杂牌电源电压不稳定时系统会自动降频保护硬件。我建议选择官方电源适配器或者正规品牌的12V 4A以上电源尽量不用USB供电。有过一次在面包板上用劣质电源跑模型频繁卡顿且偶发重启换了电源后所有问题消失。5.3 网络与外设看似简单却频繁翻车的细节Jetson板卡的网络问题很让人头疼尤其是使用SD卡启动时首次开机经常连不上Wi-Fi。先检查是不是没有启用Wi-Fi用nmcli radio wifi on开启再用nmcli dev wifi list扫描热点最后用nmcli dev wifi connect SSID password 密码连接。如果信号弱或者掉线频繁建议直接用USB网卡或者千兆有线连接稳定性比板载Wi-Fi好很多。显示方面很多人在Orin Nano上接显示器没画面第一反应是板子坏了。其实Orin Nano的HDMI口对显示器的兼容性一般尤其是高分辨率高刷新率的显示器可能出现检测不到信号的情况。我遇到过一次相关的问题参考当时的网络热词“nvidia jetson orin nx 16gb 开发套件 如何连接显示器、鼠标和键盘”解决思路是按顺序排查电源、HDMI线、显示器接口、系统启动状态。多数情况是HDMI线质量差或者转接头兼容性问题换一根高质量的HDMI 2.0线就好了。如果没有显示器也可以直接用Headless模式通过SSH远程连接在路由器后台找到板子IP用ssh 用户名IP登录即可。入手Orin Nano后建议不要先用摄像头这种“看起来简单”的外设。摄像头在Jetson上的兼容性问题极多尤其是MIPI CSI接口的相机模块必须匹配官方支持的型号和JetPack版本。USB摄像头相对省心即插即用但部分工业相机需要安装厂商提供的V4L2驱动装之前一定要确认是否支持ARM64架构。很多厂家的SDK只提供x86版本在Jetson上根本装不了采购前一定要问清楚。最后的几点心得这个平台我前后用了一个多月整体体会是Jetson Orin Nano 2的定位确实精准它不一定是最强或最便宜的但绝对是最适合入门级边缘AI和实体AI项目规模化的选择之一。算力够用、功耗可控、生态完善、成本合理这四个条件在同一个板子上同时满足在当下的设备选择里很少见。如果你正准备上手我的建议是别急着跑大模型先把刷机、性能模式、SWAP基础三步做完用自带的示例程序确认GPU工作正常再去部署自己的模型。遇到问题先查驱动时区和网络这两个最基础的外部条件往往就是最坑人的元凶。等你的模型能在TensorRT上稳定实时推理再考虑多设备部署和设备群管理一步步来踩坑的概率会低很多。
