多租户的五大核心问题

问题不解决后果
子 key 管理租户泄露一个 key 全站崩
用量隔离单租户跑光所有人额度
限速配额上游被打 429，所有租户挂
计费归账月底不知道该向谁收多少
PII 隔离租户 A 数据出现在租户 B 上下文

任何号称「就上线一个 AI 功能」的 SaaS 都逃不开这五个问题。

四种主流架构

A. 应用层手撸（0-10 租户）

租户 ─► 你的 API ─► OpenAI / Anthropic
              │
              ├─ Redis 计数表
              └─ Postgres 流水表
  • 优势：零额外依赖，代码 200-500 行搞定
  • 劣势：限速 / 重试 / fallback 都要自己写

B. LiteLLM Proxy（10-50 租户）

租户 ─► LiteLLM Proxy ─► OpenAI / Anthropic / 中转
              │
              └─ 内置 user / team / budget
  • 优势：Docker 部署 10 分钟，子 key + budget + logging 开箱
  • 劣势：UI 较简单，复杂分组管理不如 OneAPI

C. OneAPI / NewAPI（50+ 租户）

租户 ─► OneAPI 控制台分发 user key ─► 多 channel：OpenAI / Anthropic / 中转
              │
              └─ 管理界面 + 用量统计 + 配额隔离
  • 优势：成熟的多用户控制台，团队场景高规格
  • 劣势：自托管运维成本（Docker + MySQL）

D. 混合（高级团队）

租户 ─► 应用层 ─► LiteLLM Proxy（应用层 router）─► OneAPI（infra 网关）─► 多 channel
  • 应用层做业务逻辑相关的 fallback（按租户 SLA）
  • Gateway 层做 provider 抽象 + 用量管控
  • 上手成本高，但 100+ 租户场景才能发挥优势

子 key 与计费一体化设计

核心数据表（PostgreSQL 示例）：

-- 租户子 key
CREATE TABLE tenant_api_key (
  id BIGSERIAL PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  api_key_hash TEXT NOT NULL UNIQUE,
  monthly_budget_cents INT NOT NULL DEFAULT 0,
  status TEXT NOT NULL DEFAULT 'active'
);

-- 调用流水
CREATE TABLE llm_call (
  id BIGSERIAL PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  api_key_id BIGINT NOT NULL,
  ts TIMESTAMPTZ NOT NULL DEFAULT now(),
  model TEXT NOT NULL,
  input_tokens INT NOT NULL,
  output_tokens INT NOT NULL,
  cost_cents INT NOT NULL,
  request_id TEXT
);

CREATE INDEX llm_call_tenant_ts ON llm_call (tenant_id, ts);

每次调用插一条流水。月底 GROUP BY tenant_id 即得每租户月成本。

限速三级方案

级别实现典型阈值
全局 QPSNginx limit_req50 rps
租户 RPM/TPMLiteLLM Proxy / OneAPI 配置60 rpm / 100k tpm
用户日配额应用层 Redis 计数50k tokens/day

任何一层触发都返回 429 + Retry-After，应用层做指数退避。

PII 隔离铁律

  1. RAG 检索：WHERE tenant_id = current_tenant，永远不能省
  2. 缓存 key：cache:{tenant_id}:{prompt_hash}，不能跨租户共享 Prompt Cache
  3. 上下文拼接：每次只放当前租户的历史
  4. Anthropic / OpenAI 都支持 metadata.user_id 字段，传 hash(tenant_id) 帮审计

从 0 到 100 租户的迁移路径

阶段租户数推荐架构迁移点
0-10PoCA 手撸觉得限速 / 计费写得累
10-30早期付费B LiteLLM Proxy想要 UI 管理子 key
30-100规模化C OneAPI团队多人协作 + 审计
100+成熟D 混合多 SLA 等级 + 多 region

配套中转线路推荐

多租户场景对 upstream 稳定性敏感度更高——任何一家 channel 抖动都会影响多个租户。建议主备至少两家，把一条多模型统一计费的 API 网关作为备用 channel 配进 OneAPI，主线挂掉时自动 fallback。

落地条件

多租户 LLM API 落地时，最怕把法律主体、收款工具和产品代码混成一个问题。动手前看清回滚动作、费用影响和权限变化，金额较大或涉及税务时交给专业顾问处理。

一个人运营时可以用表格压住复杂度：负责人、后台入口、到期日、费用来源和回滚动作各占一列。

相关阅读