云原生项目面向 GPU 集群扩展时如何重新设计可观测性

GPU 集群扩展后，最容易出现的误区是把“GPU 利用率高低”当成完整答案。利用率低，可能是任务在队列里等待；利用率高，也可能是显存、PCIe、NVLink 或某个下游服务成为瓶颈。更稳妥的做法是把可观测性拆成设备与节点、Kubernetes 工作负载、请求链路三层，再用 workload、pod、namespace、模型版本和 trace_id 把三层串起来。

先把观测对象从一张 GPU 卡拆成三层

第一层是设备和节点：温度、功耗、显存、SM 时钟、XID 错误、健康状态以及节点是否可调度。第二层是工作负载：哪个 namespace、Job、Pod、容器或 DRA claim 占用了设备，排队时间和实际处理量是否匹配。第三层是请求链路：请求经过网关、路由、队列、推理服务和批处理器时，时间到底耗在哪一段。

这三层回答的问题不同，不能用一个大而全的 Dashboard 代替。Kubernetes 官方把 metrics、logs、traces 视为需要聚合和关联的信号；GPU 项目应沿用这个思路，把“卡异常”与“请求变慢”放进同一条排查路径。

GPU 指标要和 Pod 归属一起采集

以 NVIDIA 环境为例，DCGM Exporter 会通过 Prometheus 端点暴露设备指标，并可在 Kubernetes 映射成功时补充 pod、namespace、container 等标签；启用 DRA 时还可能出现 claim、driver、pool 和 device 等映射信息。但“配置了字段”不等于“运行时一定有数据”：硬件、驱动、权限、实体类型和 exporter 配置都会影响最终输出。

因此上线时先做两次确认：一是直接检查 exporter 的 /metrics，确认目标字段真实出现；二是随机抽一个 GPU 使用中的 Pod，核对指标上的 namespace、pod 和 container 是否与 Kubernetes 对象一致。Prometheus 查询可以先保持低维度，再按需要下钻：

# 先按命名空间观察 GPU 温度，避免一开始就展开所有高基数标签
DCGM_FI_DEV_GPU_TEMP{namespace="inference"}

# 再把异常窗口关联到具体 Pod；实际字段以 exporter 的运行时输出为准
DCGM_FI_DEV_POWER_USAGE{namespace="inference",pod=~"model-.*"}

告警也要分层。XID、健康状态、温度和功耗更适合做设备告警；队列长度、批处理等待和请求 p95 更适合做工作负载告警。不要把 GPU 利用率低直接写成故障，先确认队列是否为空、Pod 是否拿到设备、Trace 是否停在调度或下游调用。

让工作负载维度解释“谁在用、为什么慢”

扩容以后，最有价值的不是增加更多曲线，而是建立一组稳定的关联字段：cluster、node、namespace、workload、job、pod、container、model_version、queue 和 accelerator_type。长期指标优先保留前几项低基数维度；请求级的 prompt、租户原始 ID 或完整 URL 不要直接当作时间序列标签，可以放进日志或 Trace 属性并按保留策略处理。

建议把一次任务拆成“排队、装载、预处理、GPU 执行、后处理、返回”几个阶段。这样同样的 GPU 利用率下降，可以区分为没有请求、队列等待、模型装载抖动，还是数据传输受限。工作负载状态还应记录调度失败、设备分配失败、Pod 重启和模型版本，这些信息往往比一条平均利用率更接近根因。

用 Trace 把 GPU 告警连接到一次请求

指标适合发现趋势，日志适合保存局部事件，Trace 则回答一次请求经过了哪些组件。OpenTelemetry 的上下文传播可以让不同服务产生的 span 关联成同一条 Trace；在 GPU 服务中，可以为 queue.wait、model.load、batch.prepare、gpu.execute 和 response.encode 建立阶段 span，并把 workload、pod、model_version 作为资源或 span 属性。

值班路径可以固定为：先看请求 p95 与错误率，再跳到对应 Trace 的最长 span；如果最长的是 queue.wait，查调度和队列，如果是 gpu.execute，回看设备指标和 XID，如果是 model.load，则检查缓存、镜像和模型版本。日志中保留 trace_id、span_id、pod 和 job 名，才能从单次请求回到具体运行实体。

把扩容后的值班动作写成可回滚清单

上线前至少保留四类检查：设备字段是否真实可见，Pod 映射是否准确，Trace 是否跨过队列和推理服务，告警是否能指向动作。发现异常时先降低并发或暂停新批次，确认是否为单节点、单模型或单版本，再决定迁移、扩容、降级或回滚。扩容本身不是成功标准，成功标准应是请求延迟、队列等待和 GPU 有效吞吐同时回到基线。

复盘记录不要只写“GPU 利用率异常”。应留下触发信号、受影响 workload、对应 Trace、设备字段、处置动作、恢复时间和下一次要补的维度。这样下一次集群继续扩展时，观测系统会随业务边界一起增长，而不是继续堆叠孤立面板。

常见问题

GPU 利用率低就说明 GPU 没有被正确使用吗？

不一定。先区分无请求、排队、数据准备、设备分配和执行阶段，再结合 Trace 与工作负载指标判断。

DCGM Exporter 配了字段，为什么 Prometheus 查不到？

字段是否支持取决于 DCGM、GPU、驱动、权限和实体类型；应以 exporter 的实际 /metrics 输出为准，不要只看配置文件。

GPU 指标和 Trace 必须放在同一个系统吗？

不必，但必须共享可关联的 workload、Pod、时间和 trace_id 等上下文，否则跨系统排查仍要靠人工猜测。