適合 VPS 的 Open WebUI 替代方案比較

適合 VPS 的 Open WebUI 替代方案

比較 Open WebUI 替代方案時，通常是在筆記型電腦上進行。此時 RAM 成本低廉，也沒有任何服務監聽公開位址。VPS 會改變這兩項條件，因此排名也會不同。只要有第二位使用者登入，Open WebUI 仍是預設選擇，因為它提供完整的使用者帳號與管理面板。當介面需要與模型競爭最後 1 GB RAM 時，較輕量的專案會勝出。但代價是缺少驗證機制：這些專案都沒有驗證功能。

以下內容均來自各專案自己的文件，文件查閱時間為 August 2026。這 4 個評估面向，只有在伺服器可從網際網路連線時才會出現。

只有在公開 IP 上才重要的 4 個面向

• 模型旁的記憶體。模型伺服器是主機上最耗用資源的程序。介面占用的每 1 MB 記憶體，都是模型無法使用的 1 MB。
• 驗證。部分專案具備使用者帳戶與角色。其他專案則假設自己是筆記型電腦上唯一執行的程式，完全沒有登入功能。
• 遠端推論。只能連線至 127.0.0.1:11434 的 UI，會迫使模型與介面部署在同一台主機上。
• 維護。一個使用 SQLite 檔案的容器，與後方還有 MongoDB 和向量資料庫的 6 個容器，是完全不同的維運工作。

模型會為介面保留多少 RAM

介面不是這台主機上最占資源的部分，模型才是。已發布的下載大小可視為最低需求，因為模型回應時必須讓權重常駐記憶體；配置 context cache 後，實際記憶體用量會高於下載大小。

[
  {
    "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 library 頁面在 August 2026 顯示的數值。這些是發布的大小，不是實測結果。在 4 GB VPS 上，qwen3:4b 需要 2.5 GB，留給作業系統與其他程式的空間不到 1.5 GB；隨著對話變長，context cache 還會繼續占用記憶體。qwen3:8b 需要 5.2 GB，完全無法在這台主機上執行。這是 laptop 評測文章從未涵蓋的情況，也是 chat 介面占用幾百 MB 時，會決定模型能否執行的關鍵。若你要為明顯高於這些標籤的模型規劃主機，CPU-only VPS 上執行 27B model 的計算方式可顯示介面很快就不再是決定性因素。

不要相信任何評測文章中的數字，包括本文的數字，應自行測量。執行 docker stats --no-stream 時，請在實際使用 1 小時後測量，不要在 container 啟動 1 分鐘後測量，因為真正重要的記憶體會在首次使用時配置。

Open WebUI：多位使用者仍採用預設設定

Open WebUI 使用單一映像檔執行，並將資料儲存在單一 volume 中。

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 規則。

請透過下文說明的 tunnel 或 proxy 存取頁面，然後建立第一個帳戶。該帳戶會成為管理員。之後註冊的帳戶會以角色 pending 建立；這是文件記載的預設值 DEFAULT_USER_ROLE。因此，即使陌生人存取頁面，在管理員核准前也無法使用你的模型。

Open WebUI 的記憶體需求高於下列專案，因為它提供更多功能；其效能頁面也列出造成成本的元件。預設的 embedding engine 會在 container 內載入 sentence-transformers model，文件記載每個 worker process 約需 500 MB。設定 RAG_EMBEDDING_ENGINE=ollama 可將這項工作交給你已執行的 model server。AUDIO_STT_ENGINE=webapi 可避免載入本機 speech-to-text model。在 SQLite 中，若未設定 DATABASE_POOL_SIZE，pool 會退回較大的內部大小，而每個 connection 都會建立自己的 page cache 與 memory map，因此在小型主機上請設定 DATABASE_POOL_SIZE=8 與 DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0。ENABLE_AUTOCOMPLETE_GENERATION=False 可避免介面在使用者仍在輸入時向模型要求 completion。

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

git pull 如果你修改了受追蹤的 docker-compose.yml，就會因衝突而停止，導致升級只完成一半。請將變更放在專案提供的 docker-compose.override.yml 中，並將密鑰存放在 .env。這兩個檔案都未受追蹤，因此 git pull 不會修改它們。

在 librechat.yaml 中使用自訂 endpoint，讓 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 更進一步，完全沒有伺服器元件。請複製 repository，再使用現有的 web server 提供該資料夾，或直接從磁碟開啟 index.html。API key 儲存在瀏覽器的 localStorage，聊天記錄也留在瀏覽器中；聊天數量超過 512 後，應用程式會刪除最舊的聊天。

這兩個專案都沒有登入功能，因為它們都沒有可驗證登入的伺服器。在筆記型電腦上這沒有問題。在 VPS 上，這表示頁面絕不能發佈到 0.0.0.0；也有一點容易忽略：是瀏覽器呼叫模型，而不是伺服器。

這項事實決定了這兩個專案適用的環境。瀏覽器必須能直接連線到 Ollama，因此 Ollama 必須監聽 loopback 以外的介面，而且 Ollama 完全沒有驗證機制。由此產生兩項瀏覽器規則。以 HTTPS 提供的頁面不能呼叫純 HTTP endpoint，而主控台會輸出 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 而遭拒。

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，應會在原本顯示 127.0.0.1:11434 的位置輸出 0.0.0.0:11434。只有在防火牆或具備驗證功能的 proxy 已控制可連線至該埠的使用者時，才應進行這項變更，因為開放的 11434 就是公開的模型伺服器，mass scanner 很快便會找到新的公開埠。下方的 SSH tunnel 可完全避開這個問題：此時頁面會使用 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 的強化安全頁面指出，該專案「是為私人且受信任的網路環境打造，與資料庫、容器 registry 及 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 labels 驅動的 Traefik 搭配 作為身分識別提供者的 Authentik，即可讓主機上的每個應用程式共用一組登入機制與一張憑證。讓 Open WebUI 位於 TLS（傳輸層安全性）後方時，設定 WEBUI_SESSION_COOKIE_SECURE=true 與 WEBUI_SESSION_COOKIE_SAME_SITE=strict。也應將 JWT_EXPIRES_IN 調短，不要使用預設的四週，因為 Open WebUI 文件指出，未使用 Redis 時，登出不會使 token 失效；token 會持續有效，直到自行過期。

模式二無法解決僅支援瀏覽器的專案。頁面前方的代理伺服器無法保護模型端點，而該頁面向不同主機名稱發出的 fetch 不會攜帶工作階段 cookie，因此置於 Ollama 前方的驗證代理會以登入表單的重新導向回應，導致聊天失敗。請將模型端點路由至與頁面相同的主機名稱下，或改用模式一。

應選擇哪一個

如果有其他人會使用，請執行 Open WebUI。它具備正式帳戶功能，新使用者會進入待核准佇列，維護者也會發布可依循的強化指南。如果需要 LDAP 或管理面板，請執行 LibreChat，並使用 docker stats 確認其 6 項服務加上模型後，確實符合需求，再將其作為依賴。如果是小型主機上的單一使用者，且模型已占用大部分 RAM，請透過 SSH tunnel 提供 Hollama 或 OrionChat，讓瀏覽器保留狀態。在 VPS 上，最不適當的做法是將其中任何一個發布在 0.0.0.0，且前方沒有登入機制。

FAQ

直接將 Open WebUI 暴露在公開 IP 上是否安全？

Open WebUI 的強化安全頁面將其描述為供私人、受信任網路使用的軟體，分類上與資料庫或 CI server 相同。它確實具備正式的帳戶機制，第一個帳戶會成為 administrator，後續帳戶則會維持 pending，直到獲得核准，因此安全性遠高於完全沒有登入機制的 UI。不過，仍應將它放在具備 TLS 的反向代理後方，並在可行時使用單一登入。請將容器埠發布為 127.0.0.1:3000:8080，避免 Docker 自行建立的 iptables 規則在未經察覺的情況下，從網際網路開放該埠。

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

以瀏覽器為基礎的 Hollama 和 OrionChat 使用量最少，因為應用程式在用戶端執行。伺服器只需傳送靜態檔案，而 OrionChat 完全不需要 application container。Open WebUI 會在記憶體中維持 Python process、資料庫，以及預設啟用的本機 embedding model；文件指出，光是 embedding model 每個 worker 約需 500 MB。請使用 docker stats --no-stream 在自己的主機上確認數值，因為實際用量會隨啟用的功能而變動。

這些聊天 UI 能否使用其他主機上的 Ollama server？

Open WebUI 和 LibreChat 可以，且由其 server 建立連線，因此不受瀏覽器規則限制。Open WebUI 設定 OLLAMA_BASE_URL；LibreChat 則在自訂 endpoint 中設定 baseURL。若使用 vLLM 或其他相容 OpenAI 的 server，請搭配 /v1 suffix 使用 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；必須先將該 origin 列入 OLLAMA_ORIGINS。如果頁面使用 HTTPS，而 endpoint 使用 HTTP，瀏覽器會先以 mixed content 阻擋請求，Ollama 根本不會收到請求。請在 systemctl edit ollama.service override 中設定這兩個變數，或透過 SSH 轉送該埠，即可排除這個問題。