企业官网建设流程全解析

1. 先想明白：驱动、CUDA、Ollama和显存是谁在管

1.1 一层一层看透这条链路

NVIDIA驱动装了，nvidia-smi也能正常看到显卡，但ollama run一个模型，GPU显存占用却是0%，CPU直接飙到100%——这是我在Ubuntu上折腾Ollama时碰到最多的问题。很多人上来就装Ollama，跑不通就怀疑是不是模型文件坏了，其实问题往往出在更底层：驱动和CUDA环境根本没把GPU的能力交到Ollama手上。

在Ubuntu上，要让Ollama跑在显存里，背后至少涉及四个角色：NVIDIA驱动、CUDA运行时、Ollama本体、显存资源。这四者是一条完整的链，任何一环掉链子，最终表现都是“模型跑起来了，但用的是CPU”。

用个不太严谨但很好懂的类比：把这张显卡看成一家物流仓库，NVIDIA驱动是仓库的安保系统，负责让操作系统识别并管理这块硬件；CUDA是仓库里的调度管理员，指挥货物（张量数据）怎么进出、怎么摆放；Ollama是搬运工，平时把模型权重搬进仓库；显存就是仓库里的货架，空间大不大、放得顺不顺，直接决定搬运工干活的效率。

仓库保安没上岗，调度员喊破喉咙也没人开门；货架不够大，一部分货只能堆到仓库门口的临时堆场，也就是系统内存，搬运速度自然断崖式下降。

这就是为什么很多人发现，模型明明能跑，但速度只有每秒几个token，比老款CPU还慢——因为你的模型压根没完整放进显存，而是被拆成了两半，GPU算一层、CPU算一层，两者之间来回搬运数据，速度直接被拖垮。

1.2 为什么版本不匹配一定翻车

先说说一个大多数人都会误解的点：nvidia-smi输出里的CUDA Version，不是指你系统里装了CUDA工具包，而是指当前驱动版本“最高可以支持”哪个CUDA运行时版本。也就是说，这个数字只是驱动的能力上限，不是实际安装的CUDA。

Ollama比较特殊，它内部已经打包了推理所需的CUDA运行库，不需要你手动装一套完整的CUDA Toolkit也能调用GPU。但这并不意味着驱动门槛可以无视。如果驱动版本过老，Ollama在加载模型时会直接报CUDA相关错误，或者干脆识别不到GPU，只能退回CPU推理。

我见过最典型的翻车场景是：Ubuntu自动更新内核之后，NVIDIA驱动因为DKMS模块没跟上，导致重启后nvidia-smi直接报错，Ollama自然也就用不上显存。另外，一些老的笔记本显卡，驱动停留在470系列，跑新出的Ollama版本确实会遇到兼容性问题。

所以在Ubuntu上做N卡驱动的目标不是“装上能开机就行”，而是要装到和Ollama的CUDA库匹配、并且能扛住系统内核更新的状态。后面所有步骤，都围绕这个目标展开。

2. Ubuntu下N卡驱动从零到可用的完整过程

2.1 动手之前，先确认三件事

装驱动之前先把环境摸清楚，能在后面省掉一晚上的排查时间。我一般会依次确认三件事。

第一，确认系统真的能看到这张卡：

lspci | grep -i nvidia

如果这条命令没有输出，先别急着装驱动，去检查显卡是不是没插好、供电线是不是没接，或者主板BIOS里是否禁用了独立显卡。此外，如果机器是双显卡笔记本，还要确认系统至少能看到N卡。

第二，确认Ubuntu版本和内核版本：

lsb_release -a uname -a

不同版本的Ubuntu源里提供的驱动版本差别很大。Ubuntu 22.04的官方源里最高通常能到nvidia-driver-550左右，而Ubuntu 24.04可能直接有560甚至570。内核版本则决定了DKMS重新编译驱动的兼容性，遇到编译失败时，这个信息一定要发给搜索引擎。

第三，确认Secure Boot的状态。这个特别容易被忽略，很多人在重启后看到NVIDIA驱动起不来、循环登录，却不知道是Secure Boot在作祟。在终端里跑：

mokutil --sb-state

如果是“SecureBoot enabled”，那么装完驱动后还得走MOK（Machine Owner Key）签名流程，否则内核模块会被拒载，nvidia-smi一执行就报“Failed to initialize NVML”。

2.2 禁用nouveau，避免驱动打架

Ubuntu自带的开源NVIDIA驱动叫nouveau，它是系统里默认加载的显卡驱动。如果你要装NVIDIA官方闭源驱动，必须先把这个开源驱动屏蔽掉，两者都加载会出现各种诡异问题：黑屏、循环登录、nvidia-smi不认设备。

屏蔽nouveau的方法我已经在好几台机器上用过，步骤固定：

首先创建blacklist配置文件：

sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nouveau.conf" sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nouveau.conf"

然后更新内核启动镜像：

sudo update-initramfs -u

接着重启机器。重启后执行：

lsmod | grep nouveau

如果没有任何输出，说明nouveau已经被屏蔽成功了。这一步必须确认，因为有些情况下blacklist没有生效，尤其是有第三方驱动管理工具的环境，nouveau会在启动时又被拉起来。

2.3 驱动安装：三种方案怎么选

我在Ubuntu上装过很多次NVIDIA驱动，接触过三类方案，每个都各有适用场景。

第一种：图形界面“附加驱动”安装。在“软件和更新”里切到“附加驱动”标签页，系统会自动检测硬件并列出可用的NVIDIA专有驱动版本，选中一个带“proprietary”标记的版本应用即可。这个方案最省心，适合桌面版Ubuntu用户，它会自动处理很多的依赖问题。

第二种：命令行安装。先刷新源，然后让系统推荐最合适的驱动版本：

sudo apt update ubuntu-drivers devices

输出会列出当前可用的驱动版本，如果看到“recommended”字样，就安装它。比如推荐550，那就：

sudo apt install nvidia-driver-550 sudo reboot

我个人的习惯是优先选系统推荐的版本，因为它是经过Ubuntu打包测试过的，和apt依赖树、内核模块的配合最稳定。除非你有特殊需求，比如某个CUDA版本强行要求驱动版本大于某个阈值，才去手动指定更高的版本。

第三种：NVIDIA官网下载.run文件手动安装。这个方案适合服务器环境（没有桌面）或者需要装官方最新驱动但apt源还没有的情况。但说实话，非必要不推荐，因为手动安装的驱动不一定会接入DKMS管理，内核一升级驱动就可能失效，而且卸载也比apt包麻烦。

下面是三种方案的对比：

无论哪种方式，装完后记得重启，重启后再执行nvidia-smi验证。

2.4 驱动装上之后，如何确认GPU真的可用

重启后第一件事就是打开终端，执行：

nvidia-smi

正常情况会看到一张表格，列出GPU型号、驱动版本、CUDA能力版本，以及当前显存使用情况。

如果这里报错，最常见的三种情况：

第一种是No devices were found，说明驱动没成功加载。先查dmesg日志：

dmesg | grep -i nvidia

看看有没有报错，常见原因是Secure Boot没有做MOK签名，或者nouveau没有被成功屏蔽。如果是Secure Boot的问题，我建议先回头查一下mokutil --sb-state，如果开启了，去BIOS里暂时关闭Secure Boot，等驱动跑通后再决定要不要开回来。

第二种是Failed to initialize NVML: Driver/library version mismatch，这是驱动文件和内核模块版本对不上。多半是驱动升级后没重启，或者旧内核模块还在运行。解决办法是切到文本终端（Ctrl+Alt+F3），重启session或者直接reboot。

第三种是nvidia-smi能跑，但GPU-Util和显存都是0。这个不一定是驱动问题，后面在Ollama章节再排查。

确认驱动OK之后再开桌面环境，等桌面跑起来没有花屏、没有循环登录，这就算过关了。

3. Ollama网关打通：安装、GPU识别与显存控制

3.1 安装Ollama并确认服务正常

驱动这块绿了以后，最新版本的Ollama安装很简单，官方一条命令：

curl -fsSL https://ollama.com/install.sh | sh

脚本会检测系统架构、安装二进制文件，同时注册systemd服务。装完之后：

sudo systemctl status ollama

看到active (running)就说明服务起来了。如果没起来，多半是网络下载不完整，或者是系统里缺少某些基础库，可以先用ollama --version确认命令是否可用。

在Ubuntu上Ollama默认监听127.0.0.1:11434，只允许本机访问，如果要让局域网其他机器访问，需要在环境变量里改OLLAMA_HOST，这个后面会讲。

下载模型慢是很多人头疼的问题。默认源是Ollama官方的模型仓库，国内网络环境下确实不稳。我常用的做法有两种：一是手动从模型站下载GGUF格式文件，然后通过Modelfile导入本地；二是直接选择国内可访问的镜像站点，把模型文件先拉到本地再导入。

手动导入模型的方法很简单。假设你下载好了qwen2.5-7b-instruct-q4_k_m.gguf，先写一个Modelfile：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

然后在同目录下执行：

ollama create qwen2.5-7b -f Modelfile

就能在ollama list里看到这个模型了。这种方式不仅是下载慢的解决办法，还可以让你用到Ollama官方库里没有的特殊量化版本。

3.2 用 nvidia-smi 和 ollama ps 双重验证GPU加载

装好模型之后，最关键的一步来了：确认模型真的跑在显存上。

我的验证方法是开两个终端，终端A跑模型：

ollama run llama3.1:8b

终端B盯着GPU：

nvidia-smi

如果一切正常，你会看到显存使用量瞬间飙升几GB，GPU-Util也跟着抬高，说明模型权重已经加载进显存了。

另一种更直观的方法是直接看ollama ps：

ollama ps

输出里有一个PROCESSOR列，如果显示100% GPU，说明完全跑在显存上；如果显示40% CPU / 60% GPU，说明显存不够，模型有一部分被拆分到系统内存上跑了，速度会明显慢。

还有一种判断方式是看Ollama的日志：

journalctl -u ollama -f

加载模型的时候，日志里会输出推理引擎的相关信息，比如：

inference compute id=GPU-xxx library=cuda

能看到library=cuda说明GPU后端已经被Ollama正确识别了。

如果nvidia-smi看到显存没涨、ollama ps只显示CPU，那基本可以确定Ollama没走GPU，接下来要检查驱动版本是不是过老，或者环境变量里有没有误设了OLLAMA_NUM_GPU=0。不过99%的新装环境，驱动装好后这里都能通。

3.3 显存需求怎么算：模型大小、量化和上下文

跑模型之前，脑子里最好先有一个账本子，知道自己这块显卡到底能吃下多大的模型。这个估算不需要特别精确，能避免大量的试错时间。

现在的开源模型大多以GGUF格式分发，量化等级从Q2到Q8，数字越小权重文件体积越小、精度损失越大。以7B量级的模型为例：

• Q4_K_M量化版本文件大小大约4.7GB
• Q8_0版本大约7.2GB
• F16原始全精度版本大约13GB以上

权重体积只是基础，运行时还需要额外的显存放KV Cache和CUDA计算缓冲区。KV Cache的大小和上下文长度直接相关，上下文越长，占用越大。Ollama默认上下文长度是2048，如果拉到8192，KV Cache占用可能是原来的四倍。

有个非常粗的估算公式可以参考：

显存需求 ≈ 权重文件大小 × 1.1~1.3 + 上下文相关KV Cache占用

这里的1.1~1.3系数是给CUDA运行时和一些临时缓冲区留的余量。8GB显存跑7B的Q4量化模型，刚好能塞进去，但没什么富余；12GB显存跑14B的Q4模型，也非常勉强。

在训练知识里有点经验的网友应该听说过“低显存运行模型”或者“动态显存”这类关键词，本质都是通过量化、缩短上下文，或者把一部分计算挪到CPU上，来压榨小显存的容量。Ollama的策略比较直接：能放多少层就放多少层，放不下的层offload到CPU。这就是为什么同样是7B模型，8G显存跑和4G显存跑，速度差别能有两三倍。

3.4 用环境变量精细控制Ollama的显存行为

Ollama提供了几个环境变量，可以很灵活地控制显存占用和行为。如果直接用systemd管理服务，可以这样配置：

sudo systemctl edit ollama

在这个override文件里加：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_KEEP_ALIVE=5m" Environment="OLLAMA_MAX_LOADED_MODELS=1"

保存后：

sudo systemctl daemon-reload sudo systemctl restart ollama

说一下这几个变量的意义。

OLLAMA_HOST是监听地址，如果想让局域网内其他设备也能调用这个Ollama服务，必须设成0.0.0.0:11434。注意，公开监听后至少要确认内网环境可信，否则任何人都能调你的模型，模型加载多了显存会被挤爆。

OLLAMA_KEEP_ALIVE控制模型在显存里的驻留时间。默认是5分钟，意思是模型空闲5分钟后才会从显存里卸载。如果你的机器显存不大，又需要频繁切换不同模型，建议把这个值设短一点，例如30s，避免多个模型同时占用显存。

OLLAMA_MAX_LOADED_MODELS限制同时加载的模型数量。默认是0（不做限制），如果显存小，建议设为1，保证同时只有一个人在最吃显存的模型占着资源。

此外还有一个OLLAMA_NUM_GPU相关选项。旧版本里可以设置层数来控制GPU和CPU的分工，但新版本已经自动管理，普通用户不需要手动干预。如果你确实想强制全量GPU加载，可以先通过OLLAMA_GPU_OVERHEAD给显存预留一点余量，具体数值建议保留默认，只有遇到CUDA out of memory时才调大。

我实测下来，Ollama的默认策略其实已经比较合理了：有显存它就往显存里放，显存不够才往系统内存溢。你需要做的更多是“管住”它的并发和驻留，不要让它把显存和系统内存都吃满。

4. 显存不足、模型不跑GPU、速度暴跌的排错实录

4.1 常见症状速查表

装驱动、跑Ollama的过程中，绝大多数问题都可以归成下面几类。我把这几年踩过的坑整理成一个速查表，朋友们可以按症状查原因：

这张表看着简单，但每一条背后都有不少细节。下面挑几个最容易踩的展开说说。

4.2 显存不够时，模型被“拆开”跑CPU的识别与对策

我见过很多人在论坛上问：为什么同样的7B模型，别人机器嗖嗖输出，我的机器像挤牙膏一样一个字一个字蹦？多半不是因为模型文件有问题，而是显存不够，模型被拆开跑了。

怎么识别？最直接的是ollama ps的输出。如果PROCESSOR列显示84% CPU / 16% GPU，那CPU绝大概率是瓶颈。因为CPU和GPU之间通过PCIe传输数据，每一层算完都要把中间结果送回去，来回搬运的带宽远远低于GPU内部显存的带宽，整体速度能差一个数量级。

面对这种情况，优先考虑三个调整方向。

第一个方向是减小模型体积。同一个模型，Q4_K_M换成Q3_K_S，显存占用能降30%左右。代价是生成质量会有肉眼可见的下降，尤其是长文本和代码场景。

第二个方向是缩短上下文长度。如果你平时只是简单对话，不需要多长的记忆，用/set parameter num_ctx 1024或者启动时传入：

ollama run qwen2.5:7b --num-ctx 1024

能明显降低KV Cache的显存占用。实测8G显存跑7B模型，把上下文从8192降到1024，能多留出至少1~2GB显存给模型本体，加载速度会快不少。

第三个方向是减少并发。如果同时开了多个聊天窗口，或者后端有多个服务同时调同一个模型，显存会被多个会话切走。OLLAMA_KEEP_ALIVE设短一点、OLLAMA_MAX_LOADED_MODELS设为1，能有效避免这种情况。

如果三个方向都试过还是卡，那就老实换个小模型吧。8G显存跑7B模型的Q4版本已经是极限体验，14B模型虽然能勉强加载，但一旦上下文一长就触发CPU offload，体感反而更差。

4.3 不同显存规模下的模型推荐清单

经常有人问我：“我这个显卡能不能跑xxx模型？”与其一个个回复，不如直接出一份按显存规模划分的模型清单。这个清单基于我实际跑过的组合，以及模型社区里大量用户的反馈，量化等级默认都是Q4_K_M。

• 8GB显存：推荐qwen2.5:7b、llama3.1:8b、deepseek-r1:7b。Q4量化权重大概在4.7~5.2GB之间，剩下的空间给KV Cache，够跑1024~2048的短上下文。
• 12GB显存：推荐qwen2.5:14b、gemma2:9b、glm4:9b。14B模型的Q4版本大概9GB左右，12G显存能跑2048上下文，再拉长就有CPU offload风险。
• 16GB显存：推荐qwen2.5:14b、llama3.1:8b（可以拉很长的上下文）、deepseek-r1:14b。16G跑14B非常舒服，模型全量进显存后速度基本接近硬件极限。
• 24GB显存（比如RTX 3090/4090）：推荐qwen2.5:32b、yi:34b的Q4量化版本，约20GB左右。32B模型在24G上能跑，但基本没有余量，上下文最好控制在2048以内。
• 48GB以上：可以考虑llama3:70b或qwen2.5:72b的Q4版本，大约40GB左右，基本就是本地大模型的顶配体验了。

如果你有800G显存的那种服务器，当我上面什么都没说，直接上全精度模型吧。

4.4 特殊场景：双显卡笔记本、Docker、虚拟机

最后补充三个容易被忽略的特殊场景。

双显卡笔记本在Ubuntu上是个老大难。NVIDIA Optimus技术让系统里同时存在核显和独显，驱动装好后大概率默认只跑核显。可以通过以下命令手动切换：

sudo prime-select nvidia

切换到N卡后重启，再跑nvidia-smi，就能看到独立显卡被系统接管了。在Ollama场景下，如果不想全局切独显，也可以只让Ollama进程使用N卡，具体方式取决于运行环境，但通常来说prime-select on-demand模式配合CUDA_VISIBLE_DEVICES可以达到目的。

Docker场景下跑Ollama，除了在宿主机装好驱动之外，还需要在容器里挂载GPU设备。这里需要用NVIDIA Container Toolkit，安装后启动命令加上：

docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama

注意，宿主机如果连nvidia-smi都跑不通，容器里的GPU直通一定也跑不通，所以Docker部署之前先确保宿主机GPU环境是通的。

虚拟机场景，不管是VMware还是QEMU/KVM，如果虚拟机里跑Ollama想让N卡真正派上用场，必须做GPU直通（PCIe Passthrough），把物理显卡完整地交给虚拟机。普通的VMware显卡加速只是虚拟显卡，nvidia-smi在虚拟机里要么看不到卡，要么看到的是虚拟型号，装驱动意义不大。如果你只是在Windows虚拟机里装Ubuntu再跑Ollama，我建议还是换物理机或者做好直通，否则这条路基本走不通。

我个人的经验是：Ubuntu物理机装好驱动跑Ollama，稳定性和性能都远好于虚拟机方案，这也是我为什么一开始就推荐大家用物理机来跑这套东西。虚拟机适合学习Ubuntu本身，真要跑大模型，还是要让GPU直通到最底层。

最后分享一个调节心态的小技巧：如果你用的是8G显存显卡，别执着于跑14B以上的模型。模型能不能加载和能不能“好用”是两回事，一个能完整跑在显存里的7B Q4模型，体验远好于一个被迫拆到CPU上的14B模型。把上下文设短一点、量化选稳一点，日常用完全够了。

每次重装驱动或者升级内核，我都会先跑一遍nvidia-smi确认驱动正常，再跑一遍ollama ps确认模型跑在GPU上。这两个命令已经成了我判断整套环境是否健康的“体检套餐”。先驱动后Ollama再调参数，顺序别搞反，能帮你省下一大半的折腾时间。