这两年很多人想把 AI 助手搬到自己的 VPS 上：聊天记录自己保存，不依赖第三方 API，内部文档也不用丢到外部平台。最常见的组合就是 Ollama + Open WebUI。Ollama 负责拉取和运行模型，Open WebUI 提供一个类似 ChatGPT 的网页界面。
但这里有一个现实问题：不是所有 VPS 都适合跑本地大模型。 如果你拿 1C1G 小鸡直接跑 7B 模型，结果通常不是“私有 AI”，而是 SSH 变卡、内存爆掉、模型响应慢到怀疑人生。本文不鼓励盲目上车，而是先讲配置门槛，再给出一套可回滚、可加固的 Docker Compose 部署方案。
Ollama 可以在 CPU 上跑，但体验差异非常大。下面是比较现实的配置参考：
| VPS 配置 | 能做什么 | 体验预期 |
|---|---|---|
| 2C4G | 只建议测试小模型或远程调用外部模型 | 很慢，容易内存紧张 |
| 4C8G | 能跑 7B/8B 量化模型 | 可用，但不要多人并发 |
| 8C16G | 7B/8B 日常可用，14B 勉强测试 | 适合个人知识库和轻量助手 |
| 16G+ 显存 GPU VPS | 体验明显提升 | 更适合长期使用 |
| 32G+ 内存 / 更高显存 | 可尝试更大模型 | 成本也会上来 |
如果你只是想体验，CPU VPS 可以试；如果你想真正替代 API、多人使用或接入业务系统，优先考虑 GPU VPS，尤其要看显存，而不是只看 CPU 核数。
本文选择 Docker Compose 部署，原因很简单：
- Ollama 和 Open WebUI 可以分开管理。
- 数据目录清晰，方便备份和迁移。
- 出问题可以单独重启容器，不污染宿主机。
- 后续接 Nginx/Caddy 反向代理也更顺手。
如果你已经在用 1Panel，也可以通过应用商店安装 Open WebUI，再把 Ollama 地址填进去。但手写 Compose 更透明，适合排查问题。
建议系统使用 Ubuntu 22.04 / 24.04 或 Debian 12。先更新系统并安装 Docker：
sudo apt update
sudo apt install -y ca-certificates curl gnupg
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
重新登录 SSH 后确认 Docker 和 Compose：
docker version
docker compose version
如果命令正常返回版本号，就可以继续。
mkdir -p ~/ollama-webui
cd ~/ollama-webui
mkdir -p ollama open-webui
目录含义很简单：
ollama/：保存模型文件。open-webui/：保存 WebUI 数据、用户、聊天记录和配置。
模型文件可能很大，建议你的 VPS 至少准备 50GB 以上可用磁盘。如果你准备拉多个模型，80GB 以上更稳。
创建文件：
nano docker-compose.yml
写入下面内容：
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
volumes:
- ./ollama:/root/.ollama
expose:
- "11434"
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
depends_on:
- ollama
ports:
- "127.0.0.1:3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- ./open-webui:/app/backend/data
这里有两个安全点很重要：
- Ollama 只用
expose，不直接暴露到公网。 - Open WebUI 绑定到
127.0.0.1:3000，先只允许本机访问，后面通过 Nginx 或 Caddy 反向代理开放 HTTPS。
不要把 11434:11434 直接映射到公网。Ollama API 一旦裸露，别人可以直接调用你的模型，轻则耗尽资源，重则被滥用。
docker compose up -d
查看状态：
docker ps
查看日志：
docker logs -f ollama
docker logs -f open-webui
如果 Open WebUI 没起来，常见原因是镜像拉取慢、磁盘不足、内存不足。先不要急着重装，先看日志。
进入 Ollama 容器：
docker exec -it ollama bash
拉一个相对小的模型测试：
ollama pull llama3.1:8b
ollama run llama3.1:8b
如果你的机器内存不够，拉模型可能成功，但运行时会非常慢，甚至触发 OOM。低配置 VPS 可以先试更小的模型，比如 3B 或更小的量化版本。
退出容器：
exit
假设你的域名是 ai.example.com，先把 DNS A 记录指向 VPS IP，然后安装 Nginx：
sudo apt install -y nginx certbot python3-certbot-nginx
创建站点配置：
sudo nano /etc/nginx/sites-available/open-webui
写入：
server {
listen 80;
server_name ai.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 3600;
}
}
启用站点：
sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/open-webui
sudo nginx -t
sudo systemctl reload nginx
签发证书：
sudo certbot --nginx -d ai.example.com
完成后访问 https://ai.example.com，第一次进入 Open WebUI 会创建管理员账号。
建议只开放这些端口：
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status
不要开放：
11434：Ollama API 端口。3000：Open WebUI 内部端口，已经由 Nginx 代理。
如果你使用云服务商安全组，也要在那里同步限制。很多人只配置了 UFW，却忘了云防火墙，导致端口仍然能被外网访问。
CPU VPS 跑大模型慢是正常的，不一定是部署错了。你可以从这几方面判断：
htop
free -h
docker stats
df -h
常见瓶颈：
- 内存不足：模型加载后可用内存几乎为 0，系统开始 swap。
- CPU 不支持 AVX2：推理速度会更差。
- 磁盘太慢：模型加载时间很长。
- 并发太多：一个人用还行，多人同时问就卡。
优化建议：
- 从小模型开始，不要直接上 14B/32B。
- 限制使用人数，个人 VPS 不要当公共 AI 服务。
- 模型目录放在 NVMe 磁盘，不要用很慢的大盘鸡。
- 真要日常使用，考虑 GPU VPS 或本地显卡机器。
更新容器：
cd ~/ollama-webui
docker compose pull
docker compose up -d
备份数据：
tar -czf ollama-webui-backup-$(date +%F).tar.gz ollama open-webui docker-compose.yml
如果模型文件太大，也可以只备份 open-webui/ 和 docker-compose.yml，模型以后重新拉取。
下面几种情况，建议直接用 API 或选择 GPU 服务：
- 只有 1C1G / 1C2G 的便宜 VPS。
- 希望多人同时使用。
- 需要稳定、快速响应。
- 需要跑 14B、32B 或更大的模型。
- VPS 磁盘空间很小，只有 20GB 左右。
Ollama 部署很简单，但真正难的是成本和性能预期。如果你只是为了学习，4C8G 的普通 VPS 可以体验；如果你要长期用，最好从 8C16G 或 GPU VPS 开始评估。
Ollama + Open WebUI 的价值不在于“免费替代所有 AI API”，而在于你能把数据、模型和访问入口控制在自己手里。对个人知识库、内部问答、代码片段查询、小团队私有助手来说，它很有吸引力。
但 VPS 选型要现实：CPU-only 能跑，不代表体验好；内存够拉模型，不代表多人可用；端口能打开，不代表应该暴露到公网。正确做法是先用小模型验证，再根据延迟、内存、磁盘和并发需求决定是否升级到更高配 VPS 或 GPU VPS。