一、问题背景

企业级AI平台通常需要服务多个业务单元或外部客户。每个租户都有独立的需求：

• 租户A（研发部）：只能调用代码类模型，不能访问合同知识库

• 租户B（法务部）：只能调用合同审查应用，数据与其他租户隔离

• 租户C（外部客户）：需要独立计费，月底出账单

这就引出了多租户AI平台的三个核心挑战：

挑战	核心问题
权限隔离	租户A不能访问租户B的应用和模型
数据隔离	租户A的知识库不能被租户B检索到
计费隔离	每个租户的成本独立核算、独立出账

二、整体架构设计

核心思路： 在AI网关层实现租户感知，所有资源以租户为边界进行隔离。

系统架构：

租户上下文传递链路：

三、权限隔离设计

目标： 租户A不能调用租户B的模型应用，也不能访问租户B的知识库。

3.1 数据模型

3.2 权限校验流程

3.3 资源隔离策略

资源类型	隔离策略	实现方式
模型调用	租户级限流	API Key绑定租户ID
知识库	检索时过滤	查询条件强制带tenant_id
Prompt模板	租户内共享	模板表带tenant_id字段
应用/工作流	租户内共享	应用表带tenant_id字段

四、数据隔离设计

目标： 租户A的知识库数据，不会被租户B检索到。

4.1 行级数据隔离

核心原则： 所有数据表都带 tenant_id 字段，所有查询自动追加该条件。

4.2 向量数据库隔离

向量数据库的多租户隔离方案对比：

方案 实现方式 适用场景

租户分区 每个租户独立partition 租户数少（<100）

租户字段过滤 检索时带tenant_id过滤 租户数中等（100-1000）

租户独立实例 每个租户独立向量库 租户数少、数据量大、隔离要求高

推荐方案：租户字段过滤

4.3 跨租户数据共享（可选）

某些场景需要跨租户共享数据（如公共模型、公共知识库）：

五、计费隔离设计

目标： 每个租户的成本独立核算，支持多维度计费和账单输出。

5.1 计费数据采集

每次模型调用记录以下字段：

5.2 计费模式

计费模式	公式	适用租户
按Token	单价 × (输入Token + 输出Token)	用量稳定的租户
按调用次数	单价 × 调用次数	输入输出差异大的场景
套餐制	月费固定，超量按量计费	企业租户
混合模式	套餐费 + 超额按量	多数SaaS平台的标配

5.3 成本归因与报表

多维度报表：

维度	说明
租户级	每个租户月度/年度总账单
应用级	租户内各应用的消耗分布
模型级	租户内各模型的成本占比
用户级	租户内各用户的调用统计

在具体实现上，有企业采用 ZGI 作为多租户AI平台的底座方案，其权限隔离、数据隔离、计费隔离能力覆盖了上述全部设计。

六、落地路径建议

第一阶段：租户识别（1周）

• 设计租户上下文传递机制（Header/Tag）

• 实现网关层的租户ID提取和透传

第二阶段：权限与数据隔离（2-4周）

• 在数据表中增加tenant_id字段

• 改造DAO层，所有查询自动追加租户过滤

• 实现RBAC扩展权限模型

第三阶段：计费隔离（2-3周）

• 建立计费数据采集链路

• 实现按Token/按次计费逻辑

• 输出租户月度账单

七、总结

多租户AI平台的核心是三层隔离：

隔离类型	核心机制	关键实现
权限隔离	RBAC扩展模型	租户ID + 角色权限
数据隔离	行级隔离	tenant_id字段 + 查询拦截
计费隔离	租户级计量	调用记录 + 多维度归因

三层隔离既有独立的实现逻辑，又共用同一个租户标识（tenant_id）。租户ID是整个隔离体系的锚点。

本文基于多租户AI平台建设实践整理。