Open WebUI 替代方案：授權、BYOK、RAG 與遷移

多數搜尋 Open WebUI 替代方案的需求，真正關心的並不是價格：Open WebUI 可免費自架給不限數量的內部使用者，而專案完全沒有公布價格。人們實際離開的原因更明確——v0.6.6 起授權不再是標準開源授權、伺服器對單人使用者來說不合適、自訂端點的支援方式不符合其閘道，或是希望由其他人代為託管。每個原因都指向不同的替代方案，而它們之間的遷移成本也大不相同。

先釐清一點，因為搜尋結果混入了幾個名稱相似但彼此無關的專案。Open WebUI 是 open-webui/open-webui，前身為 Ollama WebUI。它不是 AUTOMATIC1111 的 Stable Diffusion web UI，也不是 OpenUI（根據提示生成 UI），更不是 text-generation-webui；後者已在 oobabooga/textgen 更名為 TextGen，是本機模型桌面應用程式，而非團隊前端。

從你離開的原因開始

精確理解授權——以及該停止重複的迷思

影響整體生命週期的事件不是更名或收購，而是授權變更。根據專案的 授權文件，截至 v0.6.5（含）以前提交或合併的所有程式碼仍採 BSD-3 授權。自 v0.6.6 起，專案改採專屬的 Open WebUI License，這是加入品牌保護條款的 BSD-3 衍生授權，而 GitHub 的儲存庫 API 將授權回報為 NOASSERTION，而非受認可的標準授權。GitHub Releases 記錄的分界日期為：v0.6.5 於 2025 年 4 月 14 日，v0.6.6 於 2025 年 5 月 5 日。請注意，授權文件本身為變更附上了日曆日期——「自 v0.6.6（2025 年 4 月 19 日）起生效」——這與 GitHub 記錄的該版本發布日期不一致，因此應引用版本，而非引用任一日期。

現在來更正。授權文字禁止修改、移除、遮蔽或替換 Open WebUI 品牌標示，但有三種例外情況；第一種是部署「任何連續三十（30）天期間內，終端使用者總數……不超過五十（50）人」；另外兩種是取得著作權所有人的事前書面許可，以及正式簽署的企業授權。授權文件另行列出「在自己的組織內部署給任意數量的內部使用者（保留所有官方品牌標示）」是免費授權允許的事項。因此，五十人這個數字是品牌例外條款，而非部署上限——與多數比較文章所說的正好相反。著作權由 Open WebUI Inc. 持有。[由 Timothy Jaeryang Baek 建立]。

企業授權實際限制的是白標化、移除品牌標示，以及企業專屬功能。其價格並未公開：企業方案頁面要求您「提供部署環境的終端使用者人數（席次）」，而 openwebui.com/pricing 在 2026 年 9 月 21 日查核時回傳 HTTP 404。您在其他地方看到的任何每席價格，都是代管服務供應商的價格，或是憑空捏造的。

就重要指標而言，專案本身狀況良好：未封存、擁有超過 150,000 顆星，且在本次檢查前幾天仍有推送；穩定版本 v0.11.3 於 2026 年 8 月 31 日發布（發布版本 API）。但其中一個子元件並非如此：外掛框架 open-webui/pipelines 上次推送是在 2025 年 8 月 18 日。如果你的部署依賴 Pipelines，在繼續建置之前，這個更新頻率值得納入評估。

依執行方式分類的入選方案

該表格有三點注意事項，均檢查於 2026 年 9 月 21 日。LibreChat 最新標籤是 2026 年 9 月 15 日的預發布版本 v0.8.8-rc3，而 GitHub 的 /releases/latest 回傳 404，因此目前沒有標記為最新的版本——固定版本前，請閱讀專案自己的變更日誌，不要相信摘要中的數字。LobeHub 的 定價頁面內容彼此不一致：方案卡片顯示 Starter、Premium 與 Ultimate 每月分別為 $9.9、$19.9 與 $39.9，但同一頁面的比較表顯示 Starter 為 $12.9，並列出 $118.8 的年度金額，因此在承諾購買前，請於結帳時確認金額。此外，TypingMind 的 Premium 價格正處於宣稱的 50% 促銷期間，這類數字最容易快速失效。Chatbox 的付費層級是針對其自有託管模型；依其 自帶金鑰指南，指向你自己的金鑰即可使用免費路徑。

替代方案清單中會出現、但不應列入的兩個專案：Chatbot UI 採 MIT 授權且未封存，但上次推送是在 2024 年 8 月 3 日，且沒有任何發布版本，因此它已休眠，而不是持續運作的選項；NextChat 現在將自己描述為一種零設定助理，註冊後即可使用，不需要 API 金鑰，並採按使用量付費，而非純粹的自帶金鑰前端。搜尋時也值得分開辨識：Jan 不是 Janitor AI，Msty Studio 不是 MSTY 交易所交易基金，而 LobeChat 與 LobeHub 更名後是同一個專案，因此 1.0 以前的 LobeChat 設定教學已不適用。

各方案如何使用自訂的 OpenAI 相容端點

以下八個用戶端的文件都說明了如何將其指向第三方端點。差異在於設定介面、URL 形式，以及是否能使用 Chat Completions 以外的功能。其中一欄的問題需要明確限定：「Anthropic Messages route」詢問的是用戶端本身是否會向你的端點傳送 Anthropic 形式的請求。該欄顯示「None documented」表示供應商文件未描述這種模式，而不是已知該模式不存在。

該表格的資料來源是各供應商自己的文件：Open WebUI 的 OpenAI-compatible 與 Open Responses 連線頁面、LibreChat 的自訂端點參考、AnythingLLM 的 Generic OpenAI 頁面、Jan 的自訂端點文件、ChatWise 的自訂供應商文件、LobeHub 的 providers 頁面、Msty 的線上供應商文件，以及 TypingMind 的模型連線文件。

Cherry Studio 刻意未列入該表格。其文件網域現在從 docs.cherry-ai.com 重新導向至 docs.cherryai.com.cn，這是一個中文網站；本頁未閱讀其供應商頁面，因此其欄位名稱與路徑慣例在此未經驗證——從舊教學複製任何 Base URL 前，請先在應用程式中確認。

無論你採用哪種方式，有兩項 Open WebUI 特性值得了解。其供應商連線文件指出，部分供應商根本沒有實作 /models；在這種情況下，連線驗證會失敗，但聊天完成仍可運作，而你需要手動輸入模型 ID。文件也警告，Google 的相容層偏離 OpenAI 串流結構，建議將 Function Calling 設為 Legacy，讓工具透過獨立的非串流請求運作。該警告針對的是單一供應商的相容層，而非一般的相容層——但它提醒我們，工具呼叫會透過上游實際實作的方式抵達，前端無法替你修正結構缺口。

在 Kunavo 方面，/v1/chat/completions、/v1/messages 與 /v1/responses 都有對應路由，因此 LibreChat 的 provider: anthropic、Jan 與 ChatWise 的 Anthropic-compatible 模式，以及 Open WebUI 的實驗性 Responses 路徑，都各自有相符的介面。本頁未對這些用戶端與 Kunavo 進行執行期測試；已發布的設定指南是設定參考，而不是相容性測試。可運作的 LibreChat 自訂區塊如下：

endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-4-6", "claude-haiku-4-5"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5"

如需了解這項設定在各用戶端中的一般形式，請參閱 OpenAI-compatible API。如需比較兩個產品，LibreChat vs Open WebUI涵蓋設定阻力，AnythingLLM vs Open WebUI涵蓋 RAG 與部署。

RAG：不會沿用聊天端點的部分

將前端指向聊天端點，並不會同時將其檢索管線指向任何地方。Open WebUI 為此使用獨立的憑證。根據其環境變數參考，RAG_EMBEDDING_ENGINE 選擇引擎，RAG_OPENAI_API_BASE_URL / RAG_OPENAI_API_KEY 承載其端點，正如圖片生成也有自己的 IMAGES_OPENAI_API_BASE_URL。留空時，RAG_EMBEDDING_ENGINE 預設為在本機執行的 SentenceTransformers——嵌入向量的 GPU 加速需透過 CUDA 映像檔選用啟用——因此預設不會產生每次請求的費用。AnythingLLM 也採相同的分離方式，將其 LLM、嵌入器與向量資料庫設定為獨立的供應商。因此，聊天相容性不會在任一產品中建立檢索相容性。

這裡的重要性在於一個具體原因：Kunavo 不提供嵌入服務——沒有啟用的模型支援該端點——因此檢索步驟會留在本機，或指向你選擇的外部供應商。請將其與聊天分開編列預算，並排除在任何閘道遷移計畫之外。RAG implementation說明各階段如何分離。

哪些內容可遷移，以及你需要重新建立的內容

開始前先建立正確預期：聊天記錄不會自動在這些產品之間移動。Open WebUI 的匯入與匯出文件表示，匯出內容包括「所有聊天訊息及其詮釋資料、每段對話所使用的模型資訊、時間戳記與對話結構」，而匯入功能接受 Open WebUI 匯出檔、ChatGPT 匯出檔及自訂 JSON——並直白指出，對其他平台「沒有內建轉換器」。在接收端，LibreChat 的匯入文件列出 ChatGPT、Claude 與 ChatbotUI v1，並未提及 Open WebUI。兩個有文件記載的匯入器，彼此沒有重疊。

即使你繼續使用 Open WebUI，最後一列也是應先解決的事項。根據擴展文件，一旦擁有正式環境資料，引擎選擇基本上就是永久性的；多副本部署需要 PostgreSQL、Redis 與外部向量資料庫，而不是 SQLite 與內嵌 Chroma；對於網路儲存上的 SQLite，文件提供的唯一補救方式是移至 PostgreSQL，而不是調整某個旗標。因此，真正的整個執行個體遷移是對資料目錄進行檔案層級複製，而不是匯出檔。資料庫維護教學將 webui.db——及其 -wal 與 -shm 側檔——放在容器內的 /app/backend/data；而環境變數參考將 DATA_DIR描述為「用於資料儲存，包括上傳內容、快取、向量資料庫等」的基礎目錄，稽核日誌則預設位於同一目錄內的 audit.log。請複製整個目錄，而不是只複製檔案清單。

在進行任何操作前先備份。先確認您自己的容器名稱——以下是格式，不是可盲目貼上的腳本：

# 1. Stop the instance so nothing writes mid-copy.
docker stop open-webui

# 2. Copy the whole data directory out of the container.
#    The documented location is /app/backend/data. DATA_DIR is
#    described as the base for uploads, cache, the vector database
#    and the audit log, so take the directory rather than webui.db.
docker cp open-webui:/app/backend/data ./open-webui-backup-$(date +%F)

# 3. Start it again and confirm the UI still loads before you touch anything.
docker start open-webui

回復計畫：在試用替代方案期間，保留舊的執行個體及其映像檔標籤，讓它們維持完整且持續運作，而不是直接在原地遷移。讓兩者對同一端點同時運作一週，先讓一個團隊使用，只有在新執行個體經歷過實際工作負載並穩定運作後，才停用原始執行個體。由於聊天記錄不會轉移，在您停用原始執行個體後才回復，意味著會遺失在新工具中寫入的內容——這比任何功能比較都更有力地支持讓兩者並行運作。

無論您選擇哪個前端，模型端的成本

這些前端都不會對 token 計費；真正計費的是其背後的 API。以下數字是示意性的 token 算術，不是實測成本，也不是帳單上限。假設一個人每天工作日進行 10 次對話，每次對話在各輪中傳送25,000 個未快取的輸入 token並接收1,500 個輸出 token，持續 20 個工作日——也就是每人每月 5,000,000 個輸入 token 和 300,000 個輸出 token。費率是每百萬 token 的即時Kunavo 目錄價格。

請將其與前端價格對照，而不是取代前端價格。自架前端不會按席位收費，因此在這些假設下，整個團隊使用 Claude Sonnet 4.6 模型的流量每月估算為 $68.25，而同一團隊使用 Claude Haiku 4.5 模型則估算為 $22.75——在流量假設完全相同的情況下，每月差額為 $45.50，而且每月都會重複產生，不是只支付一次。因此，前端預設指向哪個模型，本身就是一項即時的預算決策，與您為應用程式支付的授權費分開。真正決定成本的是您的實際使用模式，因此請先衡量自己的對話，再編列預算。AI 成本最佳化說明如何誠實地進行這項衡量。

Kunavo 的目錄金額是計費下限，而不是上限：上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成後兩者之較高者。快取費用與外部工具不包含在此範例中。最低加值金額為預付額度$10，這會增加餘額，而不是購買席位或方案——請參閱計費詳細資料。

如果您打算繼續使用 Open WebUI

這是本頁結論中完全站得住腳的一種選擇，而且對大多數團隊而言也是正確選擇：授權變更限制的是白標化，而不是部署規模；專案仍在積極發布；上述內容沒有任何理由要求您重建一個正常運作的執行個體。無論如何，值得做的是將前端決策與端點決策分開，這樣未來更換用戶端時，就不必同時更換供應商並建立新金鑰。Kunavo 為此用戶端發布了設定參考——Open WebUI 整合指南——以及 LobeHub、Chatbox 和 Cherry Studio 的設定文件。當您想在所選前端背後使用一個金鑰和一個預付餘額時，請建立 Kunavo 帳戶。

常見問題

於 2026 年 9 月 21 日查核，方法是直接閱讀每個連結頁面或 GitHub API 回應：Open WebUI 的授權條款文字、授權與企業文件、供應商連線、擴展及匯入／匯出文件、其儲存庫與最新版本；openwebui.com/pricing 的 404 頁面；LibreChat 的儲存庫與匯入文件；以及 AnythingLLM、LobeHub、Msty、ChatWise 和 TypingMind 已發布的定價頁面。同樣直接閱讀了：Open WebUI 的 Open Responses 與環境變數參考頁面、LibreChat 的自訂端點參考、AnythingLLM 的 Generic OpenAI 頁面、Jan 與 ChatWise 的自訂供應商文件、LobeHub 的供應商頁面（仍是遷移佔位頁面）、Chatbox 的自帶金鑰指南，以及 Pipelines、TextGen 和處於休眠狀態的 Chatbot UI 的儲存庫中繼資料。Msty 與 TypingMind 的設定步驟雖有連結，但內容取自文件摘要，而非完整閱讀。Cherry Studio 的設定欄位仍未驗證，並已在上文標示。此頁面中的任何用戶端都未針對 Kunavo 進行執行時測試。Kunavo token 費率取自即時目錄，成本章節中的所有美元數字都是示意性的 token 算術。