AI 应用多租户隔离：一个模型服务 N 个客户怎么设计

要把 AI 能力做成 SaaS 卖给多个客户，多租户隔离就是绕不开的问题。每个客户的数据、会话、配额都要隔离，还要保证一个客户的流量不影响另一个。这篇讲我的设计思路。

隔离的四个维度：

1. 会话隔离。每个租户的会话 ID 空间独立。我用的方案：会话 key 加租户前缀 tenant:{id}:session:{sid}，Redis 里天然隔离，查询时强制带上租户 ID，防止越权访问别人的会话。

2. 数据隔离（最重要）。RAG 场景每个客户的知识库不同。向量库集合按租户拆分：Qdrant 每个租户一个 collection，或者一个 collection 用 payload 里加 tenant_id 字段过滤。前者隔离彻底但 collection 数量爆炸；后者省资源但要保证查询必带租户过滤条件。

我选了"一个 collection + payload 过滤"，但在代码层强制注入租户条件（不是只靠调用方自觉），防止漏过滤导致数据泄露。

3. 配额隔离。每个租户设置独立的请求配额：每天 N 次、每分钟 M 次。超限返回 429 或提示升级套餐。Redis 里用计数器实现，key 带租户 ID。

4. 模型与成本隔离。不同套餐用不同模型（基础版用便宜模型，旗舰版用大模型）。成本按租户统计，账单清晰。

安全边界：

• API 鉴权用 API Key，每个租户独立 Key，可吊销
• 租户之间的数据绝不能串（特别是向量库过滤和会话）
• 敏感操作（删除、导出）要二次确认

坑：

1. 向量库过滤的坑。如果过滤条件用错（比如 tenant_id 没加引号），可能返回所有租户的数据。上线前专门写测试用例：用租户 A 的 key 查询，断言结果里没有租户 B 的数据。

2. 配额和实际使用对不上。流式请求的计费点（开始 vs 结束）要统一，不然账单有争议。

3. 共享模型池的噪声。多个租户共用同一模型实例，一个租户的峰值流量可能挤占别人的资源。高价值租户用独立实例，普通租户共用。

总结：多租户隔离的核心是"强制"而非"自觉"——隔离逻辑必须写在框架层，不能依赖每个开发者的自觉。