账本：先能量化
没有按项目、任务记录的卡时账本，共享只是口头约定，谁占得多无人知道。账本要能回答谁在何时用了多少卡、跑了多久、产出多少；计量粒度太粗，配额与分摊都无从谈起，对账也会各说各话，争议无人能裁。
调度：约束要硬
调度器要支持队列、优先级、配额与抢占，对超限任务直接拒绝而不是无限排队。只有监控没有约束，团队会先占后用，最终仍靠人工协调；约束规则还要写进使用规范，避免成为个别人的口头开关，失了公信。
负载：先分类再入池
训练、离线评测与批量生成可以排队填谷，交互式服务不行。入池前把负载标成可中断、可延迟、可拆分三类，再决定谁进共享池；不可中断的任务混进去，会把整池稳定性拖下水，故障时也无人敢停，风险外溢。
机制与运维：有人负责
需要有人审批配额、有人对超额负责、有内部结算或成本公示，也需要驱动版本矩阵、镜像仓库、坏卡隔离与节点自愈。缺少这些，共享池会在几个月内退化成各团队私占，这部分能力通常要专职运维。
适用与不适用
适合谁
- 计划把各团队分散 GPU 收拢成共享池的企业
- 已有多个算法团队长期争抢算力的集团
- 正在做算力平台立项、需要评估可行性的技术负责人
不适合谁
- 只有一个团队、负载单一的小规模场景
- 不愿调整配额与结算机制、只要技术方案的部门
典型场景
某集团把三个事业部的闲置服务器收进共享池，上线首周就出现互相抢占与无人认领的坏卡。平台组补上卡时账本、队列配额与坏卡隔离流程，要求各团队提前一天提交离线任务；两个月后，排队从口头协调变成按优先级排队，月度对账也有了依据。
可执行步骤
- 盘点现有卡与负载，按可中断、可延迟、可拆分分类，并估算日均用量与峰值
- 上线卡时账本，先做到按项目与任务可查，再逐步细化到租户、队列与时间片
- 配置队列、配额与抢占规则，写进使用规范，并公示生效时间与例外申请流程
- 指定配额审批人与超额处理办法，明确争议升级路径与最终责任人，避免口头裁决
常见坑
- 先上调度器再补计量，配额缺乏依据，团队不认，规则很快形同虚设，最后还是回到人工协调，无人再提共享。
- 把交互式服务塞进共享池，被批任务拖到频繁超时，业务方直接退出共享池，前期投入尽数落空，口碑也受损。
- 没有坏卡隔离与替换流程，一张故障卡拖慢整池任务，排查往往耗时数天，责任也分不清楚，用户只能等待。
自检与验收清单
- 是否有按项目与任务可查的卡时账本，且能月度对账
- 调度器是否支持队列、配额、优先级与抢占，并能拒绝超限
- 负载是否按可中断、可延迟、可拆分三类完成分类
- 配额审批人、超额处理与争议升级路径是否明确
常见问题
只有几台服务器也要做共享池吗？
规模很小时收益可能低于管理成本。两三台卡、单一团队时，用预约表加简单监控即可；等出现跨团队争抢、或需要按月分摊成本时，再引入账本与调度，避免为流程而流程，反而拖慢交付。
配额应该定多少？
没有通用值，应从历史用量与业务优先级倒推：先给保障额度，再设可借用的弹性额度，并按月复核。配额的作用是让争抢有规则可依，不是精确预测需求，规则要可调整并有申诉通道。
共享池日常由谁负责？
通常由平台组或 IT 运维承担，业务团队负责自身任务的提交规范与失败排查。责任边界要写清：坏卡更换、驱动升级、配额审批各归谁；无人负责时，共享池会在几个月内退化为私占。