★ FEATURED ARTICLE 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.03nvcc -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-gpudriver_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-updatenvidia-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 Version12.2 ≤ 12.2OK同时它还隐含一个前提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.2nvidia-smi显示驱动支持 CUDA 12.2那is_available()仍可能为 False——因为 PyTorch 的libtorch_cuda.so是在 12.1 环境下编译的它内部硬链接了libcudart.so.12.1而系统里只有libcudart.so.12.2。此时你需要要么重装匹配的 PyTorchpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121要么降级 CUDA Toolkit 到 12.1。这三个命令构成一个三角验证闭环命令代表层级关键约束验证失败典型表现nvidia-smi硬件抽象层HAL驱动版本 ≥ CUDA Toolkit 所需最低驱动版本NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA drivernvcc --version开发工具链SDKCUDA Toolkit 主版本 ≤nvidia-smi显示的 CUDA Versionnvcc: command not found或libcuda.so.1: cannot open...torch.version.cudais_available()运行时库RuntimePyTorch 编译 CUDA 版本 系统libcudart.so.X.Y版本True但torch.cuda.device_count()返回 0或 kernel launch 报CUDA error: invalid device context提示不要相信nvidia-smi第二行的 “CUDA Version” 是你已安装的 CUDA 版本。它只是驱动的能力声明。真正装了什么永远以nvcc --version和/usr/local/cuda/version.txt为准。我曾在一个客户现场遇到离奇案例nvidia-smi显示 Driver 525.85.12CUDA Version 12.0nvcc --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 裸机 LinuxUbuntu/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与 Toolkit11.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 WSL2Windows 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-runtimeNVIDIA 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 couldnt 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 -c0 # 强制创建设备节点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_PATHStep 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/cudaStep 2检查环境变量echo $PATH | grep cuda echo $LD_LIBRARY_PATH | grep cuda # 若无输出说明未 source 环境变量 source ~/.bashrc # 或 ~/.zshrcStep 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-5354.3llama.cpp编译失败CUDA not found或nvcc fatal : Unsupported gpu architecture compute_86这是应用层典型问题根源常在 CMake 配置Step 1确认 CMake 能找到 CUDAcd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUDAon -DCMAKE_BUILD_TYPERelease # 观察输出中是否有 # -- Found CUDA: /usr/local/cuda (found version 12.2) # -- CUDA Architecture: 86若Found CUDA为NOTFOUND说明 CMake 未识别 CUDA Toolkit。手动指定路径cmake .. -DLLAMA_CUDAon -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CUDA_COMPILER/usr/local/cuda-12.2/bin/nvcc \ -DCMAKE_CUDA_FLAGS-gencode archcompute_86,codesm_86Step 2解决架构不支持问题RTX 40 系列Ada Lovelace架构代号是sm_89但llama.cpp默认只支持到sm_86Ampere。需手动添加cmake .. -DLLAMA_CUDAon -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CUDA_FLAGS-gencode archcompute_89,codesm_89 -gencode archcompute_86,codesm_86否则nvcc会报Unsupported gpu architecture compute_86注意错误信息可能误导实际是compute_89未定义。经验llama.cpp的CMakeLists.txt中set(CMAKE_CUDA_ARCHITECTURES 86)是硬编码。最稳妥方案是 fork 仓库修改该行或每次 cmake 时用-DCMAKE_CUDA_ARCHITECTURES86;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/cuda5.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_PATHnvcc会优先读取CUDA_HOME而非/usr/local/cuda。PyTorch 的torch.cuda也会在初始化时检查CUDA_HOME下的lib64/libcudart.so。5.3 驱动版本的终极兼容性一张表看懂“我能装什么”驱动版本决定了你能跑的最高 CUDA Toolkit 版本。这张表我整理自 NVIDIA 官方文档CUDA Toolkit Release Notes并标注了实际测试过的边界值NVIDIA 驱动版本支持最高 CUDA Toolkit实测兼容性备注典型适用显卡≥ 535.104.05CUDA 12.2535.129.03 在 RTX 4060 Ti 上完美运行 12.2.2RTX 40 系列、A100≥ 525.60.13CUDA 12.0525.85.12 在 RTX 3090 上支持 12.0.1但 12.1 需 ≥525.105.17RTX 30 系列、V100≥ 470.82.01CUDA 11.4470.141.03 在 GTX 1080 Ti 上稳定运行 11.4.411.5 需 ≥470.182.03GTX 10 系列、P100≥ 418.39CUDA 10.1418.116.00 是最后一个支持 CUDA 10.1 的驱动10.2 需 ≥440.33.01GTX 9xx、Tesla M40关键结论驱动版本只能向上兼容不能向下兼容。装了 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 编译并运行deviceQueryCUDA 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 PASSCUDA Capability 8.6表示 Ampere 架构RTX 30 系列8.9表示 Ada LovelaceRTX 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 BandwidthPCIe 从 CPU 内存拷贝数据到 GPU 显存的速度。RTX 4060 TiPCIe 4.0 x16应 ≥ 12 GB/s。Device to Host BandwidthGPU 显存拷贝回 CPU 内存的速度同样应 ≥ 12 GB/s。Device to Device BandwidthGPU 显存内部拷贝速度反映显存带宽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, devicecuda) b torch.randn(10000, 10000, devicecuda) 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 0utiliz列持续在 70-90%memusag占用上升smStreaming 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的单次快照。至此从驱动安装的底层原理到多环境适配的实战路径再到全链路排错
阅读完成 · 觉得有帮助？
