GKE GPU监控盲区：利用率指标误导与归因错误的深度剖析

在生产环境中运行GPU集群，一个看似简单的问题往往被忽视：你的监控面板真的告诉你GPU在做有用的事情吗？ 一位工程师在深入研究GKE（Google Kubernetes Engine）导出的GPU指标后，发现了一个令人不安的事实——无论是GKE托管方案还是自建DCGM方案，都各自只做对了一半。这篇文章将剖析这一监控盲区背后的技术原理，以及它可能带来的真实成本。

GKE托管GPU指标的真相

很多工程师默认GKE导出的GPU指标就是业界标准的dcgm-exporter，只是换了标签名。但实际调查显示并非如此。GKE的GPU指标来自谷歌自己的采集器——运行在device-plugin DaemonSet内部的nvidia-metrics-collector容器。

要理解这一设计选择，需要先了解GKE的GPU设备管理架构。GKE是谷歌云提供的托管Kubernetes服务，用户无需自行管理控制平面。在Kubernetes中，GPU这类硬件加速器属于"扩展资源"（Extended Resources），需要通过Device Plugin机制向kubelet注册。Kubernetes的Device Plugin Framework定义了一套标准的gRPC接口，包括ListAndWatch（持续向kubelet报告可用设备列表）、Allocate（在容器创建时完成设备分配和环境配置）等关键方法。NVIDIA的Kubernetes Device Plugin以DaemonSet形式运行在每个GPU节点上，通过这套gRPC接口向kubelet注册GPU设备，报告可用GPU数量，并在容器启动时通过设置环境变量（如NVIDIA_VISIBLE_DEVICES）和挂载设备节点（如/dev/nvidia0）来完成GPU的隔离与分配。kubelet收到设备注册信息后，会将GPU数量更新到Node对象的Capacity和Allocatable字段中，使Kubernetes调度器能够感知GPU资源进行调度决策。GKE在这一标准机制上做了深度定制——它在Device Plugin的Pod中额外注入了nvidia-metrics-collector容器作为sidecar，用谷歌自研的采集逻辑替代了社区常用的dcgm-exporter。这种sidecar注入的方式使得采集器天然地与Device Plugin共享同一个Pod生命周期和网络空间，也意味着它能够直接访问Device Plugin维护的设备分配映射表，这也是指标差异和归因能力差异的根源所在。

它总共只导出四个GPU指标：

• duty_cycle：GPU处于活跃处理状态的时间百分比
• memory_used：已用显存字节数
• memory_total：总显存字节数
• request：每容器请求的GPU数量

这就是全部。没有SM占用率（SM occupancy），没有Tensor Core活跃度，没有功耗数据。 对于需要精细化观测GPU负载的团队来说，这个指标列表显得相当单薄。

duty_cycle指标的误导性

问题的核心在于duty_cycle这个指标。它的语义等同于DCGM_FI_DEV_GPU_UTIL，本质上是内核驻留（kernel residency）——它报告的是有一个内核（kernel）驻留在设备上，而不是这个内核真的在做计算。

要真正理解这个陷阱的严重性，需要深入GPU的执行模型。NVIDIA GPU上的计算以"内核（kernel）"为单位提交——一个kernel是一段在GPU上并行执行的程序。在GPU内部，计算的并行层次从细到粗依次为：线程（Thread）→ 线程束（Warp，32个线程为一组同步执行）→ 线程块（Block，多个Warp组成，在同一个SM上调度）→ 网格（Grid，所有Block的集合，构成一个完整的kernel）。每个SM内部包含多种功能单元：CUDA Core负责标量浮点和整数运算，Tensor Core专门加速矩阵乘累加运算（这是深度学习训练和推理的核心操作），此外还有Load/Store单元处理显存访问、特殊功能单元（SFU）处理超越函数等。一个kernel的线程块被GPU的GigaThread引擎分配到各个SM上执行，但如果kernel的并行度不够（即线程块数量远少于可用SM数量），大量SM就会处于空闲状态。

GPU利用率（GPU Utilization，即DCGM_FI_DEV_GPU_UTIL）衡量的是采样周期内"至少有一个kernel在GPU上运行"的时间占比，这就是所谓的内核驻留。这个指标来源于NVIDIA的nvmlDeviceGetUtilizationRates API，它以固定采样窗口（通常为1秒）统计GPU引擎处于非空闲状态的时间比例。但一个kernel可能只使用了GPU上极少数的流式多处理器（Streaming Multiprocessor, SM）。现代NVIDIA GPU拥有大量SM——例如A100有108个SM，H100有132个SM，最新的B200更是达到了192个SM——一个低效的kernel可能只占用了其中几个SM，却让GPU利用率显示为100%。相比之下，DCGM_FI_PROF_SM_ACTIVE衡量的是所有SM中实际处于活跃计算状态的比例——它统计的是每个SM上至少有一个Warp处于活跃状态的时间占比，然后在所有SM之间取平均值。DCGM_FI_PROF_PIPE_TENSOR_ACTIVE则进一步聚焦到AI训练最关键的张量计算单元的实际使用率，它衡量的是Tensor Core功能管线（pipeline）处于活跃执行状态的周期占比。三者的粒度差异可达数量级：一个GPU Util为100%的场景，SM Active可能只有15%，Tensor Core Active可能不到5%。这在推理场景中尤其常见——小批量推理请求可能启动的线程块很少，每次kernel调用都很短且只占用少量SM，但由于请求频率高，GPU几乎总是有kernel在运行，利用率指标显示为高值。

换句话说，一个用无意义循环把GPU钉住的进程，会让duty_cycle读数显示100%忙碌，而实际上什么都没算。这是一个典型的"看起来很忙，实际上很闲"的陷阱。对于成本敏感的GPU集群，这种误导可能意味着大量算力被浪费却毫无察觉。

更棘手的是，在GKE托管指标上，你无法启用任何更精细的指标。内核驻留是唯一被导出的利用率信号。而在自建集群上，你至少可以通过启用DCGM profiling指标（如DCGM_FI_PROF_SM_ACTIVE、DCGM_FI_PROF_PIPE_TENSOR_ACTIVE）来获得真实的计算活跃度。这里提到的DCGM（Data Center GPU Manager）是NVIDIA专门为数据中心场景设计的GPU管理和监控框架，提供了一套C语言API和命令行工具，能够采集数百个GPU运行时指标，涵盖温度、功耗、ECC错误、NVLink带宽、SM活跃度、Tensor Core利用率等维度。DCGM的架构由一个后台守护进程nv-hostengine和客户端库组成，守护进程通过NVIDIA的底层驱动接口（NVML和CUPTI）与GPU硬件通信。dcgm-exporter则是NVIDIA官方提供的Prometheus Exporter，从DCGM守护进程中拉取指标并以Prometheus格式暴露，通过一个CSV格式的配置文件（default-counters.csv）控制导出哪些指标。

DCGM的指标体系分为多个级别：基础指标（如温度、显存用量、功耗）不需要额外开销即可采集，它们来源于NVML（NVIDIA Management Library）接口，本质上是读取GPU上的固件传感器和状态寄存器。而Profiling级别的指标（以DCGM_FI_PROF_前缀标识）需要使用GPU的硬件性能计数器（Hardware Performance Counters），这些计数器是GPU芯片内部的专用硬件寄存器，能够以极低开销统计特定微架构事件的发生次数——比如SM上执行的指令数、Tensor Core管线的活跃周期数、显存控制器的读写事务数等。DCGM通过NVIDIA的CUPTI（CUDA Profiling Tools Interface）库访问这些计数器。然而，GPU上的硬件性能计数器数量有限，同一时刻只能监控有限数量的事件。如果dcgm-exporter已经占用了这些计数器来采集Profiling指标，那么Nsight Systems、Nsight Compute等性能分析工具就无法同时使用同一组计数器，这就是为什么两者可能产生互斥。在DCGM 3.x版本中，引入了"性能计数器复用"（counter multiplexing）的能力来部分缓解这一限制，但在高精度分析场景下仍建议避免同时运行。

GPU监控归因问题：另一半的失败

有意思的是，GKE在**归因（attribution）**上做得很对。每一个duty_cycle采样都携带了实际工作负载的pod、namespace和container信息。也就是说，你能准确知道哪个业务在使用哪块GPU。

而自建的dcgm-exporter恰恰相反。它给你诚实的利用率指标，但除非有人显式设置了DCGM_EXPORTER_KUBERNETES=true，否则每一个GPU时间序列都会被归因到exporter自己所在的pod（通常在monitoring命名空间）。按pod分组，你会得到一张"整洁"的图表——每一个GPU小时都属于那个测量它的组件，而非真正的使用者。

这里的技术根源在于Kubernetes中指标归因的实现机制。在Kubernetes的可观测性体系中，"归因"指的是将资源消耗指标关联到正确的工作负载实体（Pod、Namespace、Container）。Prometheus通过标签（labels）实现这一关联。当dcgm-exporter以DaemonSet形式部署时，Prometheus的服务发现机制（通常通过kubernetes_sd_config配置）会自动为其采集到的指标附加Pod元数据标签，包括__meta_kubernetes_pod_name、__meta_kubernetes_namespace等。但这里存在一个微妙的问题：这些标签反映的是被Prometheus抓取（scrape）的目标Pod的身份——也就是dcgm-exporter自己——而非真正使用GPU的业务Pod。GPU设备（如/dev/nvidia0）本身只是一个硬件标识符，DCGM采集到的指标天然只关联到GPU设备UUID，而不包含任何Kubernetes层面的信息。

要实现正确归因，dcgm-exporter需要主动查询kubelet的Pod Resources API。这是Kubernetes从1.13版本开始引入的一个gRPC接口，暴露在kubelet的本地Unix套接字/var/lib/kubelet/pod-resources/kubelet.sock上。该API提供了List方法，返回节点上所有Pod中每个容器被分配的设备资源列表——包括资源名称（如nvidia.com/gpu）和对应的设备ID（即GPU的UUID）。通过设置DCGM_EXPORTER_KUBERNETES=true启用此功能后，dcgm-exporter会定期调用Pod Resources API，构建一个从GPU UUID到Pod/Namespace/Container的映射表，然后在导出指标时将这些Kubernetes标签注入到对应GPU的时间序列中。这一过程的关键数据结构是PodResources消息，其Protobuf定义包含Pod名称、命名空间和ContainerDevices列表（设备资源名到设备ID列表的映射）。如果未启用此功能，所有GPU指标都只携带dcgm-exporter自身的Pod标签，导致归因完全错误。GKE的托管采集器之所以归因正确，正是因为它运行在Device Plugin内部，天然拥有设备分配信息——Device Plugin在处理Allocate请求时会记录哪个Pod被分配了哪个GPU设备，这些信息无需额外API调用即可获得。

各对一半的监控困境

于是形成了一个精妙而讽刺的对照：

方案	归因准确性	利用率指标	可升级性
GKE托管	✅ 正确	❌ 误导	❌ 无法升级
自建DCGM（默认）	❌ 错误	✅ 诚实	✅ 可配置

最危险的地方在于：两种情况下，仪表盘看起来都很完整。 每个时间序列都有namespace、有pod、有一个貌似合理的数字。表面上一切正常，实际却各藏隐患。

如何快速诊断GPU监控的失败类型

如果你在用Prometheus，可以对比GPU指标上的pod与真正请求GPU的pod：

curl -s localhost:9090/api/v1/query \\\\
  --data-urlencode 'query=count by (pod) (DCGM_FI_DEV_FB_USED)'

curl -s localhost:9090/api/v1/query \\\\
  --data-urlencode 'query=count by (pod) (kube_pod_container_resource_requests{resource="nvidia_com_gpu"})'

第一个查询列出所有DCGM显存指标中出现的Pod名称——这些是dcgm-exporter认为"拥有"GPU的Pod。第二个查询通过kube-state-metrics列出所有在资源请求中声明了nvidia.com/gpu的Pod——这些是Kubernetes调度器实际为其分配了GPU的Pod。在正确归因的情况下，两个查询返回的Pod集合应该高度重叠。

判断逻辑很直接：

• 两组结果没有重叠 → 你的归因是虚构的（自建DCGM的归因问题）。这意味着DCGM指标上的Pod标签全部指向dcgm-exporter自己，而非真正的GPU使用者。
• 第一个查询在GKE上完全没有返回 → 你用的是托管采集器，指标是duty_cycle而非DCGM系列（GKE的利用率盲区）。在这种情况下，你需要查询GKE自己的指标名称（如kubernetes.io/container/accelerator/duty_cycle）。

这个简单的对比能帮助运维团队快速定位自己踩的是哪个坑。

GPU空闲浪费的真实成本代价

理论问题最终会变成账单上的数字。在测试过程中发现了一个典型案例：一个开发工作空间占用着一块16GB的T4显卡，duty_cycle为0%，上面停着448 MiB显存和一个CUDA上下文，除此之外什么都没有——在每一个采样点上都处于空闲状态。

这里需要理解CUDA上下文对资源占用的影响。CUDA上下文（CUDA Context）是GPU编程中的核心概念，类似于CPU上的进程地址空间。当一个应用程序初始化CUDA运行时时（例如调用cudaFree(0)或任何CUDA API），驱动会在GPU上创建一个上下文，这个操作本身就会占用一定量的显存——通常在几十到几百MiB之间，具体取决于GPU型号和CUDA版本。这些显存用于存储CUDA运行时的内部数据结构，包括：上下文管理元数据、默认流（default stream）的状态信息、JIT编译缓存、页表映射结构（用于统一虚拟地址空间UVA的支持），以及预分配的设备端堆内存（用于malloc式的设备内存分配）。在深度学习场景中，当PyTorch或TensorFlow被import并检测到可用GPU时，通常会立即初始化CUDA上下文，有些框架甚至会预分配一个显存池以减少后续分配的延迟（例如PyTorch的CUDA Caching Allocator默认会在首次分配时获取大块显存）。

文中的448 MiB显存占用加上一个CUDA上下文，正是这种典型模式：某个开发者启动了一个Jupyter Notebook或调试进程，加载了CUDA运行时和可能的深度学习框架，然后就放在那里不动了。GPU不执行任何计算（duty_cycle为0%），但显存被占用意味着这块GPU无法被Kubernetes调度给其他Pod使用——因为Kubernetes的GPU调度是以整卡为单位的排他性分配。在Kubernetes的资源模型中，GPU属于不可压缩资源（与CPU不同），一旦分配给某个Pod，即使该Pod完全不使用GPU计算能力，这块GPU也被标记为已占用，调度器不会将其分配给其他Pod。除非使用了GPU共享方案如MIG（Multi-Instance GPU，将一块物理GPU在硬件层面划分为多个独立的GPU实例，每个实例拥有独立的显存、SM和L2缓存，提供硬件级别的隔离，但仅A100及以上架构支持）或Time-Slicing（通过NVIDIA GPU Operator的时间片配置，让多个Pod轮流使用同一块GPU，但没有显存隔离，且会引入上下文切换开销）。这块T4按照谷歌云的按需价格约为每小时0.35美元，一天就是8.4美元，一个月约为252美元，而它什么也没做。如果是更高端的A100 80GB（按需价格约每小时3.67美元）或H100（按需价格更高），一块空闲卡一个月的浪费可达数千美元。

一块卡，小钱。但真正的问题是：在任何一个平台的默认指标下，这种浪费都永远不会浮出水面。 因为"利用率"告诉你集群一切正常，而"归因"告诉你这块GPU属于监控组件。当集群规模扩大到几十上百块GPU时，这类隐性浪费会迅速累积成可观的成本。根据行业经验，大型GPU集群中10%-30%的GPU可能在任意时刻处于这种"被占用但未使用"的状态，尤其在开发和实验环境中更为严重。

给GPU集群运维者的解决方案

这个案例揭示了一个更深层的观测性（observability）原则：指标的存在不等于洞察的存在。 一个完整的仪表盘可能恰恰掩盖了两个方向的系统性偏差。这也是可观测性领域常说的"仪表盘的诅咒"——当所有指标都显示绿色时，人们会停止质疑，但绿色可能只是因为你在测量错误的东西。

对于在GKE上运行GPU集群的团队，可行的应对思路包括：

1. 并行部署自己的dcgm-exporter：在托管采集器旁边补充一个配置正确的dcgm-exporter，既拿到真实利用率，又通过DCGM_EXPORTER_KUBERNETES=true获得正确归因，取两者之长。这一方案的关键在于确保dcgm-exporter能够访问kubelet的Pod Resources API（需要在DaemonSet的Pod规格中挂载/var/lib/kubelet/pod-resources目录作为hostPath卷，并确保容器有权限读取该路径下的Unix套接字）。在DCGM的配置文件（default-counters.csv或自定义的counter文件）中，需要显式添加Profiling级别的指标，例如：DCGM_FI_PROF_SM_ACTIVE, gauge, SM activity和DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, gauge, Tensor Core activity。部署时还应注意设置适当的采集间隔——Profiling指标的采集频率不宜过高（建议10-30秒），过高的频率可能会略微影响GPU计算性能。需要注意的是，Profiling指标会占用GPU的硬件性能计数器，如果你的工作负载同时在使用NVIDIA Nsight Systems或Nsight Compute进行性能分析，可能会产生冲突。一个实践技巧是在dcgm-exporter的DaemonSet上设置环境变量DCGM_EXPORTER_COLLECTORS指向自定义的counter文件，并根据集群用途（生产推理 vs. 开发调试）维护不同的配置版本。

2. 接受盲区并建立补偿机制：如果坚持只用托管指标，至少要意识到duty_cycle的局限，配合显存占用、CUDA上下文检测等辅助信号做交叉判断。例如，可以设置告警规则：当某个Pod的GPU显存占用持续大于0但duty_cycle持续为0超过一定时间阈值（如30分钟）时，触发空闲GPU警告。一个Prometheus AlertManager规则的示例逻辑可以是：accelerator_memory_used > 100*1024*1024 AND accelerator_duty_cycle == 0 FOR 30m。此外，还可以结合GPU功耗信息做判断——一块空闲的NVIDIA GPU通常消耗其TDP（热设计功耗）的10%-20%，而一块满载的GPU功耗会接近TDP上限。如果同时能获取到功耗数据（DCGM_FI_DEV_POWER_USAGE），低功耗+有显存占用几乎可以确认GPU处于空闲浪费状态。这种启发式方法虽然不如SM Active精确，但能捕获最明显的浪费场景。

3. 探索Cloud Monitoring的深层能力：不排除谷歌在Cloud Monitoring体系中还有未被充分利用的指标接口。Google Cloud Monitoring（前身为Stackdriver）支持自定义指标（Custom Metrics）和OpenTelemetry集成，理论上可以将dcgm-exporter的数据通过Prometheus-to-Cloud Monitoring的转换管道导入GCP的监控体系，从而在统一的仪表盘中同时查看GKE原生指标和DCGM Profiling指标。此外，GKE从1.28版本开始支持的Managed Collection for Prometheus（GMP）也提供了一种受管理的Prometheus兼容采集方案，可能更容易与自定义的dcgm-exporter集成。

4. 实施GPU空闲回收策略：监控只是发现问题的手段，最终还需要自动化的资源回收机制。可以考虑部署自定义的Kubernetes Controller或CronJob，定期检查GPU Pod的活跃度，对持续空闲超过阈值的Pod发出警告通知或自动缩容。一些开源项目如NVIDIA GPU Operator和Run:ai已经在探索类似的GPU资源池化和动态调度方案，将GPU从"静态分配"模式转向"按需分配"模式，从根本上减少空闲浪费。

无论选择哪条路，关键的第一步是承认默认监控可能在骗你。在GPU成本高企的今天，一块被误报为"忙碌"或"归属错误"的空闲显卡，就是实打实的资金流失。定期用上述诊断查询审计你的集群，或许是最低成本的成本优化手段。

核心要点

• GKE托管GPU指标仅导出4个基础指标，其中duty_cycle（内核驻留率）可能严重高估GPU的实际计算利用率，因为它无法区分"有kernel在运行"和"kernel在高效计算"。
• 自建dcgm-exporter默认存在归因错误，所有GPU指标会被标记到监控组件自身的Pod上，而非真正使用GPU的业务Pod。启用DCGM_EXPORTER_KUBERNETES=true并配置Pod Resources API访问权限可修复此问题。
• 两种方案的仪表盘看起来都很完整，这是最危险的地方——表面正常的监控数据掩盖了系统性的观测盲区。
• GPU空闲浪费在默认监控下不可见，CUDA上下文的显存占用和Kubernetes的整卡排他分配机制意味着一块什么都不做的GPU也无法被其他工作负载使用。
• 推荐并行部署配置正确的dcgm-exporter，启用Profiling级别指标（SM Active、Tensor Core Active）并开启Kubernetes归因，同时建立基于多信号交叉验证的告警规则来捕获空闲浪费。