硬件层指标
采集 GPU 利用率、显存占用、温度、功耗、ECC 错误与 Xid 报错，配合风扇与电源状态。硬件异常往往先体现在温度与错误计数上，早发现能避免批量故障；这些指标还要按机型留存基线，便于横向比较不同机型，也便于判断批次差异。
服务层指标
盯每秒生成 token 数、首字延迟、队列长度、超时率与批处理效率。队列持续增长说明容量不足或某类请求异常变长，需要下钻到请求类型；只看平均延迟会掩盖长尾，用户体验的抱怨往往集中在长尾上。长尾体验往往才是投诉来源。
业务层结果
成功率、人工接管率与用户反馈是最终判据。硬件指标正常但业务成功率下降，通常指向模型版本、提示词或知识库变化；这条线索能快速缩小排查范围，避免在硬件上浪费时间，避免只盯硬件指标。
变更与升级
驱动、固件与推理框架升级要灰度到少量节点，观察稳定后再全量。升级窗口避开业务高峰，并准备回滚镜像；升级记录要与性能基线关联，否则出问题时无法判断是哪一次变更引入，灰度范围要写进方案。
容量与疏散
设容量水位线，接近阈值时提前扩容或限流；单节点故障要能自动摘除并迁移请求。定期演练疏散，确认实际耗时符合预期，演练结果要写回预案并用于修订扩容计划，而不是只留在报告里，也要与扩容计划联动。
适用与不适用
适合谁
- 已自建推理集群、有多团队共用场景的运维团队
- 多团队共用算力、需要分账并愿意协作的企业
- 遇到间歇性故障、难以定位的项目组
不适合谁
- 仅使用托管接口、无自有硬件的团队，也缺少可观测的数据。
- 尚未上线的试点项目，也缺少可观测数据。
典型场景
某企业推理集群出现间歇性超时，硬件指标正常。运维按请求类型下钻，发现某类长文档请求的上下文接近上限，导致显存紧张并触发排队。团队为该类请求单独设池并限制最大长度，超时告警随之减少，容量水位线也重新核定。
可执行步骤
- 部署硬件与服务两层指标采集，统一标签与时间口径，接入统一监控平台
- 确定四组指标与各自基线，把阈值写入运维手册，明确响应时限，并由值班人确认
- 配置分级告警与接收人，明确响应时限与升级路径，避免告警无人认领，每月复核一次
- 建立驱动与框架的灰度升级流程，保留可回滚的镜像版本，先小范围验证
- 设置容量水位线，按季度演练故障疏散并修订预案，记录演练结论与改进项
常见坑
- 只看 GPU 利用率，忽略队列与延迟，用户已感知卡顿才告警，损失已经发生。复盘只能事后补救，事后补救成本很高。
- 驱动与框架直接全量升级，兼容性问题波及全部节点，回滚又不熟练。停机时间被拉长，变更窗口也随之延长。
- 容量水位无阈值，扩容总是滞后于业务增长，临时采购周期又长。业务只能降级，扩容总是慢半拍，投诉随之增加。
- 故障疏散从未演练，真故障时迁移耗时远超预期，业务中断时间被拉长，客户侧感知非常直接，投诉随之增加。
- 指标采集缺少标签，多团队共用时无法分账，成本争议长期存在。扩容也难以推动，分账争议难以调解。
自检与验收清单
- 硬件与服务水平指标是否都在采集，是否统一口径
- 告警是否分级并有明确接收人，升级路径是否清楚
- 升级是否灰度并保留回滚镜像，是否有回滚方案
- 容量水位线是否设定并持续监控，阈值是否合理
- 疏散演练是否定期进行并修订预案，是否更新预案
常见问题
需要专门的 GPU 运维吗？
规模较小时可由系统运维兼任，但要具备驱动、框架与硬件故障排查能力。规模上去后建议设专人或依托厂商服务，否则故障定位会很慢，业务侧的等待成本更高，也影响故障复盘。
温度和功耗告警阈值怎么定？
参考设备规格与机房环境设定，并结合历史数据调整。阈值过严会误报频繁，过松则失去预警作用，建议先观察一段时间再定，之后按季度复核，否则阈值很快失真，告警也会被忽视。
多团队共用怎么分账？
通过命名空间、队列或标签记录资源使用，按实际占用与任务量分摊。分账口径要事先约定并公开，否则月底对账容易产生争议，也会影响后续扩容，分账结果要定期公示，并保留对账记录。