指南

作者： Matt Connor 2026-08-03 · 更新于 2026-08-07

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

Q: 为什么我的浏览器聊天 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 override 中设置这两个变量，或者通过 SSH 转发端口，即可解决问题。

对比 Open WebUI、LibreChat、Hollama 和 OrionChat 在公网 VPS 上的内存、登录、远程 Ollama 与维护成本，说明 4 GB VPS 的具体限制。

适合 VPS 的 Open WebUI 替代方案

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

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

公网 IP 上才需要关注的 4 个方面

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

模型会为界面保留多少 RAM

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

ChartPublished download size of common Ollama models, August 2026

label

download_gb

llama3.2:3b

2.0

qwen3:4b

2.5

gemma3:4b

3.3

qwen3:8b

5.2

The data behind this chart

[
  {
    "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；随着对话增长，上下文缓存还会继续占用内存。qwen3:8b 需要 5.2 GB，完全无法在这台服务器上运行。这正是笔记本电脑评测通常不会涉及的情况：一个占用几百 MB 的聊天界面，可能决定模型能否运行。

不要相信任何评测中的数值，包括本文中的数值，应通过测量确认。运行 docker stats --no-stream 时，应在实际使用 1 小时后测量，而不是在容器启动 1 分钟后测量，因为真正影响运行的内存是在首次使用时分配的。

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 的拒绝规则。

通过隧道或代理访问页面，具体配置见下文，然后创建第一个账户。该账户会成为管理员。之后注册的账户会使用 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 登录，并提供用于管理用户和角色的管理面板。此功能需要一组后端服务。

ChartContainers a default install adds, not counting the model server

label

containers

notes

OrionChat

static files, served by a web server you already run

Hollama

one container serving a browser app

Open WebUI

application and SQLite in one image

LibreChat

api, admin panel, MongoDB, Meilisearch, pgvector, RAG API

The data behind this chart

[
  {
    "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

git pull 如果您修改了受跟踪的 docker-compose.yml，会因冲突而停止，升级过程也会处于半完成状态。请将修改放入项目为此提供的 docker-compose.override.yml，并将密钥保存在 .env 中。这两个文件都未被跟踪，因此 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 不能只监听回环地址，而且 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.。调用其他来源时会被拒绝，并显示 has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource，直到允许该来源。

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 来源上，Ollama 默认允许该来源，并且该端口不会离开本机。

每个界面都能使用远程 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。该请求同样从服务器发出，因此不受浏览器规则限制。

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.

方案一：绑定到回环地址，通过 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 继续监听回环地址。该方案的安全性取决于 SSH 配置，因此还应配合仅使用密钥的 SSH 和加固后的 sshd。

方案二：在应用收到请求前执行身份验证的反向代理。 让应用继续监听回环地址，由代理接管 443 端口，并在应用前部署单点登录。使用由 Docker Compose 标签驱动的 Traefik 和作为身份提供商的 Authentik，即可让服务器上的每个应用共用一个登录入口和一张证书。让 Open WebUI 运行在 TLS（传输层安全）后时，设置 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 override 中设置这两个变量，或者通过 SSH 转发端口，即可解决问题。

#open-webui#librechat#ollama #self-hosted-ai#chat-ui