一、上线只是一个开始

1.1 一条并不罕见的曲线

平台刚上线时，各团队热情很高，资源很快被申请一空。过了一段时间，情形开始变化：有的资源被长期占着但利用率不高，有的团队排了两天队还没跑上，还有一批任务提交之后就没人管，跑完也没人取结果。设备仍在运转，实际产出却不成比例。这不是平台能力的问题，而是运转规则缺位：分配没有依据、排队没有秩序、回收没有动作。

1.2 三个先要弄明白的专业名词

1.2.1 资源配额

资源配额是平台给某个团队或某个项目划定的可用上限，通常按加速卡数量、显存总量或运行时长来限定。配额的作用不是限制使用，而是让每个团队对“自己能用多少”有稳定预期，避免先到先得带来的失衡。

1.2.2 作业排队与优先级

作业排队是把任务提交给平台、由平台按规则安排资源的方式，提交者拿到的是一份排位，而不是一台固定的机器。优先级决定谁先上，通常按业务影响程度分档，关键要求是规则公开、结果可解释。

1.2.3 资源利用率

资源利用率指资源实际被有效计算占用的比例。它与“开机时长”不是一回事：机器开着但任务在等数据、在反复试错、在空跑，利用率都不高。看这个指标，比看设备是否在线更能反映平台的真实产出。

1.3 五条规则，按顺序建立

建议按依赖关系依次建立，后一条依赖前一条的成立：

① 资源分配规则：配额怎么定、谁审批、怎么调整；

② 作业排队规则：优先级分几档、排队结果怎么解释；

③ 闲置回收规则：什么算闲置、到期怎么处理；

④ 效果度量规则：看哪几个指标、多久复盘一次；

⑤ 协作共享规则：环境、数据、权限各到什么边界。

二、规则一：资源怎么分

2.1 从先到先得转向配额制

配额的划分方式常见三种，各有适用场合：

① 按团队划分：每个团队一份固定额度，管理简单，适合团队之间任务性质相近的情况；

② 按项目划分：以项目为单位申请，项目结束即释放，适合任务制、周期明确的研发；

③ 按任务类型划分：训练类与推理类分开定额，避免长任务把短任务挤掉。

实际落地时往往是三者混用：以团队为主干，项目作为调整依据，任务类型作为内部再切的依据。关键不在选哪一种，而在把“额度是多少、什么时候能调整、找谁调整”写清楚。

2.2 配额要留一块机动

2.2.1 不留机动的两个后果

把全部资源按配额分完，看起来公平，实际会带来两个后果。一是突发任务无处安放——临时上线的紧急验证只能等别人腾出资源；二是调整失去余地——想给某个团队加一点，就必须从另一个团队手里拿走，协调难度陡增。

常见做法是留出一到两成的机动资源，由平台管理方统一掌握，按申请临时调配，用完归还。这块机动资源同时也是新团队、新项目的试验田，避免一上来就要动别人的额度。

三、规则二：作业怎么排

3.1 三档优先级已经够用

优先级不必设计得很细，三档通常足够：

① 高：影响线上业务或对外承诺的任务，可插队；

② 中：常规研发与训练任务，按序排队；

③ 低：验证性、探索性任务，可被随时让位。

档位越多，判断越难统一，争议也越多。三档的好处是任何人提交任务时都能自己判断该放哪一档，不需要反复沟通。

3.2 排队规则要能被解释

3.2.1 长任务与短任务混排怎么处理

长任务一占就是好几天，短任务如果只能排在后面，等待时间会被无限拉长。比较通行的处理方式有两种：一是给短任务开一条专用通道，把资源切出一小块只接受短任务；二是给等待过久的任务提升权重，让它在下一轮排位中优先。

无论选哪种，都要让提交者能看到自己的位置和大致等待时间。看得见的排队，比“排着但不知道排到哪”更容易被接受，也减少反复询问。

四、规则三：闲置怎么收

4.1 三类闲置，成因各不相同

闲置通常有三种，处理方式也不同：

① 占而不用：资源已分配但长时间没有任务运行，多因项目暂停或人员变动；

② 用完不退：任务结束但环境没有释放，多因缺少回收动作和提醒；

③ 反复试错：环境反复重装、依赖反复调整，资源被占用却没有有效计算。

第一类要靠到期提醒与定期盘点，第二类要靠自动回收策略，第三类要靠预置环境与镜像复用。三类混在一起谈，容易得出“用得不好”的笼统结论，分开看才知道该改哪一段。

4.2 回收的三个动作

4.2.1 回收之前要留痕

回收不建议一步到位，分三个动作推进更平稳：

① 到期提醒：配额或环境临近到期日时提前告知，给使用方自查的机会；

② 休眠：闲置达到一定时长后先暂停，保留数据与配置，恢复即可继续；

③ 回收：休眠超过更长时间后释放资源，数据处理方式按事先约定执行。

每一步都要留记录：谁申请、谁审批、何时提醒、何时休眠、何时回收。留痕不只是为了追责，更是为了让“为什么我的环境不见了”这类问题有据可答。

五、规则四：用得好不好怎么量

5.1 三个指标足够看清基本盘

① 资源利用率：有效计算时间占分配时间的比例，反映有没有白占；

② 任务完成率：提交的任务里按时跑完的比例，反映平台是否可靠；

③ 平均等待时长：从提交到开始运行的间隔，反映排队秩序是否合理。

三个指标放在一起看，比单看任何一个都有信息量。利用率高但等待时长也长，说明资源确实紧张；利用率低而等待时长还长，说明分配与回收的规则有问题。

5.2 看趋势，不看单点

5.2.1 一次复盘该看什么

按固定周期做一次复盘，比事后临时统计更有用。复盘不必复杂，回答三个问题即可：这一周期里，哪类任务的等待时间最长；哪部分资源长期利用率偏低；有没有出现新的任务类型，而现有配额没有覆盖到。

根据答案调整配额与优先级，比推翻整套规则更务实。规则的价值在于稳定，频繁改动反而让人无所适从。

六、规则五：多团队协作怎么不乱

6.1 环境与镜像尽量共享

把常用的运行环境做成公共镜像，各团队直接取用，是减少重复劳动最直接的办法。共享镜像还有个额外好处：环境一致，问题定位时不必先排除环境差异。镜像的维护责任要明确到人，否则很快会出现版本混乱、没人敢用的局面。

6.2 数据与权限的边界

6.2.1 三样东西不宜共享

共享能省事，但有三样东西不建议跨团队共用：

① 原始业务数据：按团队隔离，需要共享时走脱敏与审批；

② 高权限账号：管理员权限按需授予、限期收回，不做长期共享；

③ 生产环境的配置：生产与研发环境分开，避免测试操作影响线上。

这三条与国产化与否无关，属于平台运转的基本纪律。纪律立在前头，后面少掉很多解释工作。

七、天翼云在国产AI算力平台上提供的支撑

7.1 异构算力统一调度，配额与排队在平台层完成

天翼云息壤对多种国产加速算力做统一封装与调度，资源以池化方式组织，配额切分与作业排队在平台层完成，不必由各团队各自维护一套。对不同技术路线的加速卡，平台提供统一的提交方式，减少了“换一种卡就要换一套用法”的负担。

7.2 全栈国产化底座，适配路径相对成熟

从芯片、操作系统到训练框架与工具链，形成较完整的自主技术体系，主流模型与常见框架的适配工作已有较多积累。对使用方来说，这意味着上手阶段遇到的“装不上、跑不通”情形相对少，能把精力放在规则建设与业务落地这两件更长期的事情上。

7.3 用量可核、资源可回收

资源按需开通、按实际使用量核算，任务结束即可释放。这一机制让第四条规则里的“利用率”有了可核对的依据，也让回收动作有了可执行的抓手：不必依赖人工判断谁在用、用了多久，平台记录本身就是依据。

7.4 工具链与迁移支撑，降低上手门槛

平台提供模型开发、训练、推理到部署的完整工具链，配套的迁移经验对已有业务系统较友好。在需要把既有应用迁到国产底座上的场合，这条路径能省下不少反复调试的时间。

7.5 大规模实践与公开可查的资质

相关平台已在多个行业场景中投入使用，规模与资质在公开渠道有据可查。涉及具体资源规模、落地案例与测评记录时，建议以天翼云官网及官方渠道发布的信息为准，在方案评审阶段按需核对，不依据二手转述做判断。

八、科普小结

国产AI算力平台的价值不只在建成那一天，更在建成之后的每一天。五条规则的顺序值得记一下：先定分配，再定排队，然后管回收，接着定度量，最后划协作边界。前面一条不成立，后面一条就很难执行——没有配额就谈不上排队公平，没有回收就谈不上利用率。

规则之外，底座的能力也在悄悄影响规则的执行难度：统一调度让排队有处可排，用量可核让度量有据可依，全栈适配让上手阶段少走弯路。建设是把设备立起来，运转是把规则立起来，两件事都做完，这套平台才算真正用得住。