企业官网建设流程全解析

简介：针对Ubuntu系统安装NVIDIA显卡驱动的常见痛点，这份PDF指南给出了清晰、可照做的解决路径，尤其适合初学者和需要手动安装驱动的用户。资源共1个文件，格式为PDF，包体仅489KB，内容紧凑、便于随时查阅。文档以GTX970M为例，完整覆盖从获取显卡型号、前往NVIDIA官网筛选兼容驱动版本，到通过PPA方式安装nvidia-384、重启后验证安装结果的全过程；同时针对安装报错、已有驱动冲突、nouveau占用等问题提供了排查建议，能有效降低循环登录等安装失败风险。该资料发布以来已有18858人学习下载，实用性已得到较多验证。对于在Ubuntu 16.04/17.10等版本上配置NVIDIA驱动的用户，这份资料可以作为简洁的起步参考，帮助节省搜索和踩坑时间。

1. 装 nvidia 驱动翻车的人，多半不是装不上，而是选错了“简单”的方向

在 Ubuntu 下装 nvidia 显卡驱动这件事，网上教程永远分成两派：一派让你去官网下 runfile 手动装，一派让你敲一串 apt 命令。我在某实验室帮同事装过的驱动，加起来超过两位数，得出的结论和标题一致——真正简单的方法，反而被大多数人忽略了。所谓“简单”，不是功能最全、也不是性能调得最狠，而是让你的机器从开机到跑起 CUDA 程序，全程不碰黑屏、不碰循环登录、不碰内核模块手工编译。这篇文章不会让你成为驱动编译专家，但会让你避开那些让新手翻车的深水区，用最不容易出错的方式把显卡驱动装好、装稳、装到能干活。适合谁？刚接触 Ubuntu、被驱动折腾过一次、以及网上教程看得越多越不知道选哪条路的人。

2. 三种安装方式对比：为什么“简单”两个字最容易被误解

2.1 nvidia 驱动在 Ubuntu 里的三种形态

如果你搜索过安装教程，会发现网上主流方案大致归为三类，我先把它们摆出来，后面所有操作都围绕这张表展开。

先说结论：绝大多数人应该选第一种或第二种，而不是 runfile。很多教程之所以推荐 runfile，是因为它的“可控性”最强，能指定某个 exact 版本、能加--no-opengl-files这类参数。但可控的另一面是，你需要自己面对内核头文件、gcc 版本、nouveau 冲突、Secure Boot 签名这些前置条件。每一样单独看都不难，叠在一起就是对耐心的极大考验。

我见过最典型的翻车现场：某开发者在官网下载了最新驱动，在 Ubuntu 桌面环境下直接sudo sh执行，跑到一半提示“The kernel module failed to build”。原因通常是内核头文件没装，或者 gcc 版本和内核编译时用的不一致。而图形界面的安装方式，本质上调用的还是 apt 仓库里的驱动包，这些包在打包时已经做过了大量兼容性测试，Ubuntu 的维护者替你挡住了大部分坑。

2.2 判断机器该走哪条路：先查硬件和现有驱动状态

不管是哪种方式，装之前先花五分钟把系统状态摸清楚，这五分钟能省下后面几小时。我会依次跑三条命令，把显卡型号、当前是否加载了开源驱动、以及系统推荐哪个版本这三个信息拿到手。

# 查看显卡硬件型号和 PCI 设备信息 lspci | grep -i nvidia # 查看当前是否已经加载了 nouveau（开源驱动）或 nvidia 闭源驱动 lsmod | grep -iE "nouveau|nvidia" # 查看 apt 仓库里有哪些 nvidia 驱动包以及系统推荐版本 ubuntu-drivers devices

先说第一条lspci | grep -i nvidia，它会输出一行类似VGA compatible controller: NVIDIA Corporation ...的信息，括号里的型号就是你的显卡。这个命令的作用是确认系统确实识别到了显卡，如果这条命令没有输出，说明显卡没插好、PCI 通道被占用，或者机器根本是双显卡且 nvidia 卡被屏蔽了。后两种情况先去 BIOS 里确认，暂不需要继续装驱动。

第二条lsmod | grep -iE "nouveau|nvidia"很关键。nouveau是 Linux 社区逆向工程出来的开源 nvidia 驱动，它和闭源驱动不能共存。如果这条命令输出了大量的nouveau字样，说明当前系统正在使用开源驱动，装闭源驱动前必须屏蔽它，否则两个驱动会抢设备，轻则装不上，重则开机黑屏。如果输出了nvidia字样，说明你已经装过驱动，这时候再装一次之前最好先卸载。

第三条ubuntu-drivers devices是核心中的核心。它会扫描你的显卡，然后列出 apt 仓库里所有可用的驱动版本，并标注哪一个是 recommended。我见过很多人在网上问“我该装 470 还是 525”，其实 Ubuntu 已经替你选好了，看 recommended 那一行就行。

2.3 内核模块是怎么被加载的

搞明白“装驱动”到底在装什么，能帮你理解后续每一步操作的目的。nvidia 显卡驱动不是一个普通的应用程序，它分成两部分：一部分是用户态的库，比如libnvidia-gl、libcuda.so，应用程序通过它们调用显卡能力；另一部分是内核模块，就是nvidia.ko这个文件，它负责和显卡硬件直接通信。

内核模块必须加载进内核里才能工作。每次开机时，系统会去/lib/modules/$(uname -r)/这个目录下找对应的.ko文件，然后通过modprobe nvidia之类的方式加载。这就是为什么“升级内核后驱动失效”几乎是必然事件——你的内核从 5.15 升到了 6.2，模块目录变了，原来编译好的nvidia.ko还在旧内核目录里，新内核里没有，自然就加载失败。

GPU 的工作方式也决定了驱动的特殊性。显卡不像硬盘或网卡那样有一个标准协议，每个型号的指令集都有差异，驱动必须针对具体型号做适配。这也就是为什么命令行安装时，包名里会带着分支号，比如 470、525 之类的。这些分支号对应的是不同的硬件代际。理解了这一层，你再去看那些“装完驱动重启黑屏”的帖子，就能很快定位到问题范围——要么是内核模块没编译成功，要么是模块和内核版本不匹配，要么是被开源驱动抢占了设备。

3. 用“软件和更新”装 nvidia 驱动：图形界面下最小的操作路径

3.1 先决条件：更新系统索引和确认 nouveau 状态

图形界面安装听起来是“点鼠标”，但点鼠标之前，我还是建议先打开终端做两件小事。第一件事是更新软件源索引，因为 apt 仓库里的驱动包列表是本地缓存的，不更新的话可能看不到最新版本，甚至可能因为索引太老而误装一个已经不被当前内核支持的驱动。

# 更新软件源索引，让 apt 认识最新的驱动包 sudo apt update # 顺便把系统已有的软件包升级一遍，避免依赖不匹配 sudo apt upgrade -y

第二件事就是重复上一节提到的lsmod检查。如果在输出里看到了nouveau，先不要急着进图形界面装驱动。你可以先看后面 5.1 节怎么屏蔽它，也可以直接往下走——图形界面的安装流程里，Ubuntu 的安装器会自动处理部分 nouveau 冲突，但为了获得最稳妥的结果，我习惯手动先把 nouveau 屏蔽掉。

需要说明的是sudo apt upgrade -y这一步不是必须的，但强烈建议。原因是 nvidia 驱动包对内核版本有依赖，旧内核上的驱动装完之后，一旦系统后续自动升级内核，驱动就可能失效。提前把系统升到当前版本，可以减少这种滞后性带来的麻烦。

3.2 打开 Additional Drivers 选对应版本

完成上面的准备后，按Super键打开活动概览，输入“software”会看到两个入口：一个是“Software Center”，另一个是“Software & Updates”。我们要进的是后者。进去之后切到“Additional Drivers”标签页，它会自动扫描硬件，几秒钟后列出可用的驱动列表。

这个列表长什么样？通常会有几项：nvidia-driver-XXX (proprietary, tested)、nvidia-driver-XXX-open (proprietary)、以及nouveau (open source)。我的建议是优先选“tested”字样的那一项，不要一上来就选 open 版本。-open后缀代表 NVIDIA 的开源内核模块，这玩意儿从某个版本之后性能已经追上了闭源模块，但兼容性历史更短，在 CUDA 生态里也偶尔有玄学问题。生产力环境我一般选“tested”。

选中后点击“Apply Changes”，系统会开始下载并安装。这个过程和你用apt install是一样的，但它会自动处理依赖，你不需要手动装nvidia-kernel-common或者dkms这些配套包。安装完成后它会提示重启。重启是整个流程里最容易让新手紧张的一步，但只要你前面没有跳过检查步骤，基本就是顺滑开机。

3.3 验证安装结果和重启后第一件事

重启后别急着跑任何程序，先打开终端验证三件事。第一件事是确认内核模块加载成功，第二件事是确认驱动和 CUDA 运行时能通信，第三件事是确认桌面会话还在正常跑。这三件事一条命令就能覆盖大部分：

# 查看 nvidia 驱动版本、CUDA 版本、显存占用和当前 GPU 进程 nvidia-smi # 如果 nvidia-smi 输出正常，再确认模块加载状态 lsmod | grep nvidia

nvidia-smi如果正常输出，你会看到驱动版本号、支持的 CUDA 版本，以及一张当前进程表。看到这些，你基本上可以放心了。如果这条命令报错NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，说明内核模块没有加载成功，不要慌，先跑lsmod | grep nvidia确认模块在不在。模块在但nvidia-smi失败，一般是设备节点权限问题；模块不在，就要回到后面的排查章节。

还有一个细节：重启后如果你发现桌面分辨率不正常，或者窗口卡顿，先不要急着判死刑。可能是因为驱动装好了，但显示服务器还没完全切到新驱动上，这时注销一次再登录，问题通常就消失了。

3.4 为什么这个方法对新手最友好

图形界面安装最大的价值，在于它替你把“依赖关系”这个黑匣子处理掉了。nvidia 驱动包在 Ubuntu 仓库里不是一个孤零零的二进制文件，而是一组包的集合：nvidia-driver-XXX会依赖nvidia-kernel-XXX、nvidia-utils-XXX、libnvidia-gl-XXX等。手动用 dpkg 或者 runfile 装的时候，漏掉任何一个包都可能导致编译失败或者运行报错。

另外，通过“软件和更新”安装时，Ubuntu 会自动启用 DKMS。这意味着以后你升级了内核，dkms会自动重新编译 nvidia 模块并放到新内核目录下。这是我推荐这个方案的核心原因——它让“驱动维护”这件事从手工劳动变成了自动化。我在某公司帮 A 同学处理过一次环境问题，他装的是官网 runfile，三个月后自己升了一次内核，重启后发现不仅显卡不工作了，连本地软件源的签名都乱了，最后花了整个下午才救回来。如果走图形界面这条路，那个下午本来可以省掉。

4. 命令行路线：apt 安装与 DKMS 在升级时的取舍

4.1 用 ubuntu-drivers 自动推荐版本

不是所有人都喜欢图形界面。有些人拿到的是无桌面版 Ubuntu Server，有些人需要通过 SSH 远程装驱动，还有些人就是习惯终端操作。这时候命令行安装就是主路。命令行安装的核心命令其实只有两条：

# 查看你的显卡和系统推荐的驱动包 ubuntu-drivers devices # 直接安装系统推荐的版本（推荐命名规则里带 recommended 标注） sudo ubuntu-drivers install

sudo ubuntu-drivers install做的事很简单：它把ubuntu-drivers devices里 marked as recommended 的包安装上。好处是你不用自己记包名，坏处是它装的永远是当前推荐版本，如果你需要特定分支（比如某个 CUDA 版本只支持特定驱动分支），就得自己指定包名。

指定包名的命令长这样，但记住，XXX要替换成你实际想装的版本号：

# 手动指定驱动分支安装，XXX 请替换为具体分支号 sudo apt install nvidia-driver-XXX

这里有个关键点：nvidia-driver-XXX是虚拟包，apt 会把它解析成一组具体的二进制包。所以不要担心自己只装了一个包不够，apt 会自动把nvidia-kernel-dkms、nvidia-utils-XXX、libnvidia-gl-XXX这些依赖一起拉下来。装完之后同样重启，重启后跑nvidia-smi验证，流程和图形界面方案一致。

4.2 手动指定驱动版本时怎么避免装错

手动指定版本常见于两种情况：一种是你有特定 CUDA 版本的要求，另一种是你查过 nvidia 官方文档，知道某个分支对你的显卡支持得最好。但手动指定也容易翻车，最常见的错误是随便选了一个最新分支，结果和显卡代际对不上。

怎么避免？有一个笨但可靠的办法：先看ubuntu-drivers devices的完整输出。如果你的显卡年代比较老，recommended 往往不是最新分支，而是停留在某个更稳定、驱动功能更匹配的版本上。比如某系列老卡，最新驱动分支已经停止支持了，Ubuntu 仓库里的 recommended 会帮你选到最后一个可用版本。

另外一个建议是安装前先查一下分支和显卡的支持矩阵。这种事可以在 nvidia 驱动发布说明里找到，打开搜索你的显卡型号，看它是否在 Supported Products 列表里。如果不在，就别装这个分支。这个步骤听起来繁琐，但实际上三分钟就能确认，却可以避免你重复经历“装完随机花屏”的折磨。

4.3 DKMS 是什么：内核升级后驱动不失效的关键

DKMS（Dynamic Kernel Module Support）值得单独拿出来讲，因为它决定了你的驱动在系统升级后面临什么命运。DKMS 的设计思路很简单：当你安装了某个内核模块时，它不会只把.ko文件放到当前内核目录，而是把模块源码存在/usr/src/下。以后每次系统安装新内核，DKMS 都会自动为新内核重新编译一份模块。

这意味着什么？意味着只要驱动的内核模块源码还在，内核从 5.15 升到 6.2，你的 nvidia 驱动也会在新内核里重新生成一份可加载的模块。这就是为什么 apt 安装的驱动在内核升级后通常还能正常工作，而官网 runfile 安装的驱动却经常失效——runfile 本质上不依赖 DKMS，它把模块编译好直接放进当时的内核目录里，新内核安装时它不会自动触发重建。

验证 DKMS 是否生效的命令：

# 查看 dkms 管理的模块列表和当前内核下的状态 dkms status

如果输出里能看到nvidia/XXX, 6.2.0-XX-generic, x86_64: installed这样的行，说明模块已经注册到 DKMS 里，并且为当前内核编译好了。如果你用 runfile 装驱动，dkms status很可能什么都不会显示，这也是判断当前驱动是 apt 装还是 runfile 装的快速方法之一。

4.4 从 runfile 切回 apt 版的后悔药

如果你已经用 runfile 方式装了驱动，现在想切回 apt 版，需要两步走。第一步是卸载现有驱动，第二步是清理残留文件。直接执行 apt 安装会让两个驱动打架，出现各种不可预料的符号冲突。

# 第一步：如果有 runfile 安装的驱动，用官方卸载脚本清除 sudo /usr/bin/nvidia-uninstall # 第二步：把 apt 历史遗留的 nvidia 包一起清掉（如果之前混装过） sudo apt purge nvidia-* # 第三步：清理完检查是否彻底，无输出代表干净了 lsmod | grep nvidia

执行完这三步之后，系统会回到没有闭源驱动的状态。此时如果你重启，Ubuntu 会自动加载 nouveau 开源驱动，桌面还能用。然后再按 4.1 节的sudo ubuntu-drivers install重新装，就能切到 apt 版了。这个“后悔药”的操作顺序很关键，先卸载再清理再重装，顺序错了容易留下libnvidia之类的残留库，导致新装的驱动调用到旧库，行为就会变得诡异。

5. 黑屏、循环登录、驱动失效：5 条高频踩坑与排查

5.1 开机黑屏：nouveau 没屏蔽的典型症状

现象：装完驱动重启，屏幕亮一下 Logo 就彻底黑了，或者卡在紫屏/黑屏界面不动，但机器好像还在运行，风扇在转。原因：nouveau 开源驱动和 nvidia 闭源驱动抢占了同一个设备，两个驱动都试图初始化显卡，最终导致显示输出失败。解决：进恢复模式，把 nouveau 屏蔽掉，再重新装驱动。

# 修改 modprobe 配置，把 nouveau 加入黑名单 sudo bash -c "echo 'blacklist nouveau' > /etc/modprobe.d/blacklist-nvidia-nouveau.conf" # 生成新的内核 initramfs，让黑名单在开机早期就生效 sudo update-initramfs -u # 移除已加载的 nouveau 模块（如果当前还加载着） sudo modprobe -r nouveau

我特别强调一下第二行update-initramfs -u。很多人只改黑名单文件不重建 initramfs，重启后发现一样黑屏，就是因为 initramfs 里已经把 nouveau 模块打包进去了，开机早期它还是会被加载。重建之后，nouveau 从启动一开始就不会被加载，闭源驱动才能独占设备。这个操作在图形界面安装和命令行安装之前做都可以，做了它，黑屏概率会大幅下降。

5.2 循环登录：驱动和显示管理器打架

现象：输入密码后屏幕闪一下，又回到登录界面，反复循环，进不了桌面。有的机器还能看到类似“/dev/nvidia0: No such file or directory”的报错写在某个日志里。原因：大部分情况是显示管理器（GDM/LightDM）启动时加载了 nvidia 模块失败，或者加载了不完整的 nvidia 库，导致 X server 崩溃重启。

解决路径分两步。先按Ctrl + Alt + F2切到纯命令行 TTY，登录后用下面命令查看 X server 日志里的关键错误：

# 查看 X server 日志里 nvidia 相关的报错，方便定位是哪个环节崩了 grep -iE "nvidia|drm|failed" /var/log/Xorg.0.log | tail -n 40

如果报错指向Failed to load module "nvidia"，说明内核模块和 X server 之间的层没对好。常见做法是重装一次nvidia-driver-XXX，同时确认配套的libnvidia-gl版本和驱动分支一致。如果报错指向No devices detected，则可能是 Secure Boot 把模块挡了，看 5.4 节的排查。这个问题的本质是驱动组件的版本一致性，图形界面安装不太容易触发，但手动指定分支安装时偶尔会遇到。

5.3 内核升级后 nvidia-smi 消失

现象：某次系统更新完之后，nvidia-smi报错，或者直接提示 command not found，lsmod | grep nvidia也没有任何输出。原因：内核升级了，新内核目录下没有编译好的 nvidia 模块，而驱动没有通过 DKMS 注册，所以系统不知道要为新内核重新编译。

解决：先确认当前驱动是不是 apt 版，如果是 apt 版但 DKMS 没生效，手动触发一次重建：

# 查看 dkms 状态，确认 nvidia 模块是否存在且已安装 dkms status # 如果模块存在但状态为 built 而不是 installed，手动安装到当前内核 sudo dkms install nvidia -k $(uname -r)

$(uname -r)会自动取出当前内核版本号，比如6.2.0-26-generic。这个命令会把已经编译过的模块注册到当前内核目录下。如果dkms status里根本没有 nvidia 的记录，那说明驱动不是 DKMS 方式装的，大概率是 runfile 装的老驱动。这时候要么重新跑一遍 runfile（安装器会为新内核重编），要么干脆按 4.4 节切到 apt 版，一劳永逸。

这个坑其实是最冤枉的，系统升级本来是好意，驱动却因此在重启后静默失效。自从我养成了装完驱动后顺手看一眼dkms status的习惯，就再没踩过这个坑。

5.4 Secure Boot 挡住模块加载

现象：装机时开启了 Secure Boot，驱动装完，重启后进系统一切正常，但nvidia-smi报Unable to determine the device handle，或者模块加载时提示Key was rejected by the kernel。原因：UEFI 安全启动只允许加载经过签名认证的内核模块，而 apt 仓库里的 nvidia 驱动模块默认不带有被主板信任的签名。

解决：最省事的办法是进 BIOS 关掉 Secure Boot。不过有些机器关闭后 Windows 引导可能会受影响，如果你双系统共存，更稳妥的做法是给模块签名。麻烦的是签名需要自己生成私钥并把公钥注册到主板，这个流程对新手很不友好，我一般建议：纯 Ubuntu 单系统就直接关 Secure Boot；双系统有顾虑的，检查mokutil --sb-state的状态，如果显示 enabled，再决定是否走注册流程。

# 检查 Secure Boot 当前状态 mokutil --sb-state

如果显示SecureBoot enabled，而你已经装好驱动但模块加载失败，最简单的路径是重启进入 BIOS 关闭它，然后回来执行sudo update-initramfs -u重建 initramfs。这不算投机取巧，Ubuntu 的第三方驱动在 Secure Boot 下本来就是一道附加题，普通开发环境没必要在这上面死磕。

5.5 PPA 和 runfile 混装的依赖混乱

现象：驱动装完，nvidia-smi能跑，但一运行 CUDA 程序就报libcuda.so.XXX: cannot open shared object file，或者提示driver version is insufficient。原因：系统中存在多个来源的 nvidia 库文件，比如你之前加过某个 PPA，后来又从官网装过 runfile，apt 的 dpkg 数据库里记录的是 PPA 的库，而运行时 load 的是 runfile 的库，两条链的版本不一致。

解决：把系统里所有 nvidia 相关的东西全部清理干净，然后只从单个来源安装。我的建议是统一走 apt，代码已经放在 4.4 节。这个坑的高发人群是喜欢“多教程交叉验证”的探索型用户——A 教程说加 PPA 能拿到新驱动，B 教程说官网 runfile 最原汁原味，两边都试一遍之后，系统自己都分不清该听谁的。

清理时有一个细节：sudo apt purge nvidia-*的通配符会把很多包一起删掉，但不会清理/usr/local/cuda里的内容。CUDA Toolkit 本身不建议通过 apt 卸载，它和驱动是两层东西。CUDA Toolkit 的影响面没那么大，但如果你之前手动把 toolkit 的libcuda.so链接到系统库目录里，那卸载驱动后这个链接会变成悬空，跑 CUDA 程序时的报错会很迷惑。所以我建议清理驱动后，检查一下/usr/lib/x86_64-linux-gnu/下是否有遗留的libcuda.so*软链接，有就用sudo rm清掉，避免后续误用。

6. 从“装上”到“跑满”：验证性能与固化一个验证习惯

6.1 nvidia-smi 的完整用法

大多数人验证驱动就是跑一下nvidia-smi，看到版本信息就关机走人。这个习惯不算错，但不够。nvidia-smi最值钱的参数是-l，它可以每间隔几秒刷新一次实时状态，让你在跑负载时直接看到 GPU 利用率、显存占用、温度和功耗的变化。

# 每 2 秒刷新一次 GPU 状态，适合跑程序时实时观察 nvidia-smi -l 2 # 和系统监控合流，查询完整 JSON 格式的状态信息，方便写脚本解析 nvidia-smi --query-gpu=utilization.gpu,memory.used,temperature.gpu --format=csv

第一条命令适合人肉观察，第二条适合写进监控脚本。我一般会在跑模型训练或者渲染任务时挂一个终端窗口执行nvidia-smi -l 2，一旦发现某个进程把显存占满但 GPU 利用率只有个位数，就能立刻意识到程序可能没有真正用到显卡算力，而是把数据搬运卡在了 CPU 侧。

6.2 负载是否真正落到 GPU 上

驱动装好了，不代表你的程序一定在用 GPU。有个快速验证方法：用一个带 GPU 加速的矩阵运算库跑一次较大规模的计算，同时观察 GPU 利用率。在 Python 里可以这样验证：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) a = torch.randn(4096, 4096, device="cuda") b = torch.randn(4096, 4096, device="cuda") for _ in range(10): c = a @ b torch.cuda.synchronize() print("GPU compute check passed")

这段代码先确认 CUDA 可用，再在 GPU 上做矩阵乘法。跑这段代码的时候，另一侧开着nvidia-smi -l 1，如果能看到 utilization 跳到 90% 以上，说明驱动和 CUDA 运行时之间整条链路是通的。如果torch.cuda.is_available()返回False，但nvidia-smi正常，问题大概率出在 CUDA Toolkit 版本和驱动分支不匹配，需要去核对分支支持矩阵，而不是怀疑驱动装坏了。

6.3 把验证装进肌肉记忆

最后分享一个我踩过无数次坑后形成的习惯：每次升级内核后，重启完干的第一件事不是打开浏览器、不是启动开发环境，而是跑一条dkms status加一条nvidia-smi。这两条命令加起来不到五秒钟，但它们能在我开始工作前就把“驱动是否还活着”这个不确定性清零。

有一次我升级完内核后忘了验证，直接启动训练任务，跑了二十分钟才发现程序一直在 CPU 上跑，浪费时间不说，机器温度还莫名升高。后来我把这两条命令写成了一个 shell 函数，登录终端后敲两个字就能触发检查。自那以后，驱动失效变成了一件“开机后立刻知道”的事，而不是“程序跑到一半才发现”的事。

我给这个方案的评价是：如果你使用 Ubuntu 的场景是深度学习、视频编解码或日常 GPU 计算，那么图形界面或 apt 路线已经覆盖了绝大部分需求。官网 runfile 留给那些需要特定分支、或者在做驱动定制的人就好，普通人用它只会增加维护成本。希望这篇文章帮你把驱动这件事从“玄学”变成“日常操作”，装一次就安稳用下去。

本文还有配套的精品资源，点击获取