nvidia-docker 通过预装匹配的驱动兼容层、固化 cuda/cudnn/pytorch 版本、自动挂载设备与库、预设环境变量，绕过宿主机依赖冲突，确保 torch.cuda.is_available() 返回 true。
torch.cuda.is_available() 返回 False 是最常见也最让人抓狂的信号——它不告诉你缺驱动、还是缺库、或是版本错配，只冷冷地拒绝 GPU。用 nvidia-docker 搭建环境之所以更稳定，核心就一条：**把所有依赖锁死在一个已验证的运行时单元里，绕过宿主机环境的不可控变量**。
为什么手动装 PyTorch + CUDA 总是失败？
你不是操作错了，而是踩进了“依赖链脆弱性”的坑：
-
nvcc --version显示 CUDA 12.1，但torch编译时实际链接的是系统里某个隐藏路径下的libcudart.so.11.8 - 宿主机装了驱动 535.xx，但 CUDA 12.1 要求 ≥ 525.xx —— 表面能跑
nvidia-smi，却在 PyTorch 初始化时静默失败 -
LD_LIBRARY_PATH漏配一个路径，import torch就报libcudnn.so.8: cannot open shared object file - conda 环境里
pytorch-cuda=11.8安装成功，但底层cuDNN版本其实是 8.6.0，而 PyTorch 2.7 需要 8.9.0 才能启用某些算子
nvidia-docker 是怎么绕过这些坑的？
它不修你的宿主机，而是直接给你一个“干净、完整、已测通”的小系统：
Jarvis - Chief of AI Staff on NVIDIA GB10
下载
在OpenClaw上部署你的首席AI助理贾维斯（JARVIS）。针对Dell Pro Max GB10（NVIDIA DGX Spark）边缘设备优化。用于设置和配置贾维斯。
- 镜像内已预装匹配的 NVIDIA 驱动兼容层（如
libnvidia-ml.so.1），无需宿主机驱动升级到最新版也能工作 - CUDA Toolkit、cuDNN、PyTorch 三者版本在构建阶段就固定（例如
pytorch/pytorch:2.7.0-cuda11.8-cudnn8-runtime），不存在运行时动态查找冲突 - 容器启动时，
nvidia-container-toolkit自动挂载/dev/nvidia0、/usr/lib/x86_64-linux-gnu/libcuda.so.1等关键设备与库，路径完全可控 - 所有环境变量（
CUDA_HOME、PATH、LD_LIBRARY_PATH）已在镜像中设好，进容器就能直接import torch; torch.cuda.is_available()
实际命令和最容易忽略的细节
这条命令看着简单，但少一个参数就可能白忙活：
docker run --gpus all -it --rm pytorch/pytorch:2.7.0-cuda11.8-cudnn8-runtime python -c "import torch; print(torch.cuda.is_available())"
- 必须用
--gpus all（或--gpus device=0），不能只写--runtime=nvidia（旧写法已弃用） - 镜像标签里的
cudnn8不代表“随便哪个 8.x”，官方镜像实际固化的是cuDNN 8.9.0，和 PyTorch 2.7 的编译配置强绑定 - 别自己
FROM nvidia/cuda:12.1-base再装 PyTorch —— 这样失去版本协同保障，等于回到手动安装的老路 - 宿主机只需装好基础 NVIDIA 驱动（≥ 对应镜像要求的最低版本），不用装 CUDA Toolkit 或 cuDNN —— 它们全在容器里
to('cuda') 这行代码不报错。用 nvidia-docker，你交付的不是一个脚本，而是一个可执行的环境承诺。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
