莫同动手在Ubuntu上本地化部署大模型，驱动就是第一道门神。很多玩本地大模型的朋友都是Windows用户，显卡插上、驱动装好、直接跑PyTorch就完事；一旦转向Ubuntu，第一个拦路虎就是NVIDIA驱动安装。这篇我写的是自己在Ubuntu上从零装好NVIDIA驱动、跑通大模型推理的完整过程，重点是那些教程里不会细说但实际一定会碰到的选择和坑。
先简单交代一下我的环境：Ubuntu 22.04 LTS桌面版，双系统（Windows+Ubuntu），显卡是RTX 3090，24GB显存，目标是在本机跑DeepSeek系列蒸馏模型和Qwen3相关模型的本地推理，后面还要接RAGFlow做知识库。如果你也是这个方向，这篇下来应该能少走不少弯路。
1. 为什么部署大模型第一步要折腾驱动
很多人不理解，装大模型和显卡驱动有什么关系？模型不是装个Python包就能跑吗？有这个疑问很正常，因为我一开始也这么想。
大模型推理本质上是海量矩阵运算和注意力机制计算，CPU也能算，但速度慢到没法用。GPU之所以快，是因为NVIDIA的CUDA并行计算架构把密集型运算拆成了上千个核心同时算。而操作系统要调用GPU的CUDA能力，必须先有驱动做桥梁——驱动是硬件和软件之间的唯一通道，没有驱动，系统根本不知道这张显卡能做什么。
在Windows下，NVIDIA驱动通常装好系统就自带了，或者用GeForce Experience一键更新，用户感知很弱。到了Ubuntu就不一样了。Ubuntu默认用的是开源驱动nouveau，性能只有闭源驱动的几分之一，而且很多大模型推理框架根本不认它。如果你用PyTorch加载模型时报"CUBLAS_STATUS_NOT_INITIALIZED"或者"CUDA error: no kernel image is available for execution on the device"，八成就是驱动没装对。
还有一个维度很关键，就是CUDA生态的对接。PyTorch、llama.cpp、DeepSeek官方推理脚本、RAGFlow这类工具链，默认都假设你已经有一个能支持特定CUDA版本的NVIDIA驱动。驱动版本不够新，装上最新版PyTorch也会报"CUDA driver version is insufficient"。所以驱动不只是"能显示画面"这么简单，它是整个大模型软件栈的地基。
我这篇文章会从环境检查、驱动选型、禁用nouveau、安装驱动到验证全流程走一遍，最后把装完驱动之后常见的黑屏、循环登录、模块加载失败这些坑的排查链路也复盘清楚，帮你在本地化部署大模型这条路上把第一块拼图放对位置。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手之前：先搞清楚你的显卡到底需要什么驱动
很多教程上来就让你装驱动，但从来不告诉你为什么要选某个版本，结果就是一堆人在评论区问"为什么我装完黑屏""为什么nvidia-smi报错"。实际上，装驱动之前花五分钟做三件事，后面能省两小时。
2.1 确认显卡型号与当前驱动状态
打开终端，逐条执行：
bash复制lspci | grep -i nvidia
这条命令会列出所有NVIDIA相关的PCI设备。看到类似"VGA compatible controller: NVIDIA Corporation GA102 [GeForce RTX 3090] (rev a1)"的输出，说明系统识别到了显卡硬件。这里的GA102是芯片代号，GeForce RTX 3090是商业名称。
然后检查系统当前有没有装NVIDIA驱动：
bash复制nvidia-smi
如果提示"command not found"或者"NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver"，说明驱动没装或者没加载。如果能看到一个表格，显示驱动版本、CUDA版本、显存使用量，说明系统里已经有可用驱动，只是可能版本不够新。
再用下面这条命令看系统里可用的驱动候选版本：
bash复制ubuntu-drivers devices
这条命令会读取系统硬件信息，然后从Ubuntu软件源里匹配可用的NVIDIA驱动版本。输出里通常会有一个"recommended"标记，表示系统推荐的默认版本。我的习惯是：优先用带recommended标记的版本，而不是盲目追求最新版。原因很简单——Ubuntu仓库里的驱动是经过发行版测试的，和大模型推理场景的CUDA兼容性经过了大量用户验证。
2.2 理解驱动版本和CUDA版本的关系
很多新手在驱动和CUDA的关系上栽跟头。NVIDIA驱动、CUDA Toolkit、CUDA运行时是三个不同的东西，但经常被混为一谈。
驱动是内核模块加用户态库，负责让操作系统能调用GPU。CUDA Toolkit是开发套件，包含编译器nvcc和各种库，用来把代码编译成能在GPU上跑的程序。而PyTorch这些推理框架，通常自带一套CUDA运行时依赖，不需要你单独装CUDA Toolkit也能跑。
驱动版本决定的是你能支持多新的CUDA。比如驱动535.x对应CUDA 12.2，意味着任何需要CUDA 12.2及以下版本的框架都能跑。就算你只装了驱动，没装CUDA Toolkit，PyTorch自带的CUDA运行时也能通过驱动调用GPU做计算。
我见过有人在驱动没装好的情况下，跑去NVIDIA官网下载了一个几百MB的CUDA Toolkit安装包，装完发现nvidia-smi还是报错。因为CUDA Toolkit只是开发库，它不包含内核驱动。正确的顺序是：先装驱动，再决定要不要装CUDA Toolkit。对于纯粹的本地部署大模型，只需要驱动版本够新，推理框架自带的CUDA运行时就能工作。
2.3 三种安装方式的取舍
Ubuntu下装NVIDIA驱动有三种主流方式，我按实际推荐度从低到高给你拆解。
第一种是从NVIDIA官网下载.run安装包手动安装。这种方式能装到最新版驱动，但风险最大。安装过程中需要停掉图形界面、处理内核模块签名、应对各种依赖缺失，中间任何一个环节出错都容易翻车。我只在apt仓库找不到满足需求的驱动版本时才会考虑这条路。
第二种是Ubuntu自带的"软件与更新"图形化界面。在"附加驱动"标签页里勾选一个驱动版本，点应用更改，重启完事。这种方式适合不想记命令行的用户，但缺点是没法精确控制安装过程，排错时少了很多可用的日志和命令。
第三种是通过apt命令行安装：
bash复制sudo apt update
sudo apt install ubuntu-drivers-common
sudo apt install nvidia-driver-535
用apt安装用的是Ubuntu官方仓库里的驱动，经过了发行版测试，稳定性最好，后续系统更新时也会同步维护。这也是我在本地化部署大模型场景里最推荐的方式。驱动不是越新越好，稳定压倒一切。apt仓库里的版本可能不是最新，但它一定是在这套Ubuntu版本上被验证过能稳定工作的。
3. 正戏：从零开始把NVIDIA驱动装到能用
下面进入实操环节。我的步骤全部基于Ubuntu 22.04 LTS，但命令在20.04和24.04上同样适用。整个过程拆成四个阶段：准备、禁用nouveau、安装、验证。
3.1 系统更新与内核准备
装驱动之前，先把系统更新到最新状态。这一步很多人会跳过，但内核模块编译时如果头文件版本不匹配，后面会碰上一堆莫名其妙的报错。
bash复制sudo apt update
sudo apt upgrade
sudo apt install build-essential dkms
build-essential提供编译工具链，DKMS（Dynamic Kernel Module Support）的作用是：当系统内核升级时，自动重新编译NVIDIA驱动模块。如果不装DKMS，每次内核升级后驱动都会失效，又得重装一遍。这个坑我早期装驱动时踩过不止三次。
重启一次系统，确认内核已经更新到最新版本。然后用uname -r查看当前内核版本，记录下来。后面排查问题时必须知道当前内核是哪个版本。
3.2 禁用nouveau开源驱动（必做）
Ubuntu默认自带的是nouveau——一个由社区逆向工程开发的开源NVIDIA驱动。它在电源管理、性能调度上都远不如NVIDIA官方闭源驱动，而且最要命的是：nouveau的内核模块会和闭源驱动的内核模块产生冲突，导致装完闭源驱动后不生效或者直接黑屏。
创建屏蔽nouveau的配置文件：
bash复制sudo bash -c "echo 'blacklist nouveau' >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
sudo bash -c "echo 'options nouveau modeset=0' >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
然后更新内核引导镜像：
bash复制sudo update-initramfs -u
这一步做完必须重启。重启后验证nouveau是否真的被屏蔽了：
bash复制lsmod | grep nouveau
如果没有任何输出，说明屏蔽成功。如果还有输出，可能是之前有残留的模块缓存，重新执行一遍update-initramfs再重启应该能解决。
3.3 安装驱动：我的推荐命令和理由
重启完，确认nouveau已经禁用，接下来就是install了。我用的是最直接的apt方式：
bash复制sudo apt update
sudo apt install nvidia-driver-535
如果你用ubuntu-drivers devices看到了不同的推荐版本，装那个推荐的也行。比如在很多新版本Ubuntu上，推荐版本可能是535、545、550。我自己用535是因为它在CUDA 12.2的支持上非常稳，而这正好是PyTorch 2.x和很多大模型推理框架的基准版本。
装完驱动后重启一次：
bash复制sudo reboot
重启回来第一件事：
bash复制nvidia-smi
如果能看到一张表，表头写着NVIDIA-SMI 535.xx.xx、Driver Version、CUDA Version: 12.2，说明驱动已经装好并且内核模块正常加载了。
如果这个时候没成功，别急，往下跳到第4章的排查链路。先对一下你遇到的是哪类问题，照着思路排查。
3.4 用Python/PyTorch验证GPU计算链路
nvidia-smi能看到，只代表驱动层通了。大模型推理框架是通过CUDA运行时调GPU的，更接近实战的验证方式是直接用PyTorch试试。
先装一个带CUDA支持的PyTorch：
bash复制pip install torch --index-url https://download.pytorch.org/whl/cu121
然后执行：
python复制python3 -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"
输出True和GeForce RTX 3090，说明整个链路通了：驱动、CUDA运行时、PyTorch三层都在正常工作。这个验证方式我非常推荐，因为它模拟的正是大模型推理框架实际调用GPU的路径。如果这里报错，远比nvidia-smi报错更能说明问题。
顺带提一个容易踩的坑：很多用户会在系统里额外安装nvidia-cuda-toolkit来获得nvcc编译器：
bash复制sudo apt install nvidia-cuda-toolkit
如果你确定不自己编译CUDA扩展，其实没必要装这个。装了反而可能和PyTorch自带的CUDA运行时产生库冲突。我有一次编译自定义算子时用系统nvcc编译出了和PyTorch运行时版本不兼容的库，报了一堆link error，查了半天才意识到是双CUDA环境混用导致的。所以我的原则是：能用apt生态解决的事，别手动引入额外的独立环境。
4. 装完黑屏、驱动未加载、循环登录：三类高频问题的完整排查链路
装驱动这件事，最烦的不是命令记不住，而是出了问题不知道该从哪里查。我见过太多人在社区里问"装完NVIDIA驱动重启黑屏怎么办"，得到的答案往往是"重装系统"。其实大部分问题都有清晰的排查路径，按顺序来根本不用走到重装那一步。
我把最常见的三类问题按"现象-排查-解决"的结构完整复盘一遍。
4.1 开机后黑屏或卡在登录界面循环
先说黑屏。黑屏分两种：一种是有光标在闪的黑屏，一种是纯黑什么都没有。前者通常是显示管理器配置出了问题，后者可能是引导阶段驱动加载失败。
按Ctrl+Alt+F2（或F3-F6任意一个功能键）切换到纯文本终端。这个操作在任何时候都能用，它能让你在图形界面挂掉的情况下依然能进入命令行操作。用你的用户名和密码登录。
登录之后第一步，运行nvidia-smi看看驱动状态：
bash复制nvidia-smi
如果nvidia-smi能正常显示表格，说明驱动其实没问题。黑屏大概率是显示管理器（比如GNOME的gdm3）和NVIDIA DRM模块之间的兼容问题。这时候可以看日志：
bash复制journalctl -b -1 | grep -i nvidia
journalctl -b -1 | grep -i gdm
我的实际经验是，在双系统环境下，如果从Windows重启到Ubuntu时出现黑屏，很多情况下是显卡硬件没有被正确重置。最简单的操作是：回到Windows彻底关机（不是重启），等几秒再开机选Ubuntu。这能重置显卡的硬件状态，解决一大部分黑屏问题。如果你现在卡在Ubuntu黑屏进不去，可以强制关机，再开机选Ubuntu试试，经常就这么好了。
如果nvidia-smi直接报错，说明驱动模块没加载。继续往下走。
4.2 nvidia-smi提示无法与驱动通信
nvidia-smi报"NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver"，是典型的模块加载失败。先检查模块加载状态：
bash复制lsmod | grep nvidia
如果没有任何输出，说明NVIDIA内核模块没加载进来。试着手动加载：
bash复制sudo modprobe nvidia
如果报错，比如"Operation not permitted"或者"No such device"，那问题要么出在模块编译，要么出在系统安全机制。前者用DKMS重编，后者基本上是Secure Boot在拦。
Secure Boot是在UEFI层面对内核模块做签名校验的安全机制。NVIDIA闭源驱动没有内嵌进系统引导链的签名库，Secure Boot开启时，未签名的内核模块会被拒绝加载。处理方式有两种：进BIOS直接关掉Secure Boot，或者走MOK（Machine Owner Key）签名流程。MOK流程会要求你设置一个密码，重启时进入蓝色背景的MokManager，选"Enroll MOK"完成签名注册。
我的建议很直接：本地部署大模型这台机器，你最优先的目标是让它稳定工作。如果没有强安全合规要求，直接关Secure Boot，省去一整套签名烦恼。我自己就是关掉之后再也不折腾这个了。
4.3 DKMS编译失败：内核头文件缺失
装驱动过程中最常见的编译错误，提示类似"ERROR: The kernel header file '/usr/src/linux-headers-xxx/include/linux/version.h' is missing"。
原理很简单：DKMS要把NVIDIA驱动的源代码编译成当前内核能加载的模块，编译时必须引用当前内核的头文件来确保接口一致。如果内核刚升级过，但头文件包没跟上，就会报这个错。
解决办法分两步。第一步，确认当前内核版本：
bash复制uname -r
第二步，安装对应的头文件包：
bash复制sudo apt install linux-headers-$(uname -r)
这里用$(uname -r)自动替换成当前内核版本号，不需要手打。装完头文件后重新触发DKMS编译：
bash复制sudo dkms autoinstall
或者干脆重装一遍驱动：
bash复制sudo apt install --reinstall nvidia-driver-535
然后重启，基本就能解决。
这里要特别提醒一个场景：很多人装完驱动跑得好好的，某天做了sudo apt upgrade，系统悄悄把内核升级了，驱动模块就跟新内核失配了。因为DKMS重编没有自动触发。症状就是你发现重启后nvidia-smi报错、跑大模型的脚本报CUDA error。我的习惯是：每次大版本升级内核后主动执行一遍sudo dkms autoinstall，别等出问题了才想起来。
5. 驱动装好之后，我建议你立刻做的几件事
驱动装好、nvidia-smi正常显示，这只是本地化部署大模型的第一步。如果你接着就去clone模型仓库、跑推理脚本，大概率还会在别的地方卡一下。下面几件事是我在驱动就位后立刻会做的，能帮你把"驱动装好了"真正变成"环境可用了"。
5.1 开启GPU持久化模式
NVIDIA专业卡（如A100、A10）默认开启持久化模式（persistence mode），但消费级显卡（RTX 3090、4090）默认不开。持久化模式的作用是让GPU驱动常驻后台，避免每次调用时重新初始化GPU。
对大模型推理来说，这意味着更低的首请求延迟和更稳定的显存管理。手动开启命令很简单：
bash复制sudo nvidia-smi -pm 1
这个配置重启后失效，最好做成开机自启。用systemd服务：
bash复制sudo nano /etc/systemd/system/nvidia-persistence.service
内容如下：
ini复制[Unit]
Description=NVIDIA Persistence Mode
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -pm 1
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
然后启用服务：
bash复制sudo systemctl enable nvidia-persistence.service
sudo systemctl start nvidia-persistence.service
这个动作虽小，但对长时间连续跑推理任务确实有效。我之前跑一个批量生成任务，没开持久化模式时，每次启动推理进程第一次调用GPU都有几秒延迟；开启后延迟基本降到感知不到的程度。
5.2 检查显存和温度：建立日常体检习惯
大模型推理对显存是硬性需求。模型权重多大，配套的KV Cache和临时张量也要占显存。以7B参数模型为例，FP16格式权重约14GB，4bit量化后约4-5GB，加上推理时的缓存，最少也要8GB显存才能跑得比较舒服。RTX 3090的24GB显存可以比较从容地跑7B到14B级别的量化模型。
日常监控GPU状态，用nvidia-smi：
bash复制nvidia-smi
这里有三个指标值得重点关注：显存占用（Memory-Usage），GPU核心利用率，温度。温度长时间超过80度要小心，超过85度就是危险的降频线了。还有一个更实时的监控命令：
bash复制nvidia-smi dmon
它会实时滚动显示GPU利用率、显存读写带宽、功耗、温度等指标。排查推理性能瓶颈时，dmon比默认视图好用得多。
我遇到过一个典型案例：跑Llama 3 8B量化版时，推理速度一开始正常，几分钟后显著下降。用dmon看到GPU温度在87度左右，功耗受限，核心频率从1.7GHz掉到1.2GHz——降频了。后来清理机箱灰尘、调整风道，把温度控制在70度以下，推理速度才恢复。这种散热问题不去看dmon的话，很容易误判成软件或模型问题。
5.3 清理残留进程，规划显存分配
大模型推理脚本崩了之后，显存经常出现假性占用：nvidia-smi里能看到残留的Python进程还占着几GB显存。这是因为进程崩溃时，GPU显存没有被及时释放。
处理方式：
bash复制nvidia-smi
找到状态栏里疑似残留的进程PID，杀掉：
bash复制kill -9 PID
更暴力的方式是用fuser清掉所有占用NVIDIA设备的进程：
bash复制sudo fuser -v /dev/nvidia*
但用之前要确认没有正在跑的重要任务。
另外，如果机器上要同时跑多个模型服务（比如同时部署embedding模型和主对话模型），合理的显存规划很重要。通常建议给每个进程预留至少20%的显存余量，防止显存碎片化导致OOM。这个经验是从实际部署RAGFlow加Qwen3-embedding-0.6b的场景里积累的——embedding模型虽然很小，但如果和其他服务盲目抢显存，主模型就容易被挤出可用空间。
5.4 把CUDA能力纳入日常开发验证体系
驱动装好了不代表以后不会再遇到CUDA相关的问题。我建议把GPU验证固化到日常开发流程里：每次新建Python环境、每次升级PyTorch之后，都跑一次：
python复制import torch
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))
print(torch.cuda.get_device_capability(0))
第三行输出的是GPU的计算能力版本，比如(8, 6)对应RTX 3090。这个值在编译自定义CUDA算子时会用到。养成这个习惯之后，你会发现自己遇到的大部分"装了几个包之后GPU突然不可用"的问题，都能在十几秒内定位到是哪一层出了问题。
6. 从Windows迁移到Ubuntu的额外提醒
最后专门写一节给从Windows转过来的用户。Windows下装NVIDIA驱动，基本是下载官方的GeForce Experience或者手动下载驱动包，双击一路Next就完事。到了Ubuntu，如果还保持这个思维，去NVIDIA官网下载Linux版的.run驱动包，拿回来执行，很容易掉进依赖泥潭。
Windows驱动的形态是一个独立的用户态安装包，与操作系统内核解耦。而Linux驱动需要编译成内核模块，与当前运行的内核严格绑定，所以它天然依赖内核头文件、编译器版本、模块签名机制这些条件。这就是为什么在Ubuntu下用apt源安装驱动比官网手动安装稳妥得多——apt源里的驱动经过发行版适配，会处理掉我们在第4章里遇到的绝大多数坑。
另外，Ubuntu下的驱动升级频率和Windows完全不是一个节奏。Windows下显卡驱动几乎每个月都有新版本，但在Ubuntu下，没有碰到具体问题不建议频繁升级。apt源里一个驱动版本用上一年半载很常见。尤其是本地化部署大模型的服务器，稳定压倒一切——新版驱动带来的性能提升，很多时候不足以抵消升级带来的兼容性风险。
如果你确实有特殊需求要用新版驱动，建议动手之前先把当前版本记录下来：
bash复制dpkg --list | grep nvidia
万一翻车，可以快速回退到老版本。在本地化部署大模型这个场景里，我强烈建议：用Ubuntu的包管理机制去管理驱动，放弃官网手动安装的执念。系统推荐用apt你就用apt，推荐535你就装535。等你真正理解为什么需要更新版本的时候，再去碰官网的.run包也不迟。
我自己从最初在Ubuntu下装驱动反复折腾，到后来能一次装好、稳定跑大模型推理，最大的体会就是：不要轻视"环境准备"这四个字。在Linux里，驱动不是一个孤立的软件，它和内核、桌面环境、Secure Boot、DKMS、CUDA生态是一条完整的链路。任何一个环节没对齐，后面跑大模型时都会以各种奇怪的方式找你麻烦。先把这条链路的底层逻辑摸透，后面部署DeepSeek、Qwen3、RAGFlow这些任务时，你会觉得顺畅得多。