企业官网建设流程全解析

如果你在 Ubuntu 服务器上捣鼓过 Ollama，大概率遇到过这种让人血压升高的场景：nvidia-smi里清清楚楚能看到显卡、驱动版本和显存容量，Ollama 也正常启动了，结果一ollama run拉起大模型，CPU 直接飙到 100%，显存占用纹丝不动，显卡风扇安静得像没下班一样。我最初还以为是拉取的模型没有 GPU 版本，后来才发现根本不是模型的问题，而是本机 Ollama 版本太旧，加上之前安装时留下的文件和 systemd 服务互相打架，让新版进程一直在偷偷用 CPU 推理。

这篇文章我就按自己实际排查的顺序来写：先把 Ubuntu 下 Ollama 无法使用 GPU 的常见原因拆开，再给出一套完整的旧版本卸载、新版本下载安装步骤，最后带你跑通一个大模型并用命令验证 GPU 确实在干活。无论你是刚开始接触本地大模型的小白，还是已经折腾了一段时间没搞定老手，照着这套流程走一遍，基本能省下大把试错时间。

1. GPU不生效的逐层排查：不急着重装，先把症状看透

很多人一遇到 GPU 不生效就直接卸载重装，但装完之后问题依旧。原因很简单：没搞清楚到底是哪一层出了问题。Ollama 要用上 GPU，至少要满足三层条件：硬件层、驱动层、服务层。任何一层断链，表现都是“GPU 没用上”，但处理方式完全不同。

1.1 硬件层：显卡驱动到底有没有正常工作

第一步永远是执行nvidia-smi，看驱动是否正常响应。如果输出正常，能看到类似这样的表格：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 470.129.06 Driver Version: 470.129.06 CUDA Version: 11.4 | +-------------------------------+----------------------+----------------------+

这说明驱动已经装载，GPU 能被系统识别。如果命令报了Failed to initialize the NVML或者提示找不到显卡，那问题就不在 Ollama，而在 NVIDIA 驱动本身。这时候需要先解决驱动，常见做法是：

sudo ubuntu-drivers autoinstall sudo reboot

或者用 apt 手动安装对应版本的nvidia-driver-xxx包，装完重启后再次确认nvidia-smi能正常输出。这里踩过一个坑：有些云服务器或者迷你主机用的是 NVIDIA 的 Grace Hopper 或者低速独显，ubuntu-drivers不一定能识别到，需要去硬件厂商提供的驱动源里装，别硬套通用方案。

1.2 运行库与驱动版本的匹配关系

nvidia-smi顶部显示的CUDA Version: 11.4只是当前驱动所支持的最高 CUDA 运行版本，并不代表你系统里装了 CUDA Toolkit。很多人在这里被误导，以为要手动安装对应 CUDA 才能让 Ollama 用上 GPU。

Ollama 的 GPU 加速机制不太一样：它把 CUDA runtime 直接打包进了发布构件里，只要本机驱动版本不是太老，通常能直接利用显卡。真正的问题往往出在“旧版 Ollama 内置的 CUDA 绑定过旧，和新驱动不匹配”，或者“系统里同时存在多个 CUDA 版本导致动态链接器找错了库”。这也是为什么很多人驱动没问题、模型也能跑，但 GPU 始终不生效——Ollama 本体太旧了。

经验值：如果你发现nvidia-smi显示驱动版本是 470.x 或更早，却非要跑最近几个月的 Ollama 版本，基本都能跑，但个别型号的旧卡（比如计算能力 5.x 的老卡）在新版里可能反而被放弃支持。这块需要结合实际硬件来判断，不能一概而论。

1.3 Ollama服务日志里的关键行

在硬件和驱动都正常的前提下，接下来要看的不是ollama run窗口，而是系统服务日志。Ollama 通过 systemd 托管时，日志里会直接写明推理设备。执行：

journalctl -u ollama -f

正常加载 GPU 时，会看到类似：

msg="inference compute id=GPU_0 library=cuda"

如果一直显示：

msg="inference compute id=CPU library=cpu"

那基本可以确定 Ollama 确实没识别到显卡。到这里问题就聚焦在两个方向上：一是 Ollama 版本太旧导致 GPU 探测逻辑有 bug，二是安装残留让服务加载了错误的运行文件。我在实际排查中超过一半的情况是第一种，而且重装新版后立竿见影。

2. 卸载旧版本最容易踩的四个残留角落

如果你确定要重装新版，最忌讳的就是简单apt remove ollama或者直接删一个二进制文件。Ollama 在 Ubuntu 上的安装文件分散在多个目录，systemd 服务、库文件、模型缓存、环境变量各占一块，任何一个角落没清理干净，新版装完可能还是在调用旧的库文件。

2.1 systemd服务文件与守护进程残留

旧版卸载后会留下/etc/systemd/system/ollama.service这类服务文件。你重装新版时，安装脚本检测到服务文件已存在，可能会跳过覆盖，导致 systemd 启动的还是旧版定义的那套进程参数。更麻烦的是，systemctl daemon-reload如果没有执行，系统里会残留一堆无效的 unit 文件引用。

我建议在卸载阶段就顺手把这些服务文件全删掉：

sudo systemctl stop ollama sudo systemctl disable ollama sudo rm -f /etc/systemd/system/ollama.service sudo rm -f /usr/lib/systemd/system/ollama.service sudo rm -f /lib/systemd/system/ollama.service sudo systemctl daemon-reload

有些机器上曾经手动启动过ollama serve，进程还在后台跑着，卸载后重装时端口 11434 被占用，新服务起不来。这时候用ps aux | grep ollama查一遍，把残留进程也 kill 掉。

2.2 各种路径下的二进制与库文件

Ubuntu 下 Ollama 的安装位置比较分散。官方安装脚本默认会把主程序放到/usr/local/bin/ollama，而部分 apt 源版本会放到/usr/bin/ollama，库文件则可能出现在/usr/local/lib/ollama或者/usr/lib/ollama。

如果旧版本是从不同渠道装的，这几个目录里可能同时存在多个二进制。shell 的PATH搜索顺序决定了哪个版本先被调用，如果你一直用/usr/local/bin下的新版，但 systemd 服务引用的却是/usr/lib/ollama下的旧库，那么一切表现都会像“旧版在运行”。

清理时可以执行一遍：

which -a ollama ls -l /usr/local/bin/ollama /usr/bin/ollama 2>/dev/null ls -ld /usr/local/lib/ollama /usr/lib/ollama 2>/dev/null

把能看到的二进制和库目录全部删除。只保留一个版本的安装路径，避免后续混淆。

2.3 模型缓存和配置目录

模型缓存默认在~/.ollama下，用 root 跑服务时则在/root/.ollama。这个目录里存了已经拉取的模型分片、manifest 文件和一些配置，不删除也不影响新版安装，但会占用磁盘空间。更重要的是，如果你之前改过OLLAMA_MODELS之类的环境变量并且写进了某个配置文件，残留的配置可能会覆盖新版的默认路径。

我的习惯是：如果不是有必须保留的模型，直接删掉一了百了。

sudo rm -rf /root/.ollama rm -rf ~/.ollama

如果你的模型文件放在专门的磁盘目录，记得先确认路径再删别把数据卷也一起清掉。

2.4 shell配置里的残留项与顽固进程

还有一个容易忽略的地方是.bashrc、.zshrc或/etc/profile.d/里可能有人以前手动加过export OLLAMA_HOST=...或者export PATH=/usr/local/ollama/bin:$PATH之类的环境变量。这些残留项不会导致 GPU 失效，但会影响你对新版本的判断，比如明明已经删掉了旧版，却仍然能找到ollama命令，查了半天才发现来自 shell 别名或环境变量。顺手把这些也清掉，避免重装后出现“版本对不上”的错觉。

2.5 一套可以照抄的卸载命令序列

把上面几个步骤汇总成可复制的命令串，适合 Ubuntu 20.04/22.04/24.04 这类用 systemd 的发行版：

sudo systemctl stop ollama sudo systemctl disable ollama sudo rm -f /etc/systemd/system/ollama.service /usr/lib/systemd/system/ollama.service /lib/systemd/system/ollama.service sudo rm -f /usr/local/bin/ollama /usr/bin/ollama sudo rm -rf /usr/local/lib/ollama /usr/lib/ollama sudo rm -rf /root/.ollama sudo rm -rf ~/.ollama sudo systemctl daemon-reload pkill -f ollama

执行完这些命令后，建议执行which ollama，如果还能找到输出，继续检查是不是 shell 缓存或者 PATH 残留。确保这一步返回 nothing，才算真正清干净。

3. 下载安装新版Ollama：安装方式和验证清单

清理完成之后，安装新版就清爽很多了。Ollama 官方提供了自动安装脚本，绝大多数人直接跑脚本就够用。

3.1 为什么选官方安装脚本而不是手动装

如果你只是为了解决 GPU 不生效的问题，我没有理由劝你手动去解压 tar 包。官方脚本的核心价值在于它会自动处理 systemd 服务单元、用户组、路径规范和依赖检测，把前面提到的“装不干净”问题通过一个标准流程解决掉。

脚本执行方式很简单：

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

要注意的是，这种“curl 管道 sh”的安装方式只适合你信任官方源的场景。如果在内网环境或者公司服务器上，建议先下载 install.sh 审查一遍再执行。

安装脚本跑完会看到类似这样的输出：

>>> Installing ollama to /usr/local >>> Adding ollama user to video group... >>> Creating ollama user... >>> Adding current user to ollama group... >>> Creating systemd service file /etc/systemd/system/ollama.service >>> Enabling and starting ollama service...

这里面两行值得注意：把 ollama 用户加到video组，是为了让进程有权访问 GPU 设备节点；创建 systemd service 文件后脚本会自动systemctl enable和systemctl start。

3.2 安装过程的完整输出怎么看

如果你看到服务已经Active: active (running)，说明安装过程正常。接下来先验证版本：

ollama --version

新版版本号通常会是一个类似0.5.x的数字，早晚版本差异很大，但不要只以版本号判断新旧，重点看下一次运行模型时日志里的推理设备。

再检查一次 systemd 服务状态：

systemctl status ollama

正常输出里应该包含：

Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: enabled) Active: active (running)

如果状态是failed，大概率是端口被占或者权限问题。sudo journalctl -u ollama -n 50可以直接看到失败原因。

3.3 安装后的服务自检与权限确认

新版安装完成后，建议顺手确认一下/dev/nvidia*设备节点的权限。Ollama 的 systemd 服务默认以User=ollama运行，如果ollama用户不在video组里，即使驱动正常，进程也可能因为访问不了设备节点而退回 CPU 模式。

groups ollama ls -l /dev/nvidia0

如果用户缺少权限，可以手动补上：

sudo usermod -aG video ollama sudo systemctl restart ollama

这也是很多“新版本还是用 CPU 跑”问题的隐藏原因，表面上装好了，实际权限没到位。

4. 让大模型真正跑在GPU上：运行、验证与调优

安装完成后，接下来就是拉模型、跑模型，然后通过各种命令确认 GPU 确实在干活。

4.1 拉取模型并启动对话

Ollama 的模型仓库里有很多现成模型，这里以我经常用的qwen2.5:7b为例：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

首次 pull 会下载几个 GB 的分片文件，具体大小取决于模型参数量和量化格式。7B 模型通常用 4-bit 量化后体积在 4-5 GB 左右。下载完成后会直接进入交互式对话界面，直接输入一句话测试：

>>> 你好，用一句话介绍你自己。

如果模型开始正常回复，说明基础链路已经通了。

4.2 用ollama ps和nvidia-smi双重确认GPU生效

真正要确认 GPU 是否在做推理，光看对话速度是不够的。在模型对话保持打开的另一个终端里执行：

ollama ps

输出里有一个PROCESSOR列，如果显示GPU，说明当前模型已经加载到显存：

NAME ID SIZE PROCESSOR UNTIL qwen2.5:7b a1b2c3d4 4.2 GB GPU 5 minutes

同一时刻再跑一遍nvidia-smi，你应该能看到类似：

+-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | |=============================================================================| | 0 N/A N/A 12345 C ollama 4210MiB | +-----------------------------------------------------------------------------+

如果ollama ps显示CPU，而nvidia-smi的进程列表里也没有 ollama，那就说明新版安装后依然没有走 GPU，需要回到第 3 节的权限和服务日志去排查。如果nvidia-smi有进程但显存占用很小，可能是模型部分层被卸载、或者 KV cache 使用量不高，通常不用太担心。

4.3 CPU与GPU跑同一个模型的体感差异

同样是 7B 参数规模模型，在普通桌面级 CPU 上生成一个 token 大概要几百毫秒到一两秒，而在中端显卡上可以降到几十毫秒甚至更低。如果你之前一直用 CPU 跑，切换到 GPU 后最明显的感觉是“输出速度像换了个模型”，而且在对话过程中 CPU 占用率会明显下降，因为计算主体转移到了显卡上。

如果切到 GPU 后依然卡顿，先别急着怪设备。可以看看是不是模型被重组 KVCache 时显存不够，或者同时加载了太多模型。这里可以临时调低上下文长度试试，比如ollama run qwen2.5:7b --num-ctx 2048，看看生成速度是否改善。

4.4 多GPU选择与内存限制

如果你机器上有两张以上显卡，Ollama 默认会尝试把模型分配到所有可用设备上。可以通过设置CUDA_VISIBLE_DEVICES环境变量来指定只使用某一张卡：

sudo systemctl edit ollama

在打开的编辑窗口里写入：

[Service] Environment="CUDA_VISIBLE_DEVICES=0"

保存后重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

对于显存较小的卡，比如 8GB 左右的显卡，跑 7B 模型通常没问题，但如果同时开多个模型或者把上下文长度调得非常大，就可能出现out of memory。这时候可以把OLLAMA_MAX_LOADED_MODELS环境变量设为 1，限制同一时刻只保留一个加载模型，减少显存压力。

5. 模型日常使用的几条实战经验

模型能跑在 GPU 上只是第一步，真正用得顺手还需要了解模型管理、服务参数和性能调优。这几条是我平时用得最多的经验，整理出来供参考。

5.1 通过Modelfile定制专属模型

Ollama 支持用 Modelfile 构建自定义模型。你可以在基础模型之上指定系统提示词、温度、上下文长度等参数，生成一个专属入口。

比如创建一个Modelfile：

FROM qwen2.5:7b PARAMETER temperature 0.7 PARAMETER num_ctx 4096 SYSTEM "你是一个熟悉 Linux 运维的中文助手，回答尽量简洁直接。"

然后执行：

ollama create my-helper -f Modelfile ollama run my-helper

这样做的好处是不用每次对话都重复输入提示词，也方便团队里统一模型行为。多个自定义模型之间互不干扰，删除也很简单。

5.2 服务端环境变量对并发行为的影响

Ollama 服务默认会保持模型在内存/显存中一段时间，避免每次请求都重新加载。相关环境变量有三个比较关键：

• OLLAMA_KEEP_ALIVE：模型保持加载的时间，默认 5 分钟。如果你频繁调用同一模型，可以调大到30m或1h，减少冷启动次数。
• OLLAMA_NUM_PARALLEL：同一个模型并行处理请求的数量。默认值是 1，调大会增加吞吐，但也会增加显存占用。
• OLLAMA_MAX_LOADED_MODELS：同时加载模型数量上限。小显存机器建议设为 1，否则频繁换入换出会导致首字延迟很高。

修改方式同上，systemctl edit ollama写入环境变量后重启服务即可。

5.3 模型镜像的磁盘管理与杂项

拉取的模型都存放在~/.ollama/models目录，日积月累会占用大量磁盘空间。常用的管理命令：

ollama list # 查看本地模型列表 ollama rm 模型名 # 删除某个模型 ollama cp 模型名 新名称 # 复制模型 ollama pull 模型名:tag # 拉取指定标签

建议定期用ollama list检查本地模型，用完就删，保持磁盘空间充足。另外，模型下载过程中如果中断，重新执行ollama pull一般会从断点继续，不用删掉重下。

如果你们团队有多台机器，考虑共享一个模型存储目录，通过 NFS 挂载到多台机器上，可以省去每台机器分别拉取模型的重复流量。Ollama 的服务模型路径由OLLAMA_MODELS控制，挂载时保证权限一致即可。

最后再分享一个小技巧：如果你在journalctl -u ollama里看到大量inference compute id=CPU的日志，不要急躁，先按第 1 节的三层排查走一遍，再执行第 2 节的完整清理，最后用第 4 节的ollama ps做最终确认。这套流程我前前后后给好几个同事解决过问题，基本都能一次搞定。GPU 跑大模型这条路，说难不难，但细节一个都不能漏。