想在一台 Ubuntu 24.04 服务器上跑自己的大模型服务，又不想把数据交给外部 API，Open WebUI 配合 Ollama 是目前我试下来最省心的一套本地方案。它解决的问题很直接：Ollama 负责把开源模型拉下来跑推理，Open WebUI 提供一个像模像样的网页聊天界面，两者通过一个 OpenAI 兼容的接口对接起来。无论你只有一台闲置 PC，还是配置不错的专用服务器，都能照着这条路搭出一套可日常使用的对话服务。
这篇文章我会把整套部署过程按“环境检查 -> Ollama -> Open WebUI -> 联调测试 -> 守护进程”的顺序写清楚。每一步除了给命令，还会解释为什么这么做，以及我第一次装的时候在哪里卡过。如果你之前没碰过 Linux 服务器，也能照做；如果已经有一定基础，可以直接跳到第 3 章之后看部署细节。
1. 为什么是 Ollama + Open WebUI，而不是直接跑 Web 服务
先聊清楚选型，很多人一上来就急着敲命令，结果装完发现不是自己想要的东西。
Ollama 和 Open WebUI 是两条独立的东西。Ollama 专注做一件事：管理模型文件、启动本地推理服务。它本身不带聊天界面，启动后默认监听 11434 端口，提供的是一个 HTTP API。你直接用 curl 也能跟它对话，但没有任何图形界面，对普通用户不友好。Open WebUI 补上了这一层，它负责提供网页聊天窗口、历史会话、文档上传、用户管理等体验类功能。
这两者为什么能配合？Open WebUI 内部实现了 OpenAI 兼容接口的客户端，而 Ollama 从某个版本开始对外暴露了/v1路径，专门兼容 OpenAI 的请求格式。所以 Open WebUI 只要把请求地址指向 Ollama 的 11434 端口，就能像调用外部大模型 API 一样调用本地模型，不需要写胶水代码，也不需要改模型文件。
从实际需求角度看，这种组合适合三类人：
- 数据敏感的团队：文本内容不出内网，不经过第三方服务，适合内部知识库、工单助手这类场景。
- 想反复试模型的人：Ollama 切换模型只需要一条命令，同一个 WebUI 界面可以对应多个底模，不用每个模型搭一套 UI。
- 刚入门本地大模型的人：部署链路短，不需要懂 Kubernetes，也不需要自己写推理服务，一个 Docker 容器加一个二进制文件就能跑起来。
反过来说，如果你追求的是训练模型或者精细调优，那这套方案不适合你，Ollama 更适合推理而不是训练。如果只是临时调几个 API 玩一下，也不用部署 WebUI，直接 Ollama 就够了。认清边界，后续才不会白折腾。
2. 动手前先检查环境：Ubuntu 24.04 上最容易出问题的三个地方
很多人部署失败不是因为命令错了，而是基础环境不对。我建议先花十分钟把下面三件事确认完，比出错之后排错要省时间得多。
2.1 系统版本、内存、磁盘空间
Ubuntu 24.04 的版本号可以直接用lsb_release -a查看。理论上 22.04 甚至 20.04 也适用于本文大部分命令，但 24.04 的 Python 是 3.12，软件源里的 Docker 版本也较新，整体兼容性更省心。
内存和磁盘分别关乎推理速度和能否下载模型。我自己的判断标准是：
- 内存：跑 7B 到 8B 参数量的模型，建议至少 16GB 内存，32GB 会比较从容。内存不够也能跑，但加载模型和对话速度都会变慢。
- 磁盘：模型文件不是小东西。7B 模型 Q4 量化后大约 4.7GB，14B 约 9GB，32B 约 20GB，70B 级别要 40GB 往上。如果只是试一试，预留 50GB；如果打算长期用，建议给模型单独挂一块数据盘，而不是堆在系统盘。
检查命令很简单：
free -h df -h /如果磁盘空间不够，有些朋友会临时把模型目录软链到移动硬盘，我不建议这么做，USB 外置盘的读写延迟会让模型加载和推理都很难受，最好是 SATA SSD 或 NVMe。
2.2 NVIDIA 驱动与显卡情况
Ubuntu 24.04 默认内核是 6.8，系统自带的显卡驱动是开源的 nouveau。如果你有一块 NVIDIA 显卡，直接用开源驱动跑 Ollama 大概率会失败，或者加载模型极慢。Ollama 的 CUDA 后端需要安装 NVIDIA 官方闭源驱动。
先看显卡型号：
lspci | grep -i nvidia nvidia-sminvidia-smi如果提示 command not found，说明驱动没装。在 Ubuntu 上最省事的方式是：
sudo ubuntu-drivers list这个命令会列出当前系统支持的闭源驱动版本，通常会有 recommended 标记。然后直接：
sudo ubuntu-drivers install sudo reboot重启后再看nvidia-smi，如果能正常显示显卡型号和显存，就说明驱动就位了。
没有 NVIDIA 显卡也不用放弃，Ollama 支持 CPU 推理，只是速度慢不少。比如 7B 模型在纯 CPU 环境下，每秒生成几个 token 是正常水平，拿来聊天能忍，做文档分析会比较痛苦。如果你的机器只有 CPU，建议先选 7B 以下的模型试水。
2.3 防火墙、端口和 Python 环境
Ubuntu 24.04 默认不一定启用了 UFW 防火墙，但如果你之前手动开过，需要确保 11434 和 3000 这两个端口是放行的。11434 是 Ollama 的 API 端口，3000 是 Open WebUI 的默认 Web 端口。
sudo ufw status sudo ufw allow 11434/tcp sudo ufw allow 3000/tcp如果是在云服务器上部署，还要去安全组控制台放行对应的入方向规则，这个很容易漏。另外要注意，如果你打算用 Open WebUI 的 pip 方式安装，系统 Python 环境尽量别直接用，开一个虚拟环境是更安全的选择，具体我在第 4 章说。
3. 安装 Ollama：官方脚本、存储目录与常用运维配置
Ollama 的安装是整套方案里最简单的一环，但安装完之后的存储调整和并发参数设置，才是真正影响长期使用体验的地方。
3.1 官方安装脚本与手动安装两条路
官方推荐一条命令：
curl -fsSL https://ollama.com/install.sh | sh这个脚本会检测操作系统架构，把 Ollama 二进制放到/usr/local/bin，同时配置好一个 systemd 服务。安装完直接ollama --version看版本。
如果你不想用脚本，也可以去官方仓库下载二进制包手动解压，放到任意目录，然后自己写 systemd 服务。脚本安装对绝大多数人来说就够了，手动安装更适合“二进制必须放在指定路径”的管控型环境。
这里有个新手容易困惑的点：安装完成后，ollama命令是有了，但服务并不会自动启动。启动方式：
sudo systemctl start ollama sudo systemctl status ollama服务启动后，可以用curl http://127.0.0.1:11434试一下，能返回Ollama is running之类的响应就说明正常。
3.2 模型存储目录，一定要提前规划
Ollama 默认把模型放在/usr/share/ollama/.ollama/models（root 安装时），或者当前用户目录下的.ollama/models。问题在于很多人的服务器系统盘不大，而模型动辄十几 GB，很容易把根目录塞满。
我建议安装完成后、下载第一个模型之前，先把存储目录改到数据盘。方法是通过 systemd 的环境变量覆盖：
sudo systemctl edit ollama在打开的文件里加：
[Service] Environment="OLLAMA_MODELS=/data/ollama/models"保存后执行：
sudo systemctl daemon-reload sudo systemctl restart ollama然后ollama list确认没有报错，再检查一下/data/ollama/models目录是否自动创建。这个步骤看起来多花两分钟，但能避免几个月后“磁盘已满，Ollama 无法写入新模型”的尴尬。
3.3 并发参数与基础运维命令
Ollama 默认的并发处理能力偏保守。如果你的服务器内存和显卡都足够，但一次只能处理一个对话，体验会比较差。可以通过环境变量OLLAMA_NUM_PARALLEL调整同时处理的请求数：
sudo systemctl edit ollama[Service] Environment="OLLAMA_NUM_PARALLEL=4"数字不是越大越好，它取决于显存。7B 模型 Q4 量化大约占 5~6GB 显存，如果你的卡是 24GB，并发 4 基本没问题；如果是 8GB 卡，设置并发 2 都容易显存溢出。建议先从 2 试，观察nvidia-smi的显存占用和ollama ps的输出，再逐步往上加。
日常运维里最常用的命令也就这几个：
ollama list # 查看本地已下载的模型 ollama ps # 查看当前正在运行的模型 ollama pull 模型名 # 下载模型 ollama rm 模型名 # 删除模型 ollama run 模型名 # 命令行直接对话ollama ps很多人不看，但它很有用。当觉得对话变慢时，看一眼这里有没有多个模型驻留显存，如果有且不是你立刻要用的，用ollama stop 模型名把它清掉，能明显释放显存。
4. 安装 Open WebUI：Docker、pip、源码三种方式的取舍
Open WebUI 的官方文档给了多种安装方式，实际能选的也就三种：Docker、pip、源码运行。我给一个明确的建议：有 Docker 就用 Docker，没有 Docker 再用 pip。
4.1 Docker 方式，最省心也最推荐
Docker 方式把所有依赖打包在镜像里，不需要担心前端编译、Python 包冲突、Node 环境缺失这些事。命令如下：
docker run -d \ --name open-webui \ --restart always \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui-data:/app/backend/data \ open-webui/open-webui:main逐行解释一下：
-p 3000:8080：宿主机 3000 端口映射到容器内 8080 端口。--add-host=host.docker.internal:host-gateway：让容器内可以通过host.docker.internal访问宿主机。因为 Ollama 跑在宿主机上，而 Open WebUI 在容器里，没有这一行，容器默认访问不到宿主机服务。-v open-webui-data:/app/backend/data：持久化数据卷。Open WebUI 的数据库、密钥、用户信息都存在这里。不映射的话，容器一删全没。
Docker 方式唯一的痛点是镜像拉取速度。如果你发现docker pull非常慢，可以在 Docker 配置文件里配置公共镜像加速器，具体地址每个服务商不一样，选自己网络可达的即可。实在拉不动，就切到 pip 方式。
4.2 pip 方式，适合没有 Docker 的轻量机器
如果你的服务器不打算装 Docker，或者内存本身就紧张，pip 方式可以少一层容器开销。Ubuntu 24.04 自带 Python 3.12，先建虚拟环境：
python3 -m venv venv source venv/bin/activate pip install -U open-webui启动：
open-webui serve --host 0.0.0.0 --port 8080这里有一个很多人会踩的坑：如果你直接pip install open-webui，它会装到系统 Python 目录，以后升级或者卸载容易跟系统包互相干扰。用虚拟环境能避免这个问题。另外，Open WebUI 依赖的包里有不少需要编译的组件，如果你的服务器 CPU 老，安装过程可能比较慢，耐心等就行。
pip 方式下 Open WebUI 和宿主机 Ollama 的通信没有容器网络隔离，默认配置就能连通，反而省了配置这一步。
4.3 源码方式，适合要改代码的人
如果你打算二次开发，比如改前端界面或者加自定义逻辑，才需要走源码安装：
git clone 官方仓库 cd open-webui python3 -m venv venv source venv/bin/activate pip install -e .源码方式能让你改完代码重启即生效，但安装依赖时间最长，第一次启动还要等前端资源构建。普通用户不建议碰这种方式。
4.4 三种方式对比
| 方式 | 适合场景 | 依赖复杂度 | 升级难度 | 资源占用 |
|---|---|---|---|---|
| Docker | 绝大多数人 | 低，镜像自带 | 低，换镜像重建 | 多一层容器开销 |
| pip | 无 Docker 的轻量环境 | 中，依赖较多 | 中，venv 内升级 | 较低 |
| 源码 | 二次开发、改 UI | 高，前后端都要装 | 高，需处理合并 | 最高 |
我自己的选择逻辑很简单：能 Docker 就 Docker。原因是升级方便，docker pull新镜像再重建容器即可，不用管 Python 依赖怎么迁移。但如果你在国内网络环境下镜像拉不动，pip 方式才是备选。
5. 第一次对话前的最后几步：模型选择、接口联调与常见坑
环境都装好了，不等于能直接对话。Open WebUI 第一次启动会有一个初始化流程，Ollama 也需要把模型拉下来。这中间有几个细节经常卡人。
5.1 模型选择：不是越大越好，先看显存再看算力
Ollama 模型库里有大量模型可选，新手最常犯的错误是一上来就选 70B 级别的模型，然后发现对话速度慢到无法接受。
我列一个粗略的对照表，量化精度以 Q4 为主：
| 模型参数量 | 量化后体积 | 推荐显存 | 适合场景 |
|---|---|---|---|
| 7B | 约 4.7GB | 8GB 起步 | 日常聊天、轻量问答 |
| 8B | 约 4.9GB | 8-10GB | 通用对话、代码助手 |
| 14B | 约 9GB | 16GB 起步 | 需要更好推理能力的场景 |
| 32B | 约 20GB | 24-32GB | 复杂逻辑、长文本分析 |
| 70B | 约 40GB | 48GB 以上 | 高质量生成，资源要求高 |
选模型的关键不只看参数量，还要看显存余量。显存不够时 Ollama 会把部分层放到内存里，速度骤降。如果显卡只有 8GB，老老实实跑 7B/8B 模型，流畅度远比纸面参数重要。
下载模型用：
ollama pull 模型名下载速度取决于你的网络。如果拉取过程中反复超时，可以多试几次，或者换个网络环境再拉。模型下载是支持断点续传的，中断后重新执行 pull 会继续。
5.2 第一次打开 WebUI，管理员账号不能乱填
浏览器访问http://服务器IP:3000，Open WebUI 会要求先注册账号。这里有一个重要规则：第一个注册的账号会被自动设为管理员。
这是一个我踩过的坑：初次试用时随手输了一个测试账号，后面正式使用想换管理员，才发现 Open WebUI 没有自助找回/转移管理员的功能，只能进数据库操作或者清空数据卷重来。所以第一次注册时，一定要想好管理员账号和密码，最好用组织内部统一规划的账号名。
注册完成登录后，进入设置页面，看“外部连接”或者“Ollama API”相关配置。默认情况下 Open WebUI 会自动探测同主机的 Ollama，地址一般是http://localhost:11434。
这里分两种情况：
- 如果 Open WebUI 和 Ollama 在同一台宿主机，且 Open WebUI 用 pip 方式运行，通常不需要改配置。
- 如果 Open WebUI 在 Docker 容器里，Ollama 在宿主机，需要把 Ollama 地址改成
http://host.docker.internal:11434。因为我们前面 docker run 时加了--add-host=host.docker.internal:host-gateway，这个地址是通的。
改完地址保存，回到对话页面，如果左侧模型列表是空的，去模型选择框里选一个已下载的模型再开始对话。如果提示连接失败，多半是地址没改对，回到设置里检查。
5.3 对话参数和联网搜索
Open WebUI 的对话界面里，展开高级设置能看到 temperature、top_p 等参数。这些参数不是越高越好：
- temperature 控制随机性。0.1 到 0.3 适合代码生成、事实问答；0.7 以上适合创意写作。
- top_p 一般保持默认 0.9 即可，不需要频繁调整。
另外 Open WebUI 自带联网搜索能力，但它依赖外部搜索 API。需要你自己注册搜索服务商并取得 API Key，然后在设置页填入。这里注意：填 Key 之前先确认这台服务器能访问对应服务商的接口，网络不可达的话，配置了也搜不了。如果网络条件受限，干脆不开启联网搜索，只作为纯本地知识问答来用，反而更稳。
5.4 最容易忽略的：模型加载缓存与首次响应慢
第一次调用某个模型时，Ollama 需要把模型文件从磁盘加载到内存和显存，这个过程会持续几十秒甚至一分钟，然后才有响应。这不是故障，只是首次加载的冷启动开销。
如果你发现后续对话依然很慢，可以打开一个终端执行ollama ps看模型是否驻留。如果模型在ollama ps里消失了，说明它的空闲超时默认值到了五六分钟，已经在后台自动卸载。这时重新发起对话又会重新加载。要想减少这种等加载的现象，可以通过环境变量OLLAMA_KEEP_ALIVE调整驻留时间，单位是秒：
[Service] Environment="OLLAMA_KEEP_ALIVE=86400"设置成 86400 表示让模型在显存里驻留一天，只要显存够，响应速度会稳定很多。但要注意，长时间驻留会影响其他模型加载，如果显存不够大，建议设成 1800 左右即可。
6. 部署完之后的“生产化”：开机自启、日志查看和常见维修
只是能对话，不算完事。一台服务器上跑服务，至少要保证重启后能自动恢复、日志能看、出问题能快速定位。这一章我按自己的操作习惯写一遍。
6.1 Ollama 和 Open WebUI 的开机自启
如果你用的是官方安装脚本安装的 Ollama，它已经注册为 systemd 服务，自启是默认开启的：
sudo systemctl enable ollamaOpen WebUI 要分两种情况。Docker 方式下，如果创建容器时带了--restart always，重启后容器会自动拉起。pip 方式则要自己写 systemd 服务：
[Unit] Description=Open WebUI After=network.target [Service] User=你的用户名 Group=你的用户组 WorkingDirectory=/你的目录/venv Environment="PATH=/你的目录/venv/bin" ExecStart=/你的目录/venv/bin/open-webui serve --host 0.0.0.0 --port 8080 Restart=always [Install] WantedBy=multi-user.target保存后：
sudo systemctl daemon-reload sudo systemctl enable open-webui sudo systemctl start open-webui把用户名、目录替换成实际值，注意WorkingDirectory和ExecStart里的路径都要指向你的虚拟环境。
6.2 日志查看和性能观察
出问题先看日志，这是排查的第一步，不要盲目重装。
Ollama 日志：
sudo journalctl -u ollama -fOpen WebUI 容器日志：
docker logs -f open-webuipip 方式的话：
journalctl -u open-webui -f性能观察方面，nvidia-smi不能只盯着显存占用看，还要关注功耗和 GPU 利用率。如果 GPU-Util 接近 100%，说明推理负载重，对话排队是正常的。如果 GPU-Util 只有个位数但响应也慢，有可能是模型部分层在 CPU 上跑，或者是 OLLAMA_NUM_PARALLEL 设置得太小导致请求排队。
内存层面用free -h看可用内存，特别注意 swap 是否被大量使用。一旦开始用 swap，对话速度会断崖式下跌。
6.3 磁盘膨胀与模型清理
Open WebUI 的数据卷会随时间增长，主要是历史会话和文档上传。如果你长期不清理，几百 MB 甚至几个 GB 都是正常的。Docker 数据卷清理要看实际情况，别动不动就把整个卷删掉，那会连管理员账号一起删没。
比较安全的清理思路是：定期在 WebUI 设置里删除不用的历史会话，而不是直接操作数据库文件。模型层面也一样，用ollama list看哪些模型长期没用，用ollama rm释放空间。
6.4 升级与回滚
升级 Ollama 和 Open WebUI 其实没有官方一键命令，但也不复杂。Ollama 重新跑一次安装脚本即可：
curl -fsSL https://ollama.com/install.sh | sh脚本会保留已有模型，不会覆盖模型文件。Open WebUI 如果是 Docker 方式，先拉新镜像再重建容器：
docker pull open-webui/open-webui:main docker stop open-webui docker rm open-webui docker run ... # 用之前同一套参数重建因为数据卷独立于容器，重建不会丢账号和会话。pip 方式则是pip install -U open-webui。
升级前的好习惯：先拍一个数据卷快照或者备份一下/usr/share/ollama/.ollama/models目录的清单。出问题能退回旧版本，至少能知道之前是哪条命令让服务跑起来的。
整套环境正常跑起来之后，我的最大感受是：本地部署大模型的门槛并不在安装命令，而在于资源规划和网络可达性。Ollama 把底层推理做得足够简单，Open WebUI 把交互体验补得足够完整，真正的风险集中在显存够不够、磁盘够不够、端口通不通这三个朴素问题上。如果你在部署过程中遇到某一步卡住，别急着重装，先看日志，再检查端口和网络，大部分问题都能在十分钟内定位。
最后再分享一个小技巧：配置好之后，把ollama pull模型、nvcc版本青云工具的版本号、数据卷位置这三样信息写在一个部署备注文件里放服务器上。很多问题在你三个月后回来看的时候，都是靠这些备注想起来的。
