多租户隔离
多租户隔离的目标是让每个租户只能到达被授权的模型、看到自己的用量与费用、受自己的限流约束。网关用「密钥组 + 访问密钥 + Header ACL + 限流」四层组合实现。
隔离的四个维度
| 维度 | 机制 | 配置处 |
|---|---|---|
| 模型可达 | 密钥组的 models 列表 | 控制台 → 密钥组 |
| 负载均衡器可达 | 密钥组的 load_balancers 列表 | 控制台 → 密钥组 |
| 客户端身份 | 访问密钥 + Header ACL 规则 | 控制台 → 访问密钥 / Header ACL |
| 用量约束 | 每密钥限流（RPM / 并发 / TPM） | RATE_LIMIT_* + 控制台 |
用密钥组切分模型与负载均衡器
每个租户一个密钥组，models 列出该租户能调的模型名，load_balancers 列出能调的 LB 名。租户的访问密钥挂到对应密钥组。字段见 访问密钥与密钥组字段。
LB 是独立的授权维度
密钥组的 models 与 load_balancers 是两个独立列表。「所有模型」（*）不附带 LB 权限，反之亦然——两个维度要分别勾选。这是多租户场景最常见的配错点。详见 创建负载均衡器 的「与密钥组的关系」。
负载均衡器是授权单元（易错点）
网关只在请求进入时校验一次 LB 名称是否在密钥组的 load_balancers 白名单内，不会再用 models 列表逐个校验该 LB 内的 entry。也就是说，一旦密钥组放行了某 LB，该组密钥就能到达该 LB 里的每一个 entry。
严格隔离时别用 LB
若要严格限制某租户只能用某个模型，把它配成普通模型并加入该租户密钥组的 models 列表，不要放进一个已被多租户授权的 LB——LB 的 entry 集合是所有持权密钥的可达并集。
用请求头规则区分客户端
同一密钥组下想按客户端进一步分流，用 Header ACL 规则按请求头（如 X-Tenant）匹配，做白名单/黑名单。规则字段见 Header ACL 规则字段，配置示例见 配 Header ACL 的白名单模式。
每租户限流与配额
计费口径
定价与计费 配置价格快照后，月度账单按模型 + 访问密钥维度汇总。每个租户用自己的密钥组与访问密钥，账单天然按租户拆分。
常见问题
Q：同一把访问密钥能给多个租户用吗？ 不能。访问密钥挂在一个密钥组上，权限由该组决定。多租户要每租户独立的密钥组与访问密钥。
Q：密钥组的 models 写别名行吗？ 不行。密钥组的模型 ACL 只匹配规范名称（name 字段），不解析别名。见 上游与模型字段 的「模型别名与隐藏名称」。
Q：怎么让某租户的限流不互相干扰？ 每租户独立访问密钥，限流按密钥计。多实例配 Redis 让限流跨实例共享。
下一步：满足合规与审计要求 看合规；访问密钥与密钥组字段 看字段；访问控制设计 看设计原则。