LibreChat 与 Open WebUI——哪个接入自定义端点更省事

两者都支持自托管，都使用 OpenAI 协议，而且都能完成工作。针对这个问题排名靠前的比较文章通常会列出功能表。本页面回答的是你可能真正关心的更具体问题：哪一个连接自定义 OpenAI 兼容端点时阻力更小，以及各自提供了什么作为交换。

以下所有陈述都来自各项目自己的 README。这里没有基准测试，也没有关于哪个更好的结论，因为我们没有以足以支持结论的规模运行过任一项目。

两者的起点

	Open WebUI	LibreChat
起源	本地模型和 Ollama	多提供商 ChatGPT 克隆
列出的后端	Ollama、兼容 OpenAI 的 API	Anthropic、AWS Bedrock、OpenAI、Azure OpenAI、Google、Vertex AI、OpenAI Responses API，以及自定义端点
自定义端点配置	`OPENAI_API_BASE_URL` + `OPENAI_API_KEY`，或 Connections 界面	`librechat.yaml` 中的 `custom` 区块
检索	跨九个向量数据库的本地 RAG、带重排序的混合搜索、网页搜索	通过其支持的端点与文件聊天
访问控制	细粒度 RBAC 和用户组、LDAP/AD、SSO、SCIM 2.0	支持 OAuth2、LDAP 和电子邮件的多用户认证，以及用户、组和角色管理面板
可扩展性	Filters、actions、pipes、tools 和 skills；MCP 和 OpenAPI 工具服务器	带 MCP 工具的代理、代理市场、沙盒代码解释器
安装	pip、uv、Docker、Kubernetes	Docker 和多种一键式云部署方式

整体来看，Open WebUI 更侧重部署和检索，而 LibreChat 更侧重提供商和代理。你更看重哪一侧，通常比功能数量更适合作为最终选择依据。

将 Open WebUI 连接到网关

设置两个环境变量即可运行：

# Open WebUI — the OpenAI-compatible connection is a base URL and a key.
docker run -d -p 3000:8080 \
  -e OPENAI_API_BASE_URL=https://api.kunavo.com/v1 \
  -e OPENAI_API_KEY=sk-kn-... \
  -v open-webui:/app/backend/data \
  --name open-webui ghcr.io/open-webui/open-webui:main

# The same two values can be set in Settings -> Connections after
# first launch, which is the faster path when you are trying it out.

由于模型选择器可以从 GET /v1/models 填充，提供多个模型系列的端点会将它们全部放入同一个下拉菜单——Claude 和 GPT 的 ID 会一起出现，无需第二次配置。

将 LibreChat 连接到网关

LibreChat 要求使用 YAML 区块，而不是环境变量；需要编写的内容更多，但可以为你提供命名和模型控制：

librechat.yaml

# LibreChat — a custom endpoint is a block in librechat.yaml.
version: 1.2.1
endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-5", "gpt-5-6-terra", "claude-haiku-4-5"]
        fetch: true          # populate the picker from GET /v1/models
      titleConvo: true
      titleModel: "claude-haiku-4-5"
      modelDisplayLabel: "Kunavo"

无论端点是什么，titleModel 这一行都值得复制：LibreChat 会通过模型调用生成对话标题，将其固定为列表中最便宜的模型，可避免标题按你当时聊天所用模型的费率计费。

为什么要在任一客户端后面放置网关

两个客户端都可以同时连接多个提供商，因此网关并非必需。它改变的是需要配置的事项数量和收到的账单数量：用一个基础 URL 和一个密钥，替代每个模型系列各自的账户、凭据和计费关系。之后添加模型系列，只需在列表中加入模型 ID，而不是进行新的集成。

Kunavo 提供两个客户端所使用的兼容 OpenAI 接口，因此上面的基础 URL 已足够。每个客户端的设置细节见集成中心，端点参考见聊天补全，兼容 OpenAI 的 API 指南说明了“兼容”包含和不包含哪些内容。

常见问题

LibreChat 和 Open WebUI 有什么区别？

两者都是自托管、开源的聊天界面，可以连接兼容 OpenAI 的 API；区别在于它们的起点不同。Open WebUI 围绕 Ollama 和本地模型发展，其 README 首先介绍了跨九个向量数据库的本地 RAG、细粒度 RBAC 和用户组、由 filters、actions、pipes 和 tools 组成的插件系统，以及通过 pip、Docker 或 Kubernetes 安装。LibreChat 则起源于多提供商 ChatGPT 克隆，其 README 首先列出 Anthropic、AWS Bedrock、OpenAI、Azure OpenAI、Google、Vertex AI 和 OpenAI Responses API 等命名提供商支持，以及自定义端点、带 MCP 工具的代理和支持多种语言的沙盒代码解释器。

哪个更容易连接到自定义的 OpenAI 兼容 API？

如果你希望一条命令运行，Open WebUI 更简单：连接只需两个环境变量 OPENAI_API_BASE_URL 和 OPENAI_API_KEY；首次启动后，也可以在界面的 Connections 中设置同一对变量。LibreChat 则要求使用 YAML 文件——自定义端点需要在 librechat.yaml 中配置一个包含 name、apiKey、baseURL 和 models 部分的区块。需要编写的内容更多，但也换来了更多控制：你可以命名端点、控制显示哪些模型，并将便宜的模型固定用于对话标题。两者都不需要代理；LibreChat 文档明确说明，自定义端点无需代理即可工作。

团队使用应该选哪个？

应将每个项目自己的功能列表与需求对照，而不是直接接受包括本页面在内的比较页面结论。Open WebUI 声明支持细粒度 RBAC 和用户组、LDAP/Active Directory、通过受信任标头和 OAuth 实现的 SSO，以及 SCIM 2.0 配置。LibreChat 声明支持 OAuth2、LDAP 和电子邮件登录的多用户认证，以及用于管理用户、组和角色的管理面板。两者都覆盖常见场景；对特定组织真正重要的差异通常在配置细节中，应优先查看这些内容。

两者可以同时使用 Claude 和 GPT 吗？

可以，这正是许多人在两者背后使用网关的主要原因。两者都接受兼容 OpenAI 的端点；如果该端点提供多个模型系列，所有模型就会在一个密钥下出现在同一个模型选择器中。没有网关时，你需要分别配置每个提供商，每个提供商都有独立账户和账单；使用网关后，添加模型系列只需在列表中加入模型 ID，而不是进行新的集成。

使用 Open WebUI 必须安装 Ollama 吗？

不需要。Open WebUI 支持 Ollama 和兼容 OpenAI 的 API，其 README 说明可以将 API URL 指向托管提供商并混合使用。仅连接托管端点运行是受支持的配置，而不是权宜之计——如果你希望使用该界面但没有能够在本地运行模型的机器，这一点很重要。

网关会改变任一客户端的行为吗？

它改变的是请求发送到哪里以及费用如何计算，而不是界面的工作方式。两个客户端都通过 OpenAI 协议与所提供的基础 URL 通信，因此 RAG、代理和 RBAC 等功能属于客户端，不受影响。需要检查的一点是模型列表：两者都可以通过 GET /v1/models 填充模型选择器，因此你看到的模型取决于端点报告的内容，而不是硬编码列表。