在很多AI团队的监控大屏上，GPU利用率常年徘徊在30%甚至更低，可训练任务却依然要排队等资源。这不是玄学，而是一种普遍存在的“测量幻觉”：GPU利用率衡量的是“计算活动”，而不是“容量是否真正可用”。一块GPU完全可以在被某个任务独占整卡的同时，报告出很低的利用率。
编者按：本文讨论的不是“买不到卡”，而是“买了卡却用不满”。后者往往更隐蔽，也更烧钱——因为扩容解决不了编排层的问题。
利用率是个会骗人的指标
nvidia-smi或DCGM报告的GPU利用率，本质上只是采样窗口内“至少有一个内核在跑”的时间占比。它不告诉你SM阵列被填满了多少、显存带宽吃掉了多少、Tensor Core是否在空转。一个正在等数据加载、等主机端预处理、被Python解释器卡住、或阻塞在集合通信上的任务，利用率可以接近于零，但它依然牢牢占着整块设备。
于是出现了两个完全不同的概念：利用率和分配率。从调度器视角看，这块卡已被100%分配；从监控面板看，它却像在“摸鱼”。两者之间的巨大缝隙，正是“自己机房里的GPU短缺”——卡并不缺，缺的是把空闲容量重新变成可调度容量。
四个看不见的瓶颈
其一，分配与占位。多数调度器以整卡为最小单位，任务一旦拿到卡就长期持有，哪怕中间大量时间在等I/O、等checkpoint、等上下游流水线。空闲不等于释放，这是队列形成的第一个原因。
其二，显存与碎片。HBM容量常常比算力更早触顶。大模型推理的KV Cache、训练时的激活值、优化器状态都会吃掉大量显存，导致“算力富余、显存告急”的错配。同时，反复申请释放造成的显存碎片，会让本可容纳的任务被拒绝。
其三，放置与拓扑。一个需要8卡同节点、位于同一NVLink域的任务，无法被8块散落在不同机器上的空闲卡满足。机架级、节点级、NVLink与NVSwitch拓扑、PCIe带宽差异，都会把物理上存在的容量切成调度器无法拼合的形状。跨节点碎片，是集群级排队最常见的隐形推手。
其四，应用层瓶颈。数据加载器太慢、tokenize占满CPU、batch size过小、推理请求串行处理、冷启动与模型加载耗时、checkpoint写入阻塞训练——这些都不是GPU的问题，却全部以“GPU闲置”的形式表现出来。一个典型例子是：单条请求逐条推理时，GPU几乎全程在等CPU准备输入。
GPU共享：几条路线的取舍
时间片轮转（Time-slicing）实现最简单，多个进程轮流使用同一设备。代价是上下文切换开销、缺乏显存隔离，且一个“吵闹的邻居”可能显著拖慢其他人。它更适合开发调试与交互式场景，而非对延迟敏感的生产推理。
MPS（Multi-Process Service）让多个进程共享同一CUDA上下文，降低切换开销、提升并发吞吐。但它隔离性较弱，一个进程的异常可能波及同卡上的其他任务。
MIG（Multi-Instance GPU）提供硬件级分区，A100/H100可切成多个具备独立显存与故障隔离的实例，安全性最好，但切分粒度固定、配置不够灵活，且并非所有型号都支持。它适合推理与中小规模任务，却无法满足需要整卡带宽的大规模训练。
虚拟化与容器化切片（vGPU/配额调度）以软件方式实现多租户与配额管理，部署灵活，但性能开销、驱动兼容性与运维复杂度需要仔细评估。
这些方案没有绝对优劣，只有与负载形态的匹配度：训练任务看重带宽与拓扑，推理服务看重隔离与弹性，开发环境看重密度与成本。
为什么“再买几张卡”不总是答案
真正的瓶颈往往不在芯片数量，而在编排层。
如果一块卡被低效任务独占12小时，扩容只是把浪费复制一遍。更有效的路径是先把度量换掉：用SM占用率、显存占用、队列等待时长与有效吞吐（goodput）替代单一的“利用率”指标；再建立按时间、按拓扑维度呈现的“可用容量视图”，让调度器看得见真正的空闲。
同时引入配额与优先级队列、gang scheduling（成组调度）、checkpoint与抢占式调度，让低优先级任务可以被安全中断并让出整卡；对推理侧则通过批处理、连续批处理与KV Cache复用，把“等CPU”的时间填满。行业里已有大量案例表明，在不增加一张卡的前提下，仅靠调度与共享策略优化，就能把集群有效吞吐提升数成。
给团队的一份落地清单
第一，区分利用率与分配率，把两者同时纳入监控。第二，统计“因拓扑无法拼合”而失败的调度请求占比。第三，为不同负载定义SLO，再据此选择共享方案。第四，对长时间低效占卡的任务设置提醒与回收策略。第五，把冷启动、数据加载、checkpoint等非GPU环节当作一等优化对象。
GPU短缺有两种：一种是买不到，一种是买到了却用不起来。前者靠预算解决，后者靠工程能力解决。而在算力成本高企的当下，后者的回报率往往更高。
本文编译自AI News
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接