四层指标各管什么
设备层看温度、功耗、显存错误与掉卡；调度层看队列深度、等待时长与抢占次数；任务层看成功请求、失败重试与空转；成本层看按项目归集的卡时。混在一张大盘上，故障时看不出瓶颈在哪一层，排障时间被拉长。
标签比采集工具重要
节点侧采集 GPU 指标，经时序数据库汇总，再按租户、项目与任务打标签。标签设计决定数据能不能用：没有项目与任务标签，只能证明卡在忙，回答不了谁在用、用得值不值；口径要一次定好，后补成本很高。
告警分级才有人看
掉卡、ECC 错误与驱动异常属于立即处理；队列长期积压、利用率持续偏低进入周度复盘；温度接近阈值按趋势观察。所有指标都设告警会迅速疲劳，最后没人看；应按影响面分级，写清值班人与升级路径。
周报看趋势再定容量
容量决策要按周对比有效吞吐、排队分位与空转卡时，并标注版本变更与业务活动。瞬时截图容易被误读，采购后负载回落、卡长期闲置的情况并不少见；连续几周说明问题的趋势，才值得调整配额。
适用与不适用
适合谁
- 已建成 GPU 集群、需要长期稳定运行的运维团队
- 多租户共享算力平台的负责人与平台组
- 需要向财务解释算力成本构成的 IT 管理者
不适合谁
- 只有单机开发环境、无共享需求的团队
- 期望装一块大屏就算完成监控的项目
典型场景
某企业的推理集群在促销期频繁超时，运维起初只盯 GPU 占用率，始终找不到原因。补上队列等待与失败重试指标后，发现是网关限流叠加客户端重试造成雪崩。团队把告警分为三级、把容量复盘改成周会，促销前按历史峰值预留冗余，超时问题才稳定下来。
可执行步骤
- 按设备、调度、任务、成本四层定义指标，写成可查、可交接的指标字典并评审
- 在节点侧部署采集，统一打上租户、项目与任务标签，并定期校验标签完整性
- 配置三级告警、值班表与升级路径，先空跑两周再逐步收紧阈值与静默规则
- 建立周报，按周对比有效吞吐、排队分位、空转卡时与版本变更记录，形成趋势
常见坑
- 只监控 GPU 占用率，网关限流与客户端重试造成的雪崩被掩盖，排障方向一开始就错了，复盘也找不到证据。
- 所有指标都设告警又不分级，值班被噪音淹没，真正的掉卡告警反而无人处理，故障时长被拉长，团队逐渐不信告警。
- 指标没有项目与任务标签，成本分摊只能靠估算，月度对账各执一词，结算工作难以推进，财务也不认。
自检与验收清单
- 是否按设备、调度、任务、成本四层定义指标并成文
- 采集数据是否带租户、项目与任务标签，且校验完整
- 告警是否分级，值班人与升级路径是否明确到人
- 是否有周报趋势对比与每月卡时账本对账机制
常见问题
用开源监控组件够吗？
多数场景够用，节点采集加时序数据库与看板即可覆盖设备与调度层。难点在标签设计与告警治理，不在工具选型；若需要按租户结算，还要补任务级账本，开源组件通常需要二次开发。
利用率偏低就该扩容或缩容吗？
先分清是需求不足还是调度问题。队列常年很短、卡大量空转，说明该缩容或收紧配额；排队很长但占用率低，往往是调度、数据加载或网关限流的问题，扩容只会增加闲置与库存压力。
值班一定要全天候吗？
取决于业务时延要求。在线推理通常需要，离线批处理可以在工作时段处理。关键是分级：立即处理的告警要有明确接手人与升级路径，其余进入次日工单，避免所有告警都变成半夜电话并消耗人力。