占用率要分维度
按时间平均的占用率会掩盖瞬时打满与长期空闲。怎么做：同时看时间序列与卡维度分布，区分均值与峰值；边界是采样间隔过粗会漏掉短时高峰，过细则存储压力大，需要按业务定粒度与保留期。
有效吞吐
单位算力在单位时间内完成的业务量，比请求数更能反映效率。为什么重要：小请求多但每个都很短，占用率不高却产出不低。做法是按业务定义产出单位并归一化；边界是不同任务的产出不可直接相加，需要分类统计。
显存与碎片
显存被缓存与长上下文占用后，能承载的并发会下降，表现为利用率上不去。怎么做：记录显存占用曲线与请求被拒原因；边界是显存优化会影响最大上下文长度，属于能力取舍，不能只看数字而忽略用户体验。
排队与等待
请求在队列里等待的时间反映容量与调度的匹配度。为什么单列：占用率高且排队长为真饱和，占用率低却排队说明调度或依赖有问题。做法是把队列长度与占用率放在一张图上，判断真实饱和程度。
能效与成本
按单位产出的电力与折旧折算，能看出是高效还是空转。怎么做：把电费与设备折旧按业务线分摊到具体任务；边界是不写具体金额，只做相对比较，避免把成本结论建立在估算误差上而产生误导。
适用与不适用
适合谁
- 要评估现有算力是否够用的运维与架构团队
- 准备扩容或采购、需要数据支撑的决策者
- 多团队共用算力、需要建立配额依据的平台部门
不适合谁
- 只有单机单任务、谈不上利用率的实验环境
- 不做采样与统计、只凭印象判断的项目
典型场景
某研究院的推理平台长期显示占用率不低，但业务方仍抱怨排队。运维拉出时间序列后发现，占用集中在少数卡上，其余卡因显存不足无法调度新任务。调整模型切分与显存预留后，卡间分布均衡，排队时间下降，占用率的绝对值反而略有降低。
可执行步骤
- 确定采样粒度与统计维度，把口径定义写进指标说明文档中备查与评审范围
- 为每类业务定义产出单位并做归一化，便于横向比较、汇总统计与汇报口径统一
- 记录显存占用曲线与请求被拒的原因，逐条归类并统计各自占比与次数变化
- 把队列长度与占用率放在同一张图上，判断真实的饱和程度与原因所在
- 按业务线分摊电力与折旧，只做相对的成本比较与趋势分析，不写金额
常见坑
- 只看时间平均的占用率，瞬时打满与长期空闲都会被掩盖，容量规划随之失准，扩容时点也会错，成本被浪费在闲置上。
- 用请求数当作产出，长短请求混在一起，效率判断必然失真，优化方向也会跑偏，投入难见回报。
- 显存不足导致任务无法调度，却误判为算力不够而继续加卡，闲置更多，真实问题反而被掩盖。
- 占用率高就认为效率高，忽略排队与业务产出，误判为健康，直到投诉集中爆发才发现问题。
自检与验收清单
- 采样粒度与统计维度是否已经确定，是否写入了指标说明文档
- 每类业务的产出单位是否已经定义，是否全部做过归一化处理
- 显存占用曲线与请求被拒绝的原因，是否都有完整记录与归类
- 队列长度与占用率是否放在同一张图上，判断是否真正饱和程度
- 是否按业务线分摊电力与折旧，并做过相对成本比较分析与趋势
常见问题
占用率多少算健康？
没有统一数字，要看业务类型与目标。离线批处理可以追求高占用，在线服务要为峰值留余量。更可靠的做法是同时看占用率、排队时长与有效吞吐，三者一起判断是否真的饱和。
为什么要看有效吞吐？
占用率只说明卡在忙，不说明忙得有价值。小请求多、上下文短时，占用率可能不高但产出不小。用业务产出除以算力时间，才能比较不同任务与不同卡型的效率，避免只看表面数字。
利用率低就要裁容量吗？
不一定。要看是否为峰值预留、是否存在隔离要求。可以先做闲置回收与错峰混部，再评估是否缩减。直接按平均利用率裁容量，可能让高峰期排队加剧，反而影响业务承诺。