注意：以下内容未检测到任何违反安全规范的内容，请放心阅读。
1. 版本查询这件小事，为什么值得认真对待
先讲个真实经历。以前接手过一台别人配好的深度学习工作站，上面跑着一个训练脚本，动不动就报CUDA error: no kernel image is available for execution on the device。刚开始我还以为是代码问题，排查了半天，后来无意间用nvidia-smi和python查了一下版本，发现驱动支持 CUDA 12.4，但 PyTorch 是用 CUDA 11.8 编译的，显卡又是较新的型号——三者不在一个频道上，代码写得再对也没用。
这其实就是版本查询操作最核心的价值：在深度学习环境里，"能装"不等于"能用"，"能用"不等于"匹配"。而你要搞清楚自己到底处在哪个状态，第一步永远是查版本。
很多初学者喜欢直接跑pip install torch，装完就跑代码，根本不关心装的是 CPU 版还是 GPU 版、对应的 CUDA 版本是多少。在 CPU 上行数少的小模型可能感觉不出来，一旦换到大模型训练、推理加速，或者用上 WSL2、Docker 这类环境，版本问题就会集中爆发。到那时候再回头补课，成本比一开始就学会查询要高得多。
所以我写这篇东西的目的很明确：把"查询版本"这件事一次性讲透。包括 CUDA 驱动版本、CUDA Toolkit 版本、PyTorch 版本之间的关系，Windows、Linux、WSL2 不同环境下的查询姿势，以及查完之后怎么判断匹配不匹配、怎么处理常见的多版本共存问题。不管你是刚装完 PyTorch 想确认环境没问题的新手，还是正在排查torch.cuda.is_available()返回 False 的老手，这篇文章应该都能给你一些参考。
另外说明一下，这篇内容基于我自己的实践经验，涉及到的命令和对应关系在主流环境下都验证过，但由于 CUDA 和 PyTorch 的版本迭代很快，具体的对应关系请以官方文档为准，我的主要价值在于给你一套"怎么查、怎么判断、怎么排查"的完整思路。
2. CUDA相关版本的三层查询体系，不搞混是关键
2.1 nvidia-smi 显示的到底是哪个版本
先解决最常见的误区。很多人第一次查版本，看到nvidia-smi右上角有个 CUDA Version，就以为这是自己安装的 CUDA 版本。这是个非常普遍的误解。
nvidia-smi显示的是显卡驱动支持的最高 CUDA 版本，而不是你当前环境里实际安装并正在使用的 CUDA Toolkit 版本。它代表的是一个"上限"——你的驱动能撑得起多高的 CUDA 版本。换句话说，如果你的驱动显示支持 CUDA 12.4，那么你装 CUDA 12.4 或以下的任何版本理论上都能跑，但装 13.x 就不行（除非升级驱动）。
在 Windows 的命令提示符、Linux 终端还有 WSL2 的终端里，nvidia-smi的输出结构基本一致，都是上面显卡信息、下面进程列表，右上角就是 Driver Version 和 CUDA Version。我习惯把这两个数字一起记下来，因为驱动版本和 CUDA 支持上限是配套的，换驱动之后支持上限也会变化。
还有一个细节：在 WSL2 环境里，nvidia-smi显示的驱动版本其实是 Windows 宿主机的驱动版本。这是因为 WSL2 使用 GPU 时依赖 Windows 侧安装的 NVIDIA 驱动，Linux 侧不需要单独装驱动。所以如果你在 WSL2 里查版本，发现驱动版本和 Windows 下看到的一模一样，这是正常的，不要以为是自己装错了。
2.2 nvcc 才是真正在用的编译工具版本
要查看实际安装的 CUDA Toolkit 版本，标准命令是：
nvcc --version输出内容一般长这样：
nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2023 NVIDIA Corporation Built on Wed_Nov_22_10:17:15_CST_2023 Cuda compilation tools, release 11.8, V11.8.89 Build cuda_11.8.r11.8/columbia_11.8/0重点看release 11.8, V11.8.89这一行，这就是你当前 PATH 里生效的 CUDA Toolkit 版本。
nvcc是 CUDA Toolkit 自带的编译器，它所在的位置决定了你使用的是哪一套 CUDA。Linux 下常见路径是/usr/local/cuda/bin/nvcc，而/usr/local/cuda通常是一个软链接，指向/usr/local/cuda-11.8或/usr/local/cuda-12.4这类具体目录。所以多版本共存的核心操作就是改这个软链接，后面我会专门讲。
对比一下就很清晰了：
| 命令 | 显示内容 | 含义 |
|---|---|---|
nvidia-smi | CUDA Version: 12.4 | 驱动支持的最高 CUDA 版本上限 |
nvcc --version | release 11.8 | 当前 PATH 中实际使用的 CUDA Toolkit 版本 |
/usr/local/cuda软链接指向 | cuda-11.8 | Linux 下默认激活的 CUDA 安装目录 |
如果nvcc命令提示找不到，大概率是没把 CUDA 的 bin 目录加进 PATH，或者还没装 Toolkit。这种情况很常见，尤其是在只用 pip 装了 PyTorch 的机器上——PyTorch 的 CUDA 运行时是随包自带的，不依赖系统级 CUDA Toolkit，所以nvcc自然不存在。这属于正常现象，不代表 PyTorch 不能用 GPU，只是你不能在系统层面写 CUDA C/C++ 代码而已。
也许有人遇到的是这样的报错：in file included from gpu_burn-drv.cpp:50: /usr/local/cuda-13.4/include/cuda...。这属于编译 GPU 压力测试工具时头文件路径指向了不存在的目录，解决思路是先确认/usr/local/cuda软链接是否有效、指向的目录里是否真有 include 文件夹，再考虑是不是环境变量CUDA_HOME写错了。
2.3 Windows 和 WSL2 查询路径的区别
Windows 下查 CUDA 版本有几个入口：
- 命令行执行
nvidia-smi，看右上角驱动支持上限。 - 执行
nvcc --version，前提是安装了 CUDA Toolkit 且把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8\bin加到了系统 PATH。 - 打开安装目录看一眼文件夹名字，比如
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA下有几个v11.8、v12.4这样的文件夹，每个都代表一套已安装的 Toolkit。 - 在"设置-系统-关于"或者"控制面板-程序和功能"里能看到 NVIDIA 驱动版本和 CUDA Toolkit 的安装记录。
WSL2 的情况稍微特殊一点：
# 在 WSL2 的 Ubuntu 终端里执行 nvidia-smi你会看到 Linux 版的输出，但实际调用的是 Windows 侧的驱动。这就导致一个现象：WSL2 里nvidia-smi显示的驱动版本和 Windows 一致，但nvcc --version取决于你在 Linux 侧装了什么版本的 CUDA Toolkit。
我在 WSL2 里遇到过一个典型问题：Windows 驱动支持 CUDA 12.4，我在 WSL2 里也装了 CUDA 12.4 Toolkit，但 PyTorch 装的是 cu118 版本。结果跑起来没问题，因为 PyTorch cu118 自带 CUDA 11.8 的运行时，而驱动 12.4 对 11.8 的兼容性很好——大版本驱动对小版本运行时通常是向下兼容的。但这不代表可以随便混搭，后面讲匹配判断的时候再细说。
3. PyTorch版本与构建信息的查询技巧
3.1 一行命令看出"真身"
安装完 PyTorch，第一件应该做的事就是在 Python 环境里执行：
import torch print("PyTorch 版本:", torch.__version__) print("CUDA 构建版本:", torch.version.cuda) print("是否可用 GPU:", torch.cuda.is_available())这三行输出基本能定位 90% 的环境问题。但要注意，torch.version.cuda显示的是当前这个 PyTorch 包是用哪个 CUDA 版本编译的，而不是你机器上装的 CUDA Toolkit 版本。举例：你在官网选择了 cu118 的安装命令，那么即使机器上装着 CUDA 12.4 的 Toolkit，torch.version.cuda依然显示 11.8。
很多新人会被这个搞晕，怀疑自己装错了。其实这是 PyTorch 的设计：PyTorch 的 GPU 支持是通过自带的 CUDA 运行时库实现的，不强制依赖系统级 CUDA Toolkit。你只需要保证显卡驱动支持 PyTorch 构建所用的 CUDA 版本就行，系统级 Toolict 更多是给那些需要自己编译 CUDA 扩展或写自定义算子的用户准备的。
如果你想看得更细一些，还可以输出：
import torch print(torch.version.major) # 主版本号 print(torch.version.minor) # 次版本号 print(torch.version.patch) # 补丁号 print(torch.version.cuda) # 编译时用的 CUDA 版本 print(torch.version.git_version) # 源码编译对应的 Git commit其中git_version在排查诡异 bug 时特别有用。比如你发现某个算子行为异常，就可以对比自己和官方预编译包的 commit 差异，判断是不是源码编译引入了额外改动。
3.2 torch.cuda 那一堆 API 能帮你确认更多信息
torch.cuda.is_available()返回 True 只说明 PyTorch 检测到了可用的 CUDA 设备，但还不够，我建议再跑一段更完整的检查：
import torch print("CUDA 可用:", torch.cuda.is_available()) print("CUDA 设备数量:", torch.cuda.device_count()) print("当前设备索引:", torch.cuda.current_device()) print("设备名称:", torch.cuda.get_device_name(0)) print("设备算力:", torch.cuda.get_device_capability(0)) print("显存总量(GB):", torch.cuda.get_device_properties(0).total_memory / 1024**3)设备算力（compute capability）这个数字值得关注，它代表显卡的计算架构版本。像 RTX 4060 Ti 这类 Ada Lovelace 架构的卡，算力是 8.9；而 A100 是 8.0；更早的 V100 是 7.0。PyTorch 是否支持你的显卡，很多时候取决于构建版本的 CUDA 是否包含对应算力的内核。
我之前遇到过一台机器，torch.cuda.is_available()返回 True，但一执行实际运算就报错。后来发现是显卡太老（算力 3.0），而 PyTorch 2.x 的 CUDA 构建最低要求是 3.5——查询算力这步在排查时非常重要。
3.3 区分 pip 版、conda 版、源码版
查询 PyTorch 版本的时候，还有一个容易忽略的点：同一个 PyTorch 版本，通过不同渠道安装，查询出来的信息略有差异，行为也可能不同。
- PyPI 默认源安装：
pip install torch默认装的是 CPU 版还是 GPU 版，取决于当时 PyPI 上的 tag。早期版本 PyPI 默认就是 CPU 版，后来 CUDA 版和 CPU 版用+cu、+cpu后缀区分。但在某些历史时期和某些平台配置下，默认安装的可能是 CPU-only 版本，导致torch.cuda.is_available()永远 False。 - 官方源指定版本安装：在 PyTorch 官网用指定 CUDA 版本的命令安装，比如：
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118这种安装方式得到的包，torch.__version__通常会带+cu118后缀，看到这个后缀就能立刻确认是 GPU 版。
- conda 安装：
conda install pytorch ... -c pytorch这种方式会连同 CUDA 相关依赖一起通过 conda 管理，版本信息的表现形式可能不那么直观，需要结合torch.version.cuda和conda list | grep cuda综合判断。 - 源码编译安装：从 GitHub 拉源码自己编译的话，
torch.version.cuda取决于编译时指定的 CUDA 版本，torch.version.git_version也会是一条具体的 commit 记录，而非官方发布的 tag。
我自己的习惯是：优先用官方提供的--index-url命令安装，这样版本后缀信息最明确，排查问题的时候一眼就能看出构建来源。如果你用 conda，务必确认是-c pytorch安装的，而不是从默认源装的 CPU 版。
4. 版本匹配判断与实战排查链路
4.1 判断匹配的黄金组合
查完版本之后，最关键的一步是判断到底匹配不匹配。网上有很多人问"CUDA 11.8 能不能配 PyTorch 2.0""4060 Ti 该用哪个 CUDA 版本"，答案其实取决于三个约束条件：
- 显卡驱动支持的上限（
nvidia-smi右上角）≥PyTorch 构建版本所用的 CUDA 版本。 - PyTorch 构建版本（
torch.version.cuda）必须与 PyTorch 主版本兼容——这个兼容关系由 PyTorch 官方在 whl 页面给出，比如 PyTorch 2.1 提供 cu118、cu121 等构建。 - 显卡算力受 PyTorch 构建版本的支持范围约束。
用大白话讲：驱动是地基，PyTorch 是在地基上盖的楼，楼里自带了一整套装修材料（CUDA 运行时）。只要地基强度足够（驱动版本够高），楼就能住；地基不够（驱动版本太低），楼再漂亮也白搭。
举个实际例子。一台 4060 Ti 显卡的机器，驱动支持 CUDA 12.4，想装 PyTorch 2.1.0：
- 官方提供了 cu118、cu121 两个 GPU 构建。选 cu121 比较合理，因为 4060 Ti 算力 8.9，cu121 构建覆盖了 9.0 以内所有算力，性能发挥更完整。
- 理论上选 cu118 也能装，驱动 12.4 向下兼容 11.8 运行时，但可能无法完全发挥新架构的全部特性，个别算子也有编译优化差异。
再举个反例：一台老机器，显卡算力 5.0（GTX 9 系），驱动只支持 CUDA 10.2，你硬装 PyTorch 2.0 的 cu118 构建，结果显而易见——驱动上限小于构建版本，torch.cuda.is_available()大概率返回 False，或者干脆直接报错。
我把常见的判断流程总结成一段伪代码逻辑：
输入：显卡架构（算力）、驱动支持 CUDA 上限、PyTorch 目标版本 1. 查官方 whl 页面，确认该 PyTorch 版本提供的所有 cu 版本构建 2. 过滤掉 cu 版本高于驱动支持上限的构建 3. 从剩余构建中选算力覆盖最完整的（一般选最高的那个） 4. 安装后验证 torch.version.cuda 和 torch.cuda.is_available()4.2 典型报错与排查思路
光说不练假把式，我把实际工作中最常见的四类报错整理成一张表，附带完整的排查链路：
| 报错/现象 | 根因 | 排查顺序 |
|---|---|---|
torch.cuda.is_available()返回 False | 装的是 CPU 版 PyTorch，或驱动版本过低 | 先查torch.__version__看是否有+cu后缀；再查nvidia-smi驱动上限；最后确认是否有 NVIDIA 驱动 |
CUDA error: no kernel image is available for execution on the device | PyTorch 构建版本的 CUDA 不支持当前显卡算力 | 查显卡算力，对照 PyTorch 构建版本的编译选项；通常换更高 CUDA 版本的 PyTorch 构建能解决 |
CUDA error: invalid device ordinal | 代码里指定的 GPU 编号超出机器实际数量 | 先nvidia-smi确认物理 GPU 数量和编号；再用torch.cuda.device_count()确认 PyTorch 视角的设备数 |
CUDA driver version is insufficient for CUDA runtime version | 驱动版本低于 PyTorch 构建所需的 CUDA 运行时版本 | 核对nvidia-smi驱动上限和torch.version.cuda，升级驱动或降级 PyTorch 构建 |
第一类报错的完整排查链路是这样的（我遇到不下十次）：
1. python 里执行 import torch; print(torch.__version__) → 如果显示 2.1.0+cu118 说明是 GPU 版，继续 → 如果显示 2.1.0+cpu 说明装错了，卸载重装 GPU 版 2. 终端执行 nvidia-smi → 如果命令不存在或显示"No devices were found"，说明没装好驱动 → 如果能显示显卡信息，看右上角 CUDA Version 是否大于 PyTorch 需要的版本 3. 如果以上都正常但 is_available() 仍返回 False → 检查 python 环境是否混用了 conda 环境和系统 python → 检查是否设置了 CUDA_VISIBLE_DEVICES 等环境变量第二类报错的排查链路比较有意思。有一次我在新买的显卡上跑老项目，项目用的 PyTorch 1.13.0（cu117 构建），新版显卡算力高但架构太新，cu117 没有对应的内核，于是报no kernel image。解决方式是升级 PyTorch 到新版构建，而不是升级驱动。
4.3 多版本 CUDA 与 PyTorch 共存管理
实际工作里经常会遇到多个项目依赖不同 CUDA 版本的情况。比如项目 A 是老代码只能跑 CUDA 11.8，项目 B 想用最新的 cu121。这种需求很常见，解决方案有两层：
第一层：系统级 CUDA Toolkit 多版本共存。Linux 下安装多个版本的 Toolkit 到不同目录，靠环境变量控制当前会话用哪一个：
# 假设安装了 cuda-11.8 和 cuda-12.4 export CUDA_HOME=/usr/local/cuda-11.8 export PATH=/usr/local/cuda-11.8/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH不过手动改环境变量容易记错项目该用哪个版本，更工程化的做法是写进项目启动脚本，或者用 conda 环境管理。我个人的建议是优先用 conda 环境隔离，不同环境装不同 CUDA 版本的 PyTorch，这样互不干扰，切换环境就是切换整个依赖集：
conda create -n py311-cu118 python=3.11 conda activate py311-cu118 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118如果确实需要在系统级切换默认 CUDA 版本（比如要用 nvcc 编译自定义算子），可以修改/usr/local/cuda软链接：
sudo rm -rf /usr/local/cuda sudo ln -s /usr/local/cuda-11.8 /usr/local/cuda改完再执行nvcc --version验证。注意这样做会影响所有使用系统 CUDA 的会话，不要在高负载生产环境随意切换。
第二层：以 PyTorch 为单位的"软隔离"。由于 PyTorch 自带 CUDA 运行时，很多场景根本不需要系统级 Toolkit 参与。你在 conda 环境 A 里用 cu118 构建，环境 B 里用 cu121 构建，两边同时跑完全没有问题。真正需要系统级 CUDA 的环境只有：编译自定义 CUDA 扩展、用 CUDA 工具做性能分析、或者跑不依赖 PyTorch 的纯 CUDA 程序。
顺便提一句，网上经常能看到"安装 PyTorch 是不是必须装 CUDA"这种问题。准确回答是：用 GPU 跑 PyTorch 不必须安装系统级 CUDA Toolkit，因为预编译包自带运行时；但如果你想自己编译算子、用 nvcc 调试、或者做底层性能分析，那就需要装。这也是很多人装完 PyTorch 发现nvcc --version报错却一切正常的原因。
5. 日常维护中的版本查询速查手册
说句实在话，版本查询操作本身不难，难的是每次都记得查、并且知道查出来的数字代表什么。为了减少重复劳动，我自己习惯写一个统一的环境检查脚本，每次换机器或接手新环境，先跑一遍：
import platform import subprocess import sys import torch print(f"操作系统: {platform.system()} {platform.release()}") print(f"Python 版本: {sys.version.split()[0]}") # 查询 nvidia-smi 输出中的驱动和 CUDA 上限 try: output = subprocess.check_output(["nvidia-smi"], text=True) for line in output.splitlines(): if "CUDA Version" in line: print(f"驱动信息: {line.strip()}") except FileNotFoundError: print("驱动信息: nvidia-smi 命令不存在或驱动未安装") # 查询 PyTorch 与 CUDA 构建信息 print(f"PyTorch 版本: {torch.__version__}") print(f"PyTorch 编译 CUDA 版本: {torch.version.cuda}") print(f"CUDA 可用: {torch.cuda.is_available()}") if torch.cuda.is_available(): print(f"GPU 名称: {torch.cuda.get_device_name(0)}") print(f"GPU 算力: {torch.cuda.get_device_capability(0)}")这段脚本把系统信息、驱动信息、PyTorch 信息一次性打出来，排查问题时直接贴给同事或贴进 issue，沟通效率会高很多。里面的nvidia-smi查询通过subprocess调用，在 Windows 和 Linux 甚至 WSL2 下都能跑。
下面这些命令我按使用频率整理了一份速查表，建议收藏，或者干脆贴在自己的笔记软件里：
| 目标信息 | 命令/代码 | 参考位置 |
|---|---|---|
| 驱动支持 CUDA 上限 | nvidia-smi | 右上角 CUDA Version |
| 系统 CUDA Toolkit 版本 | nvcc --version | release 后的数字 |
| Linux 默认 CUDA 指向 | ls -l /usr/local/cuda | 软链接指向的目录 |
| PyTorch 主版本 | torch.__version__ | 如 2.1.0+cu118 |
| PyTorch 编译 CUDA 版本 | torch.version.cuda | 如 11.8 |
| GPU 是否可用 | torch.cuda.is_available() | True/False |
| GPU 设备名称 | torch.cuda.get_device_name(0) | 如 NVIDIA GeForce RTX 4060 Ti |
| GPU 算力 | torch.cuda.get_device_capability(0) | 如 (8, 9) |
| 已安装的 PyTorch 包来源 | pip show torch | Location、版本号 |
| conda 环境中的 CUDA 相关包 | conda list | grep cuda | 包名和版本列表 |
在实际使用中还有几个小习惯值得培养。
第一，每次安装完 PyTorch，先跑一遍检查脚本再开工。装完就跑代码，跑通了就万事大吉，遇到问题才回头查，这是新手最常见的低效模式。一次 30 秒的检查可以省掉后面几小时的排查。
第二，记录当前项目的版本指纹。我习惯在项目根目录放一个requirements.txt之外，再放一个environment.log，记录关键版本信息。这样三个月后重新捡起项目，或换机器复现实验，照着日志就能还原环境。日志内容就三行：
PyTorch: 2.1.0+cu118 GPU: NVIDIA GeForce RTX 4060 Ti (capability 8.9) Driver: 550.54.14 (max CUDA 12.4)第三，注意区分"我想用的版本"和"我能用的版本"。网上教程一搜一大把，每个都推荐最新版本，但不一定适合你的显卡和驱动。查询操作的价值就在这里——别人说的是他们机器的答案，你机器的答案要自己去查。
最后再分享一个技巧。如果 PyTorch 某个版本在你这台机器上行为异常，而你又没有强需求必须用这个版本，优先尝试切换官方支持的其他同主版本的 CUDA 构建，比如从 cu118 换成 cu121。这种切换成本很低，只需要重建一个 conda 环境或卸载重装 whl 包，但常常能解决莫名其妙的问题。反正现在我碰到奇怪的问题，第一反应是怀疑版本组合，而不是怀疑代码逻辑。
