独占物理机
整机给单一业务，隔离最好，利用率取决于该业务自身负载。为什么仍常见：关键业务不愿承担相互干扰。怎么做：把离线任务填进空闲时段；边界是独占意味着无法跨业务调剂，低负载业务的浪费最明显，也最难被察觉出来。
虚拟切分
把整卡切成多个实例，适合小模型与轻量任务。为什么能提利用率：小任务不再独占整卡。做法：按显存与算力需求匹配切分规格；边界是切分后单实例算力有限，且部分任务对切分支持不佳，需要先实测再推广。
共享资源池
用编排平台统一调度，按配额分配，能跨业务调剂。怎么做：设命名空间与配额上限，配合优先级与抢占；边界是共享会带来邻居干扰，延迟敏感业务要有保障机制或独立池，不能只靠口头承诺维持秩序。
错峰与批处理
把离线训练、数据标注与报表任务放到夜间，与在线推理错峰。为什么有效：在线负载有明显日周期。做法是用队列与定时调度；边界是离线任务可能超时并影响次日业务，要设截止时间、中断策略并提前通知相关方。
混合与弹性
常备容量覆盖基线，峰值用云端弹性补足。怎么做：按基线确定本地规模，峰值按需扩展；边界是跨环境的数据与网络限制要先确认，弹性扩容的启动时间也要计入，不能假设随时都可以立即调用得到。
适用与不适用
适合谁
- 多团队共用 GPU、需要定配额规则的平台部门
- 负载有明显峰谷、希望提高平均利用率的业务
- 在独占与共享之间反复权衡的技术负责人
不适合谁
- 只有一两个业务、共享收益有限的早期团队
- 没有调度平台、也不准备建设的小型机房
典型场景
某制造企业的视觉质检既训练又推理。原先每个团队各自占卡，白天推理排队、夜里大量空闲。改造为共享池加配额，训练任务排到夜间并设截止时间，推理获得优先级保障。运行一个季度后，卡间负载趋于均衡，新增需求先看池内余量再决定采购。
可执行步骤
- 按负载曲线与隔离要求给业务分类，形成一页可评审的对照清单材料与结论
- 为共享池设置配额、优先级与抢占规则，组织评审确认并留档备查与公示给业务方
- 把离线任务排入低谷，并设置截止时间、中断策略、优先级与回退方式预案说明
- 实测切分与共享下的干扰程度，记录分位延迟、吞吐变化曲线与拐点位置
- 按基线确定本地规模，峰值用弹性补足，验证启动时间、上限与费用口径边界条件
常见坑
- 直接共享而不设配额，一个业务占满资源，其他业务长期排队，投诉集中到平台部门，协调很吃力。
- 把延迟敏感的业务放进共享池，邻居干扰导致尾部延迟恶化，却难以举证是邻居的问题，排查耗时很长，业务方失去耐心与信任。
- 离线任务没有截止时间，常常跑到白天挤占在线资源，引发连锁投诉，只能临时杀任务，结果还要重跑，耽误更久的时间。
- 只按峰值采购容量，平日大量闲置，利用率长期偏低，下一年预算被砍，形成难以打破的循环。
自检与验收清单
- 业务是否已经按负载曲线与隔离要求完成分类，并留有对照清单
- 配额、优先级与抢占规则是否已经落地执行，是否经过正式评审与留档
- 离线任务是否设置了截止时间、中断策略、优先级与回退方式
- 切分与共享下的干扰程度是否实测过，是否留有分位延迟数据与结论
- 峰值是否用弹性容量补足，是否验证过启动时间、扩容上限与费用口径
常见问题
共享池一定比独占好吗？
不一定。共享能提高平均利用率，但会带来邻居干扰与配额争议。延迟敏感或强隔离要求的业务，独占更稳妥。判断依据是隔离要求、负载波动与运维能力，而不是单纯的利用率数字高低。
切分会不会影响性能？
会有影响，取决于切分规格与任务类型。显存与算力被切分后，单实例上限下降，部分任务可能无法运行。上线前应按目标模型实测吞吐与延迟，再决定切分粒度，不要只看理论规格。
峰值不用弹性会怎样？
只能靠常备容量硬扛，平日闲置、高峰期仍可能排队。若不确定扩容启动时间与费用上限，弹性方案在关键时刻也会失效。建议先做一次峰值演练，记录扩容耗时与失败情况，再决定是否依赖。