一、为什么必须分三层

1. 一层管到底的三种崩法

第一种是资源失控：没有额度，先到先得，一个大规模实验就能把整片资源占住，别人的小任务全部排队。第二种是权限失控：为了省事大家都给管理员，于是没人说得清谁删过数据集、谁改过配额。第三种是退出失控：人员离开后账号没人回收，权限长期挂着。

三种崩法互相牵连。资源失控往往催生权限放宽——反正要快速协调，不如人人都有管理员；权限放宽之后，退出就更没人管了。

2. 三层的分工

顶层是租户，管的是“谁是谁的地盘”：这个团队能看到哪些资源、数据存在哪、网络能不能互通。中层是项目，管的是“这块地盘里怎么分额度”：每个项目拿多少卡时、能不能临时借用、周期怎么重置。底层是成员，管的是“这个人能做什么动作”：能提交、能查看、能管配额，还是只能看报表。

三层之间是层层收窄的关系。租户边界定了，项目不会跑到边界外；项目额度定了，成员的动作不会超出额度。

3. 三层之外还有一层

三层之上还有一层：谁定租户边界、谁批大额配额、谁定计量口径。这层不做日常操作，只做规则与例外审批，三层之间才有仲裁者。

二、第一层：租户边界与四个隔离面

1. 身份隔离：账号体系要对得上组织

租户通常按部门、业务线或独立客户划分，划分依据一旦确定，就要与身份体系绑定：这个人属于哪个租户、哪些管理员能看见哪些资源、租户内外的角色怎么区分。

判断这一层有没有做到位，有个简单测试：拿一个租户的普通成员账号登录，看能不能通过搜索、跳转、直接输入标识等方式看到别的租户的资源。能看到的，说明只在界面上分了，底层没分。

2. 资源隔离：不只是命名空间

资源隔离要落到四样东西上：加速卡与内存的额度边界、网络访问范围、镜像与模型的可见范围、数据的读写路径。四样里缺一样，隔离就退化成“界面上看着分开、底层互相影响”。

对核心业务或敏感租户，通常需要专属节点池，而不是放进完全共享的池子。哪些资源适合共享、哪些必须专属，要提前定一张表。

3. 数据隔离：按项目分，不按个人分

数据隔离的粒度建议对齐项目而非个人。按个人分，粒度太碎，权限体系会膨胀到没人维护得动；按租户分，又太粗，同一部门里不同项目的资料会互相看见。

具象做法是每个项目一个独立存储区：数据集、中间结果、模型产物、日志分目录存放，默认只有本项目成员可读写。公共样本集单独设为只读并多项目共享，防止每个项目各存一份。

4. 网络隔离：默认不通，按需放行

容器之间默认禁止跨租户互访，需要对外提供服务的任务统一走网关暴露入口，经身份校验后转发。这条默认规则能挡掉大量“内部节点被直接摸到”的风险。

三、第二层：把配额分成三种

1. 保底额度：保证核心任务能启动

每个项目保留一份基础额度，确保核心任务不会因为共享资源竞争而完全无法启动。这份额度的作用是给排期一个确定的前提——团队能据此规划长周期任务，而不是每天抢资源。

保底额度宜小不宜大。定得太大，共享池就空了，弹性失去意义；定得太小，又起不到保底作用。可行的确定办法是按“日常可用的下限规模”定，即扣除突发之后的常态用量。

2. 弹性借用：让闲时余量流动起来

共享池里有空闲时，允许项目在规则内临时超额使用。这一机制能把整体使用率明显拉上去，但必须配三样东西：借用上限、借用时限、回收规则。

三样缺一样就会变味。没有上限，一个项目能把共享池吃干；没有时限，借用会变成长期占用；没有回收规则，持有方回归时无法收回。

3. 硬性上限：给总量一个天花板

每个项目设一个不可逾越的上限，理由有三条：资源池有物理边界，无上限的申请在关键时刻必然失败；预算要可控；上游依赖承受不了无限制的并发增长。

4. 配额的四个参数

一是额度值，以卡时或卡数为单位；二是周期，按月还是按季度重置；三是超用处理，是拒绝、还是允许超用但记录、还是自动转借用；四是优先级，核心项目在资源紧张时能不能抢占实验类任务。

四个参数要在同一张表里写清。分开写在几个文档里的配额，执行时一定对不上。

四、第三层：角色与权限收窄

1. 四种角色够用

第一种是租户管理员，管本租户的成员、项目与额度分配；第二种是项目开发者，提交任务、读写本项目数据；第三种是观察者，只能看任务状态、日志与报表；第四种是审计角色，只读操作记录，不碰业务数据。四种之外，全局管理员只做全局配置与例外审批，不参与日常任务；收窄这一层的权限，是三层能站住的前提。

2. 权限要给到动作，不给到界面

常见做法是按页面授权：给某人“任务页面”的访问权，他能看到页面上所有按钮。更稳的做法是按动作授权：提交、取消、删除、取回产物、查看日志，五个动作分开。

区别在实际出问题时才显出来。按页面授权的人，很难说清他到底有没有删除权限；按动作授权，一查就知道。

3. 高危动作单独收紧

删除数据集、修改配额、取回模型产物、变更成员角色，这四类动作建议单独收紧：要么限定角色，要么要求两人确认，要么留必填备注。

五、跨层的三处冲突

1. 借用与保底的冲突

持有方回归时，借出的资源还在被别人跑着任务。如果直接收回，会中断别人的计算；不收回，自己的排期就作废了。

可行的规则是分层处理：借用时约定归还宽限期，宽限期内允许正在跑的任务跑完，但不再接受新任务；宽限期结束仍未释放的，逐步降低其优先级而不是直接杀掉。规则写进借用协议，比临场协调省事。

2. 跨项目协作怎么办

同一个人同时参与两个项目，是很常见的场景。做法是把人加到两个项目里，各自继承权限，而不是给他一个更高层级的角色。跨项目的数据共享走只读授权，并设有效期。

要防的是“为了方便给他租户管理员”。一旦开了这个口子，后面所有项目的隔离都失去意义。

3. 人员流动怎么收

入职、转岗、离职三种动作要各有一条流程。离职这一项尤其要紧：账号停用、密钥吊销、权限清出、数据归属交接，四件事一次做完。交接时列一份清单，写明名下有哪些项目、哪些数据集、哪些任务还在跑；缺了这份清单，人走了之后没人知道哪些资源还被占着。

六、落地走四步

1. 第一步：画组织与资源的对应表

把现有的部门、项目、人员与资源现状列成一张表，先看清楚谁在用、用了多少。这一步不做，后面的额度分配全靠猜。

2. 第二步：定租户边界，做隔离

先把身份、资源、数据、网络四个面的边界定下来，把隔离做到位。这一步是基础，跳过它直接分额度，等于在不密封的容器里倒水。

3. 第三步：分额度，先只展示不拦截

额度先以报表形式展示各项目的用量与占比，不做硬性拦截。观察一个周期，让团队看到自己的实际消耗，也让自己确认额度定得合不合理。

这一步的价值在于建立信任。直接上硬配额，第一周就会有人因为任务被拒而来争论，而那时你手上的用量数据还不一定站得住。

4. 第四步：开拦截，配例外通道

报表跑稳之后开硬配额，同时留一条例外通道：临时超额走申请，注明用途与时长，批了给临时额度，到期自动失效。没有例外通道，硬配额会被各种“特殊情况”绕过去。

七、验收看六件事

一是拿一个租户的成员账号，确认看不到其他租户的任何资源。二是给一个项目设满额度，确认超额提交被拒绝且提示明确。三是验证借用：让一个项目借用、持有方回归、观察回收是否按规则执行。

四是核对权限：观察者尝试提交被拒、尝试删除被拒，提示都要具体。五是查操作记录：四类高危动作各做一次，确认能追到人、时间与对象。六是做一次退出演练：把一个账号按离职流程处理，看四样事情是否都做完。

六件事都过，这套三层设计才算真的立起来。

结语

多租户管不好，通常不是缺功能，而是缺分层。租户这一层定边界，解决“谁的地盘”；项目这一层定额度，解决“怎么分”；成员这一层定角色，解决“能做什么”。三层各管一件事，调整就变成改一条记录。

落地顺序建议：先画组织与资源的对应表，再定边界做隔离，然后用报表跑一个周期，最后才开硬配额并配例外通道。判断这套设计是否到位，有个很实际的标准：某个项目临时需要更多资源时，它知道该找谁、走什么流程、多久能有答复，而不是直接去找管理员账号。