★ FEATURED ARTICLE 最近连续被好几个做边缘AI的朋友问同一个问题新项目到底选 Jetson Orin 还是等 Thor问的人里有做车载视觉的有做工业质检的还有在学校带学生做机器人竞赛的。大家的纠结都差不多Orin 的资料多、坑都踩平了但总担心很快落伍Thor 听起来算力猛可是开发板还没普及谁也不敢拿项目周期去赌。这篇文章不聊玄的就讲我这半年多在 Jetson AGX Orin、Orin NX、Orin Nano 上实际做项目攒下来的经验。包括平台之间的真实差异SD 卡和 NVMe SSD 做系统盘的完整流程在 AGX Orin 上搭 YOLO 环境的那些坑以及驱动装不上、版本回退这类高频问题怎么处理。如果你正准备入手 Jetson 系列开发板或者已经在用但被环境折腾得头疼这篇应该能帮你省不少时间。1. Orin 和 Thor 的实际差异算力数字背后藏着什么很多人看芯片只看 TOPS每秒万亿次操作觉得数字越大越好。但真到跑项目的时候你会发现TOPS 只是纸面参数跟实际能跑通什么模型、跑到多少帧率完全是两回事。Orin 系列目前覆盖了从入门到高端的完整产品线而 Thor 还在逐步铺开这一步差在生态成熟度上非常明显。1.1 平台命名与核心规格先搞清楚你手里是哪颗芯片Jetson Orin 家族目前常见的有三兄弟Orin Nano、Orin NX 和 AGX Orin。很多人第一次接触容易混淆尤其是 Orin Nano 和 Orin NX 长得几乎一样都是小模块加底板的形式。区别核心在于算力层级和内存带宽平台AI 算力内存内存带宽典型功耗定位Orin Nano20/40 TOPS4GB/8GB LPDDR568 GB/s5W-15W入门级边缘推理Orin NX70-100 TOPS8GB/16GB LPDDR5102.4 GB/s10W-40W中端边缘计算AGX Orin200-275 TOPS32GB/64GB LPDDR5205 GB/s15W-60W高端边缘计算/机器人Thor预览标称 750 TOPS待定待定待定车载/超高端域控Thor 的标称算力确实吓人但这就是我想强调的第一点标称算力高不代表你项目的推理延迟就一定低。延迟受制于模型优化程度、TensorRT 引擎是否适配、内存带宽能不能喂饱芯片。Orin 系列经过这两年的大量项目验证TensorRT 的适配已经很成熟社区里踩坑记录也多你有问题基本搜得到。Thor 的软件栈对齐还需要时间至少目前我接触到的开发套件很多基础工具链还在频繁更新拿来做量产项目风险偏高。1.2 算力之外的隐性差异带宽、编解码器和外设扩展看芯片不能只看 TOPS内存带宽在视觉任务里往往是真正的瓶颈。我做多路视频流推理的时候遇到过这种情况AGX Orin 的 205 GB/s 带宽跑 8 路 1080p 解码加推理还游刃有余同样的模型换到 Orin NX 上虽然 TOPS 看起来也没差多少但多路推流时帧率直接掉一半。这就是带宽的差异模型计算不复杂但数据搬来搬去的时候窄带宽的芯片先卡住了。另一个容易忽略的是视频编解码器。Orin 系列内置的 NVENC/NVDEC 单元数量和代数不同。AGX Orin 比 Orin NX 支持更多的并发解码路数。如果你的项目不只是推理还要做视频采集、推流、录像一定要对照官方 datasheet 的编解码能力表别只看算力。1.3 开发者最关心的兼容性JetPack、CUDA、TensorRT英伟达把 Jetson 平台的 SDK 统称为 JetPack它包含了 Ubuntu 系统、CUDA、cuDNN、TensorRT、OpenCV 等一系列组件。很多人不清楚的是JetPack 的版本和桌面显卡驱动的版本号体系不一样它有自己的绑定关系。比如 JetPack 5.x 对应的是 CUDA 11.4 到 12.2 的某个子版本JetPack 6.x 才把 CUDA 升级到了 12.2 以上。这意味着你在 GitHub 上找代码的时候必须留意依赖的 CUDA 版本。我遇到过好几个项目代码在 PC 上跑得好好的拿到 Orin 上编译报错查到最后就是 JetPack 版本不匹配的问题。Thor 后续大概率是绑定更新的 JetPack 版本这会导致另一个麻烦旧项目在 Orin 上做的 TensorRT 引擎.engine 文件没办法直接搬到 Thor 上用必须重新做序列化导出。这个我在最后一章会详细讲。2. 开发板到手后的第一道坎从 SD 卡启动盘到 NVMe SSD 系统盘这一步几乎每个新手都会踩。Jetson 开发板默认是支持 SD 卡启动的很多教程也让大家去下个 Image 写到 SD 卡里就完事。但实际上SD 卡的 I/O 速度和寿命都撑不起正经开发编译个 OpenCV 都能卡半天频繁读写还容易把卡写坏。我的建议是SD 卡只用来做第一轮点亮能进系统之后立刻换到 NVMe SSD 上。2.1 为什么建议直接上 SSD 启动说个真实对比我在同一块 AGX Orin 上分别用 SD 卡和 NVMe SSD 做系统盘跑同一个 YOLOv8 模型的 TensorRT 导出。SD 卡大概花了 15 分钟SSD 用了不到 3 分钟。编译大项目的时候差距更离谱OpenCV 从源码编译在 SD 卡上可能要 40 分钟以上SSD 上 15 分钟就搞定了。另外开发过程中系统崩溃是常事SSD 在数据安全和使用寿命方面也远好于 SD 卡。2.2 SD 卡系统盘制作两个工具的对比做 SD 卡启动盘常见的有两个工具NVIDIA 官方出的 SDK Manager和第三方的 balenaEtcher。SDK Manager 适合需要完整刷机包括恢复分区、配套驱动等的用户但它依赖英伟达开发者账号且要联网申请流程略重。Etcher 就是直接把镜像写到卡里轻量快捷。我推荐的做法第一次使用直接用官方镜像加 Etcher 烧录镜像文件从 NVIDIA 官网下载对应板卡的版本。写入完成后插卡开机如果板子前面板 LED 灯正常点亮串口或 HDMI 有输出说明 SD 卡启动成功了。# 在 Linux 主机上查看 SD 卡设备名确认别写错盘 lsblk # 卸载自动化挂载分区 sudo umount /dev/sdX* # 使用 dd 写入镜像请替换镜像路径和设备路径 sudo dd ifjetson-orin-nano-sd-card-image.img of/dev/sdX bs4M statusprogress sync注意dd 写入那一步千万别搞错盘符写错会清空你电脑硬盘的数据。最好先用lsblk确认目标盘的容量和型号。2.3 NVMe SSD 配置为系统启动盘的完整流程Orin 的开发者套件背板通常带 M.2 插槽支持 NVMe SSD。配置 SSD 启动有两种思路一种是把镜像直接烧到 SSD 上另一种是先 SD 卡启动然后把系统搬到 SSD。第一种思路更干净我推荐用 SDK Manager 配合开发者模式Force Recovery 模式烧录。具体步骤拆解如下把 SSD 装进板卡的 M.2 插槽盖上散热片。给板卡接好电源、USB-C 数据线另一端接主机、HDMI 显示器和键鼠。按住板卡背面的 Force Recovery 按键然后按一下 Reset 按键保持 Recovery 按键两三秒后松开让板卡进入强制恢复模式。在主机端运行lsusb能看到 NVIDIA APX 设备说明进入 recovery 模式成功。打开 SDK Manager登录账号后选择对应板卡型号和 JetPack 版本。选择存储设备为 NVMe而不是内置 eMMC 或 SD 卡。点击 Flash 开始烧录。这里 SDK Manager 会安装 JetPack 的完整组件包括 CUDA、cuDNN、TensorRT 等时长和网络速度关系很大通常 20 到 40 分钟。烧完自动重启系统就直接从 SSD 启动了。此时你把 SD 卡拔掉板子照样正常开机。后面所有操作都在 SSD 上做体感会流畅非常多。我踩过的一个坑是SDK Manager 烧到一半提示Failed to flash。排查发现是主机的 USB 线和端口供电不稳导致的换了一根高质量的 USB-C 数据线并插在主板直出的 USB 口上问题就消失了。这种问题很隐蔽如果你烧录失败且硬件没错优先检查 USB 连接。2.4 Orin Nano 开发套件更换 Orin NX 模块硬件上的小心思有些朋友买的 Orin Nano 开发套件用一段时间觉得算力不够想直接换成 Orin NX 模块。这两者的模块外观和引脚在不少版本上是兼容的理论上可以替换但有几个细节必须注意。首先是功耗需求。NX 模块的峰值功耗比 Nano 高Nano 的底板供电设计能不能扛住 NX 的瞬时电流这是一个需要确认的问题。我查过不少改造案例大多数开发者套件底板能自适应调整供电策略但没有官方保证如果长期满载跑建议外接合格的直流电源而不是只靠 USB-PD。其次是散热。NX 的发热量明显更大Nano 的被动散热片不一定压得住。我换了一次模块发现跑推理负载时温度直冲 80 度后来换了带风扇的定制散热器才稳在 65 度左右。换模块之前先算清楚散热余量。最后系统镜像需要重装。不同模块的设备树和驱动配置不同换模块后最好重新烧录对应版本的 JetPack而不是让旧系统直接启动。直接启动可能进系统后大量驱动报错浪费的时间比重装还多。3. 在 AGX Orin 上搭建 YOLO 环境比想象中更棘手YOLO 系列是边缘视觉项目里用得最多的检测模型AGX Orin 上跑 YOLO 也是很多团队的首选。但网上教程鱼龙混杂照着做很可能卡在一堆环境问题上。我按自己验证过的流程整理一遍。3.1 JetPack 版本与 CUDA 环境的坑在 Jetson 上搭 YOLO 环境第一步不是 pip install而是先确认你手上的 JetPack 版本对应的 CUDA 版本。JetPack 5.x 自带 CUDA 11.4JetPack 6.x 对应 CUDA 12.2。不同版本的 PyTorch 对 CUDA 版本有严格依赖装错了要么 import 报错要么 CUDA 不可用。我目前的主力环境是 JetPack 6.0 加 CUDA 12.2。PyTorch 需要从 NVIDIA 官方的预编译 wheel 装不能用 PC 端的命令直接装。正确的装法是# 安装系统依赖 sudo apt update sudo apt install python3-pip libopenblas-dev libopenmpi-dev # 安装 PyTorch通过 NVIDIA 官方提供的 wheel pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu122注意 Jetson 的 PyTorch wheel 和桌面版是分开的。如果你看到undefined symbol: cudnn_*之类的错误大概率是 cuDNN 版本和 PyTorch 不匹配先检查 JetPack 里的 cuDNN 版本。3.2 编译 OpenCV 与 TensorRT 推理YOLO 在 Jetson 上跑通常还要 OpenCV 配合画面处理。JetPack 自带的 OpenCV 是做了 CUDA 加速的版本不需要自己编译。但用 pip 安装新版本 OpenCV 的话默认是不带 CUDA 的性能差异巨大。我的建议是尽量用 JetPack 自带的 OpenCV遇到版本冲突再针对性处理不要盲目去源码编译。TensorRT 是 YOLO 推理加速的关键。NVIDIA 官方给出的流程是先把 PyTorch 模型导出成 ONNX再用 TensorRT 的trtexec工具生成 engine 文件。这一步有两个容易踩坑的地方第一ONNX 导出的 opset 版本要跟 TensorRT 支持的范围匹配。opset 太高TensorRT 解析阶段会报 unsupported operator。我一般会在导出时强制指定 opset 12 或 13。第二engine 文件的序列化和反序列化对硬件平台敏感。在 AGX Orin 上生成的 engine 只能用在同代平台上换到 Orin NX 上需要重新生成。这一点很多人忽略导致交付到客户现场时发现跑不了。# 使用 trtexec 将 ONNX 转为 TensorRT engineFP16 模式 /usr/src/tensorrt/bin/trtexec \ --onnxyolov8n.onnx \ --saveEngineyolov8n.engine \ --fp16 \ --workspace20483.3 推理性能实测与显存占用我用一块 AGX Orin 64GB 跑 YOLOv8n输入分辨率 640x640FP16 模式TensorRT 推理单帧延迟大约在 5 到 8 毫秒。如果用 YOLOv8s延迟会到 15 毫秒左右。这个数据在边缘设备里已经相当能打了。如果是 Orin NX 16GB推理延迟大概会翻一倍跑轻量模型仍然可接受。显存占用是另一个关键指标。YOLOv8n 的 engine 大约占 1GB 显存YOLOv8s 大约 2.5GB。如果同时跑多路视频流显存和内存带宽会先于算力成为瓶颈。我做过 8 路 1080p YOLOv8n 的测试AGX Orin 基本扛得住Orin NX 就会开始掉帧。3.4 常见报错应对我在搭建过程中整理了几个高频报错和对应解法报错信息原因解决办法CUDA error: out of memory显存不够降低 batch size或换更小模型[TensorRT] ERROR: Unknown operatorONNX opset 太新导出时指定低版本 opsetImportError: libcudnn.so.8cuDNN 版本不匹配检查 JetPack 自带 cuDNN 版本切到配套的 PyTorch wheelGLIBCXX_3.4.30 not found系统编译器太旧升级 gcc/g 版本Failed to allocate memory板卡功耗模式太低切换到 MAXN 模式sudo nvpmodel -m 0提到功耗模式顺便说一句Jetson 默认的功耗模式可能不是满血状态。开机后先执行sudo nvpmodel -q查看当前模式建议开发阶段直接切到 MAXN# 查询所有可用模式 sudo nvpmodel -q # 切到最大性能模式 sudo nvpmodel -m 0 # 打开动态频率调整 sudo jetson_clocks --fan很多性能不如预期的问题最后都出在这一步——板子根本没跑在最高频率。4. 驱动和系统排错实录0x80070002、旧版驱动回退与国产系统Jetson 开发板上跑的是定制 Ubuntu问题相对少。但如果你在普通 PC 上装了英伟达桌面显卡驱动问题就真的是日常了。这一章说三个高频问题正好都是最近被问到最多的。4.1 英伟达驱动安装失败 0x80070002 排查链路Windows 上安装英伟达驱动报0x80070002这个错误码意思是系统找不到指定的文件。很多人一看到这个错误就以为驱动包坏了其实根因往往不是文件缺失而是 Windows 更新服务和驱动安装流程互相打架。我排查过一台机器报错链路是这样的下载最新驱动双击安装走到一半弹 0x80070002。换用 GeForce Experience 安装一样的位置报同样的错误。查看 Windows 更新记录发现系统更新也卡住了。问题定位到这里就清楚了Windows Update 组件损坏导致驱动安装时依赖的组件的服务不可用。解决办法分两步。第一步先修复 Windows Update# 以管理员身份打开 CMD net stop wuauserv net stop cryptsvc net stop bits ren C:\Windows\SoftwareDistribution SoftwareDistribution.old ren C:\Windows\System32\catroot2 catroot2.old net start wuauserv net start cryptsvc net start bits第二步重新运行驱动安装程序。如果还是报同样错误用显示驱动卸载工具DDU在安全模式下把旧驱动清理干净再装。DDU 清理的作用是移除注册表残留和驱动服务残留这一步对解决疑难安装问题非常关键。我在实战中发现0x80070002 还有一个容易被忽略的变体驱动包所在路径包含中文或空格导致安装程序无法解析临时目录。解决办法很简单把驱动的 exe 文件放到纯英文路径下比如C:\temp\driver\再执行安装。4.2 如何回退英伟达驱动版本与历史驱动下载有时候新驱动反而带来问题游戏帧率下降、显示器黑屏、CUDA 工具链不兼容。这时候就要回退驱动版本。英伟达官方提供了历史驱动的下载入口路径是官网驱动下载页面 → 手动查找驱动程序 → 在驱动程序类型选“Game Ready”然后在下面的列表里选全部。这时可以看到历史版本列表。回退操作本身不算难注意事项反而更多一定要用 DDU 先卸载干净旧驱动再装旧版本直接覆盖装很容易残留冲突。回退到同一大版本的旧小版本一般不需要 DDU跨大版本回退必须 DDU 清理。如果回退后系统不稳定可以考虑在设备管理器里把显卡驱动回滚驱动程序。前提是 Windows 保留了旧驱动的备份这个功能必须在装完新驱动后没手动清理过备份的情况下才有效。我个人经历过一次因为驱动回退导致桌面图标消失的情况。不是图标被删了而是新驱动不兼容导致桌面进程反复重启。用 DDU 清理并重装上一个稳定版本后图标显示就恢复正常了。4.3 麒麟系统安装英伟达显卡驱动依赖的注意事项国产化场景里银河麒麟等系统装英伟达显卡驱动是另一个高频需求。这里最大的问题在于英伟达对 Linux 发行版的驱动支持是分级的官方安装包主要面向主流的 Ubuntu、CentOS、Debian对麒麟这种基于其他发行版改造的系统更多时候需要手动调整。我的实操结论如下优先尝试英伟达官方.run安装包加上--no-opengl-files参数避免覆盖系统的 OpenGL 库。安装前必须装好 gcc、make、dkms 和对应内核头文件。大部分安装失败都是缺少kernel-devel导致内核模块编译不了。麒麟系统内核版本可能比官方驱动支持的内核新如果编译报错最省事的方案是换用发行版自带的驱动仓库或厂商适配的驱动版本。# 麒麟系统安装依赖示例 sudo apt-get install gcc make dkms linux-headers-$(uname -r) # 安装英伟达驱动关闭 X 服务后执行 sudo init 3 sudo ./NVIDIA-Linux-x86_64-*.run --no-opengl-files --dkms装完重启后用nvidia-smi验证驱动是否加载。如果提示No devices were found先检查是不是内核模块没有成功编译再检查 BIOS 里显卡输出模式是否设成了独立显卡优先。注意麒麟这类系统如果已经带了一套可用的开源驱动如 nouveau装 NVIDIA 闭源驱动之前需要先禁用 nouveau。方法是在/etc/modprobe.d/下新建配置写入blacklist nouveau然后再更新 initramfs。这一步不提前做闭源驱动装上也会被 nouveau 抢占。5. 从 Orin 到 Thor 的迁移思路现在就该开始准备的事虽然 Thor 平台离大范围铺开还有一段距离但如果你判断自己的项目将来必须迁移到 Thor有几个技术准备可以提前做起来。这不是瞎焦虑而是我见过太多项目在后期迁移时推倒重来非常可惜。5.1 TensorRT 引擎的跨平台兼容性TensorRT 生成的 .engine 文件是绑定具体设备型号的。这意味着你在 Orin 上辛苦调出的引擎文件拿到 Thor 上直接加载会失败必须用新平台重新导出。但是导出引擎的工程链路是可以复用的ONNX 模型 TensorRT Python API 脚本 后处理逻辑这些跨平台基本通用。所以建议你现在就把模型的导出脚本做干净至少把 ONNX 模型维护好这是迁移时最大的筹码。5.2 模型精度对齐与量化差异迁移到新平台之后模型推理的数值结果不可能是完全一致的。FP16 的累计误差、卷积算子的实现差异都会导致输出边界处的检测框小数位不同。更麻烦的是如果原项目做了 INT8 量化量化校准的统计参数每个层的缩放因子可能不通用。我的建议是在项目里保留一份纯 PyTorch 浮点推理的测试脚本用来在迁移前后做精度对比。拿同一批测试图片跑一遍对比检测框的 IoU 和置信度分布偏差在可接受范围内就算达标。这一步能省去大量真机联调时间。5.3 JetPack 生态迁移的实际准备Thor 肯定对应更新的 JetPack 版本这意味着系统级组件也会整体升级。你现在在 Orin 上使用的第三方库比如某个版本的 cuDNN、某个 OpenCV 的 patch到新平台上可能得同步升级。所以提前做的事就一件把项目的依赖清单和版本矩阵整理清楚别等到迁移时再慢慢翻 log。另外代码层面尽量少用硬编码的设备相关参数。比如在代码里写死cuda:0或者依赖某个特定 GPU 的共享内存尺寸这类代码在迁移时一定会出问题。提前抽象一层运行环境检测会平滑很多。搞嵌入式 AI 这些年我最大的体感就是硬件永远在迭代但解决问题的思路是通用的。选平台的时候别只盯着算力数字和营销话术要把生态、带宽、存储、散热、工具链这些隐形参数都算进去。Orin 系列到今天依然是边缘开发最稳的选择不是因为它最强而是因为它的坑都被前人踩平了。Thor 值得等但在它成熟之前把手里的 Orin 项目做扎实才是最划算的投入。
阅读完成 · 觉得有帮助？
