Kubernetes 上的 GPU 是自带一切，从账单开始
内容提要
在Kubernetes中，GPU成本最高但最难按工作负载分摊。DCGM默认按物理设备上报，共享GPU时各Pod数据重复，无法准确归因。GPU按整数分配、不支持超卖，利用率指标也易误导。目前最可靠的是按显存计费，计算量仅作参考。共享方式包括时间切片、MPS、MIG和DRA，各有局限。
延伸解读
共享GPU时指标重复的陷阱
文章指出，DCGM导出器默认按物理设备上报指标，当多个Pod共享GPU时，每个Pod都会看到相同的整卡数据。例如三个Pod共享一块GPU，每个都显示使用了整块GPU，汇总后得到300%的虚假利用率。这种错误数据在图表上看似正常，却会误导容量规划和成本分摊，团队需警惕基于错误指标构建的仪表盘。
GPU资源模型的特殊性
与CPU和内存不同，GPU在Kubernetes中以整数资源请求，且请求与限制必须相等，调度器不支持超卖。这意味着CPU场景中常见的资源超配、突发和回收闲置资源等做法在GPU上几乎不可行。共享GPU需依赖时间切片或MIG等底层机制，但Kubernetes的请求模型无法精确匹配，导致资源合理配置的前提难以成立。
利用率指标的误导性
GPU利用率通常只表示采样窗口内有内核在运行，并不反映实际计算量或内存带宽消耗。文章举例，GPU可能显示100%利用率但计算几乎空闲，而内存往往先成为瓶颈，因为vLLM等框架启动时会占用大量显存。因此，团队应尽早确定对自身工作负载有意义的信号，如计算占用、内存占用、带宽或功耗，避免依赖单一利用率数字做出错误判断。
按显存计费的现实选择
由于计算量无法在共享GPU时准确归因，文章建议按显存进行计费，因为NVML能提供每个进程的显存占用，并可追溯到Pod和团队。显存数据可靠，但需注意驱动自身保留部分显存，导致总和略低于卡的总量。计算量只能作为参考信号，用于驱动成本分摊。在需要公平分摊成本的场景下，显存是目前最准确的归因依据。
Q&A
为什么在Kubernetes中GPU成本难以按工作负载分摊？
因为GPU是账单上最贵的项目，但Kubernetes和内核没有像CPU/内存那样提供按容器的使用跟踪。DCGM默认按物理设备上报，共享GPU时每个Pod看到相同数据，无法准确归因。
DCGM exporter在共享GPU时有什么问题？
DCGM默认按物理设备级别上报。当多个Pod共享一个GPU（如时间切片或MPS）时，每个Pod都会看到相同的整卡使用值，导致数据重复，总和可能超过100%，无法区分各工作负载的实际消耗。
Kubernetes中GPU资源分配与CPU/内存有何不同？
GPU以整数形式分配（如nvidia.com/gpu: 1），请求和限制必须相等，调度器不支持超卖。而CPU/内存支持毫核、超卖、突发等，GPU缺乏这些灵活性，使得基本的资源合理配置难以实现。
为什么GPU利用率指标可能误导？
GPU利用率仅表示在采样窗口内有内核运行，并不反映实际计算或内存带宽消耗。GPU可能显示100%利用率但计算量很低，且内存常先耗尽（如vLLM启动时占用大量显存）。依赖此指标可能导致错误结论。
目前最可靠的GPU计费依据是什么？
按显存计费最可靠。NVML库可提供每个进程的显存占用，并能追溯到Pod和团队，数据可靠（但总和略小于卡总容量，因驱动保留部分）。计算量仅作为参考信号，不用于精确计费。
共享GPU有哪些方式？各有什么局限？
共享方式包括：时间切片（轮询，无隔离，可超卖）、MPS（内核并发，无隔离）、MIG（硬件分区，但云厂商仍按整卡收费，A100/H100最多7实例）、DRA（动态资源分配，生态仍在成熟）。每种方式都改变“已分配”的含义，影响可见性。
