前阵子刚给手里的 Jetson AGX Orin 重装系统选了 JetPack 6.2.3然后把 conda、PyTorch、YOLO 环境整个从零搭了一遍。整个过程谈不上轻松尤其是刷机阶段差点以为板子变砖后面配置 conda 和 PyTorch 的时候也踩了不少坑。这篇就把完整流程和遇到问题后的解决思路整理出来给正准备上手 AGX Orin、或者想在板子上跑 YOLO 的朋友做个参考。不管是新买板子要第一次刷系统还是想彻底清掉旧环境重来照着这个流程走能少走很多弯路。1. 刷机前的准备先想清楚再动手很多人拿到 AGX Orin 就直接开刷结果刷到一半发现主机系统版本不对、线材不对、或者数据没备份最后浪费时间。刷机前的准备工作其实比刷机本身更重要尤其是那些不想重头再配一遍环境的人一定要先想清楚。1.1 确认板卡型号与固件版本Jetson 系列有好几款AGX Orin 和 Orin Nano、Orin NX 的刷机方式不一样JetPack 版本兼容性也有差异。你手上的设备如果本来能正常开机先查看当前固件版本比如执行cat /etc/nv_tegra_release输出里能看到 L4T 版本号比如R36.2.0。JetPack 6.x 对应的是 Ubuntu 22.04底层 L4T 是 r36.x。如果你手头的是旧版本 JetPack 5.x那系统还是 Ubuntu 20.04刷完后很多包的安装方式都不一样所以刷之前要确认。另外AGX Orin 有 32GB 和 64GB 两个版本SDK Manager 和烧录镜像对硬件型号是自动检测的不用手动区分但你要知道自己的板子是哪个型号方便后面选组件。1.2 准备 Ubuntu 主机和线材官方推荐的刷机方式是通过 SDK Manager 在 x86 的 Ubuntu 主机上操作。我用的是一台 Ubuntu 22.04 的台式机硬盘剩余空间最好有 50GB 以上内存建议 8GB 起。主机的 USB 接口最好是直出的 USB 3.0 或 USB-C不要用前置扩展坞刷机过程中经常因为供电或信号问题导致识别失败。线材方面AGX Orin 开发者套件自带的 USB-C 线是最好的选择。如果没有原装线随便找一根能传数据的 USB-C 线也行但千万别用那种只能充电的线。我试过用一根劣质线刷机结果 USB 设备反复断开重连日志里全是 timeout换了线之后一次过。确保主机和板子都能上网刷机过程中 SDK Manager 会自动下载 JetPack 组件包有些包体积很大比如 CUDA 和 TensorRT网络不稳定很容易中断。最好在系统设置里把自动休眠关掉不然刷到一半显示器休眠、USB 断连直接前功尽弃。1.3 备份与恢复方案别等丢数据才后悔刷机会清空 AGX Orin 的整个 rootfs板子上所有的用户数据、conda 环境、模型文件都会没掉。如果你之前已经在板子上安装过很多东西先把需要保留的内容备份出来。我的习惯是把两个东西单独备份一是用户主目录下的代码、数据集、模型权重二是当前环境里的pip和conda包列表。代码和模型用 U 盘或 scp 传到主机就行包列表可以用命令导出pip freeze ~/packages-backup.txt conda env export ~/environment-backup.yaml这样刷完系统后即便不能百分百复刻原来的环境至少知道之前装了哪些版本重新搭建的时候有据可依。注意如果你板子里的数据包含加密密钥、SDK 授权之类的东西刷机前一定确认这些密钥不会因为系统重置而失效。2. 用 SDK Manager 刷入 JetPack 6.2.3 的完整流程准备完毕开始刷机。SDK Manager 是 NVIDIA 官方提供的图形化工具支持在 JetPack 下载、烧写、安装组件一条龙。版本我用的 2.x 的 SDK Manager具体哪个小版本无所谓能登录 NVIDIA 账号就行。2.1 进入恢复模式按键时机比想象中重要这一步最磨人。AGX Orin 进入恢复模式的方法看起来很简单断电状态下手按住板子上的 Recovery 键不放插上电源等几秒后松开然后用 USB-C 线连接板子和主机。但实际操作里有几个细节一定要在断电状态下按住 Recovery然后再上电顺序反了会进不了恢复模式。上电后继续按住 Recovery 保持 3 到 5 秒再松开太早松手可能没进入。连接主机后执行lsusb能看到一个NVidia Corp.设备如果看到的是0955开头的 ID就说明进入恢复模式成功了。我第一次刷的时候就是因为没带电按住 Recovery 键导致主机怎么都识别不到设备还以为板子坏了。后来仔细看官方文档才发现自己的操作顺序有问题。如果你在主机上运行 SDK Manager 后页面一直停在“No device found”优先检查这一步。2.2 刷机参数选择从镜像到组件勾选SDK Manager 登录后会自动识别连接的 Jetson 设备然后让你选择 JetPack 版本。我们这里选 JetPack 6.2.3。接下来的界面会让你勾选需要安装的组件常见有 CUDA、cuDNN、TensorRT、VisionWorks、Vulkan 等。我的建议是如果只为了跑 PyTorch 和 YOLO保持默认勾选即可但注意不要勾选那些体积特别大的样例源码包比如“Samples”下的内容这会白白增加刷机时间。如果后续需要交叉编译或者开发 CUDA 应用再手动补装。存储位置和安装模式也有讲究。SDK Manager 支持在烧写系统后自动安装组件到 Jetson 板上我建议这里勾选“Manual”手动安装而不是自动安装。原因很简单自动安装过程很容易被网络或依赖问题打断一旦失败还得整个重来。手动安装可以在系统刷好后用 apt 或 pip 自己控制更稳。2.3 刷机失败的典型场景与排查思路刷机过程中最容易遇到两类问题。一类是主机软件卡在某个百分比不动日志显示connection to target lost。这个通常说明 USB 连接不稳定或者主机处于待机状态。解决方法是换一根线、换一个 USB 口然后重新执行刷机。SDK Manager 支持断点续备但保险起见我一般直接从头开始。另一类是刷写 rootfs 完成后板子重启后停在开机画面进不了系统。这种情况多半是主机和板子的设备树不匹配或者镜像下载不完整。可以重新进入恢复模式用 SDK Manager 重新刷一次。不用怀疑板子变砖Jetson 设备只要有 recovery 模式在就能重新救回来。刷完之后第一次开机进入 Ubuntu 桌面还是那句老话先不要急着装东西先把系统和网络稳定跑起来再做后续初始化。3. 系统初始化换源、时区与基础环境JetPack 6.2.3 自带的系统是 Ubuntu 22.04CPU 是 ARM64 架构。刷完机之后我习惯先把系统基础环境调整好再开始装 conda 和 PyTorch不然之后每一步都会遇到环境问题。3.1 换源与更新系统包镜像站选择有讲究Ubuntu 默认的 apt 源在板子上速度很慢尤其国内网络环境下更新包经常超时。需要把/etc/apt/sources.list里的源地址替换成国内镜像源。JetPack 底层的 Ubuntu 是 22.04所以源要匹配jammy注意不要用成 x86 的源。比如把默认的ports.ubuntu.com替换成阿里云或清华的mirrors地址。这里以阿里云为例sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup sudo sed -i shttp://ports.ubuntu.comhttp://mirrors.aliyun.comg /etc/apt/sources.list sudo apt update换源之后apt upgrade把系统包更新一遍。这一步有可能更新到内核和驱动更新完成后建议重启一次板子确保基础系统处于稳定状态。时区也顺手设置一下避免后面日志时间错乱sudo timedatectl set-timezone Asia/Shanghai3.2 安装 MiniforgeJetson 上 conda 的最优解Jetson 是 ARM64 架构官方 Anaconda 虽然有 Linux 版本但对 ARM 架构的支持一直不完善安装过程容易失败。实际更推荐用 Miniforge它同样提供 conda 命令完全兼容 conda 生态而且在 ARM64 上安装非常顺滑。Miniforge 的安装很简单从 GitHub 或国内镜像下载Miniforge3-Linux-aarch64.sh然后执行wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-aarch64.sh bash Miniforge3-Linux-aarch64.sh -b安装完成后需要把 conda 所在的目录加入 PATH并且初始化 shell~/miniforge3/bin/conda init bash source ~/.bashrc之后就能正常使用conda activate了。这里有个关键点conda init之后一定要重新开一个 shell 或者source ~/.bashrc否则你执行conda activate会看到类似CommandNotFoundError的提示后面专门讲这个坑。3.3 解决 conda 命令不生效的两种典型报错很多人在 Jetson 上装完 conda 后敲conda命令直接提示conda: command not found或者提示要先运行conda init。这两个问题本质上都是环境变量没有正确加载。先看第一种提示conda: command not found说明当前 shell 没有找到 conda 的可执行文件。检查一下~/.bashrc里是否有一段由conda init生成的代码特别是PATH中是否包含~/miniforge3/bin。如果发现没有手动执行export PATH~/miniforge3/bin:$PATH再试。第二种提示run conda init before conda activate。这个一般是 conda 函数没有在当前 shell 中定义。执行一次source ~/.bashrc就好或者重新打开终端。有些远程操作的场景比如在 SSH 里因为.bashrc在非交互 shell 下不会自动加载你可以改成执行source ~/.miniforge3/etc/profile.d/conda.sh来加载 conda 函数。建议安装完 Miniforge 后立刻创建一个虚拟环境来测试 conda 命令比如conda create -n test python3.10 -y。如果这一条能顺利执行后面的环境问题基本上都能自己解决了。4. 安装 PyTorch必须用 NVIDIA 打包的版本PyTorch 的安装是整个过程中最需要小心的部分。很多新手在 Jetson 上直接执行pip install torch然后 import 就报错原因在于官方 PyTorch 包是为 x86_64 架构编译的而 Jetson 是 ARM64并且需要和 JetPack 里的 CUDA、cuDNN 版本匹配。4.1 理解 Jetson 的 PyTorch 为什么不是 pip 直接装JetPack 6.2.3 里自带的 CUDA 版本是 12.x但 NVIDIA 提供的 PyTorch wheel 并不是通过 PyPI 发布的而是在 NVIDIA 的服务器上维护了一套专门为 JetPack 编译的版本。这套版本用了与 JetPack 底层库一致的 CUDA 库性能和兼容性都比从 PyPI 硬装要好。你如果直接在 Jetson 上pip install torch大概率会下载一个 x86_64 的 wheel 或者 ARM64 但依赖系统 CUDA 库的版本导致torch.cuda.is_available()返回 False或者直接报libcupti.so找不到。正确的方式是先从 NVIDIA 官方下载对应的 wheel 文件再 pip 安装。以 JetPack 6.2.3 为例你可以到 NVIDIA 的 JetPack PyTorch 下载页面找到类似torch-2.3.0a0...的文件。4.2 安装与验证从 wheel 到 CPU/GPU 检查下载对应 Python 版本的 wheel 后安装就很简单了。如果下载的是本地文件安装命令是pip install torch-2.3.0a0xxxxxx.whl然后安装 torchvision同样要用 NVIDIA 打包的版本。注意 torchvision 的版本必须与 torch 匹配不能直接pip install torchvision否则可能装成不带 CUDA 支持的版本。NVIDIA 提供了配套的 torchvision wheel同样下载后安装即可。装完后验证一下python -c import torch; print(torch.__version__, torch.cuda.is_available())如果输出True说明 PyTorch 能用 CUDA。再测一下 GPU 加速是否有效python -c import torch; x torch.randn(3,3).cuda(); print(x)如果打印出 CUDA 张量就说明安装没问题。第一次执行.cuda()可能比较慢因为要初始化 cuDNN 等库但后面就会很快。4.3 版本对应关系速查表Jetson 上安装 PyTorch 最容易混淆的就是版本对应关系。我整理了一份基于 JetPack 6.2.3 的对应表方便你核对组件版本示例来源JetPack6.2.3SDK ManagerUbuntu22.04刷机自带CUDA12.xJetPack 内置Python3.10 / 3.11MiniforgePyTorch2.3.0a0...NVIDIA wheelTorchVision0.18.0a0...NVIDIA wheel要注意这个表只是当时的版本NVIDIA 会持续更新 wheel。每次安装前最好到官方页面查看是否有新的 wheel 版本不要盲目使用网上别人发的过时链接。5. YOLO 部署与训练从预训练权重到自定义数据集PyTorch 装好之后YOLO 环境的搭建就轻松很多了。Ultralytics 的 YOLO 系列通过pip install ultralytics就能装然后下载预训练模型就能直接跑推理。不过训练自定义数据集时有不少隐藏坑这里一起说了。5.1 搭建 ultralytics 环境并跑通推理在 conda 虚拟环境里安装 ultralyticsconda activate your_env pip install ultralytics如果之前 PyTorch 装好了这一步通常不会出问题。跑推理需要下载预训练模型比如 YOLOv8n 或 YOLOv8s。Ultralytics 会自动从 GitHub 下载模型文件如果下载慢可以手动下载.pt文件放到当前目录。测试图片推理yolo predict modelyolov8n.pt sourcehttps://ultralytics.com/images/bus.jpg如果能看到输出框说明环境正常。这里要注意Jetson AGX Orin 的推理速度虽然比普通 CPU 强很多但和桌面级 GPU 比还是有差距。如果你跑的是高分辨率视频建议调小模型尺寸或降低输入分辨率。5.2 自定义数据集格式与训练参数建议自定义数据集是 YOLO 系列最常用的场景。YOLO 格式的数据集目录结构一般是dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml每个图像对应一个.txt标签文件每行是class x_center y_center width height坐标归一化。写data.yaml时指定类别名称和路径然后开始训练yolo detect train data/path/to/data.yaml modelyolov8n.pt epochs100 imgsz640 batch16在 AGX Orin 上训练batch 和 imgsz 要适当调低比如batch8 imgsz512不然显存容易爆。YOLOv8 的损失函数包含分类损失、回归损失和 DFL 损失默认配置一般不用动新手别尝试自己改损失权重容易导致训练不稳定。还有一个常被问到的训练时如果发现 loss 突然变成 NaN大概率是批大小设太大或者模型初始化权重有问题。可以先降低 batch或者关闭 AMPyolo detect train ... ampFalse5.3 训练中的典型案例与解决思路这里总结几个我实际遇到过的经典问题。第一个是“BN 崩溃”。训练过程中出现 loss 崩掉、mAP 一直为 0这通常发生在 batch size 很小的情况下。BatchNorm 层在小 batch 时均值和方差估计不准导致梯度爆炸。解决方法是增大 batch如果显存不够就降图像分辨率或者换用更小的模型。坦白说在 AGX Orin 上训练中小型数据集用 YOLOv8n 或 YOLOv8s 是最现实的。第二个是“混淆矩阵总和不为 1”。很多人在验证阶段计算混淆矩阵时发现行的总和不等于该类的真实数量甚至所有数字加起来超过 1。这通常是因为混淆矩阵包含“背景”类别或者忽略了一些无法匹配的预测框。YOLO 在计算 mAP 时会用 IoU 阈值过滤低质量预测最终矩阵的统计口径和像素级混淆矩阵不一样。只要你是用官方metrics.confusion_matrix或ClassificationMetric看到的数值本身不是错误不用过分纠结。第三个是“conda create 太慢”。因为 Miniforge 默认从 conda-forge 下载在国内环境很慢。可以给 conda 换源例如使用清华或阿里云的镜像源。conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/conda-forge conda config --set show_channel_urls yes换源后再创建环境速度会明显提升。最后再分享一个小技巧如果你在刷机和安装过程中遇到一个看似无解的错误别急着重新刷机先去/var/log/或 SDK Manager 的日志目录里看完整报错信息很多问题都是网络下载不完整、缺依赖、版本不匹配导致的日志里会写得很清楚。整个过程里我最深的体会是Jetson 设备不像普通服务器那样讲究一步到位它更像一个有自己脾气的小型超级计算机每个组件都要顺着它来。按这个顺序走下来从刷机到 YOLO 训练都不是什么难事。