GPU利用率不足30%：预留资源闲置的破局之道

一个健康科技公司的真实困境

在Reddit的机器学习社区，一位健康科技公司的ML平台工程师分享了一个让许多团队感同身受的问题：当他为一次容量审查拉取GPU利用率数据时，结果令人震惊——平均利用率不足30%。

换句话说，公司为整个预留GPU池付费，实际却只用到不到三分之一的算力。这不是个例，而是当下许多企业AI基础设施的普遍写照。根据多项行业调研，企业级GPU集群的平均利用率通常在15%-40%之间徘徊。这与CPU服务器的利用率模式截然不同——CPU工作负载通常是持续性的（如Web服务），而GPU工作负载往往是突发性的（如模型训练、推理批处理）。企业为了应对峰值需求而预留的GPU容量，在非峰值时段必然存在大量闲置。加之NVIDIA A100、H100等数据中心GPU单卡成本高达数万美元，云端预留实例年费用同样不菲，即便是10%的利用率提升也意味着数十万美元的节省。

"We pay for all of it and use less than a third."（我们为全部资源付费，却只用了不到三分之一。）

GPU闲置的三种形态

作者在深入排查后，发现闲置的GPU大致分为三类，每一类背后都藏着不同的管理盲点：

• 合理的待命型：少数机器每天跑几次批处理任务，必须保持随时可用状态。这部分闲置是业务特性决定的，无可厚非。
• 纯粹的浪费型：剩下的GPU就是单纯地空转，没有任何任务在运行。
• 僵尸占用型：最典型的是两台机器被人打开的Jupyter Notebook长期占用，其中一台竟然挂了好几周。若不是作者主动去挖，根本无人察觉。

这种"开了Notebook就走人"的现象，几乎是所有共享GPU集群的通病——研究人员习惯性地占坑，却忘了释放。这一问题的技术根源在于Jupyter Notebook的架构设计：当用户启动一个Notebook并请求GPU资源时，底层的Kernel进程会持有GPU显存分配，即便用户关闭了浏览器标签页，Kernel依然在后台运行并锁定GPU。在Kubernetes环境中，这表现为Pod持续运行且占用GPU资源配额；在Slurm集群中，则表现为作业保持RUNNING状态。更棘手的是，许多深度学习框架（如PyTorch、TensorFlow）在初始化时会预分配大块显存，即使没有任何计算在进行，nvidia-smi显示的显存占用率也可能很高，给监控系统造成"正在使用"的假象。

财务与研究团队的GPU资源拉锯战

这个问题真正棘手的地方，不在于技术，而在于组织内部的利益冲突。

财务视角：GPU账单为何如此高昂

财务部门反复追问：预留费用为什么这么大？这是完全合理的质疑。当一个资源池的利用率长期低于30%，从成本核算的角度看，这就是明显的浪费。对于健康科技这类需要严控合规成本的行业，任何不透明的大额支出都会引发关注。

值得注意的是，健康科技行业的GPU基础设施还面临额外的合规约束。在涉及患者数据的AI模型训练中，HIPAA（美国健康保险可移植性和责任法案）等法规要求数据不得离开特定安全边界，这意味着企业不能随意将工作负载迁移到公有云的Spot实例或按需实例上以降低成本。预留的GPU可能部署在通过合规审计的特定数据中心或VPC中，使得"用完即释放、按需重新获取"的弹性模式在实践中受到限制，进一步加剧了预留资源闲置的问题。这也解释了为什么财务部门会格外关注——这些预留资源的成本是刚性的，且几乎没有灵活调整的空间。

研究视角：GPU闲置是为了不排队

但当作者把问题抛给研究人员时，得到的回应同样有道理：

"If the GPUs aren't free their experiments queue and they lose time."（如果GPU不空闲，他们的实验就得排队，浪费的是研究时间。）

对研究团队而言，宁可让GPU"备着"，也不愿意在需要时排长队等待。实验的迭代速度直接影响研究进展，等待就是成本。在现代深度学习研究中，一轮超参数搜索可能需要同时启动数十个实验变体，模型训练的反馈周期可能从几分钟到几天不等——如果每次都需要排队等待GPU分配，研究人员的工作流就会被严重打断，认知上的"上下文切换"成本远超表面的等待时间。

死循环：问题在两方之间反复弹跳

于是问题就卡在了这里——"it bounces between the two and nothing changes"（在两方之间来回弹跳，什么都没改变）。财务觉得贵，研究觉得不够用，双方都站在自己的立场上，谁也说服不了谁，最终陷入僵局。

真正的技术盲点：GPU资源可见性缺失

作者点出了问题的核心：他可以从**DCGM（NVIDIA Data Center GPU Manager）**拉取每个节点的利用率数据，但他做不到的是——

"Tie an idle card back to who reserved it and whether they still need it."（把一张闲置的显卡，关联到是谁预留的、以及他们是否还需要它。）

DCGM是NVIDIA官方提供的数据中心GPU管理工具套件，能够实时采集GPU的底层指标，包括SM（Streaming Multiprocessor）利用率、显存占用率、功耗、温度、PCIe带宽利用率、NVLink流量等。DCGM通常与Prometheus等监控系统集成，将指标暴露为可查询的时间序列数据。然而DCGM的设计定位是硬件级监控——它只能告诉你物理层面发生了什么，却无法感知上层的调度逻辑、用户身份和业务意图。这正是作者所说的"有利用率指标，没有资源归属"的技术根源。

这句话道破了大多数GPU成本优化失败的根本原因。

有利用率指标，没有资源归属

利用率数据只能告诉你"哪张卡在闲置"，却无法回答三个更关键的问题：

1. 谁预留了这张卡？
2. 他还需不需要？
3. 这个闲置是临时的（等着跑下一轮）还是永久的（早该释放）？

没有这层归属和意图的映射，运维团队就无法做出安全的回收决策。贸然回收可能中断某个正在等待的关键实验；放任不管则继续烧钱。

当前主流的GPU集群调度系统——无论是面向云原生的Kubernetes还是面向HPC的Slurm——在这方面都存在先天不足。Kubernetes通过Device Plugin机制将GPU暴露为可调度资源，Pod请求GPU后独占该资源直到Pod被销毁。Slurm则通过GRES（Generic Resource）系统管理GPU分配。两者的共同问题是：资源一旦被分配，系统默认会一直持有，不会主动检查使用者是否仍然活跃。调度器知道"GPU分配给了哪个Pod/Job"，但不知道"这个Pod/Job是否还在有效利用GPU"——而这恰恰是回收决策所需要的关键信息。

如何判断一张预留GPU可以安全回收？

作者最后抛出的问题极具代表性：How do you decide when a reserved GPU is safe to give back?（你如何判断一张预留的GPU可以安全归还？）结合业界实践，可以从以下几个方向着手。

建立GPU资源归属与标签体系

仅有DCGM的节点级指标远远不够。需要在调度层（如Kubernetes、Slurm或云平台的资源标签）为每一块GPU打上归属标签：预留人、团队、项目、预期使用周期。只有把"闲置的卡"和"具体的人"绑定，对话才能从抽象的账单争论，转向具体的资源问责。

在实践中，这意味着需要构建一个跨越监控层（DCGM/Prometheus）、调度层（Kubernetes/Slurm）和业务层（项目管理系统）的统一数据模型。例如，通过Kubernetes的Label和Annotation机制为每个GPU Pod标注owner、team、project、expected-duration等元数据，再将这些信息与DCGM的硬件指标在Grafana等可视化平台上关联展示。

设定GPU空闲超时与自动回收策略

针对"僵尸Notebook"这类最典型的浪费，应设置空闲超时机制：

• Notebook或交互式会话在N小时无GPU活动后，自动发出提醒；
• 超过阈值（如挂起数天）自动挂起或释放；
• 对批处理待命型机器单独标记，排除在自动回收之外。

这类策略能把"挂了几周"的极端情况扼杀在萌芽状态。JupyterHub等平台已经提供了Culler（空闲回收器）功能，可以根据Kernel最后活动时间自动关闭长期不活跃的Notebook Server。更进一步，可以结合DCGM的GPU利用率指标——如果SM利用率和显存带宽利用率连续N小时为零，则触发回收流程，而不仅仅依赖Notebook的交互活动。

引入弹性调度与GPU抢占机制

研究团队担心排队，本质上是对"资源不可预期"的恐惧。解决之道不是无限预留，而是建立优先级抢占与快速调度：低优先级的空闲任务可被高优先级任务抢占，同时保证高优先级请求能在可接受时间内拿到资源。这样既提升整体利用率，又缓解研究人员对排队的焦虑。

GPU抢占机制借鉴了操作系统进程调度的思想。在Kubernetes中，PriorityClass可以为不同工作负载设定优先级，当高优先级Pod无法调度时，调度器会驱逐低优先级Pod释放资源。在Slurm中，类似功能通过QOS（Quality of Service）和Preemption策略实现。然而GPU工作负载的抢占比CPU复杂得多：一个训练了数小时的模型如果被抢占，需要依赖Checkpoint机制才能恢复进度，否则所有计算将前功尽弃。因此成熟的GPU抢占方案通常结合弹性训练框架（如PyTorch Elastic、Horovod Elastic），支持任务的优雅暂停与透明恢复——被抢占的任务自动保存Checkpoint，待资源可用时从断点继续，而非从头开始。近年来NVIDIA的Run:ai、Google的DWS（Dynamic Workload Scheduler）等平台都在这一方向进行了深度优化。

用数据重构财务与研究的对话

当GPU利用率能够精确归因到人和项目时，财务与研究的死循环就有了破解钥匙。可以把"预留但闲置"的成本明确核算到具体团队，用透明的数据让每个团队为自己的资源负责，而不是让平台工程师在中间反复背锅。

这种模式在业界被称为"Showback"或"Chargeback"。Showback是将资源消耗数据透明展示给各团队，让他们了解自己的使用模式；Chargeback则更进一步，将实际成本按照使用量或预留量分摊计入各团队的预算。实践表明，即便只是实施Showback（展示但不计费），许多团队在看到自己的闲置成本数据后，就会主动释放不需要的资源——因为数据让浪费变得"可见"且"有名有姓"。

结语：GPU利用率问题本质是治理问题

这位工程师的困境，浓缩了当下企业AI基础设施的普遍矛盾：算力越来越贵，但闲置率居高不下；技术上能看到问题，组织上却难以推动改变。

真正的GPU成本优化，从来不只是买更少的卡或压榨更高的利用率，而是建立一套可见、可归因、可自动化的资源治理体系。当每一张显卡的使用都能追溯到人、追溯到意图时，财务的质疑和研究的诉求才能在同一张数据表上达成和解。

从更宏观的视角来看，GPU资源治理正在经历与十年前云计算成本管理相似的演进路径。当企业刚开始使用AWS时，也曾面临EC2实例大量闲置、账单失控的问题，直到FinOps（财务运营）这一学科的兴起，通过标签体系、成本归因、自动化策略等最佳实践逐步解决。如今，GPU作为远比CPU更昂贵的资源，正在催生"GPU FinOps"这一新领域——将FinOps的方法论适配到GPU工作负载的特殊性上，包括突发性使用模式、Checkpoint恢复机制、以及多租户公平性保障等。

对于任何正在为高昂GPU账单发愁的团队来说，第一步或许不是砍预算，而是先回答那个最朴素的问题：这张闲置的卡，究竟是谁的，他还需要吗？