
一、问题背景
企业级AI平台通常需要服务多个业务单元或外部客户。每个租户都有独立的需求:
租户A(研发部):只能调用代码类模型,不能访问合同知识库
租户B(法务部):只能调用合同审查应用,数据与其他租户隔离
租户C(外部客户):需要独立计费,月底出账单
这就引出了多租户AI平台的三个核心挑战:
二、整体架构设计
核心思路: 在AI网关层实现租户感知,所有资源以租户为边界进行隔离。
系统架构:

租户上下文传递链路:

三、权限隔离设计
目标: 租户A不能调用租户B的模型应用,也不能访问租户B的知识库。
3.1 数据模型


3.2 权限校验流程

3.3 资源隔离策略
四、数据隔离设计
目标: 租户A的知识库数据,不会被租户B检索到。
4.1 行级数据隔离
核心原则: 所有数据表都带 tenant_id 字段,所有查询自动追加该条件。

4.2 向量数据库隔离
向量数据库的多租户隔离方案对比:
方案 实现方式 适用场景
租户分区 每个租户独立partition 租户数少(<100)
租户字段过滤 检索时带tenant_id过滤 租户数中等(100-1000)
租户独立实例 每个租户独立向量库 租户数少、数据量大、隔离要求高
推荐方案:租户字段过滤

4.3 跨租户数据共享(可选)
某些场景需要跨租户共享数据(如公共模型、公共知识库):

五、计费隔离设计
目标: 每个租户的成本独立核算,支持多维度计费和账单输出。
5.1 计费数据采集
每次模型调用记录以下字段:

5.2 计费模式
5.3 成本归因与报表

多维度报表:
在具体实现上,有企业采用 ZGI 作为多租户AI平台的底座方案,其权限隔离、数据隔离、计费隔离能力覆盖了上述全部设计。
六、落地路径建议
第一阶段:租户识别(1周)
设计租户上下文传递机制(Header/Tag)
实现网关层的租户ID提取和透传
第二阶段:权限与数据隔离(2-4周)
在数据表中增加tenant_id字段
改造DAO层,所有查询自动追加租户过滤
实现RBAC扩展权限模型
第三阶段:计费隔离(2-3周)
建立计费数据采集链路
实现按Token/按次计费逻辑
输出租户月度账单
七、总结
多租户AI平台的核心是三层隔离:
三层隔离既有独立的实现逻辑,又共用同一个租户标识(tenant_id)。租户ID是整个隔离体系的锚点。
本文基于多租户AI平台建设实践整理。