在 Kubernetes 上跑 GPU 是「什么都得自己造」：从账单开始
来源The New Stack查看原文
速览
- CPU 和内存的可观测性由内核免费提供，GPU 的每一项指标都要自己搭
- 共享 GPU 时 DCGM 无法区分各 Pod 用量，仪表盘数字好看但明显错误
- GPU 不支持超卖，request 等于 limit，rightsizing 的对比基础一开始就不存在
- NVIDIA_VISIBLE_DEVICES 默认 all，可能让 Pod 实际占用超出调度器分配
- GPU 利用率 100% 不等于算力跑满，显存往往是先耗尽的资源
- 显存归属数据可信，算力归属在并行执行下无法准确拆分
- 建议按显存做计费，算力只作为信号使用
- time-slicing、MPS、MIG、DRA 各自改变「已分配」的含义
- GPU 单价远高于 CPU，云账单把 CPU、内存、GPU 混在一行，拆分困难
- 真正的成本还包括重建这些可见性所投入的工程时间
The New Stack 发文指出，Kubernetes 上 CPU 和内存那套成熟的资源可观测性与成本分摊方法，在 GPU 上几乎全部失效。NVIDIA 的 DCGM exporter 默认按物理设备上报指标，一旦用 time-slicing 或 MPS 共享 GPU，共享同一块卡的多个 Pod 会拿到相同的数值，三个 Pod 共享一块卡会算出 300% 的 GPU 使用率。GPU 在 Kubernetes 中是整数资源（nvidia.com/gpu: 1），request 与 limit 必须相等，调度器不支持超卖，rightsizing 的前提基本不存在。NVIDIA 容器运行时依赖 NVIDIA_VISIBLE_DEVICES 环境变量，基础 CUDA 镜像默认设为 all，若无人覆盖，Pod 可能看到并占用整机所有 GPU，与调度器记录严重不符。GPU 利用率指标只表示采样窗口内有 kernel 在跑，不代表真实算力或带宽消耗，vLLM 等框架启动时就会占走大部分显存。NVML 能按进程给出可信的显存占用，但驱动自身保留一部分内存，加总不等于整卡容量；算力归属在并行执行场景下无法准确拆分。文章建议按显存计费、把算力当作信号，并梳理了 time-slicing、MPS、MIG、DRA 等共享方式对「已分配」定义的影响。成本上，AWS 上最便宜的兼容 MIG 的 A100 实例为 22 美元/小时，spot 约 14 美元/小时，而同规格纯 CPU 实例约 5 美元/小时。
关键事实
- NVIDIA 的 DCGM exporter 默认按物理设备级别上报指标，三个 Pod 共享一块 GPU 时会被算成 300% 使用率
- GPU 在 Kubernetes 中是整数资源 nvidia.com/gpu: 1，request 与 limit 必须一致，调度器不支持超卖
- NVIDIA 容器运行时读取 NVIDIA_VISIBLE_DEVICES，基础 CUDA 镜像默认值为 all，未被覆盖时 Pod 可能占用整机 GPU
- GPU 利用率只表示采样窗口内有 kernel 在运行，不反映实际算力或内存带宽消耗
- NVML 可按进程给出显存占用，但驱动保留部分内存，各进程加总不等于整卡容量
- MIG 把 GPU 切成固定硬件分区，A100/H100 级别最多切 7 个实例，多数云厂商仍按整块物理 GPU 收费
本站视角
这篇文章对国内做 AI 基础设施和平台工程的团队有直接参考价值。最受影响的是那些已经在 Kubernetes 上跑推理服务、并且开始向业务方做成本分摊（chargeback）或展示（showback）的平台团队——他们很可能已经在用 DCGM 面板，却没有意识到共享 GPU 场景下的数字是错的。其次是使用 vLLM 等框架做推理部署的团队，文章点明这类框架启动时就会占走大部分显存，这会让按显存计费的方案在「谁占了多少」上产生争议。第三是采购 MIG 实例的团队，需要留意多数云厂商按整块物理 GPU 收费，切分带来的成本节省可能并不存在。 我们的判断是：这篇文章的价值不在于披露新事实，而在于把一个被普遍忽视的工程债讲清楚了。GPU 成本分摊的难点不是工具缺失，而是测量原理本身的限制——算力在并行执行时无法按进程准确归属，这是 NVIDIA 当前提供的计数器机制决定的，不是换个 exporter 就能解决的。因此文章给出的「按显存计费、算力只作信号」是一个务实而非完美的结论，值得平台团队采纳为过渡方案。 需要提醒的是，文章的成本对比只给出了 AWS 上 A100 与同规格 CPU 实例的单价，样本单一，不能直接外推到其他云厂商或 T4、H200 等其他卡型；文中提到的 22 美元/小时与 14 美元/小时也未标注具体实例类型和地域，实际采购时需自行核对。另外，文章对 DRA 的判断是「明显是方向」，但未给出具体的采用率数据，这属于作者的趋势判断而非既成事实，团队在做技术选型时不宜据此提前押注。
背景与影响
在传统 Kubernetes 运维中，CPU 和内存的资源可见性几乎是「开箱即用」的：内核按容器跟踪用量，Grafana 面板可以直接对比 request 与实际使用，按 namespace 拆分就能大致判断哪个团队在消耗多少资源，这套方法支撑了多年的容量规划和成本分摊。GPU 的引入打破了这一前提。GPU 由 NVIDIA 驱动和运行时管理，指标暴露在物理设备层面而非容器层面，Kubernetes 又把它当作不可分割的整数资源调度，两者之间存在结构性错位。文章梳理的六个「bring your own」——指标、rightsizing 计算、护栏、利用率定义、归属、共享范式——本质上都是这个错位的具体表现。这意味着，正在把推理或训练负载搬上 Kubernetes 的团队，需要额外投入工程资源去重建原本免费获得的可见性，而这些投入往往在预算规划中被低估。文章也指出这一领域正在快速变化：DRA 逐渐成熟、硬件分区更易用、工具链缺口随每个版本收窄，因此团队需要判断哪些层现在自建、哪些层等待生态补齐。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。