Arch Linux GPU驱动配置指南：NVIDIA/AMD安装与故障排查完全手册

说到 Arch Linux 上的 GPU 驱动，我估计每个折腾过的人都有一段“不堪回首”的经历。网上教程一大堆，但多半是复制粘贴的旧方案，照着做经常把系统搞到进不了桌面。我自己从最早的 nouveau 开源驱动一路折腾到现在的 nvidia-dkms + amdgpu 混合方案，踩坑无数，今天把这几年攒下的经验梳理成一篇完整的配置文档，希望能帮后来的朋友少走点弯路。

这篇内容适合谁看？刚把 Arch 装好、正准备给自己的 NVIDIA 或 AMD 显卡装驱动的用户；已经装好但经常遇到黑屏、驱动崩溃、内核升级后进不去桌面的用户；以及想在 Arch 上跑 CUDA、PyTorch、大模型推理的朋友。我把安装步骤、原理、坑点、排查思路全部拆开讲。

开始之前先说一句：Arch 是滚动发行版，内核和驱动都在不停更新，所以驱动配置从来不是“一次配置、一劳永逸”的事，但理解了底层逻辑之后，再遇到问题就不慌了。下面直接进入正题。

1. 动手前的准备：先搞清楚自己是什么显卡

1.1 查看显卡型号与当前使用的驱动

无论你想干什么，第一步永远是确认自己手上的硬件是什么。这一步看起来简单，但很多人跳过之后，装完驱动发现没生效，然后又回来查，反而浪费时间。

在终端里执行：

bash复制lspci | grep -E "VGA|3D"

这会列出所有显卡设备。输出里一般能看到厂商和型号，比如 NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] 或者 Advanced Micro Devices, Inc. [AMD/ATI] Navi 23。如果是笔记本，通常能看到两个设备，一个 Intel 核显（或者 AMD APU）加一个 NVIDIA / AMD 独显。

接着可以看当前内核已经给这个设备加载了哪个驱动模块：

bash复制lspci -k | grep -A 2 -E "VGA|3D"

输出中的 Kernel driver in use: nvidia 或 amdgpu 会直接告诉你现在用的是哪套驱动。如果你刚装完系统还没装任何闭源驱动，NVIDIA 显卡大概率显示的是 nouveau，AMD 显卡显示的则是 amdgpu 或 radeon。

对 NVIDIA 用户来说，这一步很重要，因为后面我们要把 nouveau 列入黑名单，必须先确认它是当前加载的模块再动手。

1.2 三大厂商驱动方案的底层差异

读懂三种驱动方案的区别，是后面所有操作的基础。

NVIDIA 官方只维护闭源驱动，内核模块需要每年跟上内核版本。Arch 的官方仓库里有 nvidia、nvidia-lts、nvidia-dkms 三个包，分别对应不同内核的预编译版本和带有 DKMS 机制的源码版本。nouveau 是社区逆向工程的开源驱动，能点亮屏幕，但性能差、功耗高、不支持新特性，实际使用基本只有应急价值。

AMD 的情况好很多。GPU 的内核驱动 amdgpu 直接编译在内核源码树里，只要你的内核版本不是太老，硬件不是太冷门，开箱就能用。用户态的部分靠 mesa 提供 OpenGL，vulkan-radeon 提供 Vulkan，本质上由同一个开源项目组维护，升级非常顺滑。

Intel 核显跟 AMD 类似，内核自带 i915 驱动（新的 Xe 架构用 xe），配合 mesa 即可。唯一需要额外装的是视频编解码的固件和用户态库，也就是 intel-media-driver。

搞清楚这些背景之后，安装选择的方向基本就定了：NVIDIA 用户装闭源驱动，AMD 和 Intel 用户保证内核、固件、mesa 三件套齐全即可。

1.3 安装前需要准备的软件包

不管哪家显卡，我建议先把基础工具装上：

bash复制sudo pacman -S base-devel linux-headers mesa-utils vulkan-tools

• linux-headers 是 DKMS 编译内核模块必须的，后面会反复用到。
• mesa-utils 提供 glxinfo，用来验证 OpenGL 渲染是否真的走了独立显卡。
• vulkan-tools 提供 vulkaninfo，验证 Vulkan 支持。

这里有个细节：如果你用的不是默认内核，而是 linux-lts 或者自己编译的内核，要装对应的头文件包，比如 linux-lts-headers。安装错了，DKMS 会直接编译报错，报错信息还很抽象，新手根本看不懂。

2. NVIDIA 闭源驱动安装与配置

2.1 选对包：nvidia、nvidia-lts 还是 nvidia-dkms

Arch 官方仓库里 NVIDIA 驱动包有四个相关选择：

我自己现在用的是 nvidia-dkms，原因很简单：Arch 上很多人会同时装 linux 和 linux-lts 两个内核作为保险，万一主内核出问题还能切到 LTS。这种情况下，nvidia 只能照顾一个内核，每次装新内核都得手动换包。DKMS 则会在内核升级时自动把模块编译好，省心。

如果你确定自己永远只用一个默认内核，装 nvidia 最省事，不用自己编译，装的也快。用下面的命令安装：

bash复制# 方案一：默认内核，预编译
sudo pacman -S nvidia nvidia-utils

# 方案二：DKMS 方式，适合多内核或自定义内核
sudo pacman -S nvidia-dkms nvidia-utils

如果是 64 位系统还想跑 32 位应用（比如 Steam 里的老游戏），再加一个：

bash复制sudo pacman -S lib32-nvidia-utils

2.2 屏蔽 nouveau 并加载 NVIDIA 内核模块

安装完驱动之后，我们要做两件事：第一，把 nouveau 列入黑名单，防止它和 nvidia 模块抢设备；第二，让 nvidia 系列模块在 initramfs 阶段就加载，避免开机过程中分辨率异常。

创建 /etc/modprobe.d/nvidia.conf：

bash复制sudo tee /etc/modprobe.d/nvidia.conf <<EOF
blacklist nouveau
options nvidia_drm modeset=1 fbdev=1
EOF

modeset=1 是必须的，没有它 Wayland 和部分 Xorg 合成器无法正常工作，nvidia_drm 内核模式设置没有启用的话，连 nvidia-smi 都可能报错。fbdev=1 是后来加的参数，主要解决高分辨率终端字体模糊和部分设备上登录界面黑屏的问题。这两个参数对新一代驱动来说基本已经是默认值，但显式写出来更保险。

然后编辑 /etc/mkinitcpio.conf，在 MODULES 一栏加入 nvidia 相关模块：

bash复制MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

注意顺序不要乱，nvidia 在最前面，后面的模块依赖它。说句实话，这个顺序我在有些机器上颠倒过，没出过事，但网上大神的经验是保持这个顺序，咱没必要赌。

改完之后重新生成 initramfs：

bash复制sudo mkinitcpio -P

2.3 添加内核参数并重启

如果你用 GRUB，编辑 /etc/default/grub：

bash复制GRUB_CMDLINE_LINUX_DEFAULT="quiet nvidia-drm.modeset=1 nvidia-drm.fbdev=1"

然后：

bash复制sudo grub-mkconfig -o /boot/grub/grub.cfg

如果用 systemd-boot，则编辑 /boot/loader/entries/arch.conf，在 options 行最后加上同样的参数。

重启之前，建议先把旧模块从当前运行的内核卸载掉，避免重启后模块状态混乱：

bash复制sudo rmmod nouveau

不过如果你已经开启了 nouveau 且显示器正在用它输出，rmmod 可能会失败甚至黑屏，这种情况直接重启就好，initramfs 会完成模块替换。

重启后先用三条命令验证：

bash复制lsmod | grep nvidia
nvidia-smi
glxinfo | grep "renderer"

如果一切正常，nvidia-smi 会显示驱动版本和显卡信息，glxinfo 会显示 NVIDIA 相关字样，lsmod 能看到五个模块都在。如果 nvidia-smi 报错说找不到驱动，多半是模块没正确加载，下一步去看启动日志：

bash复制journalctl -b -g nvidia

2.4 内核升级后的驱动失配问题

这是 Arch 用户最常遇到的情况，而且特别有 Arch 特色：pacman -Syu 更新了内核，但 NVIDIA 驱动模块没有同步更新，重启之后直接进不了桌面，或者登录界面花屏。

如果你用的是 nvidia（预编译版本），那么 nvidia 和 linux 版本是严格绑定的，pacman 一般会同时更新它们。但如果你手动安装了非官方源的内核、用了 linux-zen、或者跳过了一部分更新，就很容易失配。

这种情况下，最直接的解决方案是切到 tty（按 Ctrl+Alt+F3），登录后用 pacman -Syu 把驱动和内核都更新到最新，然后重启。如果连 tty 都进不去，或者更新后仍然黑屏，就需要用安装 U 盘 chroot 进去处理了。这个操作我在后面故障排查的部分细说。

相比之下，nvidia-dkms 在失配上更抗造：只要内核头文件版本匹配，每次内核升级 DKMS 都会自动重新编译模块，一般不会出现驱动和内核版本不一致导致的黑屏。这也是我坚持推荐 DKMS 的原因。

3. AMD 与 Intel 的驱动配置

3.1 AMD 显卡：确认 amdgpu 与 mesa 完整

AMD 用户在 Arch 上的体验通常比 NVIDIA 用户舒服得多，因为需要的驱动组件基本都在主线内核和 mesa 里。

首先确认内核模块状态：

bash复制lsmod | grep amdgpu

如果输出为空，可能是你的显卡太老（GCN 1.0/1.1 之前的 HD 7000 系列），内核默认走的是 radeon 驱动而不是 amdgpu。也可以在 /etc/modprobe.d/amdgpu.conf 里强制指定：

bash复制options amdgpu si_support=1
options amdgpu cik_support=1

加这两行的同时，还得把 radeon 对应的支持关掉，否则两个模块会冲突：

bash复制options radeon si_support=0
options radeon cik_support=0

不过说实话，HD 7000 系列已经是十年前的卡了，看到这里的读者大概率是新显卡。新卡只要保证 linux-firmware 是最新的就行：

bash复制sudo pacman -S linux-firmware

然后确保用户态库完整：

bash复制sudo pacman -S mesa vulkan-radeon lib32-mesa lib32-vulkan-radeon

重启后验证：

bash复制glxinfo | grep "renderer"
vulkaninfo | grep "deviceName"

大概率会看到 AMD RADV 或者 AMD Radeon 的字样。AMD 的闭源驱动 amdgpu-pro 在 Arch 上已经没有使用必要了，开源的 RADV 在游戏和计算场景表现都不差，维护也好，除非你有特定的专业软件需求，否则不需要碰它。

3.2 Intel 核显：从 i915 到 Xe

Intel 核显的配置和 AMD 类似，内核有 i915 驱动就能工作，用户态库是 mesa。新一点的话题是 Intel 的 Xe 架构（Arc 系列独显和新的核显），内核 6.8 之后引入了 xe 驱动，Arch 的默认内核已经支持。

查看当前加载的模块：

bash复制lsmod | grep -E "i915|xe"

如果什么都不显示，但是 /dev/dri 目录存在且里面能看到 renderD128，说明驱动已经通过其他路径加载了，不用太担心。

Intel 用户需要额外装的是视频编解码的用户态驱动：

bash复制sudo pacman -S intel-media-driver

这个包负责提供 VA-API 支持，让浏览器硬件解码视频、剪辑软件调用 GPU 编码时能正常工作。装完后用 vainfo 验证：

bash复制sudo pacman -S libva-utils
vainfo

输出里能看到 H264、HEVC、AV1 等编码格式的支持情况。注意，如果你用的是老款 HD Graphics 系列（Broadwell 及更早），应该装 libva-intel-driver 而不是 intel-media-driver，两者适用平台不同，装反了会导致硬件解码不生效。

3.3 开源驱动的性能验证与调优

AMD 和 Intel 用户装完驱动后，可以装一个监控工具确认 GPU 频率和利用率真的跑起来了：

bash复制sudo pacman -S radeontop intel-gpu-tools

• radeontop 适合 AMD 卡，能看到显存占用、核心频率、各种引擎的实时负载。
• intel-gpu-tools 里的 intel_gpu_top 适合 Intel 核显，图形化界面类似 top，能看渲染、视频编解码的占用比例。

一个常见的坑是：笔记本上 AMD 核显 + NVIDIA 独显的组合，或者 Intel 核显 + AMD 独显的组合，默认情况下很多程序只走了核显，独显闲置。这时候需要一个额外的工具 envycontrol 或者手动配置 prime-run 来切换。这个我在下一节展开讲。

开源驱动的优势在于出了问题直接看 dmesg 就行，内核日志里会有明确的 amdgpu 或 i915 报错信息，不像 NVIDIA 闭源驱动那样经常把信息吞进自己的日志文件里。

4. 双显卡、多屏与多系统引导的协作

4.1 笔记本混合显卡的配置思路

现在很多笔记本是 Intel/AMD 核显 + NVIDIA 独显的混合方案。Arch 下最省电、最稳定的做法是让核显负责显示输出，独显只在需要计算时被调用。NVIDIA 官方的 PRIME 技术就是为了这个场景设计的。

Arch 官方仓库有一个 nvidia-prime 包，装上后系统会提供 prime-run 这个命令。在游戏或渲染软件前面加 prime-run，就能让程序强制使用 NVIDIA 独显运行：

bash复制prime-run steam
prime-run blender

原理是 prime-run 会设置 __NV_PRIME_RENDER_OFFLOAD=1 等环境变量，让支持 PRIME 渲染卸载的程序在启动时选择 NVIDIA GPU 作为渲染设备。

如果在 prime-run 某个程序时提示找不到 nvidia 设备，先检查 NVIDIA 模块有没有正常加载。另外注意，只有较新版本的驱动才支持这个机制，如果你用的是非常老的驱动，可能还是得手动切 nvidia-xrun 或者整个会话切换，那都是老黄历了，现在不需要学。

4.2 Xorg 与 Wayland 下的体验差异

对于 NVIDIA 用户，Wayland 这几年的进步明显，但离“开箱即用”还是有点距离。nvidia-drm.modeset=1 开启后，GNOME 和 KDE Plasma 的 Wayland 会话基本能正常工作，OBS 录屏、浏览器硬件加速都没大问题。

不过有一个老坑还在：如果驱动加载失败或者没有启用 modeset，Wayland 会话会直接黑屏或无法启动。所以如果你主要用 Wayland，一定要确认内核参数生效了：

bash复制cat /proc/cmdline

输出里必须能看到 nvidia-drm.modeset=1，否则即使你在 modprobe.d 里写了 options nvidia_drm modeset=1，也可能因为 initramfs 里没有正确加载模块而失效。

AMD 和 Intel 用户没这个烦恼，它们的开源驱动对 Wayland 的支持相当成熟，开箱即用。

4.3 多系统引导时要注意的细节

和 Windows 组成双系统的人很多，这里面有几个跟 GPU 有关的小细节值得注意。

第一，Windows 的“快速启动”功能会导致下次进入 Linux 时显卡设备状态异常，表现为驱动加载失败、显存信息读取错误。解决方法是进 Windows 关闭快速启动：控制面板 -> 电源选项 -> 选择电源按钮的功能 -> 取消勾选启用快速启动。

第二，如果你在 Linux 下是 nouveau 或者 amdgpu 能正常显示，但进 Windows 后屏幕分辨率异常或黑屏，多半是 BIOS 里显卡输出模式设置的问题。安全做法是保持 BIOS 默认的 Discrete Graphics 或 Hybrid 模式，不要轻易切换成 iGPU Only。

第三，GRUB 检测多系统靠 os-prober，这个跟驱动没关系，但很多人装完双系统后在 NVIDIA 驱动下看不到 GRUB 菜单，原因多半是屏幕分辨率太高、显示模式太新导致引导画面渲染异常。在 /etc/default/grub 里设置 GRUB_GFXMODE=1920x1080 和 GRUB_GFXPAYLOAD_LINUX=keep 基本能解决。

5. CUDA 与深度学习环境落地

5.1 装 CUDA 的两种方案及取舍

GPU 驱动配置好之后，最常见的用途就是跑深度学习、微调大模型、跑 AI 计算。这里有个关键认知要先说清楚：系统装好 NVIDIA 驱动之后，并不需要额外安装系统级的 CUDA Toolkit 才能跑 PyTorch。PyTorch 官方安装包内置了自己需要的 CUDA 运行时，只要显卡驱动版本不低于 PyTorch 要求的版本，就能直接用。

那什么时候才需要装完整 CUDA Toolkit？两种情况：你要自己编译 PyTorch 源码，或者你要用 CUDA 的 C/C++ 接口做开发。一个简单的判断标准是：

bash复制nvidia-smi

右上角的 CUDA Version 表示当前驱动支持的最高 CUDA 版本。比如显示 CUDA Version: 12.4，那么任何要求 CUDA 12.4 及以下的 PyTorch、TensorFlow 都能直接跑，不需要额外装 CUDA Toolkit。

如果你确实需要完整的 CUDA 开发环境：

bash复制sudo pacman -S cuda cuda-tools

Arch 仓库里的 CUDA 版本更新很快，这也是双刃剑：一方面你能用上最新的计算特性，另一方面某些老项目可能跟不上。我自己的偏好是尽量用 conda 管理深度学习的 CUDA 工具链，系统层面只负责驱动，这样项目环境互相隔离，不会因为 Arch 滚动更新导致某个老项目直接跑不了。

5.2 PyTorch / TensorFlow 驱动的快速验证

装好 PyTorch 之后，用一段极简代码验证 GPU 是否可用：

bash复制python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

如果输出 True 和显卡型号，说明一切正常。如果输出 False，最常见的原因是 PyTorch 装成了 CPU 版本。注意 PyTorch 的安装命令有讲究，从官网复制来的命令里有 --index-url 参数，那个才是 GPU 版：

bash复制pip install torch torchvision --index-url https://download.pytorch.org/whl/cu124

安装前确认一下 nvidia-smi 里的 CUDA 版本，选择不高于它的 cu 版本安装。比如驱动支持到 CUDA 12.4，你装 cu121 或 cu124 都没问题，但别装 cu126，那会导致运行时直接找不到 CUDA 库。

5.3 大模型场景：ollama 与其他推理工具的 GPU 利用

现在很多人用 ollama 跑本地大模型。ollama 默认会自动使用所有可用 GPU，但如果你想控制它用哪块卡或者限制显存，可以用环境变量。常见的有：

bash复制OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_NUM_GPU=999
CUD_VISIBLE_DEVICES=0

启动之前先确认 ollama 有没有正确识别 GPU：

bash复制ollama run llama3.2

运行后到另一个终端执行 nvidia-smi，应该能看到 ollama 进程占用了显存。如果模型加载到一半显示显存不足，说明模型的大小超过了显卡的显存容量，这时可以：

• 换用量化版本（如 Q4_K_M），显存需求能减少大半。
• 减小上下文长度，因为上下文也会占显存。
• 如果还是不够，只能用 CPU 推理了。

另外，如果你用的是 AMD 显卡，ollama 也支持 ROCm。Arch 上要装 rocm 相关包，但 ROCm 在 Arch 上的配置比 CUDA 折腾不少，我不建议新手一上来就碰，先把 NVIDIA 的 CUDA 流程跑通再说。

5.4 训练和推理场景的显存与利用率判断

很多人分不清“跑训练”和“跑推理”对 GPU 资源需求的不同。我简单总结一个判断思路：

• 训练的特点是显存占用高、计算利用率起伏大、持续时间长。显存主要被模型权重、梯度、优化器状态和激活值占用。同样的模型，训练时的显存需求可能是推理的3到8倍。
• 推理的特点是显存占用相对稳定、计算利用率高、延迟敏感。显存主要由模型权重和 KV Cache 占用，所以显存容量基本决定了你能跑多大的模型。

运维 GPU 服务器时，最实用的监控命令是：

bash复制nvidia-smi dmon -s pucvmet -d 1

dmon 每秒输出一次 GPU 利用率、显存占用、温度、功耗等信息。还有一个更直观的 nvtop，界面类似 htop，一眼就能看到多卡的状态：

bash复制sudo pacman -S nvtop

如果你的机器是多卡服务器，想在跑训练时指定某几块 GPU，用 CUDA_VISIBLE_DEVICES=0,1 python train.py 就能实现。这个环境变量对 PyTorch、TensorFlow、几乎所有 CUDA 程序都生效，是日常用得最多的运维手段。

6. 故障排查实录：从黑屏到驱动崩溃

6.1 升级后黑屏、进不去桌面的排查顺序

遇到驱动问题先别慌，我整理了一套标准处置顺序，按顺序操作基本能救回来。

第一步，按 Ctrl+Alt+F3 尝试切换到 tty 终端。如果能进入字符界面，说明内核已经启动，只是图形界面起不来。这时候先登录，再执行：

bash复制sudo pacman -Syu
sudo reboot

大概率是内核和驱动版本失配，更新到最新就能解决。

第二步，如果 tty 也进不去，卡在启动画面或者黑屏，那就要用安装 U 盘进入 Live 环境，然后 chroot 进系统处理。步骤如下：

bash复制# 挂载根分区，以下以 /dev/sda2 为例，需要根据实际分区调整
mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot   # EFI 分区如果有的话
arch-chroot /mnt

进入 chroot 后，先重新安装驱动和内核：

bash复制pacman -S linux linux-headers nvidia-dkms nvidia-utils
mkinitcpio -P

然后退出 chroot 重启：

bash复制exit
reboot

如果连 chroot 都进不去，或者恢复了驱动之后还是黑屏，那就要考虑是不是内核参数的问题。我之前遇到过一台笔记本，内核参数加了 quiet 和 splash，NVIDIA 驱动加载失败时日志被 quiet 吞掉了，屏幕上什么提示都没有，把这两个参数删掉之后，错误信息直接显示出来，定位就快了。

6.2 nvidia-smi 报错和 GPU crash dump 的常见场景

nvidia-smi 最常见的报错是：

text复制NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.
Make sure that the latest NVIDIA driver is installed and running.

这个错误的意思很直白：内核模块没有加载，或者加载的模块和用户态库版本不匹配。排查顺序：

bash复制# 看看模块有没有加载
lsmod | grep nvidia

# 看看模块有没有加载失败
dmesg | grep nvidia

# 查看加载了哪些内核模块版本
modinfo nvidia | grep version

模块没加载的解决办法很简单：sudo modprobe nvidia。如果提示找不到模块，说明驱动编译有问题，去 /var/log/ 翻 DKMS 日志。如果模块加载了但还是报错，多半是 nvidia-utils 和内核模块版本不一致，重装一遍 nvidia-utils 即可。

另一个词最近很火：“gpu crash dump triggered”。这其实是 NVIDIA 驱动在 GPU 发生异常时生成的故障转储提示，常见于超频、显存过热、驱动 bug 或供电不稳定。看到这个提示，先检查散热和供电：

bash复制nvidia-smi -q -d TEMPERATURE,POWER

如果温度超过 85 度或者功耗波动异常，大概率是硬件层面的问题。如果温度和功耗正常，那可能就是驱动 bug，升级驱动版本或者回退到上一版本试试。还有一种情况是电源管理设置导致的，尝试给 NVIDIA 驱动加上 NVreg_DynamicPowerManagement=0x02 参数看是否缓解。

6.3 DKMS 编译失败的通用排查

DKMS 的报错信息通常长这样：

text复制Error! Bad return status for module build on kernel: 6.x.x-arch1-1 (x86_64)

遇到这种报错先别急着百度整段错误，按顺序检查三件事：

第一，内核头文件是否安装。执行：

bash复制pacman -Q linux-headers

如果提示未安装，或者头文件的版本跟当前内核不一致，直接 sudo pacman -S linux-headers 装好。

第二，gcc 版本是否可用。DKMS 编译依赖 gcc，如果你之前换过 gcc 版本或者系统里同时存在多个 gcc，可能编译失败：

bash复制gcc --version

第三，完整查看编译日志。DKMS 的日志在 /var/lib/dkms/nvidia/*/build/make.log，最后几行通常会给出真正的错误原因。不够，很多时候是内核 API 变了导致旧版驱动编译失败，这种只能升级驱动版本。

6.4 常见问题速查表

这张表覆盖了我这几年在 Arch 群和论坛里看到的大部分问题，实际操作中，七成以上的问题都出在上面这几行里。

7. 配置完成之后的一些个人体会

驱动配置这事儿，在 Arch 上特别能体现这个发行版的性格：它不替你决定，它给你选择，但也要求你理解自己在做什么。很多新用户装驱动失败，不是操作不对，而是不清楚自己在哪一层、面对的是哪个组件——是内核模块、用户态库、还是显示协议的问题。

我自己现在最稳的一套组合是这样：linux-lts 内核配合 nvidia-dkms，日常桌面用 linux 内核，遇到重大升级后黑屏就切到 LTS，基本没有解决不了的问题。AMD 的机器就简单多了，装了 mesa 之后几乎不用管。

最后再分享一个实际操作中很有用的习惯：每次升级完驱动或者内核之后，重启前先看一眼系统里有没有待处理的依赖问题：

bash复制sudo pacman -Qtdq | sudo pacman -Rns - 2>/dev/null || true

这个命令会清理孤儿包，避免某些老版本的库残留在系统里，干扰新驱动的运行。听起来是小事，但我在几次莫名其妙的驱动异常里，最后发现是残留的旧库在作祟。

希望这篇内容能帮你把 Arch 上的 GPU 驱动理顺。如果你在配置过程中遇到这里没覆盖到的问题，建议带着 dmesg 和 journalctl 的日志去 Arch Wiki 查对应页面，那上面更新得更快，也永远是 Arch 用户的第一参考资料。