适合公网 VPS 的 Open WebUI 替代方案对比

适合 VPS 的 Open WebUI 替代方案

人们几乎总是在笔记本电脑上比较 Open WebUI 的替代方案，因为笔记本电脑的 RAM 成本低，而且没有任何服务监听公网地址。VPS 会改变这两个条件，因此排名也会变化。只要有第二位用户登录，Open WebUI 仍然是默认选择，因为它提供了真正的用户账户和管理面板。当界面需要与模型争夺最后 1 GB RAM 时，更轻量的项目更有优势。但这种优势需要付出认证能力的代价：这些项目都不提供认证。

以下内容均来自各项目自己的文档，文档查阅时间为 2026 年 8 月。这里采用的 4 个维度，只有在服务器可从互联网访问后才会显现。

仅在公网 IP 场景下需要考虑的4个方面

• 模型旁的内存。模型服务器是主机上占用资源最多的进程。界面占用的每1 MB内存，模型就少1 MB可用内存。
• 身份验证。有些项目支持用户账户和角色。另一些项目默认自己是笔记本上唯一运行的程序，完全不提供登录功能。
• 远程推理。如果界面只能访问 127.0.0.1:11434，模型就必须与界面部署在同一台主机上。
• 维护工作。使用一个 SQLite 文件的单个容器，与后端包含 MongoDB 和向量数据库的6个容器，维护复杂度完全不同。

模型会为界面预留多少 RAM

界面不是这台机器上占用资源最多的部分，模型才是。已发布的下载大小只能作为最低值参考，因为模型响应时必须将权重保留在内存中；分配上下文缓存后，实际内存占用会高于下载大小。

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

这些是 Ollama 库页面在 August 2026 显示的数值。它们是公布的大小，不是实测结果。在 4 GB VPS 上，qwen3:4b 占用 2.5 GB 后，留给操作系统和其他组件的内存不足 1.5 GB；随着对话增长，上下文缓存还会继续占用内存。因此，设置的 num_ctx 不仅影响质量，也是一个内存配置决策。qwen3:8b 占用 5.2 GB，完全无法装入这台机器。这正是笔记本测评通常不会涉及的情况：当聊天界面占用几百 MB 时，模型能否运行取决于剩余内存。如果您要为明显高于这些标签的模型配置服务器，仅使用 CPU 的 VPS 运行 27B 模型的计算会说明界面为何很快不再是决定因素。

不要直接相信任何测评中的数值，包括本文的数值，应实际测量。运行 docker stats --no-stream 后等待一小时，让系统进入实际使用状态；不要在容器启动一分钟后就测量，因为关键内存会在首次使用时分配。Ollama 还会在空闲五分钟后释放权重，因此在两次对话之间读取的数值会低估峰值；除非使用 keep_alive 让模型常驻内存，否则下一条消息会再次触发完整加载。

Open WebUI：仍是多用户场景的默认选择

Open WebUI 使用一个镜像运行，并将数据保存在一个卷中。

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

项目 README 中的命令会发布 -p 3000:8080，使其监听所有网络接口。127.0.0.1: 前缀会将其限制在回环接口上。在 VPS 上，这个前缀比命令行中的其他内容都重要，因为 Docker 会自行写入 iptables 规则，而发布的端口会绕过 ufw deny 规则。

通过下文介绍的隧道或代理访问该页面，然后创建第一个账户。该账户会成为管理员。之后注册的账户会使用 pending 角色，这是文档中 DEFAULT_USER_ROLE 的默认值。因此，即使陌生人访问到该页面，在管理员批准前也无法使用您的模型。

Open WebUI 比下面的项目占用更多内存，因为它提供的功能更多。其性能页面列出了产生开销的组件。默认嵌入引擎会在容器内加载 sentence-transformers 模型，文档显示每个 worker 进程约占用 500 MB。设置 RAG_EMBEDDING_ENGINE=ollama 后，该任务会交给您已经运行的模型服务器。AUDIO_STT_ENGINE=webapi 可避免加载本地语音转文本模型。在 SQLite 中，如果未设置 DATABASE_POOL_SIZE，连接池会回退到较大的内部大小，并且每个连接都会创建自己的页面缓存和内存映射。因此，在小型主机上应设置 DATABASE_POOL_SIZE=8 和 DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0。ENABLE_AUTOCOMPLETE_GENERATION=False 可阻止界面在用户仍在输入时向模型请求补全。

LibreChat：多用户，后面还带有一组服务

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

界面监听 3080 端口。需要身份系统而不是简单登录框时，应考虑 LibreChat：其文档说明支持 LDAP 和 OAuth2 登录，并提供用于管理用户和角色的管理面板。这些功能需要一组配套服务。

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

默认的 compose 文件会启动 6 个服务：api, admin panel, MongoDB, Meilisearch, pgvector, RAG API。其中没有模型服务。MongoDB 和 pgvector 都需要占用独立内存；在 4 GB 的主机上，这些内存原本可供模型使用。

升级通过 git 操作完成，这也是最容易出错的地方。

docker compose down
git pull
docker compose pull
docker compose up -d

如果您编辑了受跟踪的 docker-compose.yml，git pull 会因冲突而停止，升级过程也会处于半完成状态。请将修改放入 docker-compose.override.yml，项目为此提供了该文件，并将密钥保存在 .env 中。这两个文件都未被 git 跟踪，因此 git pull 不会修改它们。

在 librechat.yaml 中配置自定义端点，让 LibreChat 连接到您自己的模型服务器。

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

将 model-host 替换为运行 Ollama 的主机地址。即使 Ollama 会忽略 apiKey 字段的值，该字段也必须存在，因此使用占位值即可。如果 LibreChat 在 Docker 中运行，而 Ollama 在同一台机器上运行，则容器内的 localhost 指向容器自身，因此应改用 host.docker.internal。

Hollama 和 OrionChat：由浏览器完成处理

Hollama 在一个小型容器中提供浏览器应用。聊天内容保存在浏览器存储中，而不是服务器上。

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

README 中的命令使用 --rm。容器停止后会被删除，因此重启后界面不会恢复。在反向代理后运行时，请添加 -e VITE_ALLOWED_HOSTS='chat.example.com'，因为该镜像只允许主机名 localhost。对于其他主机名，它会返回 blocked-host 错误，而不是提供应用。

OrionChat 更进一步，完全没有服务器组件。克隆代码仓库，然后使用现有 Web 服务器提供该目录，或直接从磁盘打开 index.html。API 密钥存储在浏览器的 localStorage 中，聊天历史也保存在浏览器中；聊天数量超过 512 后，应用会删除最早的聊天。

两个项目都没有登录功能，因为它们都没有可用于验证登录的服务器。在笔记本电脑上，这没有问题。在 VPS 上，这意味着绝不能通过 0.0.0.0 发布该页面；还意味着一个更容易忽略的问题：是浏览器调用模型，而不是服务器。

这一点决定了这两个项目适用的场景。浏览器必须直接访问 Ollama，因此 Ollama 必须监听 loopback 之外的地址，而且 Ollama 完全没有身份验证功能。由此会产生两条浏览器规则。通过 HTTPS 提供的页面不能调用纯 HTTP 端点，控制台会打印 Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.。调用其他 origin 会被拒绝，并返回 has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource，直到你允许该 origin。

Ollama 文档建议使用 systemd override 修改这两个设置。

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

现在，ss 应打印 0.0.0.0:11434，而之前打印的是 127.0.0.1:11434。只有在防火墙或带身份验证的代理已经控制端口访问者时，才进行此修改，因为开放的 11434 就是开放的模型服务器，批量扫描器会很快发现新的公网端口。下面的 SSH 隧道可以完全避开这个问题：此时页面运行在 localhost origin 上，Ollama 默认允许该 origin，而且端口不会离开本机。

每个工具都可以使用远程 Ollama 或 vLLM 端点吗

Open WebUI 可以，连接在服务器端建立。OLLAMA_BASE_URL=http://model-host:11434 将其指向 Ollama。对于 vLLM 或其他兼容 OpenAI 的服务器，请设置 OPENAI_API_BASE_URL=http://model-host:8000/v1，并为其指定非空的 OPENAI_API_KEY；同时保留 /v1 后缀，因为该后缀是必需的。OPENAI_API_BASE_URLS 支持使用分号分隔的多个后端。

LibreChat 也可以，通过上文所示自定义端点的 baseURL 实现。该请求同样从服务器发出，因此不受浏览器规则限制。在聊天窗口之外也可以使用相同的基础 URL 和相同的占位密钥；只需这样即可让编程代理指向你已经托管的模型。

Hollama 和 OrionChat 可以在设置中指向你输入的任意端点，但请求会从浏览器发出。本节上文的所有内容都适用于它们，除此之外不适用于这里的其他工具。

将界面与模型分开，是远程端点带来的最大价值。将界面部署在小型设备上，将模型部署在内存充足的位置。这也是决定应由 Ollama 还是 vLLM 处理请求的时机，因为当多人同时与模型交互时，两者的行为差异很大。如果模型服务器尚未部署，请先在 VPS 上运行 Ollama；如果设备仅使用 CPU，请在选择运行器前阅读Ollama 与 llama.cpp 的对比。

不要在 0.0.0.0 上发布无登录保护的聊天界面

Open WebUI 的加固页面指出，该项目“面向私有的可信网络构建，与数据库、容器注册表和 CI 服务器等其他自托管基础设施类似”，并要求将其置于 VPN 后，或置于带身份验证的反向代理后。完全没有登录功能的项目，至少也应采用相同的保护方式。

在信任任何服务之前，先检查哪些服务正在监听端口。

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

显示 127.0.0.1:3000 的行才是正确结果。显示 0.0.0.0:3000 的行表示你的聊天界面已暴露在公网中。从你自己的计算机执行 curl -sI http://YOUR.VPS.IP:3000，如果得到 HTTP/1.1 200 OK 响应，也会更直接地说明这一点。

使用 WEBUI_AUTH=False 关闭 Open WebUI 登录，只适用于没有其他人可以访问的单用户计算机。如果安装中已经存在账户，该设置也不会生效，并会显示消息 You can't turn off authentication because there are existing users.

模式一：绑定到 loopback，通过 SSH 访问。 将所有端口发布到 127.0.0.1，然后转发所需端口：ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com，并在笔记本电脑上打开 http://localhost:3000。没有任何端口被发布，因此也无法被扫描。对于 Hollama 或 OrionChat，在同一条命令中使用 -L 11434:127.0.0.1:11434 转发模型端口，并让 Ollama 保持监听 loopback。该模式的安全性取决于 SSH 配置，因此还应配合 仅使用密钥的 SSH 和加固的 sshd。

模式二：在应用收到请求前执行身份验证的反向代理。 让应用继续监听 loopback，由代理占用 443 端口，并在前面配置单点登录。使用 由 Docker Compose 标签驱动的 Traefik，并配合 作为身份提供商的 Authentik，可以让这台计算机上的所有应用共用一个登录入口和一张证书。在 TLS（传输层安全）保护下运行 Open WebUI 时，设置 WEBUI_SESSION_COOKIE_SECURE=true 和 WEBUI_SESSION_COOKIE_SAME_SITE=strict。还应缩短 JWT_EXPIRES_IN，不要使用其默认的四周时长，因为 Open WebUI 文档说明：未配置 Redis 时，注销不会使令牌失效；令牌会一直可用，直到自行过期。

模式二无法保护仅在浏览器中运行的项目。页面前面的代理不能保护模型端点，而且页面向其他主机名发起的请求不会携带你的会话 Cookie。因此，放在 Ollama 前面的身份验证代理会返回登录表单的重定向，聊天也就会失败。应将模型端点放在与页面相同的主机名下，或使用模式一。

选择哪个

如果除您之外还有其他人使用，请运行 Open WebUI。它提供真实账户，新用户会进入审批队列，其维护者也发布了可供遵循的加固指南。如果需要 LDAP 或管理面板，请运行 LibreChat，并使用 docker stats 确认其 6 个服务与您的模型能够共同运行，再将其用于生产环境。如果只有一个人在小型主机上使用，且模型已经占用了大部分 RAM，请通过 SSH 隧道提供 Hollama 或 OrionChat，让浏览器保存状态。在 VPS 上，错误的做法是将其中任何一个通过 0.0.0.0 直接发布，且前面没有登录认证。

FAQ

直接将 Open WebUI 暴露在公网 IP 上是否安全？

其自身的加固页面将它描述为面向私有、受信任网络的软件，与数据库或 CI 服务器属于同一类别。它确实支持真实用户账户：第一个账户会成为管理员，后续账户在获批前会保持 pending 状态，因此比完全不需要登录的 UI 安全得多。不过，仍应将它置于带 TLS 的反向代理后面，并尽可能使用单点登录。将容器端口发布为 127.0.0.1:3000:8080，这样 Docker 自身的 iptables 规则就不会在你不知情的情况下将其开放到互联网。

哪个 Open WebUI 替代方案在 VPS 上占用的 RAM 最少？

基于浏览器的方案占用最少，包括 Hollama 和 OrionChat，因为应用运行在客户端。服务器只需发送静态文件，而且 OrionChat 完全不需要应用容器。Open WebUI 会在内存中运行 Python 进程、数据库，以及默认启用的本地 embedding 模型；文档显示，仅 embedding 模型的每个 worker 约占 500 MB。请使用 docker stats --no-stream 在自己的服务器上确认实际数值，因为数值会随启用的功能变化。

这些聊天 UI 能否使用其他主机上的 Ollama 服务器？

Open WebUI 和 LibreChat 可以，而且连接由它们的服务器发起，因此不受浏览器规则限制。为 Open WebUI 设置 OLLAMA_BASE_URL，或在 LibreChat 的自定义 endpoint 中设置 baseURL。对于 vLLM 或其他兼容 OpenAI 的服务器，使用带有 /v1 后缀的 OPENAI_API_BASE_URL，并设置非空 API key。Hollama 和 OrionChat 也可以指向任意位置，但请求由浏览器发起，因此 endpoint 也必须能从浏览器访问。

为什么我的浏览器聊天 UI 无法访问 Ollama？

几乎所有情况都可归结为两个原因。Ollama 默认绑定到 127.0.0.1:11434，因此其他机器上的浏览器无法访问它，直到 OLLAMA_HOST 发生变化。Ollama 还只接受来自 localhost 的跨源请求，因此从你自己的域名提供的页面会被拒绝，并显示 No 'Access-Control-Allow-Origin' header is present on the requested resource，直到该来源被列入 OLLAMA_ORIGINS。如果页面使用 HTTPS 而 endpoint 使用 HTTP，浏览器会先将其阻止为混合内容，Ollama 根本不会收到请求。在 systemctl edit ollama.service 覆盖配置中设置这两个变量，或者通过 SSH 转发端口，这个问题就会消失。