NVIDIA-Linux-x86_64-535.54.03.run和cuda_12.2.0_535.54.03_linux.run这两个文件放在同一个目录里说明你大概率正卡在驱动装哪个版本、CUDA 要不要自带驱动、装完能不能跑起来这一串问题上。这事在 Linux 上折腾过的人都懂文件名看着像双胞胎实际职责完全不同一个负责让显卡在内核里活着另一个负责让 nvcc、cuBLAS、cuDNN 这些库能编译出能跑的代码。选错顺序、装错组合最典型的结果就是终端里那行nvidia-smi has failed because it couldnt communicate with the nvidia driver然后你在搜索引擎里翻半小时也未必找得到根因。这篇东西我按自己的实操习惯拆开讲535.54.03 这个驱动版本和 CUDA 12.2.0 到底谁绑谁、下载环节怎么避免拿到半截文件那个经典的 gzip 报错、装之前系统要做哪些准备、runfile 方式一步步怎么走、以及出问题之后按什么顺序排。适合刚上手 Linux 显卡环境的新人也适合手上有几十台机器要批量落地、需要一个稳定基线版本的运维或者算法工程师。全程给命令、给参数、给理由不玩虚的。1. 先把这两个 .run 文件的身份认清楚1.1 版本号里的绑定关系比你想的更重要很多人盯着cuda_12.2.0_535.54.03_linux.run这个名字发懵中间那串535.54.03是干嘛的答案很直接——它就是 NVIDIA 给 CUDA 12.2.0 配套打包的驱动版本号。NVIDIA 每发布一个 CUDA Toolkit 大版本都会在官方测试矩阵里选一个驱动作为当时推荐搭配然后把驱动和 Toolkit 一起塞进同一个自解压包里方便那些从零开始装机器的用户一次搞定。但这不代表你必须用它。Linux 上的 NVIDIA 驱动和 CUDA 之间是向下兼容的只要驱动版本不低于某条线就能跑更高版本的 CUDA 运行时。以 CUDA 12.x 为例官方给出的最低驱动门槛大致是这样一条曲线各版本以官方 release notes 为准这里给的是我平时记的常用对照CUDA Toolkit最低驱动要求官方打包驱动11.8450.80.02520.61.0512.0525.60.13525.60.1312.1530.30.02530.30.0212.2535.54.03535.54.0312.3545.23.06545.23.0612.4550.54.14550.54.14看明白了就明白一件事你完全可以拿 535.54.03 去配 CUDA 12.2也可以拿它去配 12.0、12.1甚至更老的 11.8反过来装了个 525 的驱动却非要跑 CUDA 12.2那就是自找麻烦运行时会因为驱动 API 不够新直接报CUDA driver version is insufficient for CUDA runtime version。这条规则比任何教程都重要记住它能省掉一半的返工。1.2 535 这条线为什么单独被人拎出来说NVIDIA 的驱动分支里535 属于长期支持性质的版本线维护周期长、回归测试做得足很多行业软件和框架的兼容性列表都把它列为推荐基线。535.54.03 是这条线的早期版本发布于 CUDA 12.2 同期往后还有 535.86、535.104、535.129、535.154、535.161 等一串小版本更新多数是修 bug 和补新卡支持。它被频繁提及还有两个现实原因。一是离线环境友好一个.run文件拷过去就能装不需要联网拉一堆 deb 或 rpm 依赖二是版本可锁定发行版仓库里的nvidia-driver-535会随仓库更新漂移而.run文件你存哪个就是哪个三年后拿同一份文件还能复现出同一套环境。做算法复现、做产品出厂镜像、做实验室多机一致化部署的团队基本都会走这条路。代价当然也有.run方式安装的驱动不会自动跟着系统更新走内核一升级模块可能对不上得自己处理。这笔账后面第 5 节会详细算。1.3 两种安装路线的取舍逻辑Linux 上装 NVIDIA 驱动和 CUDA主流的就两条路。一条是走发行版包管理apt install nvidia-driver-535apt install cuda-toolkit-12-2或者加 NVIDIA 的官方仓库另一条就是本文主角 runfile。选哪条取决于你要解决什么问题我把判断依据整理成了一张表判断维度包管理器方式runfile 方式依赖处理自动手动需自己补 gcc/make/kernel-headers版本锁定随仓库漂移可指定小版本但受仓库保留策略影响完全锁定文件即版本离线部署需自建本地源或手工收集依赖一个文件搞定最省事内核升级适配DKMS 通常自动接管需确认安装时勾选了 DKMS 注册与系统 GL 库共存由发行版协调冲突较少需自己控制--no-opengl-files等参数卸载干净度包管理器卸载较干净用安装器自带--uninstall适合场景个人开发机、联网服务器离线机器、批量出货镜像、复现实验我的用法是在联网的日常开发机上直接 apt在需要给别人交付、或者机器根本不通外网的时候才用 runfile。这不是哪个更好的问题是哪个更贴合你手上的约束。2. 下载这一步踩的坑比安装还多2.1 从哪拿文件最稳两个文件都有官方固定路径这是长期有效的归档地址不是那种随页面改版就失效的链接# 驱动包535.54.03Linux x86_64 https://us.download.nvidia.com/XFree86/Linux-x86_64/535.54.03/NVIDIA-Linux-x86_64-535.54.03.run # CUDA 12.2.0 完整本地安装包 https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run驱动归档目录的规律是XFree86/Linux-x86_64/驱动版本/NVIDIA-Linux-x86_64-驱动版本.run想找 535 分支的其他小版本把路径里的版本号替换掉就行比如 535.161.07 就把三处都改掉。CUDA 那边同理compute/cuda/CUDA 版本/local_installers/下面放着这个版本所有形式的安装包包括.run、.deb (local)、.deb (network)、.rpm (local)、.rpm (network)。想知道有哪些历史版本去 CUDA Toolkit Archive 页面翻列表最直观。网络不理想的时候用 curl 或 wget 加断点续传比浏览器下载靠谱得多curl -C - -O https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run # 或者 wget -c https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run-C -和-c都是断点续传中断之后重跑不会从头来。CUDA 12.2 的完整包在 4 GB 量级驱动包在 300 MB 出头下到一半断掉是很常见的事续传能省不少时间。提示国内一些开源镜像站清华、阿里云等主要同步的是发行版软件仓库比如各类发行版的 baseos、extras、epel 目录方便你用apt/yum装包。CUDA 的.run大文件在官方站点上通常有本地节点可用速度往往比想象中好不必非要绕道第三方。如果确实需要走镜像源装驱动优先考虑发行版仓库里的nvidia-driver-535系列包而不是找第三方重打包的.run后者没人保证内容一致。2.2 文件大小和类型先比一遍下载完第一件事不是急着跑是确认文件完整。最省事的办法是看大小ls -lh NVIDIA-Linux-x86_64-535.54.03.run cuda_12.2.0_535.54.03_linux.run驱动包应该在 300 MB 以上CUDA 完整包应该在 4 GB 上下。如果看到的是几百 KB那基本可以确定你下到的是网页重定向内容或者一段错误提示而不是真正文件——用head -c 200 文件名看一眼如果开头是html或者!DOCTYPE就说明地址拿错了或者仓库挂了。更稳妥的做法是校验哈希。官方下载页会给对应文件的 md5下载完用md5sum cuda_12.2.0_535.54.03_linux.run对着官方值比一遍。别嫌麻烦我见过太多安装报错查两小时最后发现是下载中断导致包少了几百 MB的案例前面花十秒后面省两小时。2.3 gzip: stdin: invalid compressed data 到底怎么回事这个报错是搜索热词榜上的常客很多人一看就以为文件坏了其实要分两种情况。第一种情况你真的去用tar -xzf解它了。.run文件本质是一个自解压 shell 脚本结构是文件开头一段#!/bin/sh脚本用来打印协议、做校验、调用内嵌的 tar 数据真正的压缩数据从某个字节偏移之后才开始。你用tar -xzf xxx.run从第 0 字节开始解读到的全是 shell 脚本的文本gzip 当然认不出来于是报invalid compressed># 方式一直接执行安装 sh NVIDIA-Linux-x86_64-535.54.03.run # 方式二只解包不安装查看或提取内容 sh NVIDIA-Linux-x86_64-535.54.03.run --extract-only sh cuda_12.2.0_535.54.03_linux.run --extract/tmp/cuda-extract第二种情况文件传输过程中真的损坏了。这时候执行.run本身也会报类似的 gzip 错误或者报checksum不匹配。辨别方法看大小和 md5 就够了。触发原因通常是网络中断、磁盘写满df -h看一眼、或者下载途中经过了会做内容改写的中间设备。注意如果文件放在共享目录NFS、SMB上直接执行偶尔会因为文件锁或权限映射导致读取异常建议先拷到本地磁盘再跑安装。3. 装之前该做的系统准备别跳过3.1 屏蔽开源显卡驱动是硬性前提Linux 内核自带一个叫 nouveau 的开源 NVIDIA 驱动。它和 NVIDIA 官方闭源驱动抢同一块硬件只要 nouveau 还在加载官方驱动装完也起不来表现为nvidia-smi报通信失败、X 起不来、或者屏幕上直接花屏。所以安装前必须先把它按住。Debian/Ubuntu 系sudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF sudo update-initramfs -uRHEL/CentOS/Rocky 系sudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF sudo dracut --force改完重启然后验证lsmod | grep nouveau没有任何输出才算成功。如果还有一行说明屏蔽没生效检查文件路径拼写、确认执行了 initramfs 或 dracut 重建再重启一次。这一步偷懒的代价是后面所有步骤都白做。3.2 Secure Boot 是个绕不开的岔路口现在的服务器和笔记本默认开 UEFI Secure Boot。它的规则是内核只加载有签名的模块。NVIDIA 官方驱动编译出来的nvidia.ko是没签名的于是模块编译成功、加载却被拒绝dmesg里能看到module verification failed: signature and/or required key missing这类信息最终nvidia-smi依然报那句经典错误。先查状态mokutil --sb-state # 输出 SecureBoot enabled 或 SecureBoot disabled三条路可以选关闭 Secure Boot在 BIOS/UEFI 里改最省事实验室机器、内部服务器大多这么干。用 MOK 签名保留 Secure Boot安装器会提示你设置一个临时密码重启后进 MOK 管理界面导入密钥并签名模块。流程不难但每一步都不能错适合有合规要求的场景。用发行版预签名驱动也就是 apt 装nvidia-driver-535Ubuntu 官方仓库里的驱动是签过名的直接能加载代价是版本受仓库控制。我个人的选择是能关就关关不了就老老实实走 MOK签一次之后每次内核升级都会重新签不算麻烦。3.3 编译环境和内核头文件必须提前备好.run安装器在装驱动这一步会现场编译内核模块所以要 gcc、make、内核头文件三件套齐全。缺哪个都会在安装中途报Unable to find the kernel source tree或者cc: command not found。Ubuntu 22.04 上一句话sudo apt update sudo apt install -y build-essential dkms linux-headers-$(uname -r) pkg-config libglvnd-devRocky / AlmaLinux / CentOS Stream 上sudo dnf install -y gcc make kernel-devel-$(uname -r) kernel-headers-$(uname -r) dkms libglvnd-devel elfutils-libelf-devel这里有个坑要提醒kernel-devel的版本必须和uname -r完全一致不是接近就行。如果你刚刚升级了内核但没重启跑着的还是老内核而仓库里只有新内核的 devel 包就会对不上。解决办法是重启到目标内核或者显式装对应版本。用uname -r打印出来的字符串去匹配一个字符都不能差。3.4 离线机器怎么凑齐这些依赖不通外网的机器准备阶段先在有网的同类机器上把包下全。Debian 系用apt-get install --download-only把 deb 拉到缓存目录RHEL 系用dnf download或yumdownloader。拷过去以后# Debian/Ubuntu sudo dpkg -i /path/to/packages/*.deb sudo apt-get install -f # 补依赖如果本地源配了的话 # RHEL 系 sudo rpm -ivh /path/to/packages/*.rpm # 或者 sudo dnf localinstall /path/to/packages/*.rpm顺带说一句离线环境在准备kernel-devel时特别容易翻车因为不同内核小版本的包不能混用。我的经验是先把目标机器的uname -r记下来再去匹配同版本号的 devel 包同时把kernel-headers和dkms一起备上宁可多带不可少带。4. runfile 安装全流程实机记录4.1 安装驱动关图形界面再动手装驱动时不能在图形界面运行状态下进行安装器会自己检查并提示你。稳妥流程是先把系统切到多用户文本模式停掉显示管理器。# 切到文本目标 sudo systemctl isolate multi-user.target # 停掉常见的显示管理器之一按你系统实际装的选 sudo systemctl stop gdm3 # 或 sudo systemctl stop lightdm # 或 sudo systemctl stop sddm然后进安装器所在目录执行chmod x NVIDIA-Linux-x86_64-535.54.03.run sudo sh NVIDIA-Linux-x86_64-535.54.03.run交互过程里会依次问到是否接受协议、是否注册 DKMS、是否安装 32 位兼容库、是否更新 X 配置。DKMS 那一步记得选 Yes这是内核升级后能不能自动重建模块的关键很多人是装完之后才发现没勾等到内核一升就出问题。32 位库如果没有老程序需求可以不装能省几十 MB。全自动无人值守的话参数可以这么写sudo sh NVIDIA-Linux-x86_64-535.54.03.run \ --silent \ --dkms \ --disable-nouveau \ --no-x-check \ --no-cc-version-check常用参数的含义整理如下写脚本的时候按需组合参数作用什么时候用--silent静默安装不再交互批量部署、脚本化--dkms注册 DKMS内核升级自动重建模块长期运行的机器强烈建议--disable-nouveau尝试自动屏蔽 nouveau不想手写 blacklist 文件时--no-x-check跳过 X 服务运行检查远程 SSH 里安装没有图形环境--no-cc-version-check跳过编译器版本检查较老的系统 gcc 版本偏低时--kernel-module-typeproprietary使用闭源内核模块535 分支对部分老卡只支持闭源模块--no-opengl-files不安装 OpenGL 相关文件想保留系统自带 mesa、或有特殊 GL 需求时--no-nvidia-modprobe不创建 /dev/nvidia* 设备节点极少用特殊容器场景--uninstall卸载已安装驱动换版本前先清干净关于--no-opengl-files我多啰嗦两句。这个参数不是用了更好而是特定情况下必须用。如果你在笔记本双显卡环境、或者要保留系统 mesa 做软件渲染装了 NVIDIA 的 GL 库会打架。但如果是纯计算服务器、要跑 CUDA 和图形相关的推理可视化不加这个参数才正常。别照着某篇教程无脑抄。安装完第一时间验证nvidia-smi正常输出应该是一张表格左上角显示 Driver Version: 535.54.03CUDA Version: 12.2这个字段表示驱动支持的最高CUDA 运行时版本不代表你装了 CUDA 12.2。如果这里就报错别往下走了先看第 5 节。4.2 装 CUDA Toolkit别让它再装一遍驱动这是最容易翻车的一步。直接执行sudo sh cuda_12.2.0_535.54.03_linux.run文本交互界面出来之后会列出一堆可选项Driver、CUDA Toolkit 12.2、CUDA Samples 12.2、CUDA Demo Suite、CUDA Documentation。关键动作是把 Driver 前面的勾去掉按空格切换选中状态因为驱动你刚才已经装好了。如果忘了这一步安装器会问你检测到已安装驱动 535.54.03是否覆盖你手一抖确认了它就会用包内驱动覆盖一遍虽然版本号一样但可能把你之前的 DKMS 注册状态、X 配置搞乱。Silent 模式对应的命令sudo sh cuda_12.2.0_535.54.03_linux.run \ --silent \ --toolkit \ --toolkitpath/usr/local/cuda-12.2 \ --no-opengl-libs \ --override几个参数值得解释--toolkit只装 Toolkit不装驱动、不装 samples这是最干净的做法。--toolkitpath指定安装路径。默认是/usr/local/cuda-12.2建议保留这个命名习惯多版本共存时靠目录名区分。--no-opengl-libs不装 CUDA 自带的 OpenGL 头文件和库避免和驱动安装的 GL 文件冲突。--override跳过编译器版本检查。在 glibc 或 gcc 版本偏低的发行版上不加这个经常会看到unsupported GNU version之类的提示然后中断。装完之后安装器会打印一段摘要包括安装路径、日志位置、以及一句提示请把 PATH 和 LD_LIBRARY_PATH 加到环境变量。日志分别在/var/log/nvidia-installer.log驱动和/var/log/cuda-installer.logCUDA出问题第一件事就是翻这两个文件比在网上乱搜快得多。4.3 环境变量配置与版本验证配置写成全局 profile避免换个 shell 就找不到命令sudo tee /etc/profile.d/cuda-12.2.sh EOF export CUDA_HOME/usr/local/cuda-12.2 export PATH$CUDA_HOME/bin:$PATH export LD_LIBRARY_PATH$CUDA_HOME/lib64:$LD_LIBRARY_PATH EOF重新登录或者source /etc/profile.d/cuda-12.2.sh之后验证三件事# 1. 编译器版本 nvcc -V # 期望看到 release 12.2, V12.2.140 之类的字样 # 2. Toolkit 版本信息JSON 格式适合脚本解析 cat /usr/local/cuda-12.2/version.json # 3. 驱动与设备状态 nvidia-smi一个常见疑问nvcc -V显示的版本和你apt装的系统 nvcc 不一致怎么办。答案是谁在 PATH 前面谁生效。这就是为什么建议用绝对路径的CUDA_HOME显式管理不要让多个 nvcc 在同一台机器上打架。想确认 cuDNN 版本的话cuDNN 是单独下载的不在这两个.run里可以用cat /usr/local/cuda/include/cudnn_version.h | grep CUDNN_MAJOR -A 2老版本 cuDNN 是cudnn.h新版本拆成了cudnn_version.h找不到文件先换文件名试试。4.4 多版本 CUDA 共存怎么管同一台机器上同时存在 11.8 和 12.2 是家常便饭尤其是要复现别人的实验代码时。做法很简单每个版本装到自己的toolkitpath比如/usr/local/cuda-11.8和/usr/local/cuda-12.2然后用update-alternatives或者软链接切换。sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.2 122 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-11.8 118 sudo update-alternatives --config cuda这样/usr/local/cuda始终指向当前选中的版本profile 里只需要写这一层软链接切版本的时候一条命令搞定不用改任何环境变量文件。切换完记得开新终端或者重新 source已经跑着的 shell 里 PATH 是旧的。注意LD_LIBRARY_PATH的顺序会导致运行时链接到哪个libcudart.so出现差异尤其是用 Python 生态PyTorch、TensorFlow的时候pip 装的 wheel 自带 CUDA 运行时会和系统 CUDA 抢。排查这类问题时先python -c import torch; print(torch.version.cuda, torch.utils.cpp_extension.CUDA_HOME)看清楚它到底在用哪套。5. 报错速查与排查顺序5.1 nvidia-smi 通信失败这一类nvidia-smi has failed because it couldnt communicate with the nvidia driver. Make sure that the latest NVIDIA driver is installed and running.这句话几乎每个装过驱动的人都见过。它不是单一原因是一条因果链的终点。我习惯按下面顺序查从快到慢# 第一步内核里到底有没有 nvidia 模块 lsmod | grep nvidia # 第二步nouveau 有没有还占着 lsmod | grep nouveau # 第三步手动加载试试看报什么错 sudo modprobe nvidia # 第四步看内核日志里的拒绝原因 sudo dmesg | grep -i -E nvidia|nouveau|module verification # 第五步对比模块编译时的内核版本和当前内核版本 modinfo nvidia | grep vermagic uname -r按现象对照的速查表现象大概率原因处理方式lsmod里完全没有 nvidia模块没编译成功或没加载看/var/log/nvidia-installer.log重装驱动nouveau 仍在列表里屏蔽未生效检查 blacklist 文件、重建 initramfs、重启modprobe报Key was rejected by serviceSecure Boot 拦截未签名模块关 Secure Boot 或走 MOK 签名vermagic与uname -r不一致内核升级后模块未重建DKMS 重建或重装驱动dmesg报NVRM: API mismatch驱动版本与内核模块版本不一致卸载后统一重装nvidia-smi能跑但进程里无可见卡容器未透传设备或 cgroup 限制检查容器启动参数与设备节点这里面最隐蔽的是第二种和第四种。屏蔽 nouveau 之后忘了重建 initramfs重启后 nouveau 又回来了你会以为是驱动装坏了。内核升级导致 vermagic 不匹配更常见尤其在有自动更新的机器上某天早上开机就发现 GPU 用不了了就是这个原因。5.2 安装器自身报错的处理装驱动时可能碰到的几个高频报错以及我的应对ERROR: Unable to find the kernel source tree for the currently running kernel内核头文件缺失或版本不匹配。确认linux-headers-$(uname -r)装上了且uname -r和头文件包版本完全一致。ERROR: The Nouveau kernel driver is currently in use by your systemnouveau 没屏蔽掉回到 3.1 节重做重启。cc: command not found/No compiler found缺 build-essential 或者对应的 gcc 包。ERROR: An NVIDIA kernel module nvidia appears to already be loaded之前的驱动还在跑先--uninstall卸掉或者重启到文本模式再装。glxserver_nvidiafailed to load module这条在 Xorg 日志里出现通常是 GL 相关文件位置不对。如果驱动正常工作、nvidia-smi也正常这条在部分发行版上属于噪音如果伴随图形界面起不来就需要检查--no-opengl-files的选择是否正确以及libglvnd是否安装。cannot find a valid baseurl for repo这是包管理器源配置问题不是驱动问题但它会阻断你装kernel-devel这类依赖。先修好源检查/etc/yum.repos.d/下的 baseurl、确认系统版本与仓库路径匹配再回来装驱动。5.3 内核升级后的自动/手动修复DKMS 注册过的话正常情况内核升级后会自动触发模块重建你可以用下面命令确认状态dkms status # 期望看到类似nvidia/535.54.03, 内核版本, x86_64: installed如果显示built但不是installed或者干脆没有 nvidia 条目说明没接上。手动重建sudo dkms install -m nvidia -v 535.54.03 # 或者针对特定内核 sudo dkms install -m nvidia -v 535.54.03 -k $(uname -r)实在修不动的时候最干脆的办法是引导时在 GRUB 菜单里选旧内核启动然后重装一次驱动。所以我的习惯是机器上至少保留两个可用内核并且把能正常工作的那个写在 GRUB 里显眼位置。这个习惯救过我很多次。6. 几条实际用下来才明白的经验先说版本管理的心态。很多人一开始追求用最新版本肯定没错实际恰恰相反。CUDA 和驱动这对组合越新意味着周边的框架PyTorch、TensorFlow、vLLM 之类适配越滞后你很可能装完发现某个算子编译不过、某个库没有对应的预编译包。我自己的选择原则是优先选社区里被大量验证过的组合535.54.03 CUDA 12.2 就是这样一个组合几乎所有主流框架都有对应版本的支持矩阵踩坑信息也最多出问题好搜。再说安装方式的选择。如果机器能联网、你也不是要给别处交付镜像那真的没必要折腾.run。发行版仓库的nvidia-driver-535nvidia-cuda-toolkit或者 CUDA 官方仓库的cuda-toolkit-12-2配合apt upgrade和自动 DKMS日常维护成本低得多。runfile 的价值集中在三类场景完全离线的机器、需要精确锁定版本复现实验、批量出货的定制镜像。这三类之外它带来的只有维护负担。第三个体会是关于验证的。装完驱动和 CUDA 之后很多人到nvidia-smi能看到表格就收工了这是不够的。至少再跑两个验证一个是deviceQuery在 CUDA Samples 里或者用--samples装一份它会实际调用运行时 API 枚举设备、上报计算能力、内存规格另一个是nvcc编译一个 hello world 级别的 kernel 并运行。这两个都过了才算这套环境真的能用。中间任何一环报错都能定位到具体是哪一层的问题驱动层、运行时层还是编译层。最后分享一个我在批量部署里用的小脚本骨架。核心思路是先做前置检查再做安装最后自动验证任何一步失败就退出并打印日志位置别让它糊里糊涂装完。#!/bin/bash set -e DRVNVIDIA-Linux-x86_64-535.54.03.run CUDAcuda_12.2.0_535.54.03_linux.run LOG/var/log/gpu-setup.log echo [1/4] 检查依赖 | tee -a $LOG for c in gcc make dkms; do command -v $c /dev/null || { echo 缺少 $c; exit 1; } done [ -d /lib/modules/$(uname -r)/build ] || { echo 缺少内核头文件; exit 1; } echo [2/4] 屏蔽 nouveau | tee -a $LOG grep -q nouveau /etc/modprobe.d/blacklist-nouveau.conf 2/dev/null || \ printf blacklist nouveau\noptions nouveau modeset0\n | sudo tee /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u echo [3/4] 安装驱动 | tee -a $LOG sudo sh $DRV --silent --dkms --disable-nouveau --no-x-check --no-cc-version-check echo [4/4] 安装 CUDA Toolkit | tee -a $LOG sudo sh $CUDA --silent --toolkit --toolkitpath/usr/local/cuda-12.2 --no-opengl-libs --override nvidia-smi echo 驱动就绪 || { echo 驱动异常查看 $LOG 与 /var/log/nvidia-installer.log; exit 1; } /usr/local/cuda-12.2/bin/nvcc -V echo CUDA 就绪这个脚本需要重启后再跑驱动验证部分因为 nouveau 屏蔽要重启才彻底生效。所以更贴近实际的流程是脚本跑到第 2 步结束重启再跑第 3、4 步。写成两段比强求一段跑完更可靠。还有一点值得记下来把最终跑通的版本组合、uname -r输出的内核版本、nvidia-smi的完整输出、以及dkms status的结果存一份到项目文档里。半年后有人问你这台机器怎么装的或者你自己要复现同样的环境这份记录比任何记忆都值钱。我手上每台 GPU 机器的部署记录都是这么留下来的包括当时下载文件的 md5——因为两年后那个版本的官方链接可能已经挪位置了手里这份 md5 能证明我当时用的到底是哪份文件。