【AI自托管 02】自建 OpenWebUI 对话栈：对接 Ollama / vLLM，打造私有 ChatGPT（2026 实测）

2026-08-16 · DevCraft Studio

在 VPS 上用 Docker 部署 OpenWebUI，深入对比 Ollama 与 vLLM 两种后端，配好 Caddy 反向代理、HTTPS、多用户与 RAG 文件问答，搭出带账号的私有对话平台。隐私与合规前置见系列第 1 篇。

AI 自托管部署 · 共 2 篇

延伸阅读

更多相关攻略推荐：2026 实测：VPS 上自托管 AI 编程助手——Continue、【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、2026 VPS 选购决策树与白皮书：一张图看懂怎么买、2026 海外 VPS 行业趋势年报：价格、架构与格局全景。

为什么要在 VPS 上自建 OpenWebUI

这两年本地大模型的热度不用我多说，Ollama 一键拉模型确实方便，但光在终端里聊总差点意思：没有历史记录、没有文件问答、多人也没法用。OpenWebUI 就是把这个缺口补上的前端，2026 年它在 GitHub 上已经 14 万+ star，基本是本地模型前端的事实标准。

说白了，OpenWebUI 只管界面和会话，真正的推理交给后端。后端你可以选两种：Ollama（适合 CPU 或者小显存机器，便宜省心）和 vLLM（适合带 GPU、多用户高并发）。这篇文章我就手把手带你在 VPS 上把这套私有 ChatGPT 搭起来，账号体系、HTTPS、文档问答全给你配齐，并重点讲清两种后端怎么选、怎么切换。隐私优先的架构原则（数据不出机、Tailscale 零公网端口、GDPR 合规）不在本文展开，请见本系列第 1 篇：/privacy-first-selfhost-ai-vps-2026。

选 VPS 而不是家用机，核心就三点：24 小时在线、有公网 IP 直接给团队用、数据和模型都在你掌控的机器上。如果你只跑 CPU 小模型，像 RackNerd 那种年付十几二十刀的 KVM 足够；想存模型和文档，HostDare 的硬盘套餐也划算；要上 GPU 跑 vLLM，Vultr 和 Contabo 提供带显卡的实例。下面我都按这两类机器实测过的配置来写，命令照抄就能跑。

方案一：Ollama 后端，CPU 和小显存最省

OpenWebUI 和 Ollama 是绝配，因为 OpenWebUI 原生就认识 Ollama 的接口。最省事的玩法是用同一个 docker-compose 把两个容器拉起来，让它们用服务名互相访问，不用折腾 IP。

先在 Ubuntu 22.04 或 Debian 12 上把 Docker 装好：

sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable --now docker

然后建目录写配置：

mkdir -p ~/openwebui && cd ~/openwebui
nano docker-compose.yml

compose 内容我放在后面完整版一节。这里先说 Ollama 拉模型，实测一个 7B 模型大概吃 4 到 5 GB 内存，所以 8 GB 内存的机器能跑 7B，想舒服点直接上 16 GB。命令：

docker exec -it ollama ollama pull qwen2.5:7b
docker exec -it ollama ollama pull nomic-embed-text

第二条是 RAG 用的 embedding 模型，后面文件问答要用，提前拉好。避坑点：很多新手只拉了对话模型忘了 embedding，结果上传 PDF 时报错找不到向量模型，白折腾半天。

如果机器连 GPU 都没有，也别灰心，CPU 跑 7B 量化模型虽然慢一点（实测每秒几 token），但拿来写写周报、改改文案完全够用。真要追求速度，把模型换成 3B 或者 1.5B 的蒸馏版，体验立刻好很多。记住一个原则：模型越小越便宜越快，先跑通整套流程，再慢慢往上加型号，比一上来就硬啃大模型明智得多。

方案二：vLLM 后端，GPU 高并发才值

当你的用户超过 20 个，或者要同时跑好几个会话，Ollama 的吞吐就顶不住了。vLLM 有 PagedAttention 和连续批处理，并发能力是它的强项。但实话实说：vLLM 的优势要在多用户、高并发场景才显现，个人单机用 Ollama 更省事，别为了上 vLLM 而硬上。

vLLM 启动就是一个 OpenAI 兼容的接口，监听 8000 端口。实测命令：

pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct   --served-model-name qwen2.5-7b   --host 0.0.0.0 --port 8000   --gpu-memory-utilization 0.9   --max-model-len 16384

用容器跑的话，让 OpenWebUI 通过 host.docker.internal 访问宿主机上的 vLLM：

docker run -d --gpus all --name vllm   -p 8000:8000 vllm/vllm-openai:latest   --model Qwen/Qwen2.5-7B-Instruct   --served-model-name qwen2.5-7b   --port 8000

启动后用一行 curl 验证后端活着：

curl http://localhost:8000/v1/models

能看到模型名就说明后端正常。然后再把 OpenWebUI 的 OPENAI_API_BASE_URL 指到 http://host.docker.internal:8000/v1，vLLM 默认不鉴权，API Key 随便填个 not-needed 即可。注意 vLLM 的显存分页很吃显卡，一张 16 GB 卡跑 7B 很宽裕，跑 14B 也行，但再多就要看卡了。

Ollama 和 vLLM 怎么选：一张表说清

这是被问得最多的问题，我直接给结论。Ollama 是推理引擎里最省心的，开箱即用、模型管理直观，单用户或者小团队用它最稳；缺点是并发弱，多人在线会排队。vLLM 是工程级的推理服务，靠连续批处理和显存分页把吞吐拉满，适合二三十人以上的团队同时提问。日常实测里，单机单会话两者速度差距不大，真正拉开差距的是并发数。

  • 机器只有 CPU、内存 8 GB：选 Ollama，跑 7B 级别的模型，响应能接受，别碰 vLLM，没显卡它发挥不出来。
  • 有张入门显卡（如 16 GB 显存）：Ollama 依旧最省事；如果想给团队用且并发偏高，可以上 vLLM。
  • 多用户、要 API 高并发：直接 vLLM，把 OpenWebUI 当统一前端，后端随便换模型，前端不变。
  • 预算敏感：RackNerd 年付 KVM 跑 Ollama 足够便宜；要存大量模型和文档就挑 HostDare 的大硬盘套餐，省下的钱比自建机房划算多了。

进阶玩法：你可以在 OpenWebUI 里同时接 Ollama 和 vLLM 两个后端，顶部模型下拉里本地模型和远程 vLLM 模型同时出现，同一个问题丢给两个模型对比，挑出最合适的那个。这比在终端里来回切方便太多，也是私有 ChatGPT 比单纯 Ollama 终端强的地方。

一把梭：完整 docker-compose 配置（实测可用）

下面这份是我压过两台机器、改了三四版留下来的配置。Ollama、OpenWebUI 和带 HTTPS 的 Caddy 一起拉起，复制就能跑。

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped
    # 有 NVIDIA 显卡就打开下面这段
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: all
    #           capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "8080:8080"
    volumes:
      - openwebui_data:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=换成你自己的64位随机串
      - SCARF_NO_ANALYTICS=true
      - DO_NOT_TRACK=true
      - ANONYMIZED_TELEMETRY=false
    depends_on:
      - ollama
    restart: unless-stopped

  caddy:
    image: caddy:alpine
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    depends_on:
      - open-webui
    restart: unless-stopped

volumes:
  ollama_data:
  openwebui_data:
  caddy_data:

WEBUI_SECRET_KEY 千万别留默认，生成办法：

openssl rand -hex 32

把输出粘进去就行。然后启动：

docker compose up -d
docker compose logs -f open-webui

看到容器起来，浏览器开 http://你的IP:8080，第一个注册的人就是管理员。这一步我踩过的坑：WEBUI_AUTH 一旦首次启动就不能随便改，想关登录得先想清楚，否则只能清库重来。

反代加 HTTPS：Caddy 最省心

裸奔在 8080 端口只能自己玩，团队用必须上 HTTPS。Caddy 全自动申请 Let's Encrypt 证书，配置文件极简。建一个 Caddyfile：

chat.你的域名.com {
  reverse_proxy open-webui:8080
}

前提是你把域名 A 记录指向这台 VPS 的 IP，Caddy 启动后会自动帮你搞定证书，访问 https://chat.你的域名.com 即可。实测从装到能开，十分钟以内。避坑：80 和 443 端口别被别的程序占了，云厂商安全组也要放通这两个端口。

关于「要不要直接公网开放」，这和隐私优先的第 1 篇立场一致：如果你的数据敏感，更稳妥的做法是用 Tailscale 把 8080 收进私有网络，而非暴露到公网。本文给出的是团队对外提供服务的标准反代方案，是否开放公网由你的合规要求决定，相关判断见本系列第 1 篇：/privacy-first-selfhost-ai-vps-2026。

多用户与权限模型

进管理员面板可以开关自助注册。团队用我建议先把 ENABLE_SIGNUP 设为 false，手动在建用户，或者把默认角色设成 pending 让管理员审。配置写在 environment 里：

  - ENABLE_SIGNUP=false
  - DEFAULT_USER_ROLE=pending

OpenWebUI 的权限分几层：管理员（admin）能改全局设置、管用户；普通用户（user）只能聊和用知识库；pending 是待审核状态。给团队用时，建议管理员先建好知识库，再开 pending 让同事申请后由你审核，避免外人自助注册进系统。如果要做更细的部门隔离，可以用「小组（group）」功能把用户和知识库绑定，不同组看不到彼此的资料，这对多客户场景很实用。

还有一点常被忽略：第一个注册账号是永久管理员，忘了密码只能进容器改库，所以管理员密码一定要强，且建议单独用一个邮箱。配合前面关掉的遥测开关，这套账号体系才是干净可控的。

多用户与 RAG 文件问答

RAG 文档问答是 OpenWebUI 的亮点。在聊天框点加号上传 PDF、TXT、Word，文件会被自动切块、向量化。对话时用 # 选知识库，模型就会基于你的文档回答。记得 embedding 模型（nomic-embed-text）要提前拉好，否则上传会失败。知识库在 工作区 的 知识 里能持久保存，比每次临时上传更稳。

想让问答更准，去 管理员面板 的 设置 里调文档参数：块大小（chunk size）默认 1000 字符，块重叠（overlap）默认 200，检索的 Top K 默认 4。中文文档建议把块调大一点，比如 1500，重叠 300，召回会更连贯。embedding 模型默认是 SentenceTransformers 的 all-MiniLM，想要中文质量更好可以换成 nomic-embed-text，已经在前面拉过了。

实测好用的进阶技巧有两个：一是给同一批文档建多个知识库，按主题切分（合同库、手册库、研究库），用 # 精准召回，比塞一个大盘更准；二是用「文档重新排序（rerank）」模型（如 bge-reranker）放在 Top K 之后二次过滤，能明显压掉答非所问。这些都在管理员面板里开，属于把私有 ChatGPT 从「能用」拉到「好用」的关键一步。

避坑清单（都是真金白银换来的）

  • Ollama 连不上：十有八九是 OLLAMA_BASE_URL 写错。Ollama 在另一个容器里就用服务名 http://ollama:11434，在宿主机就用 http://host.docker.internal:11434 并加 extra_hosts。
  • 上传文件报错：缺 embedding 模型，docker exec 进 ollama 拉 nomic-embed-text。
  • vLLM 连不上：OPENAI_API_BASE_URL 一定要带 /v1 后缀，模型名要和 --served-model-name 完全一致。
  • 显存爆了：把 --gpu-memory-utilization 调到 0.85 左右，给前端通信留点余量。
  • HTTPS 不生效：检查域名解析、安全组、证书目录权限，Caddy 日志最直接。
  • 切后端丢历史：换 Ollama/vLLM 不影响会话，但模型名变了旧消息会标注原模型，属正常，不影响继续聊。

最后提醒：数据要备份

openwebui_data 这个卷里存着聊天记录和账号，定期打个 tar 包，机器重装也不怕。一条命令就能备份：docker run --rm -v openwebui_data:/data -v /root/backup:/backup alpine tar czf /backup/owui.tar.gz -C /data . （这里用固定路径 /root/backup 而非变量写法，避免脚本兼容问题）。

安全上还有两件事顺手做了：一是把 SCARF_NO_ANALYTICS 和 DO_NOT_TRACK 都设为 true，关掉官方遥测，少传一点是一点；二是公网暴露前一定先设好账号体系，别把 8080 裸端口直接映射出去，否则谁都能进来建管理员。Caddy 那一层的 HTTPS 配上之后，传输过程也是加密的，放心。更严格的「数据不出机」与 GDPR 标注义务，请回看本系列第 1 篇：/privacy-first-selfhost-ai-vps-2026。