用 LibreChat 搭建多租户 AI 服务

每席每月卖 12 美元的企业 AI 助手，能不能留出 75% 毛利？作者提出的方案是：用 LibreChat 提供聊天和 Agent 能力，自己补上租户开通、身份接入、席位计费与成本控制，让每家公司拥有独立部署的助手。

这篇值得看的地方，是把 SaaS 运营拆成了具体工程问题。但它更接近一份架构提案，缺少生产规模、压测和实际账单，尤其成本结论需要拆开核算。下面涉及的价格与产品能力均按原文讨论，未做独立核验。

为什么每个客户都要单独部署

作者先找了一个价格空间：ChatGPT Business 和 Claude Team 标准席位，年付折算均为每月 20 美元，月付为 25 美元；Microsoft 365 Copilot Business 月付 25.20 美元，还需另购 Microsoft 365 许可证。于是，面向特定公司的品牌化助手，可能以每席 12 美元切入。

LibreChat 已经提供聊天 UI、agents、skills、MCP、多用户认证、管理后台和 token 余额。原文称它采用 MIT 许可，约有 46.6K GitHub stars；并引用 2025 年 11 月 ClickHouse 收购公告中的案例：Shopify 基于它运行内部 AI，拥有数千个自定义 Agent 和超过 30 个内部 MCP 服务。这能说明已有企业采用，不能直接证明本文方案的成本。

关键限制在部署方式。LibreChat 围绕一个组织设计：一份 librechat.yaml、一份 .env、一套用户和管理后台。把所有客户塞进同一实例，再给数据集合补租户 ID，需要持续维护自己的隔离改造。

作者因此选择 silo 模式，也就是每个客户各有一套应用和数据环境。

共享的控制平面负责注册、套餐、Postgres 租户登记、Stripe webhooks、部署、席位同步、用量告警和升级。每个租户的数据平面包括 LibreChat API 与网页、独立 MongoDB 数据库、Meilisearch 索引、RAG API 与 pgvector，以及连接客户工具的 MCP 服务。

客户最终拿到 acme.yourapp.com。规模达到数百个小租户时，可以把多个租户容器放到同一宿主机，数据库仍保持分离。

独立部署降低了改造 LibreChat 的压力，也把复杂度转移到了部署和运维。

隔离要同时管住数据、身份和连接器

作者给出的三项决策，分别处理不同的边界。

第一，每个租户使用独立的 Anthropic Workspace，配置专属 API key、月度消费限额和速率限制。某个客户失控时，先碰到自己的额度上限，费用也更容易归属。这里不能把部署草图里的 createAnthropicWorkspace 当成现成 API：作者明确说它是占位函数，可以通过 API 或 Console 人工管理，密钥应保存在 secrets manager，部署时注入。

第二，每个租户通过 OpenID 接入客户的 Google Workspace、Microsoft Entra ID 或 Okta。配置涉及 OPENID_ISSUER、OPENID_CLIENT_ID 和 OPENID_BUTTON_LABEL；关闭 ALLOW_REGISTRATION，开启 ALLOW_SOCIAL_LOGIN，再用 APP_TITLE、CUSTOM_FOOTER 定制品牌。

这让账号管理靠近企业现有流程。但原文把「离职后失去访问」说得较简略，已有会话何时失效、应用用户何时停用，并没有展开。

第三，MCP 使用每用户 OAuth，而不是全员共享连接器账号。原文列出的传输方式包括 stdio、sse、websocket 和 streamable-http。设置 requiresOAuth: true 后，每个人连接自己的账号，底层工具继续承担权限判断。

这能减少共享凭据造成的越权，但不等于只加一个配置就完成安全设计。MCP 服务如何保存 token、处理撤销和校验权限，仍要实现。

每席 12 美元能否成立，先看额度和模型账单

作者给成本设置了三道限制：用户余额、租户 Workspace 上限，以及按任务选择模型。下面的配置同时展示了用户额度和 MCP 接入：

version: 1.3.18

interface:
  customWelcome: 'Welcome to Acme AI. Ask about your clients, files and projects.'

balance:
  enabled: true
  startBalance: 6000000        # 1,000,000 credits = $1，所以对应 $6 的额度
  autoRefillEnabled: true
  refillIntervalValue: 30
  refillIntervalUnit: 'days'
  refillAmount: 6000000
  refillMode: 'reset'          # 每期替换额度，不结转
  display: 'currency'

mcpServers:
  documents:
    type: streamable-http
    url: https://mcp.acme.yourapp.com/documents/mcp
    requiresOAuth: true
    timeout: 60000

关键是 refillMode: 'reset'：每 30 天重置为 6000000 credits，即 6 美元，避免旧的 add 行为让余额长期累积。切换前必须确认所有副本都支持 reset。另外，每 30 天刷新并不天然等于跟随账单月份刷新。

租户 Workspace 的限额大致设为席位数乘以 6 美元。它限定的是风险上限，毛利还取决于实际消耗。

按原文价格，提示不超过 100K tokens 时，Claude Haiku 5.5 每百万输入、输出 tokens 分别为 0.10、0.50 美元；Claude Sonnet 5.5 分别为 2、10 美元。作者建议简短问答默认走 Haiku，Agent 和长文档走 Sonnet。

以每席每月 300 条消息、每条 4000 输入和 600 输出 tokens 计算，全部走 Haiku 约为 0.21 美元，全部走 Sonnet 约为 4.20 美元。模型分流确实会明显影响账单。

作者再加上 50 席租户每月 60 美元的托管预算，即每席 1.20 美元。其中，us-east-1 的 t4g.medium 按需实例标价约为每月 24.53 美元。支付成本按 Stripe Billing 的 0.7%，加美国银行卡费率 2.9% 和每笔 30 美分计算，一张 600 美元账单约摊到每席 0.44 美元。

原文最终给出混合路由后每席约 3.05 美元、接近 75% 毛利的结论，却没有给出模型调用比例，也没有逐项解释完整托管预算。Prompt caching 未计入，作者认为还能继续降本。

每人 6 美元的额度是消费上限，不能当成每席约 3 美元成本的保证。

席位同步和升级，才是需要长期维护的部分

计费方案是每天同步已开通用户数，取用户数与最低席位数的较大值，再交给 Stripe 按比例调整费用：

// control-plane/seat-sync.ts
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function syncSeats(t: Tenant) {
  const users = await tenantDb(t.slug).collection("users").countDocuments({});
  const seats = Math.max(users, t.minimumSeats);
  if (seats !== t.billedSeats) {
    await stripe.subscriptionItems.update(t.stripeSeatItemId, {
      quantity: seats,
      proration_behavior: "create_prorations",
    });
    await registry.setBilledSeats(t.id, seats);
  }
}

需要盯住的是 countDocuments({})：它统计数据库中的全部用户记录。若停用账号、离职账号仍保留，就未必符合客户理解的计费席位。代码表达了同步流程，具体计费口径仍需补齐，并向客户管理员展示收费用户名单。

升级方面，每个租户在登记表里固定 LibreChat 镜像标签，先升内部租户，再升友好客户，最后推广。配置统一从模板生成，每次升级后检查登录、一条 Haiku 消息、一条 Sonnet 消息和一次 MCP 调用。

原文还提醒了几个实际故障点：OAuth token 会过期或撤销，需要方便的重连入口；长对话会持续扩大上下文，应提示按任务新建聊天；慢 MCP 服务会拖慢回答，需要超时与告警。

我的判断

我认可先独立部署、再提高宿主机利用率的顺序。对于建立在现有开源应用上的产品，它能减少对认证和数据访问代码的侵入。相比共享实例加租户字段，代价是更多实例、配置和升级任务；客户少而规模适中时较容易接受，大量微型客户则需要重新核算。

成本部分只能视为预算示例。原文没有实际客户用量分布、完整基础设施账单，也没有模型分流的质量对照。每条消息固定输入和输出长度，尤其难以代表工具调用、长文档和多轮对话。

此外，原文披露内容由 AI 辅助，并以开发工作室的服务推广收尾。它提供了可讨论的工程路线，但没有证明这套路线已经在所述成本和规模下跑通。

能拿来做什么

• 做企业 AI 助手时，可以先把聊天能力与 SaaS 管理拆开：让 LibreChat 承担交互和 Agent，让自己的 Node 服务负责租户登记、开通流程和计费同步。
• 设计成本控制时，分别定义用户额度、租户总额和模型路由，再用真实请求记录核算成本，不要直接把文中的 75% 毛利写进预算。
• 接企业 SSO 和 MCP 时，把离职后的会话失效、OAuth 撤销及重连一起验收，检查权限是否跟随底层账号变化。
• 实现席位同步前，先明确停用账号是否收费，并让客户管理员看到计费名单；升级时则固定镜像标签，按租户逐步验证。