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

哪个 Open WebUI 替代方案适合 VPS

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

以下内容均来自各项目自己的文档。这些文档于 2026 年 8 月阅读，并于 2026 年 10 月 20 日重新检查；Open WebUI、LibreChat、Hollama 和 OrionChat 又于 2026 年 10 月 25 日重新检查。Ollama 的文档和浏览器安全规则于 2026 年 10 月 29 日再次检查。这 4 个维度只有在该主机可从互联网访问后才会出现。

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

• 模型旁的内存占用。模型服务器是主机上最耗资源的进程。界面每占用1 MB内存，模型就少1 MB可用内存。
• 身份验证。有些项目支持用户账户和角色。另一些项目假设它们是笔记本上唯一运行的程序，完全没有登录功能。
• 远程推理。只连接到 127.0.0.1:11434 的 UI 通常要求模型与界面运行在同一台主机上。将模型放到其他位置后，就需要通过隧道把本地端口转发到模型主机。
• 维护工作量。运行一个带 SQLite 文件的容器，与运行6个容器并在后端使用 MongoDB 和向量数据库，是两种不同的运维任务。

模型为界面预留多少 RAM

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

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

这些是 Ollama 库页面在 25 October 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，并在实际使用 1 小时后测量，不要在容器启动 1 分钟后就测量，因为关键内存会在首次使用时分配。Ollama 还会在空闲 5 分钟后释放权重，因此在两次对话之间读取的数值会低估峰值；除非使用 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: 前缀可将其限制在 loopback 接口上。在 VPS 上，这个前缀比该行中的其他内容都重要，因为 Docker 会自行写入 iptables 规则，发布的端口会绕过 ufw 的 deny 规则。

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

Open WebUI 比下面的项目占用更多内存，因为它提供的功能更多。其性能页面列出了造成开销的组件。默认的嵌入引擎会在容器内加载 sentence-transformers 模型，每个 worker 进程通常需要约 500 MB 或更多内存。设置 RAG_EMBEDDING_ENGINE=ollama 后，该任务会交给您已经运行的模型服务器。AUDIO_STT_ENGINE=webapi 可避免加载本地语音转文本模型。在未设置 DATABASE_POOL_SIZE 的 SQLite 环境中，连接池会回退到较大的内部大小，并且每个连接都会创建自己的页面缓存和内存映射，因此在小型主机上应设置 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 登录，默认 compose 文件还定义了用于管理用户、组和角色的管理面板。该面板默认不会运行。只有在 .env 中设置 ADMIN_PANEL_SESSION_SECRET 后，它才会启动；该值为必填项，至少需要 32 个字符，且没有默认值。如果需要，可以使用 openssl rand -hex 32 生成。该面板作为独立服务运行，不属于 LibreChat 进程；它要求 LibreChat v0.8.5 或更高版本，并且项目目前仍将其标记为预览功能。启用该功能后，系统会引入一组服务。

[
  {
    "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": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

默认 compose 文件会启动 5 个服务：api, MongoDB, Meilisearch, pgvector, RAG API。管理面板是第六个服务，也位于同一文件中；设置其密钥后，它才会加入这些服务。它们都不是模型。MongoDB 和 pgvector 都需要单独占用内存；在 4 GB 的主机上，这些内存原本可供模型使用。

文件中的两个服务会发布端口，并且两个映射都没有指定绑定地址：API 使用 3080，管理面板使用主机端口 3000，即 ADMIN_PANEL_PORT 的默认值。因此，两个服务启动后都会监听所有网络接口。上文的 Open WebUI 也使用 3000 端口，所以在启用管理面板后，如果两者运行在同一台主机上，就会发生端口冲突。在让该服务栈面向互联网前，应在 docker-compose.override.yml 中将两者都重新绑定到 127.0.0.1。

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

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

如果您修改了受跟踪的 docker-compose.yml，git pull 会因冲突而停止，升级也会处于部分应用状态。请将修改放入项目为此提供的 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，容器停止时会将其删除，因此重启后界面不会恢复。

OrionChat 更进一步，完全没有服务器组件。克隆代码仓库后，使用已有的 Web 服务器提供该目录，或者直接从磁盘打开 index.html。API 密钥存储在浏览器的 localStorage 中，聊天记录保存在浏览器内；聊天数量超过 512 后，应用会删除最早的聊天记录。OrionChat 的 Ollama 地址已在源代码（js/script.js）中固定为 http://localhost:11434，其设置中没有修改该地址的字段。

两个项目都没有登录功能。在笔记本电脑上，这没有问题。在 VPS 上，这意味着页面绝不能发布到 0.0.0.0，还意味着一个更容易忽略的事实：调用模型的是浏览器，而不是服务器。

这一点决定了这两个项目适用的位置。浏览器必须能够直接访问 Ollama。对于 OrionChat，这始终意味着访问运行浏览器的机器上的 localhost:11434，因此在 VPS 上，下面的 SSH 隧道是访问模型的唯一途径。Hollama 会将你输入的任何地址作为连接的 base URL，其自托管指南也涵盖了运行在其他设备上的 Ollama 服务器：在 Ollama 一侧将 Hollama 的源地址添加到 OLLAMA_ORIGINS。因此，除非通过 SSH 转发端口，否则 Ollama 必须监听 loopback 之外的地址；而 Ollama API 不要求登录或密钥。由此有两条浏览器规则。通过 HTTPS 提供的页面不能调用公共 IP 地址上的纯 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.。Loopback 有单独的例外：Mixed Content 规范只会阻止不具备潜在可信性的 URL，而 Secure Contexts 规范将 localhost、127.0.0.0/8 和 ::1 视为具备潜在可信性，因此同一个 HTTPS 页面可以调用 http://localhost:11434 或 http://127.0.0.1:11434。下面的 SSH 隧道正是依赖这一例外。自版本 142 起，当页面来自 https://chat.example.com 等公共网站时，Chrome 会增加一个步骤：页面向 loopback 或本地网络地址发出的请求会等待用户在权限提示中允许本地网络访问。当主机名是 192.168.0.1 这样的私有 IP 字面量、.local 名称，或 fetch 指定了 targetAddressSpace: "local" 时，Chrome 也会对本地网络端点上受权限控制的 HTTP 请求免除混合内容检查。通过隧道在 http://localhost 打开的页面已经位于 loopback 上，因此不会出现该提示。调用其他源地址时，会返回 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_API_BASE_URL=http://model-host:8000/v1，并保留 vLLM 提供 API 时使用的 /v1。只有在服务器启动时配置了密钥，才设置 OPENAI_API_KEY，因为 Open WebUI 的 vLLM 指南默认不使用身份验证。其他兼容 OpenAI 的服务器应使用其文档指定的基础路径，该路径不一定是 /v1。OPENAI_API_BASE_URLS 支持使用分号分隔的多个后端。

LibreChat 也支持，方法是使用上文所示自定义端点的 baseURL。该请求同样从服务器发出，因此不受浏览器规则影响。在聊天窗口之外，也可以使用相同的基础 URL 和相同的占位密钥；这样即可让代码代理连接到您已经托管的模型。

Hollama 可以连接到您在设置中输入的任意端点。其 Ollama 连接提供可编辑的基础 URL，默认值为 http://localhost:11434。此外，Hollama 还提供兼容 OpenAI 的连接，默认值为 http://localhost:8080/v1，这是连接 vLLM 的方式。请求从浏览器发出，因此上文中的所有内容同样适用。OrionChat 无法指定其他端点。其端点是硬编码的，Ollama 固定为 http://localhost:11434/v1/chat/completions；其 README 说明请求会直接发送到各个提供商的官方 API。只有通过 SSH 隧道让远程 Ollama 在该本地端口上响应，才能访问远程 Ollama；它完全没有用于配置 vLLM 服务器的设置。

将界面与模型分离，是远程端点最实用的用途。将界面部署在小型服务器上，将模型部署在内存资源充足的位置。此时也应决定应由 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 的行表示服务监听所有地址，而 Docker 默认允许所有外部源 IP 访问已发布的端口。除非 Docker 的 DOCKER-USER 链或服务提供商的防火墙阻止了访问，否则你的聊天界面就在公网中。从本机执行 curl -sI http://YOUR.VPS.IP:3000 并得到 HTTP/1.1 200 OK 响应，可以更直接地确认这一点。

使用 WEBUI_AUTH=False 关闭 Open WebUI 登录功能，只适用于没有其他人能够访问的单用户计算机。其文档还说明，该设置只能用于尚未注册用户的安装，因此不能应用于已经存在账户的实例。

模式一：绑定到回环地址，通过 SSH 访问。 将每个端口发布到 127.0.0.1，然后转发所需端口：ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com，并在笔记本电脑上打开 http://localhost:3000。这样不会发布任何端口，因此也不会被扫描。对于 OrionChat，在同一条命令中使用 -L 11434:127.0.0.1:11434 转发模型端口，并让 Ollama 保持监听回环地址。Hollama 可以直接访问 Ollama，但使用相同的转发方式可使 Ollama 保持在公网之外，因此对 Hollama 也更安全。该模式的安全性取决于 SSH 配置，因此应配合 仅使用密钥的 SSH 和加固后的 sshd。

模式二：在应用收到请求前完成身份验证的反向代理。 让应用继续监听回环地址，由代理占用 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；如果需要管理面板，则设置 ADMIN_PANEL_SESSION_SECRET。然后使用 docker stats 确认其五个服务（启用管理面板时为六个服务）与您的模型实际能够在资源限制内运行，再将其用于生产环境。如果只有一个人在小型主机上使用，并且模型已经占用了大部分 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 的服务器，使用 OPENAI_API_BASE_URL，并填写该服务器文档中说明的基础路径；对于 vLLM，该路径是 /v1。只有服务器要求时，才添加 API key。Hollama 也可以指向任意地址，但请求由浏览器发起，因此该端点也必须能从浏览器访问。OrionChat 不支持此功能：其 Ollama 地址硬编码为 http://localhost:11434，因此只有通过 SSH 隧道转发该端口时，远程 Ollama 才能工作。

为什么浏览器聊天 UI 无法连接 Ollama？

几乎所有情况都可归结为两个原因。Ollama 默认绑定到 127.0.0.1:11434，因此其他机器上的浏览器无法直接访问它，除非修改 OLLAMA_HOST，或通过 SSH 隧道转发该端口。Ollama 默认接受来自 localhost、127.0.0.1 和 0.0.0.0 的跨源请求，因此来自你自己域名的页面会被拒绝并显示 No 'Access-Control-Allow-Origin' header is present on the requested resource，直到将该来源加入 OLLAMA_ORIGINS。如果页面使用 HTTPS，而端点在公网 IP 地址上使用明文 HTTP，浏览器会将请求判定为混合内容并阻止它，Ollama 根本不会收到请求。环回地址（localhost、127.0.0.0/8 中的任意地址，例如 127.0.0.2，或 [::1]）不受此限制。获得本地网络权限后，Chrome 也会豁免使用私有 IP 字面量的本地网络 HTTP 请求，例如 192.168.0.1、.local 主机名或 targetAddressSpace: "local"；但仍必须满足 Ollama 的 CORS 要求。在 systemctl edit ollama.service 覆盖配置中同时设置这两个变量，或者通过 SSH 转发端口，即可解决此问题。