一台 2019 年前后的移动工作站丢到我手上显卡是 NVIDIA Quadro T1000系统是 Ubuntu 18.04.6 LTS。开机之后分辨率死死卡在 1024x768nvidia-smi报 command not foundlspci里那块卡挂着 nouveau 的名字在跑风扇还时不时抽风。这类场景我这些年处理过不少——Ubuntu 18.04 是个长寿版本很多工控机、车载标定平台、CAD 工作站至今还压在它上面而 NVIDIA 的显卡驱动安装从来不是一条命令能收尾的事。下面这篇东西我想把它写成一份能直接照着走完的记录Quadro T1000 这块卡在 Ubuntu 18.04 上为什么容易出问题、三条安装路线各自适合谁、装完之后那几个经典报错怎么一步步定位、以及长期挂着跑要怎么防止内核升级把驱动打飞。目标读者是刚拿到机器要把它调通的工程师也包括那些只想把 CUDA 环境跑起来、不打算深究显卡细节的同学。全文偏实操命令可以直接抄但每一步为什么这么做我都会讲清楚。1. Quadro T1000 在 Ubuntu 18.04 上到底卡在哪一环1.1 nouveau 与专有驱动的关系是理解一切报错的起点Ubuntu 18.04 装完之后默认加载的是开源驱动 nouveau。它由社区逆向实现能点亮屏幕、能输出一个基础分辨率但对 Turing 架构TU117这种相对新的核心支持是被动跟进的性能、电源管理、多屏输出都会打折扣nvidia-smi更是完全不认。你要装的那套 NVIDIA 官方驱动是二进制闭源的它和 nouveau 是互斥关系——同一时刻只能有一个占用这块卡。所以整个安装过程中最容易翻车的地方不是装不上去而是nouveau 没被彻底屏蔽装到一半又抢回了设备。我见过太多人执行完apt install nvidia-driver-xxx重启之后/var/log/Xorg.0.log里写的是(EE) NVIDIA: Failed to initialize the NVIDIA kernel module根因就是 nouveau 还在 initramfs 里躺着比 nvidia 模块先加载。判断当前状态只需要两条命令lspci -nnk | grep -A 3 -i vga\|3d lsmod | grep -E nouveau|nvidia前一条输出里的Kernel driver in use:会明确告诉你谁在管事是nouveau还是nvidia后一条看模块有没有真正挂载。这两条命令建议你在安装前后各跑一次形成对照比什么都直观。1.2 T1000 这块卡的定位决定了驱动版本不能乱选Quadro T1000 基于 Turing 的 TU117 核心896 个 CUDA 核心TDP 50W不需要外接供电常见于移动工作站和刀片式塔机。这块卡没有 RT CoreTensor Core 也欠奉T1000 属于 Turing 里被砍掉 Tensor Core 的型号之一但在 CAD、视频解码、多路相机采集这类任务上完全够用。问题出在时间上Ubuntu 18.04 的内核基线是 4.15后续 HWE 版本推到 5.4而 NVIDIA 新分支驱动535 及以后对内核和 GCC 的要求是被不断抬高的。你硬要在 5.4 内核 GCC 7.5 的 18.04 上装最新分支驱动nvidia-installer.log里会出现The kernel header file ... does not exist或者编译器版本相关的报错就算侥幸编过了也可能在加载阶段崩掉。我的经验是18.04 上 Quadro T1000 最舒服的落点是470 系列如 470.199.02、470.256.02 这类长期分支。470 对 Turing 全系支持完整对 4.15/5.4 内核都验证充分CUDA 版本对应到 11.4正好也是官方明确支持 Ubuntu 18.04 的末班车。如果你确实需要更新的 CUDA12.x那就该考虑升级系统而不是硬撑 18.04这个账要算清楚。1.3 三条安装路线的取舍先看结论再动手网上关于Ubuntu 安装 NVIDIA 显卡驱动的文章极多但大多数混着讲读者照着抄完也不知道自己走的哪条路。我把它们拆开路线适用场景优点主要风险apt 仓库 / PPA有网络机器要长期在线维护DKMS 自动跟随内核编译卸载干净依赖自动补齐可选版本受仓库限制18.04 的 PPA 分支上限大约到 470/495 区间官方 .run 安装包内网离线环境或要精确锁定某个版本版本绝对可控可选组件灵活内核升级后要手动重编卸载容易留残留文件CUDA 安装包内嵌的驱动想一口气把 CUDA 环境做完一次装完驱动 工具链会覆盖系统库与后续 apt 操作极易冲突我给绝大多数人的建议是走第一条除非你有明确的离线或版本锁定需求。原因很朴素显卡驱动的内核模块和内核版本是强绑定的用 apt 装会顺带装上nvidia-dkms-470将来apt upgrade把内核升到 5.4.0-xx 的时候DKMS 会自动帮你重新编译模块重启就恢复了。而 .run 装法没有这层保护内核一动nvidia-smi立刻挂掉必须手动重进 TTY 重新跑一遍安装器。2. 动手之前必须确认的四件事否则大概率要重装2.1 摸清机器的底内核、桌面、安全启动、显卡型号先把现场信息收集齐这一步花五分钟能省掉后面两小时的瞎折腾。uname -r # 内核版本后面装 headers 要用 lsb_release -a # 确认是 18.04.x echo $XDG_SESSION_TYPE # x11 还是 wayland mokutil --sb-state # SecureBoot 是否开启 lspci | grep -i nvidia # 显卡具体型号 dpkg -l | grep -i nvidia # 是否已经有残留的驱动包mokutil这条尤其重要。如果 Secure Boot 是 enabled那么 NVIDIA 编译出来的内核模块必须经过签名才能被内核加载。DKMS 方案在 apt 安装过程中会弹出一个蓝底的密码设置界面让你设置一个一次性密码重启后要在 MOK 管理界面里手动确认。这一步只要漏掉症状就是驱动明明装了lsmod里就是没有 nvidia很多人在这里卡一整天。2.2 屏蔽 nouveau 与关闭安全启动两件事一起做屏蔽 nouveau 的标准做法是写一个 modprobe 配置文件然后重建 initramfssudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF sudo update-initramfs -u重建 initramfs 是不能省的一步。原因在于早期启动阶段加载的模块来自 initramfs 镜像而不只是/lib/modules你只改配置文件不重建镜像等于没改。做完之后重启再用lsmod | grep nouveau验证应该什么都没有。提示如果你打算用官方 .run 安装包安装器自己也会往/etc/modprobe.d/里写一个nvidia-installer-disable-nouveau.conf。这两份文件不冲突但卸载的时候要记得一起清掉。Secure Boot 这边最省事的做法是进 BIOS 直接关掉。如果你的环境有合规要求不能关那就走 MOK 签名流程在 apt 安装时按提示设密码重启后选 Enroll MOK输入密码再 reboot 一次。两条路都能通但关掉能让后续所有操作顺滑很多。2.3 给自己留一条后路TTY、SSH 与救援模式装显卡驱动最坏的情况是图形界面起不来屏幕黑着或者卡在登录循环。这时候你必须能进系统否则就只能拿 U 盘重装了。三个后路建议都准备好TTY 切换Ctrl Alt F2到F6可以切到纯文本终端。前提是内核没崩、显卡还能输出基础画面nouveau 在位的时候一般可以。SSH 远程装驱动之前先在另一台机器上确认能 SSH 进来。图形界面挂了不影响 SSH这是最可靠的一条路。Live USB开机进 Live 环境挂载原系统根分区chroot 进去改配置。属于兜底手段希望用不上。顺手把重要文件备份一下。我在/etc/X11/、/etc/modprobe.d/这两个目录上做过快照事后回滚省了不少事sudo tar czf ~/x11-backup-$(date %F).tar.gz /etc/X11 /etc/modprobe.d /etc/default/grub2.4 把内核头文件和编译工具链先补齐apt 路线虽然会自动拉依赖但在内网、弱网环境下经常出现nvidia-dkms-470编译失败的情况报错就一句Error! Bad return status for module build on kernel让人摸不着头脑。根因几乎都是缺linux-headers。sudo apt update sudo apt install -y build-essential dkms linux-headers-$(uname -r)补一个细节linux-headers-$(uname -r)里的$(uname -r)必须和当前运行内核完全对应。如果你之前用apt upgrade升过内核但没重启uname -r拿到的还是旧版本号这时候该装的是linux-headers-generic这种跟随最新版的元包或者干脆先重启再装。这个坑我踩过不止一次。3. 三条路线的完整实操记录3.1 apt 路线大多数人的正确选择先把 PPA 加上。18.04 自带仓库里的驱动版本偏旧PPA 能拿到 470 系列的完整集合sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt update ubuntu-drivers devicesubuntu-drivers devices会列出所有可用驱动并标注recommended。这台机器上它给出的推荐就是nvidia-driver-470。你可以选择让它自动决定也可以手动指定版本——我更倾向手动指定因为我要确保版本可复现。sudo apt install -y nvidia-driver-470 sudo reboot安装过程中如果 Secure Boot 是开的会弹出 MOK 密码设置界面按前面说的流程处理。重启之后验证三件事nvidia-smi lsmod | grep nvidia glxinfo | grep OpenGL renderernvidia-smi应该输出一个表格右上角写着Driver Version: 470.xxx CUDA Version: 11.4。glxinfo需要先sudo apt install mesa-utils输出里应该是OpenGL renderer string: Quadro T1000/PCIe/SSE2如果写的是llvmpipe或者Software Rasterizer说明渲染还走在 CPU 上驱动没真正接管。3.2 离线场景apt 下载 .deb 再搬过去有些机器在内网、没有外网出口热词里离线安装 nvidia 显卡驱动也是高频需求。做法是在一台同版本、同架构、能联网的 18.04 机器上把包全部下载下来再拷过去。# 联网机器上执行 mkdir -p ~/nvidia-offline cd ~/nvidia-offline apt-get install --download-only -o Dir::Cache::archives$PWD -y nvidia-driver-470 # 目录里会出现一堆 .deb打包带走到目标机器上sudo dpkg -i *.deb sudo apt install -f # 补齐可能缺的依赖需要本地源或有缓存的仓库索引 sudo reboot这套流程的关键是两台机器的 Ubuntu 小版本、内核版本、架构必须一致。我遇到过 18.04.3 和 18.04.6 之间内核不同导致下载下来的nvidia-dkms-470依赖的linux-headers版本号对不上装到一半dpkg直接报依赖错误。稳妥做法是先在目标机器上跑uname -r再去联网机器上确认版本一致或者干脆把linux-headers-*的 deb 一起下下来。3.3 官方 .run 安装包参数逐个解释别照抄.run安装包适合离线和不信任仓库的场景但它的参数值得单独讲。先把下载好的文件赋予执行权限然后必须切到 TTY 并把图形界面停掉——这是硬性要求X Server 运行着的时候安装器无法替换正在使用的 GL 库。# Ctrl Alt F3 切到 TTY登录后执行 sudo systemctl stop gdm3 # 如果你的桌面是 lightdm就换成 lightdm sudo systemctl stop gdm # 18.04 上两种服务名都见过先 systemctl list-units 确认一下 cd ~/Downloads chmod x NVIDIA-Linux-x86_64-470.199.02.run sudo sh NVIDIA-Linux-x86_64-470.199.02.run \ --dkms \ --no-x-check \ --no-nouveau-check参数说明--dkms注册到 DKMS让内核升级时自动重编模块。不加这个内核一升驱动就废。--no-x-check跳过 X Server 运行检查。你已经在 TTY 里停掉了显示管理器但安装器有时会因为残留的 socket 误判加上这个更省心。--no-nouveau-check跳过 nouveau 检查。前提是你确认nouveau 已经被屏蔽并且没有加载否则加了它只是把错误延后到加载阶段。--no-opengl-files这个参数要慎重。它告诉安装器不要替换系统的 OpenGL 库。只有在一台同时有 Intel 核显和 NVIDIA 独显的笔记本上你想让桌面渲染继续由核显负责时才需要加。如果是纯 NVIDIA 输出的台式工作站加了它会导致 Xorg 找不到glxserver_nvidia之类的扩展模块图形界面直接起不来。我自己在这台 T1000 工作站上就没加因为它的显示输出完全走这块卡。另一个热词里提到的安装 3D Vision 卡住现象是安装器进度条停在Installing NVIDIA 3D Vision driver或者 32 位兼容库那一步不动。多数情况下不是真死而是安装器在后台等一个被日志刷屏盖过去的交互确认或者卡在 32 位库的下载上。处理方法sudo sh NVIDIA-Linux-x86_64-470.199.02.run \ --dkms --no-x-check --no-nouveau-check \ --no-install-compat32-libs \ --silent--no-install-compat32-libs跳过 32 位兼容库--silent让它彻底不交互。代价是日志要事后自己看sudo cat /var/log/nvidia-installer.log | tail -503.4 CUDA 自带的驱动我为什么不推荐一起装CUDA 的.run安装包里有一步会问你要不要装驱动默认是勾上的。我的建议是取消勾选。原因很简单CUDA 包里的驱动版本是它自己捆绑的、相对保守的版本而你系统上刚装好一套 apt 管理的 470两者混在一起libnvidia-ml.so、libcuda.so这类库会出现两套来源症状就是那个经典的Failed to initialize NVML: Driver/library version mismatch如果坚持要用 CUDA 自带驱动那就把 apt 装的那套彻底卸干净再装别混着来。要在 18.04 上用 CUDA我更推荐用网络 deb 包并且只装 toolkit不装驱动sudo apt install -y cuda-toolkit-11-4注意这里用的是cuda-toolkit-11-4而不是cuda。后者是元包会把驱动一起拉下来直接覆盖你现有环境。这个区别在 NVIDIA 官方文档里藏得很深但实操中非常关键。4. 装完之后必然遇到的那几个报错逐个拆4.1 nvidia-smi 报 couldnt communicate with the NVIDIA driver完整报错是NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.这句话本身没有信息量它只是用户态工具连不上内核态驱动的症状描述。真正的定位要靠下面四条lsmod | grep nvidia dmesg | grep -i -E nvidia|nvrm modinfo nvidia | grep vermagic cat /proc/driver/nvidia/version排查逻辑是这样的先看lsmod如果 nvidia 模块压根没加载问题出在模块加载环节nouveau 抢占、Secure Boot 拦截、模块编译失败如果加载了但nvidia-smi还是报错那就看dmesg里有没有NVRM: API mismatch那是内核模块和用户态库版本不一致。我整理了一份对照表遇到时按症状查现象根因处理lsmod无 nvidiadmesg无相关报错nouveau 仍在加载或模块装在错误内核下确认 nouveau 屏蔽并重建 initramfs检查modinfo的 vermagic 是否匹配uname -rdmesg出现Key was rejected by serviceSecure Boot 拒绝未签名模块关闭 Secure Boot或走 MOK 签名流程dmesg出现NVRM: API mismatch内核模块与用户态库版本不一致重启仍不行则彻底重装同版本驱动modinfo查不到 nvidiaDKMS 编译失败装linux-headers-$(uname -r)再看/var/lib/dkms/nvidia/*/build/make.loglsmod有 nvidia 但版本号诡异之前 .run 装的残留找到并清掉旧模块重新走一遍/var/lib/dkms/nvidia/470.xxx/build/make.log这个文件值得记住。DKMS 编译失败时apt只会给你一句含糊的提示真正的报错全在这个 log 里通常是缺头文件或者 GCC 版本不对。4.2 循环登录与黑屏从 Xorg 日志倒推现象是输入密码后屏幕一闪又回到登录界面或者干脆黑屏只有一个鼠标指针。这类问题的答案 90% 藏在 Xorg 日志里cat /var/log/Xorg.0.log | grep -E \(EE\)|\(WW\) | head -30 # 如果是 gdm 会话日志还可能在 cat ~/.local/share/xorg/Xorg.0.log | grep -E \(EE\)常见的几条错误和对应处理(EE) NVIDIA: Failed to initialize the NVIDIA kernel module内核模块没加载回到 4.1 的排查流程。(EE) Failed to load module glxserver_nvidiaGLX 扩展模块缺失或版本错配下一节展开讲。(WW) Unresolved symbol大量出现通常是残留的旧版本库文件在捣乱。还有一个极容易被忽略的坑~/.Xauthority的属主变成了 root。这通常是因为之前在黑屏状态下用sudo startx试图救场。修起来很简单sudo chown $USER:$USER ~/.Xauthority另外18.04 的 GDM 在某些 NVIDIA 驱动版本下会尝试用 Wayland 会话然后失败强制走 Xorg 能解决一大部分循环登录sudo tee -a /etc/gdm3/custom.conf EOF WaylandEnablefalse EOF sudo systemctl restart gdm34.3 glxserver_nvidia 加载失败到底怎么回事这条报错长这样[ 7.125] (EE) NVIDIA: Failed to load module glxserver_nvidia (module does not exist, 0)glxserver_nvidia是 NVIDIA 驱动提供的一个 Xorg 扩展模块负责把 OpenGL 请求路由到 GPU。它不存在或者版本不匹配说明用户态驱动文件装得不完整或者存在多份互相冲突的副本。先确认文件本身在不在ls -l /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so* dpkg -l | grep -i nvidia | awk {print $2} | sort如果文件在但加载失败多半是版本问题。检查一下有没有 .run 安装的残留库和 apt 装的库混在一起find /usr/lib /usr/lib/x86_64-linux-gnu -name libnvidia* -o -name libcuda* 2/dev/null | sort正常情况这些库都该由libnvidia-compute-470、libnvidia-gl-470等包管理dpkg -S能查出来归属。如果某个库查不到归属那它就是残留手动删掉后重装对应包sudo apt install --reinstall nvidia-driver-470 libnvidia-gl-470注意这个报错有时会出现在一切正常的系统上因为 Xorg 尝试加载多个版本的 GLX 模块第一个不存在就往下走。判断它是否致命要看后面有没有跟着(II) NVIDIA(0): ... GLX成功初始化的日志。别看到 EE 就慌。4.4 外接显示器、DP 固件与分辨率异常Quadro T1000 常见于多屏工作站场景接 DP 显示器时可能遇到开机时显示器无信号热插拔一下就好或者DP 1.3/1.4 高分屏点不亮的情况。NVIDIA 针对部分 Turing 卡发布过一个 DisplayPort 固件更新工具用于修复这类兼容性问题。我不建议无脑刷固件先确认现象nvidia-smi -q | grep -A 5 Display xrandr --listproviders xrandr --listmonitorsxrandr是排查分辨率问题的第一站。如果它列出的可用模式里没有你想要的 4K60可能是线材或显示器侧的 EDID 没被正确读取。这时候可以在nvidia-settings里手动配置或者用xrandr加自定义 modeline。关于 DP 固件流程是先确认自己的显卡型号在 NVIDIA 官方说明的受影响列表里再下载对应工具执行。我处理过的那台机器最终没刷固件问题出在一条劣质 DP 线换成原装线就正常了——这种时候先怀疑线材成本最低。5. 长期挂着跑内核升级、版本共存与干净回滚5.1 DKMS 是保护伞但也有失效的时候装了nvidia-dkms-470之后每次内核更新DKMS 都会触发一次模块重编。检查它的工作状态dkms status # 正常输出类似 # nvidia, 470.199.02, 5.4.0-150-generic, x86_64: installed # 手动触发重编内核换过但 DKMS 没跟上时用 sudo dkms autoinstall -k $(uname -r)DKMS 失效的典型场景是你升级了内核但新的linux-headers-5.4.0-xx没装上比如用了apt-get upgrade而不是dist-upgrade或者手动 hold 了 header 包。重启之后系统进新内核nvidia 模块对新内核来说是缺失的nvidia-smi直接罢工。处理方法有两个一是回退到旧内核启动装好 headers 再重编二是直接给新内核补装 headers然后dkms autoinstall。我遇到过更麻烦的一种内网机器根本装不了新 headers因为本地源里没有。这时候唯一的路是去 GRUB 里选旧内核启动或者用apt-mark hold linux-image-generic linux-headers-generic把内核钉在能用的版本上。5.2 用 apt-mark hold 锁住这套环境在一台生产用途的工作站上我最怕的是某天半夜自动更新把驱动顶掉第二天早上所有人对着黑屏发呆。防御手段是sudo apt-mark hold nvidia-driver-470 nvidia-dkms-470 \ libnvidia-compute-470 libnvidia-gl-470 nvidia-kernel-common-470 # 查看被 hold 的包 apt-mark showhold # 需要升级时解冻 sudo apt-mark unhold nvidia-driver-470要不要连内核一起 hold这是个权衡。锁了内核稳定性有保障但安全补丁跟不上不锁内核就得保证每次升级后都有人验证驱动还能不能起来。我的习惯是驱动包一律 hold内核交给 DKMS 处理但不做无人值守自动重启升级窗口由人守着。顺带提一下Ubuntu 18.04 的unattended-upgrades默认只处理安全更新一般不会动 PPA 装的驱动但如果你把驱动来源混用了比如部分包来自 PPA部分来自主仓库它可能只升级其中一部分导致版本错配。这也是我一再强调别混装的原因。5.3 彻底卸载apt 路线和 .run 路线完全不同apt 装的就用 apt 卸# 先列出来确认范围别一上来就通配 dpkg -l | grep -i nvidia sudo apt purge ^nvidia-.* ^libnvidia-.* sudo apt autoremove --purge sudo reboot用正则比用nvidia-*更安全因为 shell 通配符在某些 shell 下会展开成当前目录的文件名行为不可预期。执行完重启lsmod | grep nvidia应该干净lspci -nnk里的驱动会退回 nouveau。.run 装的要用它自己的卸载器sudo ./NVIDIA-Linux-x86_64-470.199.02.run --uninstall卸完还得手动清残留这几处是必查的ls /etc/modprobe.d/ | grep -i nvidia # nvidia-installer-disable-nouveau.conf ls /usr/lib/xorg/modules/extensions/ | grep -i glx ls /etc/X11/xorg.conf # nvidia-xconfig 生成的通常建议删掉顺便说一句nvidia-xconfig很多人教程里会让人跑这个命令生成/etc/X11/xorg.conf我不推荐除非你有明确的多屏布局需求。现代 Xorg 能自动识别 NVIDIA 驱动并生成合理配置手动生成的xorg.conf一旦写错比如忘记配 BusID就会直接导致图形界面起不来。我见过好几台机器的循环登录根因就是一份陈旧的xorg.conf。6. 实测表现与几个容易被忽略的调优点6.1 解码编码与 ffmpeg 硬件加速Quadro T1000 带独立的编解码单元实测用 ffmpeg 做硬件解码4K H.264 多路并发时 CPU 占用能从软解的接近满载降到个位数百分比。18.04 自带的 ffmpeg 是 3.4用法和新版本有区别这点要特别注意# 18.04 的 ffmpeg 3.4 语法 ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -c:v h264_nvenc \ -preset hq -rc vbr -cq 23 output.mp4 # 新版 ffmpeg4.x/5.x语法已经变成 # ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 ...-hwaccel cuvid和-c:v h264_cuvid是旧版本的写法网上大部分新教程都是-hwaccel cuda直接照抄在 18.04 上会报参数错误。这是我踩过的一个实实在在的坑。还有一个技术细节值得说明T1000 的 NVENC 单元是 TU117 上的较早版本H.264 编码完全没问题但 HEVC 的 B 帧支持就别指望了和同代高端卡不是同一规格。做视频转码方案设计的时候要把这点算进去别拿它去对标 RTX 系列的编码能力。验证硬件编解码是否真正生效看nvidia-smi dmonnvidia-smi dmon -s pucvmet -d 1跑转码任务的时候观察dec和enc两列有没有非零数值就是有没有真正用到硬件单元。如果一直是 0说明还是在 CPU 上跑这时候要回去看 ffmpeg 的编译选项和报错。6.2 无头场景persistence mode 与显存常驻如果是把这块卡用在无显示器的服务器场景采集、推理、渲染农场有两个调优点。第一是关掉图形界面省资源sudo systemctl set-default multi-user.target第二是打开 persistence mode避免驱动在没有任务时反复释放和重新初始化 GPU那会导致首次调用有几百毫秒的额外延迟sudo nvidia-smi -pm 1 sudo systemctl enable nvidia-persistencednvidia-persistenced是个常驻守护进程比手动nvidia-smi -pm 1更可靠因为重启之后前者会自动恢复设置后者不会。我在做多路相机采集的机器上两个都配了。6.3 几个用久了才会想到的小习惯装完之后立刻把nvidia-smi的完整输出存一份到文档里包括驱动版本、CUDA 版本、显存大小。将来出问题对比起来非常快nvidia-smi --query-gpuname,driver_version,memory.total,vbios_version \ --formatcsv ~/gpu-baseline-$(date %F).csv还有一条每次动显卡驱动之前先记录当前内核版本和驱动版本。我有个打油诗式的习惯动系统之前先跑这三条uname -r; nvidia-smi --query-gpudriver_version --formatcsv,noheader; dkms status三条输出拍张照出问题的时候就是最好的参照系。这个习惯帮我省下的时间比读十篇教程都多。最后说一个反直觉的点驱动装完之后如果nvidia-smi正常但glxinfo显示 llvmpipe别急着重装驱动先检查是不是prime-select选到了集显或者__GLX_VENDOR_LIBRARY_NAME这类环境变量被某个脚本改过。这类问题占我处理过的驱动装好了但界面很卡案例的三分之一真凶往往不在驱动本身。 Ubuntu 18.04 下 Quadro T1000 驱动安装与排障实录
一台 2019 年前后的移动工作站丢到我手上显卡是 NVIDIA Quadro T1000系统是 Ubuntu 18.04.6 LTS。开机之后分辨率死死卡在 1024x768nvidia-smi报 command not foundlspci里那块卡挂着 nouveau 的名字在跑风扇还时不时抽风。这类场景我这些年处理过不少——Ubuntu 18.04 是个长寿版本很多工控机、车载标定平台、CAD 工作站至今还压在它上面而 NVIDIA 的显卡驱动安装从来不是一条命令能收尾的事。下面这篇东西我想把它写成一份能直接照着走完的记录Quadro T1000 这块卡在 Ubuntu 18.04 上为什么容易出问题、三条安装路线各自适合谁、装完之后那几个经典报错怎么一步步定位、以及长期挂着跑要怎么防止内核升级把驱动打飞。目标读者是刚拿到机器要把它调通的工程师也包括那些只想把 CUDA 环境跑起来、不打算深究显卡细节的同学。全文偏实操命令可以直接抄但每一步为什么这么做我都会讲清楚。1. Quadro T1000 在 Ubuntu 18.04 上到底卡在哪一环1.1 nouveau 与专有驱动的关系是理解一切报错的起点Ubuntu 18.04 装完之后默认加载的是开源驱动 nouveau。它由社区逆向实现能点亮屏幕、能输出一个基础分辨率但对 Turing 架构TU117这种相对新的核心支持是被动跟进的性能、电源管理、多屏输出都会打折扣nvidia-smi更是完全不认。你要装的那套 NVIDIA 官方驱动是二进制闭源的它和 nouveau 是互斥关系——同一时刻只能有一个占用这块卡。所以整个安装过程中最容易翻车的地方不是装不上去而是nouveau 没被彻底屏蔽装到一半又抢回了设备。我见过太多人执行完apt install nvidia-driver-xxx重启之后/var/log/Xorg.0.log里写的是(EE) NVIDIA: Failed to initialize the NVIDIA kernel module根因就是 nouveau 还在 initramfs 里躺着比 nvidia 模块先加载。判断当前状态只需要两条命令lspci -nnk | grep -A 3 -i vga\|3d lsmod | grep -E nouveau|nvidia前一条输出里的Kernel driver in use:会明确告诉你谁在管事是nouveau还是nvidia后一条看模块有没有真正挂载。这两条命令建议你在安装前后各跑一次形成对照比什么都直观。1.2 T1000 这块卡的定位决定了驱动版本不能乱选Quadro T1000 基于 Turing 的 TU117 核心896 个 CUDA 核心TDP 50W不需要外接供电常见于移动工作站和刀片式塔机。这块卡没有 RT CoreTensor Core 也欠奉T1000 属于 Turing 里被砍掉 Tensor Core 的型号之一但在 CAD、视频解码、多路相机采集这类任务上完全够用。问题出在时间上Ubuntu 18.04 的内核基线是 4.15后续 HWE 版本推到 5.4而 NVIDIA 新分支驱动535 及以后对内核和 GCC 的要求是被不断抬高的。你硬要在 5.4 内核 GCC 7.5 的 18.04 上装最新分支驱动nvidia-installer.log里会出现The kernel header file ... does not exist或者编译器版本相关的报错就算侥幸编过了也可能在加载阶段崩掉。我的经验是18.04 上 Quadro T1000 最舒服的落点是470 系列如 470.199.02、470.256.02 这类长期分支。470 对 Turing 全系支持完整对 4.15/5.4 内核都验证充分CUDA 版本对应到 11.4正好也是官方明确支持 Ubuntu 18.04 的末班车。如果你确实需要更新的 CUDA12.x那就该考虑升级系统而不是硬撑 18.04这个账要算清楚。1.3 三条安装路线的取舍先看结论再动手网上关于Ubuntu 安装 NVIDIA 显卡驱动的文章极多但大多数混着讲读者照着抄完也不知道自己走的哪条路。我把它们拆开路线适用场景优点主要风险apt 仓库 / PPA有网络机器要长期在线维护DKMS 自动跟随内核编译卸载干净依赖自动补齐可选版本受仓库限制18.04 的 PPA 分支上限大约到 470/495 区间官方 .run 安装包内网离线环境或要精确锁定某个版本版本绝对可控可选组件灵活内核升级后要手动重编卸载容易留残留文件CUDA 安装包内嵌的驱动想一口气把 CUDA 环境做完一次装完驱动 工具链会覆盖系统库与后续 apt 操作极易冲突我给绝大多数人的建议是走第一条除非你有明确的离线或版本锁定需求。原因很朴素显卡驱动的内核模块和内核版本是强绑定的用 apt 装会顺带装上nvidia-dkms-470将来apt upgrade把内核升到 5.4.0-xx 的时候DKMS 会自动帮你重新编译模块重启就恢复了。而 .run 装法没有这层保护内核一动nvidia-smi立刻挂掉必须手动重进 TTY 重新跑一遍安装器。2. 动手之前必须确认的四件事否则大概率要重装2.1 摸清机器的底内核、桌面、安全启动、显卡型号先把现场信息收集齐这一步花五分钟能省掉后面两小时的瞎折腾。uname -r # 内核版本后面装 headers 要用 lsb_release -a # 确认是 18.04.x echo $XDG_SESSION_TYPE # x11 还是 wayland mokutil --sb-state # SecureBoot 是否开启 lspci | grep -i nvidia # 显卡具体型号 dpkg -l | grep -i nvidia # 是否已经有残留的驱动包mokutil这条尤其重要。如果 Secure Boot 是 enabled那么 NVIDIA 编译出来的内核模块必须经过签名才能被内核加载。DKMS 方案在 apt 安装过程中会弹出一个蓝底的密码设置界面让你设置一个一次性密码重启后要在 MOK 管理界面里手动确认。这一步只要漏掉症状就是驱动明明装了lsmod里就是没有 nvidia很多人在这里卡一整天。2.2 屏蔽 nouveau 与关闭安全启动两件事一起做屏蔽 nouveau 的标准做法是写一个 modprobe 配置文件然后重建 initramfssudo tee /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF sudo update-initramfs -u重建 initramfs 是不能省的一步。原因在于早期启动阶段加载的模块来自 initramfs 镜像而不只是/lib/modules你只改配置文件不重建镜像等于没改。做完之后重启再用lsmod | grep nouveau验证应该什么都没有。提示如果你打算用官方 .run 安装包安装器自己也会往/etc/modprobe.d/里写一个nvidia-installer-disable-nouveau.conf。这两份文件不冲突但卸载的时候要记得一起清掉。Secure Boot 这边最省事的做法是进 BIOS 直接关掉。如果你的环境有合规要求不能关那就走 MOK 签名流程在 apt 安装时按提示设密码重启后选 Enroll MOK输入密码再 reboot 一次。两条路都能通但关掉能让后续所有操作顺滑很多。2.3 给自己留一条后路TTY、SSH 与救援模式装显卡驱动最坏的情况是图形界面起不来屏幕黑着或者卡在登录循环。这时候你必须能进系统否则就只能拿 U 盘重装了。三个后路建议都准备好TTY 切换Ctrl Alt F2到F6可以切到纯文本终端。前提是内核没崩、显卡还能输出基础画面nouveau 在位的时候一般可以。SSH 远程装驱动之前先在另一台机器上确认能 SSH 进来。图形界面挂了不影响 SSH这是最可靠的一条路。Live USB开机进 Live 环境挂载原系统根分区chroot 进去改配置。属于兜底手段希望用不上。顺手把重要文件备份一下。我在/etc/X11/、/etc/modprobe.d/这两个目录上做过快照事后回滚省了不少事sudo tar czf ~/x11-backup-$(date %F).tar.gz /etc/X11 /etc/modprobe.d /etc/default/grub2.4 把内核头文件和编译工具链先补齐apt 路线虽然会自动拉依赖但在内网、弱网环境下经常出现nvidia-dkms-470编译失败的情况报错就一句Error! Bad return status for module build on kernel让人摸不着头脑。根因几乎都是缺linux-headers。sudo apt update sudo apt install -y build-essential dkms linux-headers-$(uname -r)补一个细节linux-headers-$(uname -r)里的$(uname -r)必须和当前运行内核完全对应。如果你之前用apt upgrade升过内核但没重启uname -r拿到的还是旧版本号这时候该装的是linux-headers-generic这种跟随最新版的元包或者干脆先重启再装。这个坑我踩过不止一次。3. 三条路线的完整实操记录3.1 apt 路线大多数人的正确选择先把 PPA 加上。18.04 自带仓库里的驱动版本偏旧PPA 能拿到 470 系列的完整集合sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt update ubuntu-drivers devicesubuntu-drivers devices会列出所有可用驱动并标注recommended。这台机器上它给出的推荐就是nvidia-driver-470。你可以选择让它自动决定也可以手动指定版本——我更倾向手动指定因为我要确保版本可复现。sudo apt install -y nvidia-driver-470 sudo reboot安装过程中如果 Secure Boot 是开的会弹出 MOK 密码设置界面按前面说的流程处理。重启之后验证三件事nvidia-smi lsmod | grep nvidia glxinfo | grep OpenGL renderernvidia-smi应该输出一个表格右上角写着Driver Version: 470.xxx CUDA Version: 11.4。glxinfo需要先sudo apt install mesa-utils输出里应该是OpenGL renderer string: Quadro T1000/PCIe/SSE2如果写的是llvmpipe或者Software Rasterizer说明渲染还走在 CPU 上驱动没真正接管。3.2 离线场景apt 下载 .deb 再搬过去有些机器在内网、没有外网出口热词里离线安装 nvidia 显卡驱动也是高频需求。做法是在一台同版本、同架构、能联网的 18.04 机器上把包全部下载下来再拷过去。# 联网机器上执行 mkdir -p ~/nvidia-offline cd ~/nvidia-offline apt-get install --download-only -o Dir::Cache::archives$PWD -y nvidia-driver-470 # 目录里会出现一堆 .deb打包带走到目标机器上sudo dpkg -i *.deb sudo apt install -f # 补齐可能缺的依赖需要本地源或有缓存的仓库索引 sudo reboot这套流程的关键是两台机器的 Ubuntu 小版本、内核版本、架构必须一致。我遇到过 18.04.3 和 18.04.6 之间内核不同导致下载下来的nvidia-dkms-470依赖的linux-headers版本号对不上装到一半dpkg直接报依赖错误。稳妥做法是先在目标机器上跑uname -r再去联网机器上确认版本一致或者干脆把linux-headers-*的 deb 一起下下来。3.3 官方 .run 安装包参数逐个解释别照抄.run安装包适合离线和不信任仓库的场景但它的参数值得单独讲。先把下载好的文件赋予执行权限然后必须切到 TTY 并把图形界面停掉——这是硬性要求X Server 运行着的时候安装器无法替换正在使用的 GL 库。# Ctrl Alt F3 切到 TTY登录后执行 sudo systemctl stop gdm3 # 如果你的桌面是 lightdm就换成 lightdm sudo systemctl stop gdm # 18.04 上两种服务名都见过先 systemctl list-units 确认一下 cd ~/Downloads chmod x NVIDIA-Linux-x86_64-470.199.02.run sudo sh NVIDIA-Linux-x86_64-470.199.02.run \ --dkms \ --no-x-check \ --no-nouveau-check参数说明--dkms注册到 DKMS让内核升级时自动重编模块。不加这个内核一升驱动就废。--no-x-check跳过 X Server 运行检查。你已经在 TTY 里停掉了显示管理器但安装器有时会因为残留的 socket 误判加上这个更省心。--no-nouveau-check跳过 nouveau 检查。前提是你确认nouveau 已经被屏蔽并且没有加载否则加了它只是把错误延后到加载阶段。--no-opengl-files这个参数要慎重。它告诉安装器不要替换系统的 OpenGL 库。只有在一台同时有 Intel 核显和 NVIDIA 独显的笔记本上你想让桌面渲染继续由核显负责时才需要加。如果是纯 NVIDIA 输出的台式工作站加了它会导致 Xorg 找不到glxserver_nvidia之类的扩展模块图形界面直接起不来。我自己在这台 T1000 工作站上就没加因为它的显示输出完全走这块卡。另一个热词里提到的安装 3D Vision 卡住现象是安装器进度条停在Installing NVIDIA 3D Vision driver或者 32 位兼容库那一步不动。多数情况下不是真死而是安装器在后台等一个被日志刷屏盖过去的交互确认或者卡在 32 位库的下载上。处理方法sudo sh NVIDIA-Linux-x86_64-470.199.02.run \ --dkms --no-x-check --no-nouveau-check \ --no-install-compat32-libs \ --silent--no-install-compat32-libs跳过 32 位兼容库--silent让它彻底不交互。代价是日志要事后自己看sudo cat /var/log/nvidia-installer.log | tail -503.4 CUDA 自带的驱动我为什么不推荐一起装CUDA 的.run安装包里有一步会问你要不要装驱动默认是勾上的。我的建议是取消勾选。原因很简单CUDA 包里的驱动版本是它自己捆绑的、相对保守的版本而你系统上刚装好一套 apt 管理的 470两者混在一起libnvidia-ml.so、libcuda.so这类库会出现两套来源症状就是那个经典的Failed to initialize NVML: Driver/library version mismatch如果坚持要用 CUDA 自带驱动那就把 apt 装的那套彻底卸干净再装别混着来。要在 18.04 上用 CUDA我更推荐用网络 deb 包并且只装 toolkit不装驱动sudo apt install -y cuda-toolkit-11-4注意这里用的是cuda-toolkit-11-4而不是cuda。后者是元包会把驱动一起拉下来直接覆盖你现有环境。这个区别在 NVIDIA 官方文档里藏得很深但实操中非常关键。4. 装完之后必然遇到的那几个报错逐个拆4.1 nvidia-smi 报 couldnt communicate with the NVIDIA driver完整报错是NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.这句话本身没有信息量它只是用户态工具连不上内核态驱动的症状描述。真正的定位要靠下面四条lsmod | grep nvidia dmesg | grep -i -E nvidia|nvrm modinfo nvidia | grep vermagic cat /proc/driver/nvidia/version排查逻辑是这样的先看lsmod如果 nvidia 模块压根没加载问题出在模块加载环节nouveau 抢占、Secure Boot 拦截、模块编译失败如果加载了但nvidia-smi还是报错那就看dmesg里有没有NVRM: API mismatch那是内核模块和用户态库版本不一致。我整理了一份对照表遇到时按症状查现象根因处理lsmod无 nvidiadmesg无相关报错nouveau 仍在加载或模块装在错误内核下确认 nouveau 屏蔽并重建 initramfs检查modinfo的 vermagic 是否匹配uname -rdmesg出现Key was rejected by serviceSecure Boot 拒绝未签名模块关闭 Secure Boot或走 MOK 签名流程dmesg出现NVRM: API mismatch内核模块与用户态库版本不一致重启仍不行则彻底重装同版本驱动modinfo查不到 nvidiaDKMS 编译失败装linux-headers-$(uname -r)再看/var/lib/dkms/nvidia/*/build/make.loglsmod有 nvidia 但版本号诡异之前 .run 装的残留找到并清掉旧模块重新走一遍/var/lib/dkms/nvidia/470.xxx/build/make.log这个文件值得记住。DKMS 编译失败时apt只会给你一句含糊的提示真正的报错全在这个 log 里通常是缺头文件或者 GCC 版本不对。4.2 循环登录与黑屏从 Xorg 日志倒推现象是输入密码后屏幕一闪又回到登录界面或者干脆黑屏只有一个鼠标指针。这类问题的答案 90% 藏在 Xorg 日志里cat /var/log/Xorg.0.log | grep -E \(EE\)|\(WW\) | head -30 # 如果是 gdm 会话日志还可能在 cat ~/.local/share/xorg/Xorg.0.log | grep -E \(EE\)常见的几条错误和对应处理(EE) NVIDIA: Failed to initialize the NVIDIA kernel module内核模块没加载回到 4.1 的排查流程。(EE) Failed to load module glxserver_nvidiaGLX 扩展模块缺失或版本错配下一节展开讲。(WW) Unresolved symbol大量出现通常是残留的旧版本库文件在捣乱。还有一个极容易被忽略的坑~/.Xauthority的属主变成了 root。这通常是因为之前在黑屏状态下用sudo startx试图救场。修起来很简单sudo chown $USER:$USER ~/.Xauthority另外18.04 的 GDM 在某些 NVIDIA 驱动版本下会尝试用 Wayland 会话然后失败强制走 Xorg 能解决一大部分循环登录sudo tee -a /etc/gdm3/custom.conf EOF WaylandEnablefalse EOF sudo systemctl restart gdm34.3 glxserver_nvidia 加载失败到底怎么回事这条报错长这样[ 7.125] (EE) NVIDIA: Failed to load module glxserver_nvidia (module does not exist, 0)glxserver_nvidia是 NVIDIA 驱动提供的一个 Xorg 扩展模块负责把 OpenGL 请求路由到 GPU。它不存在或者版本不匹配说明用户态驱动文件装得不完整或者存在多份互相冲突的副本。先确认文件本身在不在ls -l /usr/lib/xorg/modules/extensions/libglxserver_nvidia.so* dpkg -l | grep -i nvidia | awk {print $2} | sort如果文件在但加载失败多半是版本问题。检查一下有没有 .run 安装的残留库和 apt 装的库混在一起find /usr/lib /usr/lib/x86_64-linux-gnu -name libnvidia* -o -name libcuda* 2/dev/null | sort正常情况这些库都该由libnvidia-compute-470、libnvidia-gl-470等包管理dpkg -S能查出来归属。如果某个库查不到归属那它就是残留手动删掉后重装对应包sudo apt install --reinstall nvidia-driver-470 libnvidia-gl-470注意这个报错有时会出现在一切正常的系统上因为 Xorg 尝试加载多个版本的 GLX 模块第一个不存在就往下走。判断它是否致命要看后面有没有跟着(II) NVIDIA(0): ... GLX成功初始化的日志。别看到 EE 就慌。4.4 外接显示器、DP 固件与分辨率异常Quadro T1000 常见于多屏工作站场景接 DP 显示器时可能遇到开机时显示器无信号热插拔一下就好或者DP 1.3/1.4 高分屏点不亮的情况。NVIDIA 针对部分 Turing 卡发布过一个 DisplayPort 固件更新工具用于修复这类兼容性问题。我不建议无脑刷固件先确认现象nvidia-smi -q | grep -A 5 Display xrandr --listproviders xrandr --listmonitorsxrandr是排查分辨率问题的第一站。如果它列出的可用模式里没有你想要的 4K60可能是线材或显示器侧的 EDID 没被正确读取。这时候可以在nvidia-settings里手动配置或者用xrandr加自定义 modeline。关于 DP 固件流程是先确认自己的显卡型号在 NVIDIA 官方说明的受影响列表里再下载对应工具执行。我处理过的那台机器最终没刷固件问题出在一条劣质 DP 线换成原装线就正常了——这种时候先怀疑线材成本最低。5. 长期挂着跑内核升级、版本共存与干净回滚5.1 DKMS 是保护伞但也有失效的时候装了nvidia-dkms-470之后每次内核更新DKMS 都会触发一次模块重编。检查它的工作状态dkms status # 正常输出类似 # nvidia, 470.199.02, 5.4.0-150-generic, x86_64: installed # 手动触发重编内核换过但 DKMS 没跟上时用 sudo dkms autoinstall -k $(uname -r)DKMS 失效的典型场景是你升级了内核但新的linux-headers-5.4.0-xx没装上比如用了apt-get upgrade而不是dist-upgrade或者手动 hold 了 header 包。重启之后系统进新内核nvidia 模块对新内核来说是缺失的nvidia-smi直接罢工。处理方法有两个一是回退到旧内核启动装好 headers 再重编二是直接给新内核补装 headers然后dkms autoinstall。我遇到过更麻烦的一种内网机器根本装不了新 headers因为本地源里没有。这时候唯一的路是去 GRUB 里选旧内核启动或者用apt-mark hold linux-image-generic linux-headers-generic把内核钉在能用的版本上。5.2 用 apt-mark hold 锁住这套环境在一台生产用途的工作站上我最怕的是某天半夜自动更新把驱动顶掉第二天早上所有人对着黑屏发呆。防御手段是sudo apt-mark hold nvidia-driver-470 nvidia-dkms-470 \ libnvidia-compute-470 libnvidia-gl-470 nvidia-kernel-common-470 # 查看被 hold 的包 apt-mark showhold # 需要升级时解冻 sudo apt-mark unhold nvidia-driver-470要不要连内核一起 hold这是个权衡。锁了内核稳定性有保障但安全补丁跟不上不锁内核就得保证每次升级后都有人验证驱动还能不能起来。我的习惯是驱动包一律 hold内核交给 DKMS 处理但不做无人值守自动重启升级窗口由人守着。顺带提一下Ubuntu 18.04 的unattended-upgrades默认只处理安全更新一般不会动 PPA 装的驱动但如果你把驱动来源混用了比如部分包来自 PPA部分来自主仓库它可能只升级其中一部分导致版本错配。这也是我一再强调别混装的原因。5.3 彻底卸载apt 路线和 .run 路线完全不同apt 装的就用 apt 卸# 先列出来确认范围别一上来就通配 dpkg -l | grep -i nvidia sudo apt purge ^nvidia-.* ^libnvidia-.* sudo apt autoremove --purge sudo reboot用正则比用nvidia-*更安全因为 shell 通配符在某些 shell 下会展开成当前目录的文件名行为不可预期。执行完重启lsmod | grep nvidia应该干净lspci -nnk里的驱动会退回 nouveau。.run 装的要用它自己的卸载器sudo ./NVIDIA-Linux-x86_64-470.199.02.run --uninstall卸完还得手动清残留这几处是必查的ls /etc/modprobe.d/ | grep -i nvidia # nvidia-installer-disable-nouveau.conf ls /usr/lib/xorg/modules/extensions/ | grep -i glx ls /etc/X11/xorg.conf # nvidia-xconfig 生成的通常建议删掉顺便说一句nvidia-xconfig很多人教程里会让人跑这个命令生成/etc/X11/xorg.conf我不推荐除非你有明确的多屏布局需求。现代 Xorg 能自动识别 NVIDIA 驱动并生成合理配置手动生成的xorg.conf一旦写错比如忘记配 BusID就会直接导致图形界面起不来。我见过好几台机器的循环登录根因就是一份陈旧的xorg.conf。6. 实测表现与几个容易被忽略的调优点6.1 解码编码与 ffmpeg 硬件加速Quadro T1000 带独立的编解码单元实测用 ffmpeg 做硬件解码4K H.264 多路并发时 CPU 占用能从软解的接近满载降到个位数百分比。18.04 自带的 ffmpeg 是 3.4用法和新版本有区别这点要特别注意# 18.04 的 ffmpeg 3.4 语法 ffmpeg -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -c:v h264_nvenc \ -preset hq -rc vbr -cq 23 output.mp4 # 新版 ffmpeg4.x/5.x语法已经变成 # ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 ...-hwaccel cuvid和-c:v h264_cuvid是旧版本的写法网上大部分新教程都是-hwaccel cuda直接照抄在 18.04 上会报参数错误。这是我踩过的一个实实在在的坑。还有一个技术细节值得说明T1000 的 NVENC 单元是 TU117 上的较早版本H.264 编码完全没问题但 HEVC 的 B 帧支持就别指望了和同代高端卡不是同一规格。做视频转码方案设计的时候要把这点算进去别拿它去对标 RTX 系列的编码能力。验证硬件编解码是否真正生效看nvidia-smi dmonnvidia-smi dmon -s pucvmet -d 1跑转码任务的时候观察dec和enc两列有没有非零数值就是有没有真正用到硬件单元。如果一直是 0说明还是在 CPU 上跑这时候要回去看 ffmpeg 的编译选项和报错。6.2 无头场景persistence mode 与显存常驻如果是把这块卡用在无显示器的服务器场景采集、推理、渲染农场有两个调优点。第一是关掉图形界面省资源sudo systemctl set-default multi-user.target第二是打开 persistence mode避免驱动在没有任务时反复释放和重新初始化 GPU那会导致首次调用有几百毫秒的额外延迟sudo nvidia-smi -pm 1 sudo systemctl enable nvidia-persistencednvidia-persistenced是个常驻守护进程比手动nvidia-smi -pm 1更可靠因为重启之后前者会自动恢复设置后者不会。我在做多路相机采集的机器上两个都配了。6.3 几个用久了才会想到的小习惯装完之后立刻把nvidia-smi的完整输出存一份到文档里包括驱动版本、CUDA 版本、显存大小。将来出问题对比起来非常快nvidia-smi --query-gpuname,driver_version,memory.total,vbios_version \ --formatcsv ~/gpu-baseline-$(date %F).csv还有一条每次动显卡驱动之前先记录当前内核版本和驱动版本。我有个打油诗式的习惯动系统之前先跑这三条uname -r; nvidia-smi --query-gpudriver_version --formatcsv,noheader; dkms status三条输出拍张照出问题的时候就是最好的参照系。这个习惯帮我省下的时间比读十篇教程都多。最后说一个反直觉的点驱动装完之后如果nvidia-smi正常但glxinfo显示 llvmpipe别急着重装驱动先检查是不是prime-select选到了集显或者__GLX_VENDOR_LIBRARY_NAME这类环境变量被某个脚本改过。这类问题占我处理过的驱动装好了但界面很卡案例的三分之一真凶往往不在驱动本身。