一、单个业务调好了，放在一起又乱了
1.1 一个常见的摩擦场景
某个资源池里同时跑着三类业务：对外的在线推理、内部的批量训练、以及团队自己试新模型的探索任务。三者都配了弹性伸缩GPU算力服务的自动策略，指标、阈值、冷却时间各自看着都合理。到了业务高峰，在线推理要迅速扩容，却发现池子里的空闲资源已经被训练任务占满；训练任务按自己的策略一路扩到上限，又因为队列突然变短而收缩，来回几次之后，在线推理的响应时间开始波动。每一个策略单独看都没有写错，问题出在它们共用一个总量。
1.2 三个需要先说清的名词
① 资源池总量：一个区域内可被调度的加速卡总量。它是硬边界，不会因为策略写得好而变多。
② 抢占与等待：资源不足时，一部分任务能拿到资源，另一部分只能排队。谁先拿到，取决于策略与优先级，而不是提交时间。
③ 预留与配额：事先划出一部分资源供特定业务使用，或限定某个业务最多能用多少。它是把“总量”变成“可控”的主要手段。
1.3 为什么各自最优会变成整体最差
因为伸缩策略是各自按自己的负载写的，谁都没有考虑别人。每个业务都希望“峰值随时够用”，于是都倾向于把上限抬高、把冷却缩短。单看每一个都合理，叠加起来就变成了超额承诺：池子里每一个业务都以为自己能扩到那么多，实际同一时刻只有一部分能拿到。承诺总和大于实际总量，是共享池里绝大多数摩擦的根源。
二、共享池里的三种相互影响
2.1 挤占：先扩的拿到，后扩的等
资源总量不够用时，扩容请求谁先到谁先满足。若两个业务的峰值同时出现，结果往往是先触发策略的那个拿到资源，后触发的只能排队。排队本身不可怕，可怕的是排队时间没有被计入承诺：对外的服务承诺里写着响应时限，实际却因为拿不到资源而无法兑现。
2.1.1 排队时间要计入承诺
对外承诺的响应时限，应当以“可能排队”为前提来设，而不是按拿到资源之后的速度来设。否则高峰期即便资源最终到位，也已经超出了承诺，事后追责又把问题推回技术侧。
2.2 振荡放大：一个缩，另一个跟着抖
A 业务缩容释放资源，B 业务立刻扩起来占住；等 A 又回到高位，发现自己扩不动，只能等 B 缩。两个业务各自的曲线都不算剧烈，叠加起来却形成一种来回拉扯的节奏。这类振荡在监控上表现为“资源总量不变，但归属频繁易手”，比单纯的资源不足更难排查。
2.3 长尾拖累：一个慢任务拖住整池
有些任务占住资源的时间远超预期：训练卡在某一步、渲染任务卡在某个镜头。它不违反任何策略，却让池子的可用量长期低于账面数字。其他业务看到的是“明明有资源却扩不出来”，排查时才发现是被几个长任务占着。
三、第一个约定：先把总量与底线定下来
3.1 池子里有多少是真的可以动的
第一步不是写策略，而是算清楚这个池子在一段时间内稳定可用的数量。要把已被长期占用的、正在维护的、以及区域间调剂的部分扣除。很多团队直接从“账面总量”出发写策略，最后发现实际可动用的只有七成，所有估算都偏乐观。
3.1.1 一个简单的核对办法
把最近一段时间的资源占用记录拉出来，按小时看最低值，再取其中位数。这个数比账面总量更接近真实可动用的规模，用它去写策略，估算的偏差会小很多。
3.2 给关键业务留出不可动的部分
对外的服务承诺型业务，应该有一块专属资源，不参与共享。这块资源平时可能利用率不高，但它保证的是“无论别人怎么扩，这部分都在”。把承诺型业务的底线从共享池里划出来，是减少争执最有效的一步。
3.3 为什么要留一到两成机动
机动资源不分配给任何业务，只在突发时启用。它的作用有三个：
① 应对没有预判到的峰值：谁都没算到的增长，靠它兜住。
② 承接过渡期：长尾任务释放之后，池子需要一段时间回到常态。
③ 留出试错空间：策略调整总有偏差，有富余才敢试。
全部划完的池子看起来“一点没浪费”，实际上任何一点波动都会立刻变成排队。
四、第二个约定：按性质排优先级，不按声音大小
4.1 三类业务的天然先后
① 对外承诺型：已经对使用方作出时限或可用性承诺的业务，优先保障。
② 内部生产型：有明确交付节点的训练、渲染、批处理任务，其次保障。
③ 探索试验型：没有硬性节点、可以中断重来的试验，最后保障，且最适合被抢占。
这个排序不是价值判断，而是“可中断性”的排序：越是可以等、可以断、可以重来的，越应该让路。
4.2 优先级要写进策略，而不是靠沟通
靠人说一句“高峰期先让某某业务”很难持续，因为高峰期往往没人有空协调。可行的做法是把优先级写进调度配置：为不同业务设定不同的队列与配额，让弹性伸缩GPU算力服务的规则在人不在场时依然生效。
4.3 优先级变了要通知
优先级一旦调整，相关业务的负责人需要知道，否则他们会按旧预期安排任务，结果发现资源拿不到，误以为是平台出了问题。一条简短的变更通知，能省掉大量事后解释。
五、第三个约定：错峰往往比争夺更有效
5.1 先找出可以移动的任务
不是所有任务都必须现在跑。批量训练、离线渲染、素材转码这类任务，晚几个小时结果一样，只是交付节点要相应调整。把这些任务标出来，就有了“可移动”的池子。
5.2 用时间窗代替实时争夺
与其让两类业务在同一时段抢同一批资源，不如给可移动任务划定时间窗：白天给在线业务，夜间与周末给批量任务。时间窗一旦确立，两边的伸缩策略就不必再为对方留余地，各自的估算也能更贴近实际。
5.2.1 时间窗要靠排期表固定下来
时间窗若只停留在口头约定，很快就会失效。把它写进团队共用的排期表，标注每个时段归哪类业务使用，新人接手时也能照着执行，不必再去问一遍。
5.3 提前量要留够
把任务挪到夜间，前提是夜间确实跑得完。这就要求对批量任务的时长有可靠估计，并留出足够的提前量。挪了却没跑完，第二天又要抢白天的时间，错峰就失去了意义。
六、第四个约定：缩容要让人接得住
6.1 缩容不是释放了就完事
缩容释放的资源会被其他业务立刻占用，这是好事。但如果释放得过于急促，正在等待的业务来不及扩容，或者下游的数据处理跟不上，就会出现一段空窗。缩容的节奏同样需要设计。
6.2 给下游留一点缓冲
释放资源前，确认依赖它的下游任务是否还有未完成的读写。有些任务表面上已经结束，实际还在做收尾的落盘与上报，此时立刻回收，会影响结果的完整性。
6.2.1 收尾的时长要预估
不同任务的收尾时间差别很大：小文件很快写完，大模型检查点可能要写很久。回收前按任务类型估一个收尾时长，比按统一规则处理更稳妥。
6.3 回落的节奏可以慢一些
扩容要快，缩容可以从容。把缩容的观察窗口设得比扩容更长，虽然会多占用一些资源，但能显著减少来回抖动，也给了其他业务一个稳定的预期。
七、出现争执时的三条判断依据
共享池里的摩擦不可避免，关键是有可依据的判断标准，而不是谁的声音大谁有理。三条依据按顺序使用：
① 先看承诺：有没有对外部使用方作出过明确时限。有承诺的一方优先，这条最硬。
② 再看数据：各自的用量记录、排队时长、实际拿到的时间。用记录说话，比用感受说话更容易达成一致。
③ 最后看长期：这次让一步，下次换谁让。把单次争执放到一段时间的往来里看，很多僵局会自然松动。
八、天翼云在共享使用上的支撑
8.1 资源池与快速发放
依托加速卡资源池与快速发放能力，扩容请求能在较短时间内得到响应。对共享池而言，响应速度直接决定了排队是否会被感知为“卡住”。
8.2 策略化伸缩与配额分层
支持按业务配置伸缩策略，并可通过配额与队列做分层，把第四节的优先级落到配置上。策略生效后不依赖人工值守，高峰期也不必临时协调。
8.3 任务级调度与抢占配合
任务级调度让高优先级任务在资源紧张时优先得到满足，配合断点续训等机制，被抢占的低优先级任务不必从头再来。这正是“可中断性排序”能够落地的前提。
8.4 用量记录与观察
用量与任务记录可按业务分开查看，为第七节的“用数据说话”提供依据。没有记录时，共享池里的争执很容易退化成印象之争。
8.5 安全合规与官方口径
在数据隔离、权限管理与合规方面有相应机制。关于弹性伸缩GPU算力服务的具体规格、可用区域、实践案例与所获认可，均以天翼云官网和官方渠道发布的信息为准，本文不作超出官方口径的描述，建议在方案评估阶段按需核对。
九、科普小结
共享池里的混乱，很少是因为某个策略写错了，多数是因为几个都合理的策略共用一个不够分的总量。四个约定各自解决一段：定总量与底线，让承诺有着落；按性质排优先级，让让路有依据；用错峰代替争夺，把冲突移出高峰；缩容留出缓冲，让交接不落空。弹性伸缩GPU算力服务的价值，在单个业务上体现为省事，在多个业务共用时体现为有序——而有序从来不是自动到来的。
