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 日。请注意，许可证文档为变更附带了自己的日历日期——“Effective with v0.6.6 (April 19, 2025)”——这与 GitHub 记录的该版本发布日期不一致，因此应引用版本，而不是引用其中任一日期。

现在纠正这一点。许可证文本禁止修改、移除、遮挡或替换 Open WebUI 品牌标识，但有三种情况除外；第一种是“在任何连续三十（30）天期间最终用户总数……不超过五十（50）人”的部署；另外两种是获得版权持有人的事先书面许可，以及正式有效签署的企业许可证。许可证文档另行将“在自己的组织内部署给任意数量的内部用户（保留所有官方品牌标识）”列为免费许可证允许的事项。因此，五十名用户这一数字是品牌例外，而不是部署上限——这与大多数比较文章所说的恰好相反。版权归 Open WebUI Inc. 所有。[由 Timothy Jaeryang Baek 创建]。

企业许可证实际限制的是白标化、品牌标识移除以及企业专属功能。其价格并未公开：企业版页面要求你“向我们提供你的部署的最终用户数量（席位数）”，而在 2026 年 9 月 21 日检查时，openwebui.com/pricing 返回了 HTTP 404。你在其他地方看到的任何每席位价格，要么是托管服务供应商的价格，要么是编造的。

从关键指标来看，项目本身状态良好：未归档，拥有超过 150,000 个 stars，并在本次检查前几天内仍有推送；稳定版本 v0.11.3 于 2026 年 8 月 31 日发布（Releases 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 的提供商页面、Msty 的在线提供商文档以及TypingMind 的模型连接文档。

Cherry Studio 有意未列入该表。其文档域名现已从 docs.cherry-ai.com 重定向至 docs.cherryai.com.cn，这是一个中文网站；本页面未阅读其提供商页面，因此这里无法核实其字段名称和路径约定——从旧教程复制任何基础 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 的导入和导出文档称，导出内容包括“All chat messages and their metadata, Model information used in each conversation, Timestamps and conversation structure”，导入则接受 Open WebUI 导出文件、ChatGPT 导出文件和自定义 JSON；文档还直截了当地写明，对于其他平台“There is no built-in converter”。在接收端，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 算术。