企业官网建设流程全解析

1. 为什么“CUDA 与 N 卡驱动安装”不是一道选择题，而是一条必须踩准节奏的双轨线

很多人第一次装 CUDA，是冲着跑通一个 PyTorch 示例或编译一个 llama.cpp 开始的。结果nvidia-smi报错、nvcc --version找不到命令、import torch提示 CUDA not available——三连击下来，人直接懵在终端前。我见过太多人把“装驱动”和“装 CUDA”当成两个独立动作：先去 NVIDIA 官网下个 .run 文件一顿猛点，再从 CUDA Toolkit 页面下载对应版本的 run 包再装一遍，最后发现nvidia-smi显示驱动版本是 535.129.03，nvcc -V却报 12.4，但torch.cuda.is_available()死活返回 False。问题出在哪？根本不是哪个环节错了，而是压根没理解这两者之间的版本耦合关系——它不是“先装 A 再装 B”，而是“A 和 B 必须在同一个时间点、以同一套语义规则、由同一套依赖逻辑共同落地”的系统工程。

这背后的核心逻辑，是 NVIDIA 为 GPU 计算生态设计的一套分层契约机制：底层驱动（Driver）提供硬件抽象层（HAL），向上暴露一组稳定的内核接口（如nvidia.ko模块导出的符号表）；上层 CUDA Toolkit 则通过libcuda.so动态链接到该接口，再封装成nvcc、cudart、cublas等开发库。二者之间不是松耦合，而是强 ABI 兼容约束：CUDA Toolkit 的每个主版本（如 12.x）只承诺兼容某段驱动版本区间（例如 CUDA 12.4 要求 Driver ≥ 525.60.13），低于下限则libcuda.so加载失败，高于上限则可能因内核模块新增字段导致符号解析异常。这个约束不写在任何用户手册首页，却真实存在于/usr/lib/nvidia/current/下的.so文件符号表里，也藏在nvidia-smi --query-gpu=driver_version和nvcc --version的输出差值中。

更现实的痛点来自环境碎片化：你用的是 Ubuntu 24.04 还是 CentOS 7？是裸机、WSL2 还是 Docker？是否启用了 Secure Boot？显卡是 RTX 4060 Ti 还是 Tesla V100？这些变量会彻底改写安装路径——Ubuntu 24.04 默认 apt 源里的nvidia-driver-535可能根本不支持你的 4060 Ti（它需要 ≥535.104.05），而 WSL2 下你根本不能装传统.run驱动，必须走 Microsoft 提供的wsl-update+nvidia-cuda-toolkit组合。这不是“教程照抄就能过”的事，而是要像调试内核模块一样，先看清自己站在哪条轨道上，再决定双轨如何并行铺设。

所以这篇内容不叫“CUDA 安装教程”，也不叫“NVIDIA 驱动配置指南”，它叫《CUDA 与 N 卡驱动安装》——强调“与”字，就是强调二者的共生性、时序性与环境敏感性。接下来我会带你从零开始，拆解每一个决策点背后的硬约束，给出每种主流场景下的实操路径，并告诉你那些官方文档绝不会写的“为什么这里必须这样选”。

2. 版本对齐：读懂nvidia-smi、nvcc和torch.version.cuda三者之间的隐秘对话

所有安装失败的起点，几乎都源于对三个关键命令输出的误读。它们不是平行信息，而是一条链式验证流：nvidia-smi是硬件层可信锚点，nvcc是开发层能力声明，torch.version.cuda是运行层实际调用结果。跳过任一环的交叉验证，就等于在没校准罗盘的情况下开船。

先看nvidia-smi。它输出的不只是驱动版本号，更是当前 GPU 状态的“心跳报告”。执行后你会看到类似这样的片段：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.129.03 Driver Version: 535.129.03 CUDA Version: 12.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 NVIDIA RTX 4060 Ti Off | 00000000:01:00.0 On | N/A | | 35% 38C P0 12W / 160W | 245MiB / 8192MiB | 0% Default | +-------------------------------+----------------------+----------------------+

注意第二行：“Driver Version: 535.129.03” 和 “CUDA Version: 12.2”。这里的 “CUDA Version”不是指你本地装的 CUDA Toolkit 版本，而是指该驱动版本所宣称支持的最高 CUDA 主版本号。它由 NVIDIA 在驱动编译时硬编码进nvidia.ko模块，代表此驱动能稳定对接的 CUDA Runtime 最高兼容层级。比如 535.129.03 驱动支持 CUDA 12.2，意味着你装 CUDA 12.0、12.1、12.2 都没问题，但装 12.3 就可能触发 ABI 不匹配——因为 12.3 新增了某些驱动尚未实现的符号。

再看nvcc --version。它的输出是纯粹的 CUDA Toolkit 自报家门：

nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2023 NVIDIA Corporation Built on Mon_Aug_14_02:55:02_PDT_2023 Cuda compilation tools, release 12.2, V12.2.128

这里的关键是 “release 12.2” —— 它必须 ≤nvidia-smi显示的 CUDA Version（12.2 ≤ 12.2，OK）；同时，它还隐含一个前提：nvcc所链接的libcuda.so必须能被当前驱动正确加载。这个加载过程发生在nvcc启动时，它会尝试dlopen("/usr/lib/x86_64-linux-gnu/libcuda.so.1")，而该 so 文件又依赖/dev/nvidiactl设备节点和内核模块nvidia。如果驱动未加载或版本太低，nvcc会静默失败或报libcuda.so.1: cannot open shared object file。

最后是 Python 层的torch.version.cuda。它返回的是 PyTorch 编译时绑定的 CUDA Runtime 版本，而非当前系统实际可用的版本。执行：

import torch print(torch.version.cuda) # 输出 '12.1' print(torch.cuda.is_available()) # True or False

如果torch.version.cuda是 12.1，但nvcc --version是 12.2，nvidia-smi显示驱动支持 CUDA 12.2，那is_available()仍可能为 False——因为 PyTorch 的libtorch_cuda.so是在 12.1 环境下编译的，它内部硬链接了libcudart.so.12.1，而系统里只有libcudart.so.12.2。此时你需要要么重装匹配的 PyTorch（pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121），要么降级 CUDA Toolkit 到 12.1。

这三个命令构成一个三角验证闭环：

提示：不要相信nvidia-smi第二行的 “CUDA Version” 是你已安装的 CUDA 版本。它只是驱动的能力声明。真正装了什么，永远以nvcc --version和/usr/local/cuda/version.txt为准。

我曾在一个客户现场遇到离奇案例：nvidia-smi显示 Driver 525.85.12，CUDA Version 12.0；nvcc --version显示 12.0；但torch.cuda.is_available()为 False。排查发现/usr/lib/x86_64-linux-gnu/libcuda.so.1是软链接到/usr/lib/x86_64-linux-gnu/libcuda.so.1.1，而后者实际指向/usr/lib/nvidia-525/libcuda.so.1——但该文件权限为600，且属主是root:root，普通用户无法读取。chmod 644 /usr/lib/nvidia-525/libcuda.so.1后立即恢复正常。这种细节，没有任何官方文档会提，但它真实存在，且每天都在不同机器上重复发生。

3. 场景拆解：裸机、WSL2、Docker 三条轨道的安装逻辑与致命差异

安装 CUDA 和驱动，从来不是“下载 → 安装 → 完事”的线性流程。它是一场与操作系统内核、容器运行时、Windows 子系统深度耦合的协同作战。不同环境不仅步骤不同，其底层原理也截然相反。把裸机方案生搬硬套到 WSL2，就像给电动车装化油器——结构上就不兼容。

3.1 裸机 Linux（Ubuntu/Debian/CentOS）：驱动与 Toolkit 的双源管理

这是最“正统”但也最易翻车的场景。核心矛盾在于：驱动必须由系统包管理器（apt/yum）或 NVIDIA 官方 .run 脚本安装，而 CUDA Toolkit 既可通过包管理器安装，也可通过官网 run 文件安装，但二者版本必须严格对齐。

以 Ubuntu 24.04 为例，其默认 apt 源提供nvidia-driver-535包（版本 535.129.03），它支持 CUDA 12.2。但如果你直接sudo apt install nvidia-cuda-toolkit，装上的却是 CUDA 11.8（因为 Ubuntu 24.04 的nvidia-cuda-toolkit包仍基于旧版）。这就造成驱动（535）与 Toolkit（11.8）版本错配——虽然 535 驱动向下兼容 11.8，但你无法使用 CUDA 12.x 的新特性（如cudaMallocAsync），且nvcc编译的代码可能因 Runtime 版本过低而崩溃。

正确做法是放弃nvidia-cuda-toolkit包，改用 NVIDIA 官方 CUDA Toolkit run 文件，但必须确保其内置驱动组件被禁用：

# 1. 先确认当前驱动状态 nvidia-smi # 2. 下载 CUDA 12.2 Toolkit run 文件（注意：选择 "Linux > x86_64 > Ubuntu > 22.04 > runfile (local)"） wget https://developer.download.nvidia.com/compute/cuda/12.2.2/local_installers/cuda_12.2.2_535.104.05_linux.run # 3. 赋予执行权限并运行，关键：取消勾选 "NVIDIA Accelerated Graphics Driver" chmod +x cuda_12.2.2_535.104.05_linux.run sudo ./cuda_12.2.2_535.104.05_linux.run # 4. 安装完成后，手动添加环境变量 echo 'export PATH=/usr/local/cuda-12.2/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.2/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

为什么必须取消勾选驱动？因为nvidia-smi已证明系统驱动正常，强行覆盖会破坏现有图形会话（Xorg/Wayland），甚至导致黑屏。CUDA Toolkit run 文件中的驱动组件，仅用于无驱动环境的“一键安装”，在已有驱动的系统上，它只会带来冲突。

注意：Ubuntu 24.04 的nvidia-driver-535包实际版本是 535.129.03，而 CUDA 12.2.2 run 文件自带驱动是 535.104.05。二者虽同属 535 分支，但小版本号不同。官方明确说明：535.104.05 及以上均兼容 CUDA 12.2，因此无需担心。

3.2 WSL2（Windows Subsystem for Linux 2）：没有内核模块，只有用户态代理

这是近年最常被误解的场景。“WSL2 安装 CUDA” 的本质，是 Microsoft 与 NVIDIA 合作构建的一套用户态 GPU 虚拟化协议。它完全绕过了 Linux 内核模块加载流程——你在 WSL2 里执行lsmod | grep nvidia，永远为空；/dev/nvidia*设备节点也不存在。所有 GPU 调用，均由 WSL2 内置的wslg服务通过 Windows Host 的 NVIDIA 驱动转发。

因此，WSL2 下的安装逻辑是：

• Windows 端：必须安装支持 WSL2 的 NVIDIA 驱动（≥510.47.03，且需在 NVIDIA 控制面板中启用 “WSL” 选项）
• WSL2 端：无需安装任何.run驱动，只需安装nvidia-cuda-toolkit包或官方 CUDA Toolkit（推荐前者，因其专为 WSL2 优化）

实操步骤：

# 1. Windows 端：下载并安装最新 NVIDIA Game Ready 驱动（非 Studio 驱动！） # 安装时勾选 "NVIDIA Container Toolkit" 和 "WSL2 Support" # 2. WSL2 中（Ubuntu 22.04/24.04）： sudo apt update sudo apt install nvidia-cuda-toolkit # 3. 验证 nvidia-smi # 应显示 Windows Host 的 GPU 信息 nvcc --version # 应显示 CUDA 版本

关键点在于：nvidia-smi在 WSL2 中能工作，是因为它通过libcuda.so调用 WSL2 的libcuda.so代理库，后者再通过 IPC 向 Windows Host 发送请求。这个代理库由nvidia-cuda-toolkit包提供，它不包含内核模块，只提供用户态接口。

常见陷阱：有人试图在 WSL2 中运行cuda_12.2.2_535.104.05_linux.run并勾选驱动——这会导致nvidia-smi报错Failed to initialize NVML: Driver/library version mismatch，因为 WSL2 的libcuda.so期望连接 Windows Host 的驱动，而非自己装的假驱动。

3.3 Docker 容器：镜像层隔离与--gpus运行时注入

Docker 中的 CUDA 使用，本质是宿主机驱动能力的容器化透传。容器本身不装驱动，而是通过nvidia-container-runtime在启动时，将宿主机的/dev/nvidiactl、/dev/nvidia-uvm、/dev/nvidia0设备节点和/usr/lib/x86_64-linux-gnu/libcuda.so.1等文件挂载进容器，并设置LD_LIBRARY_PATH。

这意味着：

• 宿主机必须已正确安装 NVIDIA 驱动（nvidia-smi可用）
• Docker 必须配置nvidia-container-runtime（NVIDIA Container Toolkit）
• 容器镜像只需包含 CUDA Toolkit（如nvidia/cuda:12.2.2-devel-ubuntu22.04），无需驱动

配置步骤：

# 1. 宿主机安装 NVIDIA Container Toolkit # https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html # 2. 验证 runtime 是否注册 docker info | grep -i runtime # 3. 运行带 GPU 的容器 docker run --gpus all -it --rm nvidia/cuda:12.2.2-devel-ubuntu22.04 \ bash -c "nvidia-smi && nvcc --version"

这里--gpus all是关键开关，它触发nvidia-container-runtime的设备挂载逻辑。如果省略此参数，容器内nvidia-smi会报错NVIDIA-SMI has failed...，因为/dev/nvidiactl根本不存在。

提示：不要在 Dockerfile 中RUN apt install nvidia-driver-535！这不仅无效，还会污染镜像体积。驱动能力由宿主机和 runtime 提供，容器只负责消费。

4. 实战排错：从nvidia-smi报错到llama.cpp编译失败的全链路诊断法

当nvidia-smi报错、nvcc找不到、llama.cpp编译提示CUDA not found，别急着重装。这套诊断法我用了八年，覆盖 95% 的现场问题，核心是逆向追踪调用链：从最终失败点，一层层向上查依赖，直到定位第一个断裂环节。

4.1nvidia-smi报错：NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver

这是最底层的失败信号，意味着硬件抽象层已断开。按以下顺序排查：

Step 1：确认内核模块是否加载

lsmod | grep nvidia # 应输出类似： # nvidia_uvm 1269760 0 # nvidia_drm 61440 1 # nvidia 45060096 75 nvidia_uvm,nvidia_drm

如果无输出，说明驱动未加载。执行：

sudo modprobe nvidia sudo modprobe nvidia_modeset sudo modprobe nvidia_uvm sudo modprobe nvidia_drm

若报modprobe: FATAL: Module nvidia not found in directory /lib/modules/$(uname -r)，则是驱动未安装或内核版本不匹配（如升级内核后未重装驱动）。

Step 2：检查/dev/nvidia*设备节点

ls -l /dev/nvidia* # 应有： # crw-rw-rw- 1 root root 195, 0 Apr 1 10:00 /dev/nvidiactl # crw-rw-rw- 1 root root 195, 255 Apr 1 10:00 /dev/nvidia-uvm # crw-rw-rw- 1 root root 195, 254 Apr 1 10:00 /dev/nvidia-uvm-tools # crw-rw-rw- 1 root root 195, 1 Apr 1 10:00 /dev/nvidia0 # crw-rw-rw- 1 root root 195, 255 Apr 1 10:00 /dev/nvidia-modeset

如果缺失，执行：

sudo /usr/bin/nvidia-smi -c 0 # 重置持久模式 sudo /usr/bin/nvidia-modprobe -u -c=0 # 强制创建设备节点

Step 3：验证 Secure Boot 状态

mokutil --sb-state # 若输出 "SecureBoot enabled"，则需禁用或签名驱动模块 # 临时禁用（重启后生效）： sudo mokutil --disable-validation # 或永久禁用 BIOS 设置

Secure Boot 会阻止未签名的nvidia.ko模块加载，这是 Ubuntu 22.04+/24.04 的高频坑。

4.2nvcc --version报错：command not found或libcuda.so.1: cannot open shared object file

这属于开发链路中断。重点查PATH和LD_LIBRARY_PATH：

Step 1：确认 CUDA 安装路径

ls -l /usr/local/cuda* # 正常应有 /usr/local/cuda -> /usr/local/cuda-12.2 # 若只有 /usr/local/cuda-12.2 但无软链接，手动创建： sudo ln -sf /usr/local/cuda-12.2 /usr/local/cuda

Step 2：检查环境变量

echo $PATH | grep cuda echo $LD_LIBRARY_PATH | grep cuda # 若无输出，说明未 source 环境变量 source ~/.bashrc # 或 ~/.zshrc

Step 3：验证libcuda.so.1可达性

find /usr -name "libcuda.so.1" 2>/dev/null # 应返回 /usr/lib/x86_64-linux-gnu/libcuda.so.1 或 /usr/lib/nvidia-535/libcuda.so.1 # 若找不到，说明驱动安装不完整，重装驱动： sudo apt install --reinstall nvidia-driver-535

4.3llama.cpp编译失败：CUDA not found或nvcc fatal : Unsupported gpu architecture 'compute_86'

这是应用层典型问题，根源常在 CMake 配置：

Step 1：确认 CMake 能找到 CUDA

cd llama.cpp mkdir build && cd build cmake .. -DLLAMA_CUDA=on -DCMAKE_BUILD_TYPE=Release # 观察输出中是否有： # -- Found CUDA: /usr/local/cuda (found version "12.2") # -- CUDA Architecture: 86

若Found CUDA为NOTFOUND，说明 CMake 未识别 CUDA Toolkit。手动指定路径：

cmake .. -DLLAMA_CUDA=on -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.2/bin/nvcc \ -DCMAKE_CUDA_FLAGS="-gencode arch=compute_86,code=sm_86"

Step 2：解决架构不支持问题RTX 40 系列（Ada Lovelace）架构代号是sm_89，但llama.cpp默认只支持到sm_86（Ampere）。需手动添加：

cmake .. -DLLAMA_CUDA=on -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_CUDA_FLAGS="-gencode arch=compute_89,code=sm_89 -gencode arch=compute_86,code=sm_86"

否则nvcc会报Unsupported gpu architecture 'compute_86'（注意：错误信息可能误导，实际是compute_89未定义）。

经验：llama.cpp的CMakeLists.txt中set(CMAKE_CUDA_ARCHITECTURES "86")是硬编码。最稳妥方案是 fork 仓库，修改该行，或每次 cmake 时用-DCMAKE_CUDA_ARCHITECTURES="86;89"覆盖。

5. 多版本共存与动态切换：/usr/local/cuda软链接的艺术

生产环境中，常需同时维护 CUDA 11.8（适配旧版 TensorFlow）、CUDA 12.2（适配新版 PyTorch）、CUDA 12.4（适配最新 llama.cpp）。不可能每次切换都卸载重装——那会破坏依赖关系。真正的解决方案，是用软链接控制全局入口，用环境变量隔离局部路径。

5.1 目录结构规划：让每个版本自洽

安装多个 CUDA Toolkit 时，必须指定不同路径，避免覆盖：

# 安装 CUDA 11.8 到 /usr/local/cuda-11.8 sudo ./cuda_11.8.0_520.61.05_linux.run --silent --toolkit --toolkitpath=/usr/local/cuda-11.8 --override # 安装 CUDA 12.2 到 /usr/local/cuda-12.2 sudo ./cuda_12.2.2_535.104.05_linux.run --silent --toolkit --toolkitpath=/usr/local/cuda-12.2 --override # 安装 CUDA 12.4 到 /usr/local/cuda-12.4 sudo ./cuda_12.4.0_545.23.08_linux.run --silent --toolkit --toolkitpath=/usr/local/cuda-12.4 --override

此时目录结构为：

/usr/local/ ├── cuda-11.8/ ├── cuda-12.2/ ├── cuda-12.4/ └── cuda -> cuda-12.2 # 全局默认软链接

/usr/local/cuda这个软链接，就是你的“版本开关”。切换只需一行命令：

sudo rm -f /usr/local/cuda sudo ln -sf /usr/local/cuda-12.4 /usr/local/cuda

5.2 环境变量分层：项目级 vs 用户级 vs 系统级

全局软链接解决nvcc默认路径，但不同项目需绑定不同 CUDA 版本。这时用CUDA_HOME环境变量：

# 在项目根目录的 .env 文件中（使用 direnv 或手动 source） export CUDA_HOME=/usr/local/cuda-11.8 export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH # 在另一个项目的 .env 中 export CUDA_HOME=/usr/local/cuda-12.4 export PATH=$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH

nvcc会优先读取CUDA_HOME，而非/usr/local/cuda。PyTorch 的torch.cuda也会在初始化时检查CUDA_HOME下的lib64/libcudart.so。

5.3 驱动版本的终极兼容性：一张表看懂“我能装什么”

驱动版本决定了你能跑的最高 CUDA Toolkit 版本。这张表我整理自 NVIDIA 官方文档（CUDA Toolkit Release Notes），并标注了实际测试过的边界值：

关键结论：驱动版本只能向上兼容，不能向下兼容。装了 535 驱动，你可以自由选择 CUDA 11.8、12.0、12.2；但装了 470 驱动，你就永远无法使用 CUDA 12.x。因此，新购显卡后，第一件事不是装 CUDA，而是确认你能否升级到最新驱动——这决定了你未来三年的 CUDA 生态上限。

6. 终极验证：用deviceQuery和bandwidthTest真正确认 CUDA 是否“活”了

所有命令行检查都只是间接证据。真正的“活”，是 GPU 核心真正在执行计算任务。NVIDIA CUDA Samples 提供了两把黄金标尺：deviceQuery验证设备枚举与计算能力，bandwidthTest验证内存带宽与 PCIe 通信。

6.1 编译并运行deviceQuery

CUDA Samples 默认不安装，需手动编译：

# 进入 Samples 目录（通常在 /usr/local/cuda/samples） cd /usr/local/cuda/samples/1_Utilities/deviceQuery # 编译 sudo make # 运行 ./deviceQuery

成功输出应以Result = PASS结尾，并列出所有 GPU 的详细信息：

Detected 1 CUDA Capable device(s) Device 0: "NVIDIA GeForce RTX 4060 Ti" CUDA Driver Version / Runtime Version: 12.2 / 12.2 CUDA Capability Major/Minor version number: 8.6 Total global memory: 8192 MBytes ... Result = PASS

CUDA Capability 8.6表示 Ampere 架构（RTX 30 系列），8.9表示 Ada Lovelace（RTX 40 系列）。若此处报错cudaErrorInvalidValue或no CUDA-capable device is detected，说明驱动或 CUDA Toolkit 严重损坏。

6.2 运行bandwidthTest：测 PCIe 与显存带宽

cd /usr/local/cuda/samples/1_Utilities/bandwidthTest sudo make ./bandwidthTest

关键指标：

• Host to Device Bandwidth：PCIe 从 CPU 内存拷贝数据到 GPU 显存的速度。RTX 4060 Ti（PCIe 4.0 x16）应 ≥ 12 GB/s。
• Device to Host Bandwidth：GPU 显存拷贝回 CPU 内存的速度，同样应 ≥ 12 GB/s。
• Device to Device Bandwidth：GPU 显存内部拷贝速度，反映显存带宽，RTX 4060 Ti 应 ≥ 200 GB/s。

若Host to Device仅 1-2 GB/s，大概率是 PCIe 插槽未插满（如插在 PCIe 2.0 插槽）或 BIOS 中 PCIe 模式被设为 Gen2。

6.3 用nvidia-smi dmon实时监控 GPU 计算负载

这是最直观的“活”证据：

# 启动一个持续计算的任务（如 PyTorch 矩阵乘） python -c " import torch a = torch.randn(10000, 10000, device='cuda') b = torch.randn(10000, 10000, device='cuda') c = torch.mm(a, b) print('Done') " # 在另一终端实时监控 nvidia-smi dmon -s u -d 1

输出类似：

# gpu pwr temp utiliz memusag sm mem enc dec # Idx Watt C % MB % % % % 0 120 52 85 4200 85 72 0 0

utiliz列持续在 70-90%，memusag占用上升，sm（Streaming Multiprocessor）利用率同步飙升——这证明 CUDA Kernel 真正在 GPU 上执行，而非 fallback 到 CPU。

最后提醒：nvidia-smi的utilization是采样值，瞬时为 0 不代表没工作。真正要看的是dmon的连续波形，或nvidia-smi -l 1的滚动输出。我曾见过一个案例：nvidia-smi显示 GPU 0% 利用率，但dmon显示sm持续 95%，原因是nvidia-smi默认采样间隔 2 秒，而 Kernel 执行时间 < 1 秒，被漏掉了。所以，信dmon，不信nvidia-smi的单次快照。

至此，从驱动安装的底层原理，到多环境适配的实战路径，再到全链路排错