指南

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

适合 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，而端点使用 HTTP，浏览器会将其拦截为混合内容，Ollama 根本无法收到请求。在 systemctl edit ollama.service 覆盖配置中设置这两个变量，或者通过 SSH 转发端口，即可解决此问题。

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

适合 VPS 的 Open WebUI 替代方案

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

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

公网 IP 上才需要关注的 4 个维度

模型旁的内存占用。模型服务器是这台主机上最耗费资源的进程。界面占用的每 1 MB 内存，模型就少 1 MB 可用内存。
身份验证。有些项目支持用户账户和角色。另一些项目默认它们是笔记本上唯一运行的程序，完全没有登录功能。
远程推理。只能访问 127.0.0.1:11434 的界面会强制模型与界面部署在同一台主机上。
维护工作量。使用 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 内存时，决定模型能否运行的关键。如果您要为明显超过这些规格的模型配置服务器，仅使用 CPU 的 VPS 上运行 27B 模型的计算可以说明，界面占用很快就不再是决定因素。

不要相信任何对比文章中的数值，包括本文中的数值，应以实测为准。在实际使用一小时后运行 docker stats --no-stream，不要在容器启动一分钟后就运行，因为真正需要关注的内存是在首次使用时分配的。

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: 前缀会将其限制在 loopback 接口上。在 VPS 上，这个前缀比命令行中的其他内容都重要，因为Docker 会自行写入 iptables 规则，发布的端口会绕过 ufw deny 规则。

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

Open WebUI 的功能更多，因此比下面介绍的项目占用更多内存。其性能页面列出了产生开销的组件。默认的 embedding 引擎会在容器内加载 sentence-transformers 模型。文档显示，每个 worker 进程约占用 500 MB。设置 RAG_EMBEDDING_ENGINE=ollama 后，该任务会交给您已经运行的模型服务器。AUDIO_STT_ENGINE=webapi 可避免加载本地 speech-to-text 模型。在未设置 DATABASE_POOL_SIZE 的 SQLite 中，连接池会回退到较大的内部大小，并且每个连接都会创建自己的 page cache 和内存映射。因此，在小型主机上应设置 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 必须监听 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.。调用任何其他源都会因 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 连接。该请求同样从服务器发出，因此不受浏览器规则限制。相同的基础 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 端口，并在前面配置单点登录。使用 Authentik 作为身份提供商的由 Docker Compose 标签驱动的 Traefik，可以让主机上的每个应用共用一个登录入口和一张证书。在 TLS（传输层安全）保护下运行 Open WebUI 时，设置 WEBUI_SESSION_COOKIE_SECURE=true 和 WEBUI_SESSION_COOKIE_SAME_SITE=strict。还应将 JWT_EXPIRES_IN 从默认的四周缩短，因为 Open WebUI 的文档说明，在没有 Redis 的情况下，退出登录不会使令牌失效：令牌会一直有效，直到自行过期。

模式二无法保护仅支持浏览器访问的项目。页面前面的代理无法保护模型端点，而且页面向其他主机名发起的 fetch 请求不会携带您的会话 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 进程、数据库，以及默认启用的本地嵌入模型；文档显示，仅嵌入模型每个 worker 约占用 500 MB。使用 docker stats --no-stream 在自己的主机上确认实际数值，因为占用量会随启用的功能变化。

这些聊天 UI 能否使用另一台主机上的 Ollama 服务器？

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

为什么我的浏览器聊天 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，而端点使用 HTTP，浏览器会将其拦截为混合内容，Ollama 根本无法收到请求。在 systemctl edit ollama.service 覆盖配置中设置这两个变量，或者通过 SSH 转发端口，即可解决此问题。

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