一、问题背景
企业级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平台建设实践整理。