误区一：显存占用当产出
显存驻留、进程占卡与功耗上升，只说明资源被占用，不说明产出了多少有效结果。判断要看单位卡时完成的请求或样本数，以及任务排队时长；否则会出现卡全部占满、业务却在排队的假繁忙，这类误判常见。
误区二：均值掩盖峰值
日均值把白天高峰与夜间空转一起抹平，按它做容量决策往往失真。做法是按小时看分位指标，把交互式与离线批任务分开统计；均值好看但 P95 排队很长的集群，体验其实已经下降，只是报表没有显示出来。
误区三：把满载当目标
满载意味着没有突发余量，重试、故障切换与流量波动都会被放大成排队。更合理的做法是给在线服务留出冗余，用可中断的离线任务填谷；冗余留多少由业务时延要求决定，不能照搬其他团队的配置。
误区四：只记卡时不记产出
卡时账本解决的是成本分摊，不回答这张卡干了多少活。要在任务维度记录成功请求、失败重试与空转时段，否则团队可以通过占卡、跑空任务把指标做高；计量至少要细到项目与任务，否则分摊失真。
误区五：指标压成考核
一旦与绩效挂钩，就会出现囤卡、拆分任务、延迟释放等博弈行为，数据也更容易被修饰。利用率适合作为容量决策的输入，不宜直接考核到人；考核应回到交付质量与单位任务成本，这些指标更难做高。
适用与不适用
适合谁
- 正在评估自建 GPU 池的中大型企业技术团队
- 已建监控但指标口径混乱的运维负责人
不适合谁
- 尚无任何算力负载、只为概念调研的团队
- 期望一条指标就能判断集群好坏的采购方
典型场景
某集团采购了一池 GPU 给三个事业部共用，监控显示卡占用常年高位，算法团队却仍抱怨排队。运维改看按小时的有效吞吐、P95 排队与空转卡时，发现夜间批任务挤占白天资源，随后按优先级分队列、夜间填谷，并把配额调整到各团队。
可执行步骤
- 先把口径定下来，写清采样周期、统计维度、有效产出与排队分位，双方签字
- 再补采排队时长与空转卡时，和占用率交叉核对，标出典型的假繁忙时段
- 按业务类型拆分在线与离线队列，分别看分位指标、排队与失败重试次数
- 用两周真实负载复核大盘，逐项标出误判时段，回到口径与标签设置上修正
常见坑
- 只看 GPU 占用率就扩容，结果峰值仍在排队，闲置卡在夜间空转，预算花在了错误的地方，事后很难解释。
- 用日均值做容量决策，忽略白天峰值，扩容后体验没有改善，业务团队开始怀疑监控数据，汇报前还要先解释口径。
- 把利用率写进个人绩效，团队开始囤卡、拆分任务与跑空任务，指标上去了，单位任务成本反而更高。
自检与验收清单
- 指标口径是否有书面定义，责任人与复核周期是否明确
- 是否同时看占用率、排队与有效吞吐，而不是只看一项
- 在线与离线负载是否分开统计，并分别设定阈值
- 容量结论是否经过两周真实负载复核，并有留档
常见问题
算力利用率多少算健康？
没有通用数字。交互式服务要看排队分位与超时率，离线批处理才适合追高占用；健康的标准是业务时延达标且没有长期空转。把同行数字当目标，往往做出错误的扩容决定。
显存占用高就是利用得好吗？
不一定。显存被模型权重与缓存长期占住是常态，与是否在产出结果无关。要看单位时间完成的请求或样本，以及卡上是否空转；显存高而吞吐低，通常说明批大小或调度设置有问题。
利用率低是不是该立刻上公有云？
先分清是需求不足还是调度不当。负载有潮汐、合规又允许时，混合部署比整体迁移更稳；若只是队列与配额没管好，换云也会把浪费一起搬过去，判断依据是负载曲线与成本。