在 Kubernetes 上运行 GPU 迫使企业从零构建测量与计费体系

用于监控 CPU 和内存的工具无法同样轻松地迁移到 Kubernetes 上的 GPU。平台通常会提供容器或 Pod 级别的使用指标，但在共享 GPU 时，平台团队需要自行构建大部分可见性和分配层，从数据收集开始，一直到确定各团队应承担的成本份额。

问题的重要性源于 GPU 通常是基础设施账单中最昂贵的项目。分析指出，运行成本不仅包括节点价格，还包括用于弥补测量缺口、验证数据准确性，以及防止工作负载超出 Kubernetes 为其分配资源的工程时间。

为什么常规指标不够用？

许多运营人员从 NVIDIA DCGM exporter 开始使用，该工具默认提供物理设备级数据。当 Pod 拥有完整的 GPU 时，这可能已经足够；但在使用 time-slicing 或 MPS 共享设备时，情况就不同了。在这种情况下，每个使用一个 GPU 的 Pod 可能都会显示相同的数值，看起来就像三个工作负载消耗了实际上并不存在的 300% GPU。

问题在于，图表可能看起来正常，尽管底层数据并不适合进行归属分配。因此，团队可能会基于无法真正区分各个消费者的数据，构建完整的报告和监控面板。

平台团队在实践中需要做出哪些改变？

GPU 在资源分配模型上也不同于 CPU。在 Kubernetes 中，GPU 通常以 nvidia.com/gpu: 1 这样的整数资源形式出现，调度器无法像处理 CPU 那样处理 GPU 的小数部分。实际共享发生在调度器层级之下，通过 time-slicing、MPS 或 MIG 实现，这使得比较工作负载请求的资源与实际使用的资源变得更加复杂。

团队还需要独立的控制机制，以确认 Kubernetes 记录为已分配的资源，与应用实际能够访问的资源相匹配。如果没有适当的配置来覆盖默认行为，环境变量 NVIDIA_VISIBLE_DEVICES 可能会导致容器看到节点上的所有 GPU，即使调度器只为其分配了一个 GPU。

此外，“GPU 使用率为 80%”这一表述未必只有一种含义。它可能只衡量采样窗口中的一部分时间内有内核运行，却没有说明计算能力或内存带宽的消耗。在某些框架中，例如 vLLM，启动时可能会预留大部分 GPU 内存，这使得内存或带宽成为比总体使用率更重要的指标。

计费：内存比计算资源更容易归属

NVIDIA NVML 库可以显示每个进程占用的内存量，然后将进程与 Pod 以及负责的团队关联起来，但需要注意的是，所有数值之和不会等于显卡的全部内存，因为其中一部分会由驱动程序自身保留。

对于并行运行的工作负载，计算时间的归属精度有限。两个工作负载可能分别显示为 90% 活跃，但指标无法说明其中一个消耗了 70% 的计算能力，而另一个消耗了 30%。因此，分析建议将 GPU 内存使用作为内部计费的实际基础，同时将计算资源测量视为运营指标，而不是精确收费的依据。

共享模型的选择会改变计算方式

GPU 共享并不只有一种模型。time-slicing 会在设备上交替运行任务，但不提供隔离；MPS 允许不同进程的内核同时运行；而 MIG 则将硬件划分为固定部分。然而，云服务可能会按照完整物理 GPU 收费，即使用户只使用其中一部分；此外，根据该文章，A100 和 H100 系列显卡最多可以划分为七个实例。

Dynamic Resource Allocation (DRA) 正在成为资源管理的未来路径，但目前仍处于成熟阶段，其周边工具，包括 Karpenter 等扩展工具，也在跟进这一发展。

为什么这条消息很重要？

根据该文章，在 AWS 上，兼容 MIG 的最低价 A100 GPU 约为每小时 22 美元，使用现货定价时约为 14 美元；相比之下，仅依赖 CPU 的可比实例约为每小时 5 美元。因此，使用归属错误并非微不足道的会计问题，而是可能直接影响容量、成本以及团队负担分配公平性的决策。

编辑部总结认为，在 Kubernetes 上运行 GPU 仍然需要采用不同于 CPU 和内存的运营模型。平台团队必须确定哪些内容能够被准确测量，制定明确的成本分配规则，并避免基于无法描述真实消耗的通用 GPU 指标做出计费决策。另一方面，消息来源指出，DRA 的成熟和硬件划分可能会逐步缩小这一差距，但这将在何时发生，以及当前工具存在何种限制，仍是悬而未决的问题。