多租户隔离与配额治理#

一、四层隔离体系

数据隔离详细设计：

方案A：Schema-per-tenant（强隔离）
  └─ 每个租户独立 schema/database + 独立向量 collection
  └─ 优点：隔离彻底、迁移容易
  └─ 缺点：管理开销大、连接数多

方案B：Shared-schema + Row-level（弱隔离）
  └─ 共享表 + tenant_id 字段 + 查询自动注入 WHERE tenant_id=X
  └─ 优点：管理简单、资源利用高
  └─ 缺点：bug可能导致数据泄露，需要严格的interceptor

方案C：混合方案（推荐）
  └─ 核心数据（文档/向量）schema隔离 + 元数据共享表

上下文隔离关键：

• Redis 缓存键必须带 tenant:{tid}: 前缀
• 对话历史存储时绑定 tenant_id，查询时必须校验
• RAG 检索时向量搜索 filter 必须包含 tenant_id
• LLM 调用的 system prompt 不能包含其他租户信息

二、三级配额体系

配额实现架构：

请求进入
  → 网关层：RPM 限流（令牌桶/滑动窗口，Redis 计数器）
    → 服务层：TPM 检查（预估本次Token消耗，检查剩余额度）
      → 调用 LLM
        → 回调：扣减实际Token消耗，更新计费
          → 检查是否触发预算告警/止损

令牌桶限流实现要点：

Key: rate_limit:{tenant_id}:{minute_window}
操作: INCR + EXPIRE（原子操作，使用Lua脚本）
判断: count > quota → 拒绝，返回 429 + Retry-After 头

三、两道止损机制

第一道：软限告警（预算80%/90%）

• 触发条件：月度Token消耗达到预算的80%
• 动作：发送告警通知（邮件/Webhook）、Dashboard标黄
• 不影响服务，仅提醒

第二道：硬限熔断（预算100%）

• 触发条件：月度消耗达到预算上限
• 动作：
  1. 拒绝新请求，返回 402 + 超额提示
  2. 或者降级：切换到更便宜的模型（GPT-4→GPT-3.5）
  3. 或者限制功能：关闭非核心Agent能力
• 可配置策略：hard_stop / downgrade / notify_only

预算监控流程：
  每次 LLM 调用完成
    → 累加 actual_tokens 到 usage:{tenant_id}:{month}
    → 检查 usage / budget 比例
      ├─ < 80%  → 正常
      ├─ 80-90% → 黄色告警
      ├─ 90-100%→ 红色告警
      └─ >= 100%→ 执行止损策略

四、降级策略矩阵

五、计费与 Chargeback

Chargeback 流程：

1. 实时计量：每次调用记录 tenant_id + token_count + model + timestamp
2. 日结算：汇总每个租户每日消耗
3. 月账单：生成详细账单（按模型、按功能拆分）
4. 异常检测：消耗突增自动告警

六、审计与合规

必须记录的审计日志：

• WHO：哪个租户的哪个用户
• WHAT：调用了什么模型/工具
• WHEN：时间戳
• HOW MUCH：消耗了多少 Token/费用
• RESULT：成功/失败/降级

合规要求：

• 数据驻留：租户数据不出指定Region
• 数据删除：租户注销时完全删除数据（包括向量、缓存、日志）
• 访问审计：所有数据访问可追溯

AI平台的多租户治理我会从四层隔离和三级配额来设计。隔离方面最关键的是数据隔离，每个租户的知识库和向量索引必须独立，我推荐核心数据schema隔离、元数据共享表的混合方案。上下文隔离要确保Redis缓存键带租户前缀，RAG检索必须filter tenant_id，防止记忆串租户。配额方面分三级：RPM控制请求频率用令牌桶限流，TPM控制Token吞吐在调用前预估额度，预算控制总成本月度封顶。止损机制分两道：80%预算时软限告警通知管理员，100%时硬限熔断可以选择拒绝服务或降级到更便宜的模型。计费采用实时计量日结算月账单的模式，按input/output token分别计价。审计日志记录who/what/when/how much四要素，支持合规审查。这套体系的核心目标是：租户之间不串扰、成本可控可预测、异常有告警有兜底。

追问方向：

• “数据隔离 schema-per-tenant 连接数太多怎么办？”→ 连接池 per-tenant 设上限 + 连接复用（同租户请求共享连接池）+ 冷租户延迟建连（首次请求时才创建连接，空闲超时释放）
• “配额被恶意消耗怎么防？”→ 异常检测：单次请求 Token 异常大（超阈值拒绝）、短时间请求激增（滑动窗口计数）→ 自动临时限流 + 告警人工复核
• “多租户之间优先级怎么做？”→ 优先级队列（付费租户优先调度）+ 付费等级权重（高级租户分配更多算力配额）+ 保底配额（每个租户至少保证基础 QPS 不被饿死）
• “怎么避免吵闹邻居问题？”→ 三层隔离：算力隔离（大租户独占 GPU/Worker 进程）、请求队列隔离（每租户独立队列防止排队互相影响）、限流隔离（单租户限流不影响其他租户）
• “租户数据删除怎么保证彻底？”→ 全链路清理：向量库删 collection + Redis 扫描删 tenant 前缀 key + DB 物理删除 + 对象存储清理文件 + 审计日志保留（合规要求）；删除后跑校验脚本确认无残留

易错点：

• ❌ “共享表加tenant_id就够了”——bug导致忘记加filter就是数据泄露
• ❌ “限流只在网关做”——Token消耗在LLM调用后才知道，需要预估+实际两步
• ❌ “预算月底结算就行”——必须实时监控，月底算账为时已晚
• ❌ 忽略上下文隔离——对话记忆、缓存、检索结果都可能串租户
• ✅ 强调”隔离是安全问题，配额是成本问题，两者都要做”