Jetson Orin 安装 PyTorch 全指南:JetPack 6.2 环境配置与避坑
2026/9/8 16:04:05 网站建设 项目流程

在 Jetson Orin 上装 Torch,翻车率比我预想的高太多了。只要你在终端里敲过pip install torch,八成已经见过Could not find a version that satisfies the requirement torch这行报错。很多从 x86 服务器转到 Jetson 的朋友,卡住的第一个地方根本不在算法,而在环境。明明在台式机上简单到不行的三步,到了这台 ARM 小主机上就是装不进去,或者装进去了torch.cuda.is_available()仍然返回 False。

这篇从 JetPack 6.2 实际环境出发,完整记录给 Jetson Orin 系列(AGX Orin / Orin NX / Orin Nano)配置 Torch 环境的过程:从确认系统版本、准备编译/安装环境,到选对 PyTorch wheel、装 torchvision 和 torchaudio,再到验证 CUDA、接 TensorRT,最后把高频报错整理成速查表。刚拿到 Orin 开发套件想跑 YOLO、Diffusers 或各类多模态模型的开发者,可以直接照着做,少走我走过的弯路。

1. Jetson 装 Torch 不是“Linux 装 Torch”的翻版

1.1 先搞清楚你的设备对应哪种系统

Jetson Orin 不是一台普通 ARM 电脑。硬件上它分 AGX Orin、Orin NX、Orin Nano 等几个型号,CPU 都是 ARM Cortex-A78AE 系列,GPU 是 Ampere 架构的核显,和整块 SoC 封装在一起。系统层面,NVIDIA 为 Jetson 提供了一套叫 JetPack 的发行套件,里面不仅包含 Linux 系统,还预置了 CUDA、cuDNN、TensorRT 等一堆专门针对 Jetson 优化过的闭源组件。

这带来第一个认知差异:你不能把它当成“树莓派 + CUDA”。树莓派上你随便装 Ubuntu 然后再 pip install torch,虽然慢但逻辑上可行;Jetson 上如果你脱离 JetPack,自己去刷一个纯 Ubuntu ARM 镜像,那 CUDA 驱动、TensorRT 库这些全都没有,就算装上 PyTorch 也只能用 CPU,体验极差。

在开始动手之前,我强烈建议先跑一下这三条命令,确认手里机器到底是什么状态:

uname -m cat /proc/device-tree/model nvcc -V

uname -m应该输出aarch64,这决定所有软件包都必须找 ARM64 版本;cat /proc/device-tree/model能看出当前板卡型号,比如NVIDIA Jetson Orin NX Developer KitNVIDIA Jetson Orin Nano Developer Kitnvcc -V能看到当前 CUDA 编译器版本,如果提示找不到,说明 JetPack 没装完整,后面 torch 就算装上也很可能导入失败。

JetPack 6.2 对应的是 Ubuntu 22.04 的 ARM 版本,系统自带的 Python 通常是 3.10。这几个基础事实直接影响后面的包版本选择,建议先记住。

1.2 JetPack 6.2 与 x86 开发机的本质差异

常年在 x86 台式机上跑深度学习的人,会觉得 PyTorch 安装是一件再普通不过的事。确实,在 CUDA 12.x 的 x86_64 Linux 上,一条命令就能搞定:

pip install torch torchvision

pip 会从 PyPI 上自动拉取跟平台匹配的二进制 wheel,装完就能用 GPU。但在 Jetson 上,这套流程完全行不通,因为 PyTorch 官方在 PyPI 上发布的 Linux wheel 主要是 x86_64 架构,aarch64(也就是 ARM64)用户不会直接获得带 CUDA 支持的预编译包。

JetPack 6.2 还有一个特点,它的 CUDA、cuDNN 等库并不像 x86 那样由用户自己安装驱动,而是作为系统组件烧录进镜像。也就是说,驱动层级不用你管,你要管的是让 PyTorch 去调用这些已经存在的库。这既是好事也是坏事:好处是省去了装驱动的痛苦;坏处是 PyTorch wheel 必须和 JetPack 内置的 CUDA/cuDNN 版本严格对齐,否则 import 阶段就会报一堆libcudnn.so.9 not found之类的错。

NVIDIA 的做法是为每个 JetPack 版本单独编译一套 PyTorch 及其附属库。这套 wheel 通常带有很长的版本号,比如2.7.0a0+0e0dd36.nv24.09这种格式,里面能看到 NVIDIA 专属标记nv。它的构建基准不是纯 PyPI 的上游 torch,而是基于 NVIDIA 定制版本,针对性适配过 Jetson 的 GPU 算子和 TensorRT 接口。

1.3 为什么普通 pip install torch 在 Jetson 上必翻车

这里多说一点原理,理解了之后,排错会轻松很多。

当你直接执行pip install torch时,pip 会去 PyPI 的索引页查找所有可用的 torch 版本,然后根据当前平台标签筛选。Jetson 的平台标签是linux_aarch64,而 PyPI 上绝大多数 torch wheel 的平台标签是linux_x86_64,筛选结果就是“没有匹配版本”,终端给出一句让无数人挠头的英文:

ERROR: Could not find a version that satisfies the requirement torch ERROR: No matching distribution found for torch

有些教程建议你把源换成清华源再试。清华源里确实有 torhc 的包,但在linux_aarch64的 PyPI 仓库里,要么没有带 CUDA 的 wheel,要么版本缺东少西。源换得再快,索引里没有你要的包也白搭。这个坑我见太多人踩过,包括我自己早期也浪费过一晚上。

正确思路是:Windows 和 x86 Linux 用户面向 PyPI,而 Jetson 用户应该面向 NVIDIA 的官方 PyTorch for Jetson 资源页。这个页面上会列出和 JetPack 6.0 / 6.1 / 6.2 对应的 torch wheel 下载地址,文件名里通常带aarch64字样,拿到手再用 pip 本地安装。

2. 环境准备:刷机、电源模式、Python 环境和内存

2.1 确认 JetPack 版本与刚装好的系统

如果你手里的设备是刚拆封,通常有两种方式来装系统:一是给 Orin NX/Nano 开发者套件用 SDK Manager 线刷;二是直接烧录官方提供的 SD 卡镜像到 TF 卡或 SSD。无论哪种方式,装完第一时间要确认 JetPack 版本,因为网上很多教程对应的实际是 JetPack 5.x,库的路径和版本号完全对不上,照着操作会晕。

查 JetPack 版本最直接的方法:

sudo apt show nvidia-jetpack | grep Version cat /etc/nv_tegra_release

如果你是二手板子或者系统被别人刷过,这一步更加不能省。我第一次给 Orin NX 16GB 装环境时,教程写的是 JetPack 6.0,但机器实际已经被上一个使用者刷成 6.2,导致我在找上找了半天不存在的 wheel 版本,后来才发现版本错位。

拿到系统后先做一轮基础更新,再装环境:

sudo apt update sudo apt upgrade -y

这一步建议插着电源适配器进行,不要在电池或者供电不稳定的环境下操作,而且别想着跳过。JetPack 更新包很大,有时候要下载好几个 GB,网络中断很容易让 apt 状态不一致,后面装包的时候会出现一堆奇怪依赖问题。

2.2 打开最高性能模式,顺带关注散热

Jetson Orin 出厂默认的电源模式并不一定是满血状态。Orin NX 有 10W、15W、20W 等多种功耗档位,Orin Nano 也有 7W 到 15W(或者 25W MAXN 之类,视具体型号而定)的档位。如果系统跑在低功耗模式下,你下载、解压、安装大型 wheel 时 CPU 会明显降频,速度慢得让人怀疑人生。

切到最高性能模式的方法:

sudo nvpmodel -m 0 sudo jetson_clocks

nvpmodel -m 0表示切换到 MAXN 模式,也就是解锁功耗限制的性能模式;jetson_clocks则会把 CPU/GPU 频率拉高并固定住,避免系统因为负载波动频繁调频。

这里必须提醒一句:如果你的 Orin Nano 没有主动散热风扇,长时间开着 MAXN 模式跑任务会很危险。GPU 一旦超过温度阈值会自动降频,甚至直接触发保护性关机。个人经验是安装环境阶段开 MAXN 问题不大,因为负载峰值短;但后面真要训练模型或者连续推理,建议根据自己散热条件选择合适功耗档位,别贪性能。

用下面命令可以实时观察温度、频率、功耗:

sudo tegrastats

这个工具会一行一行刷出 CPU 占用、GPU 频率、核心温度、内存占用等信息,调试环境时非常有用。

2.3 Python 环境:venv 而不是污染系统环境

JetPack 带的系统 Python 3.10 并不是不能直接装第三方包,但我不建议直接往系统 Python 里塞 PyTorch。原因是 Jetson 上不少系统工具和 NVIDIA 自带的 Python 库依赖特定版本的 numpy、protobuf 等包,你要是用pip install --upgrade numpy强行升级,很可能把系统里 TensorRT 相关的 Python 绑定搞挂。

最稳妥的方式是建一个虚拟环境,我习惯用venv

python3 -m venv ~/pt_env source ~/pt_env/bin/activate

在这个环境里,你的 pip 操作不会影响系统包。后面所有安装都在这条环境下进行,终端提示符前面出现(pt_env)就对了。

也有人习惯用 conda。Jetson 上 Anaconda 官方不提供 aarch64 完整资源,建议用 Miniforge。创建环境的时候注意 Python 版本尽量保持 3.10:

conda create -n pt python=3.10

不要用 conda 默认的 3.12 或者 3.13,因为 NVIDIA 为 JetPack 编译的 torch wheel 虽然理论上兼容更高版本 Python,但很多周边库的 ARM64 预编译包还不一定跟得上,没必要给自己找麻烦。

2.4 扩展交换空间防止 OOM

Jetson Orin 的内存是 CPU 和 GPU 共享的,这一点和桌面显卡很不一样。Orin Nano 基础版可能只有 8GB 内存,跑起 PyTorch 后很容易被一些中等模型直接打满,进程被 OOM Killer 干掉,没有任何报错日志,非常迷惑。

如果你机器内存只有 8GB 或者 16GB,建议装环境之前先加一个 swapfile:

sudo fallocate -l 8G /var/swapfile sudo chmod 600 /var/swapfile sudo mkswap /var/swapfile sudo swapon /var/swapfile

如果要重启后仍然生效,把这行写进/etc/fstab

/var/swapfile none swap sw 0 0

这里有个安全提示:swapfile 放在 TF 卡上会明显磨损存储卡,而且速度很慢;如果你用 SSD 启动,放在 SSD 上是更合理的选择。Jetson 上的统一内存机制意味着你看到的“内存”和“显存”其实是同一块物理资源,扩大 swap 只能防止进程被系统杀死,不能提升推理性能,所以主力还是建议选大内存版本,或者尽量用小 batch size。

3. 实操:JetPack 6.2 + Torch 安装全流程

3.1 先装对 PyTorch wheel

进入正题。在 JetPack 6.2 上装 PyTorch,核心原则就是:不要从 PyPI 装,从 NVIDIA 官方渠道下载 aarch64 wheel。

我先说一个最不容易出错的路线:直接在浏览器打开 NVIDIA 的 JetPack PyTorch 资源页,找到对应 JetPack 6.2 的安装说明。页面里通常会给出一段 pip 命令,类似下面这样(具体版本号会随时间更新,我写例子时对应的是 torch 2.7.x,你看到 2.8 或更高版本时以官方页面为准):

pip install --no-cache-dir torch==2.7.0 --index-url https://developer.download.nvidia.com/compute/redist/jp/v62/pytorch

这条命令里有两个关键点。第一,--index-url指定了 NVIDIA 的索引地址,而不是默认 PyPI;第二,torch==2.7.0只是示例版本,实际版本号要看官方页面给出的对应关系。JetPack 6.2 对应的 CUDA 版本是 12.x,你不需要自己去匹配 CUDA 小版本,因为 NVIDIA 已经帮你配好了,这一点比 x86 上手动装 CUDA 简单太多。

我更推荐先下载再安装,因为网络不稳定时 pip 直接装到一半断开会留下一个残缺环境,排查起来心烦。先把 wheel 下载到本地:

pip download torch==2.7.0 --index-url https://developer.download.nvidia.com/compute/redist/jp/v62/pytorch -d ~/wheelhouse

然后离线安装:

pip install ~/wheelhouse/torch-*.whl

如果你已经在网上找到了具体的.whl文件直链,用 wget 或者 curl 下载也行。记得安装前把 pip 升级到最新版:

python -m pip install --upgrade pip

旧版本 pip 在解析 torch 这种带本地版本号(+后缀)的 wheel 时偶尔会出问题,报的错还很奇怪,不如一开始就升级。

3.2 同步安装 torchvision 与 torchaudio

PyTorch 本体装完之后,很多人直接pip install torchvision,结果又掉进另一个坑:torchvision 在 Jetson 的 aarch64 环境下没有对应 PyTorch 官方 wheel,pip 会尝试从源码编译。

源码编译 torchvision 对 Jetson 来说不是不行,但过程很痛苦。它需要预先装好 libjpeg-dev、libpng-dev、libopenblas-dev 等一系列系统库,编译时常受内存影响,经常会因为某个头文件找不到冒出一堆红字。实际上 NVIDIA 同样提供了和 torch 配套的 torchvision 预编译 wheel,你还是应该指定同一个 index-url:

pip install torchvision==0.22.0 --index-url https://developer.download.nvidia.com/compute/redist/jp/v62/pytorch

torchvision 版本必须和 torch 版本严格对齐。torch 2.7.0 对应的 torchvision 是 0.22.0,torch 2.8 对应 torchvision 0.23 左右。具体版本号请在 NVIDIA 资源页确认。

如果你做音频模型,还要装 torchaudio:

pip install torchaudio==2.7.0 --index-url https://developer.download.nvidia.com/compute/redist/jp/v62/pytorch

装 torchaudio 时容易遇到 HMM 或者 FlashAttention 之类衍生态依赖,但 NVIDIA 给的预编译 wheel 已经把坑填好了,一般不会出问题。

这里插一句,如果你确实需要从源码安装某个扩展库,记得先把编译相关工具装上:

sudo apt install -y build-essential cmake ninja-build libjpeg-dev libpng-dev libopenblas-dev export MAX_JOBS=4

Jetson 的内存不像 x86 服务器那么宽裕,MAX_JOBS控制的是同时编译线程数,设得太高会内存爆炸,设成 4 是相对保守但安全的数字。

3.3 验证 torch 是否真的调用了 CUDA

安装完成后,别急着跑模型,先做一次最小验证。在虚拟环境里执行:

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

正常情况下你会看到类似这样的输出:

2.7.0a0+0e0dd36.nv24.09 12.6 True NVIDIA Tegra X8

如果前两行正常但torch.cuda.is_available()返回 False,多半有两个原因。一是环境变量没有指向 CUDA 库,JetPack 把 CUDA 装在/usr/local/cuda,你需要把库路径写进~/.bashrc

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

改完后执行source ~/.bashrc再验证一次。

二是你安装的 torch 不是 NVIDIA 预编译版本,而是某个没有包含 CUDA 扩展的纯 Python 版本。这种情况很常见于你在某个源里强行找到了一个“能装上”的 torch,但它其实不支持 Jetson GPU。卸载重装最省事,别在上面花太多时间兼容。

另外,torch.cuda.get_device_name(0)在 Jetson 上显示的内容比较特殊,有的版本会显示NVIDIA Tegra X8,有的会显示你的板卡型号,不同 JetPack 有差异,不用太纠结。

3.4 把 TensorRT 作为推理加速的后备选项

JetPack 6.2 里已经预装了 TensorRT,它在/opt/nvidia/tensorrt目录下。PyTorch 装好后,TensorRT 并不会自动接进 PyTorch 的推理流程,但 NVIDIA 为 PyTorch 提供了torch_tensorrt这个后端,可以在不修改模型代码的情况下把部分算子编译成 TensorRT engine。

如果你已经走到“装完 Torch 准备跑 YOLO”这步,建议顺手验证一下 TensorRT 可用不可用:

apt list --installed | grep tensorrt python3 -c "import tensorrt; print(tensorrt.__version__)"

如果你在 venv 环境里 import 不到 tensorrt,但系统 Python 能 import,说明你的虚拟环境没有继承系统 site-packages。一个快速办法是把系统 site-packages 里 tensorrt 相关的.so文件和 Python 包软链到虚拟环境的 site-packages,或者干脆激活虚拟环境后安装一个python3-libnvinfer的 Python 绑定。

不过要注意,不是所有 PyTorch 模型都能直接用 TensorRT 编译。包含动态 shape、复杂控制流或者自定义算子的模型,转 TensorRT 时经常会提示不支持的 op。我的建议是:先用原生 PyTorch 把模型跑通,再考虑 TensorRT 加速,不要第一轮就引入太多变量,否则报错了你都分不清是环境问题还是代码问题。

4. 高频报错与排查实录

4.1 “Could not find a version that satisfies the requirement torch”

这是出现频率最高的一条报错,完整信息通常是:

ERROR: Could not find a version that satisfies the requirement torch (from versions: none) ERROR: No matching distribution found for torch

在 Jetson 上看到这句话,90% 是因为你没有指定 NVIDIA 源,pip 正在从默认 PyPI 索引找包,而那里没有适配linux_aarch64的 torch。解决方案就是回到第 3.1 节,指定--index-url或者直接下载官方 wheel。

还有一种情况是你指定了 index-url 但仍然报 no matching version,那很可能是源里的版本和你的 Python 版本不匹配。比如你用 Python 3.12 建了虚拟环境,而 NVIDIA 的 wheel 是针对 Python 3.10 构建的,pip 会直接忽略。这种情况下用conda create -n pt python=3.10或者python3.10 -m venv重建环境即可。

另外,确认一下网络是否真的能访问 NVIDIA 下载域名。有些办公网络会限制大文件下载或者拦截部分域名,表现为 pip 卡住很久然后报 timeout,而非 no matching version。可以用curl -I测试目标域名连通性:

curl -I https://developer.download.nvidia.com

4.2 “specified attn_implementation='torch' is not supported”

这个报错我见得非常多,它出现在 transformers 库加载模型的时候:

ValueError: specified `attn_implementation="torch"` is not supported.

很多新手会误以为是 torch 没装好,其实恰恰相反,这个报错恰恰说明 transformers 已经在尝试调用 torch 了,问题出在 transformers 版本和你的 torch 版本之间兼容性不一致。

huggingface transformers 在加载模型时,如果代码里写了attn_implementation="torch",就是要求模型使用 PyTorch 原生的 SDPA(Scaled Dot Product Attention)实现。但是不同 transformers 版本对“torch”这个标识的支持程度不一样,较老版本里它只接受"sdpa""eager",遇到"torch"就抛出这个异常。

解决思路按优先级排列:

  • 升级 transformers:pip install -U transformers
  • 如果不想升级,把调用参数改成attn_implementation="sdpa"
  • 如果模型本身比较古早,不支持 SDPA,那就直接去掉这个参数,用默认实现

其实不只是 Jetson,x86 上也有这个问题,但 Jetson 用户经常参照最新的多模态项目代码,而这些项目经常激进地使用新参数,所以在 Jetson 上撞到这条报错的概率更高。

4.3 torch 报 DLL/so 加载错误,或 cuda.is_available() 为 False

如果你在 Windows 上遇到过torch 报 dllmain 1114,那是 Windows DLL 初始化失败,通常和 CUDA/cuDNN 动态库不匹配有关。在 Jetson 的 Linux 环境下,虽然不会显示dllmain 1114这种字眼,但类似的问题表现为 import torch 时报:

OSError: libcudnn.so.9: cannot open shared object file: No such file or directory

报这个错说明系统里缺少 cuDNN 或者 CUDA 库路径没配置对。Jetson 的 JetPack 镜像理论上已经内置了这些库,但有两种情况会翻车:一是你刷的是不带完整 JetPack 的精简镜像;二是在安装系统组件时被 apt 自动清理或者你手动误删过。

先用系统的查找命令确认库文件存在:

find /usr -name "libcudnn*" 2>/dev/null ldconfig -p | grep cudnn

如果库存在但没有被 ldconfig 收录,执行:

sudo ldconfig

如果确实不存在,说明 JetPack 没有完整安装,运行:

sudo apt update sudo apt install -y nvidia-jetpack

这个包会补齐 CUDA、cuDNN、TensorRT 等所有 NVIDIA 组件,体积比较大,耐心等待即可。装完再重新验证 torch。核心点有两个:库必须存在,库必须能被动态加载器找到。

4.4 其他需要留意的隐藏坑

安装过程中还会遇到不少零碎问题,比如pip安装了 torch,但 import 时用的是系统目录里的旧版本 torch;或者在容器里运行时报权限问题;又或者torch.cuda.memory_summary()里的数值和free -h对不上,让你怀疑是不是没识别到 GPU。

这里列一个我整理的速查表,方便你对照处理:

现象可能原因快速处理
pip install torch 报 no matching version没有指定 NVIDIA 源--index-url或下 wheel 后本地安装
import torch 报找不到 libcudnnJetPack 组件不完整sudo apt install nvidia-jetpack,再sudo ldconfig
torch.cuda.is_available() 为 False环境变量没配 / 装错 CPU 版LD_LIBRARY_PATH,重装 NVIDIA wheel
torchvision 安装时触发源码编译没有用 NVIDIA 源装 torchvision用同一个 index-url 安装匹配版本
跑模型时进程被杀内存不足扩大 swap,降低 batch size
transformers 报 attn_implementation 不支持transformers 版本过老升级 transformers 或去掉该参数
pip 解压 wheel 时 CPU 长时间 100%低功耗模式sudo nvpmodel -m 0 && sudo jetson_clocks

还有一个经常被忽略的问题:Jetson 的系统盘如果太小,多个 wheel 下载到默认缓存里会把根目录塞满。pip 默认缓存位置是~/.cache/pip,如果你发现df -h显示根分区满了,可以清理一次:

pip cache purge

或者安装时直接加--no-cache-dir,不存缓存文件。

5. 跑一个端到端小实验确认环境可用

5.1 最小推理测试代码

环境装完不能只看torch.cuda.is_available()是 True 就收工,我建议跑一次真实的小模型前向推理,把整条链路真正通一遍。

这里用一个不依赖外部图片数据的 ResNet18 随机推理作为验证:

import time import torch print("PyTorch version:", torch.__version__) print("CUDA version:", torch.version.cuda) print("CUDA available:", torch.cuda.is_available()) device = torch.device("cuda") model = torchvision.models.resnet18(weights=None).to(device) model.eval() x = torch.randn(1, 3, 224, 224, device=device) with torch.inference_mode(): for _ in range(5): _ = model(x) torch.cuda.synchronize() start = time.time() for _ in range(10): _ = model(x) torch.cuda.synchronize() elapsed = (time.time() - start) / 10 print(f"ResNet18 单次前向耗时: {elapsed * 1000:.2f} ms")

这段代码会初始化一个 ResNet18,生成随机输入,然后统计多次前向的平均耗时。第一次调用时 cuDNN 会做 autotune,比较慢,所以我先循环了 5 次预热,再正式计时。如果你看到耗时输出在 10ms 到 50ms 之间,说明 GPU 工作正常;如果耗时几百毫秒甚至几秒,检查一下是否模型被放到了 CPU 上运行。

5.2 看系统资源与性能数据

跑实验的时候,另开一个终端跑sudo tegrastats,能实时看到 CPU 占用、GPU 频率、内存占用和温度变化。这一步能帮你确认 PyTorch 是不是真的把任务卸载到了 GPU。

我用 Orin NX 16GB 测试时,ResNet18 这类小模型跑起来 GPU 占用率并不高,因为模型太小,计算量不足以把 Ampere 架构的 GPU 吃满。遇到这种情况不用担心,不代表环境有问题。真正吃 GPU 的是 YOLO、Stable Diffusion、大语言模型这类任务。如果你想快速验证 GPU 满载能力,可以稍微加大输入分辨率或者换成 ResNet50:

x = torch.randn(4, 3, 640, 640, device=device)

同时把 batch size 调大一些,GPU 利用率才会明显提升。

如果过程中内存飙升到接近物理上限并且系统卡顿,建议降低 batch size。Jetson 的统一内存架构决定 CPU 和 GPU 共享同一块内存,没有独立显存,所以你在free -h里看到的内存就是模型能用的全部“显存”,这是一个和 x86 平台截然不同的概念,开发时别用显存思维去套。

5.3 如果不想手动折腾:容器镜像方案

手动装完一轮后,我越来越推荐另一条路线:直接用 NVIDIA NGC 上的 L4T PyTorch 容器镜像。NGC 是 NVIDIA 的容器镜像仓库,里面的l4t-pytorch镜像已经把 JetPack 对应版本的 PyTorch、TensorRT、torchvision 全部封装好了,你只要拉下来就能跑。

使用方式大致是:

docker pull nvcr.io/nvidia/l4t-pytorch:r36.3.0-pth2.7.0

注意标签里的r36.3.0这类数字对应 L4T 版本,而 L4T r36.x 正好对应 JetPack 6.x。具体 tag 请以 NGC 页面为准,不同 JetPack 版本有对应不同 tag,不要随手复制一个旧命令。

拉取完成后启动容器:

docker run --rm -it --runtime nvidia --network host nvcr.io/nvidia/l4t-pytorch:r36.3.0-pth2.7.0

进入容器后,torch 已经是可用状态,再也不用考虑 CUDA 库路径。这个方案尤其适合多人共用一块 Jetson 开发板的场景,每个项目一个容器,环境完全不互相污染。

容器方案的缺点是镜像较大,通常要几个 GB,磁盘空间不足的板子可能撑不住。另外如果你需要修改 PyTorch 源码或者编译自定义算子,容器内做这些操作会比物理机麻烦,需要额外配置挂载目录。到底选 pip 手动装还是容器,取决于你的使用场景。自己长期维护一块板子,手动装更透明;频繁切换项目版本、需要复现别人工作,容器更省心。

6. 写在最后:几条让我少折腾半天的习惯

6.1 每换一次环境,先跑诊断脚本

环境配置这东西,一两次成功了不代表每次都能顺利。我现在拿到 Orin 板子后,第一件事不是急着跑业务代码,而是先写一个check_env.py,把 Python 版本、torch 版本、CUDA 是否可用、cuDNN 库是否存在一次打印出来,然后再开始干活。这个脚本我存在/home/user/scripts/下,换了设备也不重写。看起来多此一举,但实际上能帮你至少省下一小时的瞎猜时间。

6.2 保存已经下载的 wheel 文件

NVIDIA 的 wheel 下载地址虽然稳定,但偶尔会因为域名调整或者网络环境问题访问不了。我建议下载完成后,把 wheel 文件复制到一个专门目录长期保留,比如/home/user/wheelhouse。下次新到一块板子,或者虚拟环境被弄坏想重建,直接用本地文件安装,速度快而且不受网络影响。这个小习惯救过我很多次,尤其是出差时在弱网环境下干活。

6.3 不要顺手升级系统自带包

JetPack 系统自带的一些 Python 包和 CUDA 工具链有微妙耦合,比如numpyprotobuflibnvinfer的版本都不能随便升级。严格在虚拟环境里做项目开发,系统层面的包只要能用就别动。我看到很多朋友环境装崩,就是因为顺手pip install -U升级了某个看起来无关的系统包。在这台机器上,稳定压倒一切,真需要新版本依赖,新起一个虚拟环境重新装,这是最保险的思路。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询