Cast AI 2026年报告统计数万个生产集群从 2025 年 1 月到 2026 年 4 月的平均GPU计算利用率为 5%；但该媒体指出，低利用率不等于可用容量，Kubernetes默认把整块GPU独占分配给一个Pod，时间切片、MIG、MPS的隔离与硬件要求各不相同。
AI解读：这条内容来自AI News，核心观点并不复杂：GPU利用率这个指标很容易被误读。仪表盘上的百分比反映的是计算活动，不是这块卡还能不能接活。一块卡可以只跑 5% 的SM，同时被一个推理服务整块占着，Kubernetes不会往上面再排任何东西。
文章把“旁边看着闲、任务却在排队”的原因拆成四类：整卡独占、显存被占满、调度约束刷掉可用硬件、以及运行中的负载卡在CPU预处理或I/O上。只有第一类能靠GPU共享解决。先跑kubectl看分配状态，再跑nvidia-smi看显存，顺序错了就会买错卡或者配错方案。
Cast AI的报告给了一个抓眼球的数字：2025 年 1 月至 2026 年 4 月间数万个生产集群平均GPU计算利用率为 5%。但文章明确提醒，别把这条数据直接当成“95% 的算力可以马上回收”，每个集群甚至每块卡都需要单独排查。报告博客还提到一个集群在 136 块H200上维持了 49% 利用率，差距被归因于使用技巧而非硬件。
三种共享方法各有代价：时间切片在任意NVIDIA GPU上可用，但副本之间没有显存和故障隔离；MIG提供硬件隔离的内存路径，最多把一块卡切成 7 个实例，但只支持Ampere及更新的架构，实例之间也不支持NVLink；MPS让多个CUDA进程同时跑在同一批SM上，带SM分区的版本从CUDA 11.0起提供，Cast AI的MPS目前只在GCP GKE上可用，AWS和Azure仍在路线图里。
对真正受影响的人——管推理集群的工程师和平台团队——最有用的信息是诊断顺序：先看节点上nvidia.com/gpu的可分配数量，再用nvidia-smi对照used memory与total memory，然后用kubectl describe pod查MatchNodeSelector、InsufficientResource、TaintToleration这类事件，最后用nvidia-smi dmon或DCGM看 %SM随时间的变化。
前两步能区分分配瓶颈与显存瓶颈，后两步能区分调度配置问题和应用层阻塞。
AI News发表一篇产品向技术文章，主题是GPU短缺问题有时发生在用户自己的基础设施内部：监控显示利用率很低的GPU，实际上可能已经被整块分配，新工作负载只能在队列里等。
文章引用的一个研究钩子来自Cast AI的《2026 Kubernetes优化报告》。该报告分析了 2025 年 1 月至 2026 年 4 月期间数万个生产集群，记录到的优化前平均GPU计算利用率为 5%。文章同时援引Cast AI的报告博客称，数据集中有一个集群在 136 块H200上维持了 49% 的GPU利用率，差距“几乎完全归因于使用技巧而非硬件”。
AI News强调，5% 的平均值反映的是整个机群普遍存在的过度配置与使用不足，但不意味着 95% 的容量可以立刻接收新工作负载；每个集群、每块GPU都要单独诊断后才能下这个结论。文章还明确说明，不应暗示排队的工作负载与看似闲置的GPU出现在同一测量环境中。
四种GPU利用率指标的区别
文章指出，“GPU利用率”至少涵盖四种不同测量，混用会直接导致误诊。多数仪表盘展示的是计算利用率，即某个时间窗口内处于活动状态的流处理器（SM）百分比。
该指标只说明硅片运行时有多忙，不说明设备是否可分配给新工作负载。一个模型加载进显存后会持续占用显存：推理服务可能每分钟只处理一个请求，计算活动维持在 5%，但设备已被分配、内存已被占用，Kubernetes不会再往上面调度别的东西。
- 计算活动（%SM）：测量采样窗口内活动的SM占比；不显示GPU是否已被分配、显存是否可供其他负载使用。
- 显存占用（VRAM）：测量已加载模型和张量消耗的GPU内存；不显示计算活动，也不显示排队负载能否放进剩余内存。
- 队列等待时间（Pod调度）：测量待处理Pod等待GPU设备可用的时长；不显示延迟来自分配、内存、放置规则还是应用瓶颈。
- 吞吐/延迟：测量每秒请求数、首token时间或端到端响应时间；不显示GPU资源利用率或分配效率。
工作负载为何在看似闲置的GPU旁排队
Kubernetes调度器把GPU视为“可用”或“不可用”两种状态，判断依据是节点上的nvidia.com/gpu资源计数，而不是硅片的活动百分比。文章列出四种会产生排队的情况，其中只有一种能靠GPU共享解决。
NVIDIA Kubernetes设备插件默认按独占方式分配GPU。当Pod申请nvidia.com/gpu: 1 时，它在整个生命周期内获得一块物理设备的唯一所有权。占用负载实际消耗多少计算或内存并不影响这一规则。文章称这是推理集群中“排队在旁边闲置”模式最常见的原因：一组各自独占一块GPU、只服务突发或低频请求的模型，会让每块设备都处于已分配状态；新负载发现节点上nvidia.com/gpu为 0，只能等待，即使节点整体计算活动可能低于 10%。
文章还指出，设备插件关注的是分配而非回收。Kubernetes集群自动扩缩器可以创建新节点，但不会回收现有节点上的闲置容量。问题出在调度层，解法需要改变设备呈现给调度器的方式。
第二类原因是显存被占用，而不只是利用不充分。文章给出两个场景：70B参数模型以FP16加载约消耗 140 GB显存（仅基础权重；4K上下文长度下KV缓存会在基础权重之上增加 15%–20%，128K上下文长度下KV缓存需求可能超过基础权重本身），需要两块以上A100 80GB才能加载；13B FP16模型约占 26 GB，可放进单块A100 80GB，但仍持续占用该显存。计算活动可能显示 8%，设备却无法接收另一个工作负载。
文章建议在配置共享之前先检查量化是否适用：INT4量化的 7B模型约占 4 GB，FP16约 14 GB，这会改变时间切片和MIG配置的共置算术；INT8相对FP16大约把需求减半，对推理负载通常有可接受的质量取舍。
这对考虑时间切片的团队尤其重要：时间切片在计算访问上做多路复用，但不划分显存，所有副本共享同一段VRAM地址空间；两个负载合计超过设备内存时无法安全共存。先用nvidia-smi检查显存占用，如果相关设备的空闲内存列接近零，约束就是VRAM容量而非计算调度。MIG提供硬件隔离的内存分区，可以解决其中某些版本的问题，但需要兼容硬件并改变工作负载的调度方式。
第三类原因是放置规则排除了本来可用的硬件。节点亲和性指定GPU型号或代际、拓扑分布约束要求最少节点数、以及没有匹配容忍度的污点，都可能在工作负载层面阻止调度，即使原始设备计数看起来够用。申请nvidia.com/gpu: 1 并带A100节点选择器的工作负载，不会落到只有H100的节点上，即便那些H100空闲且有能力。诊断命令是kubectl describe pod，查看Events中类似MatchNodeSelector、InsufficientResource或TaintToleration的原因。放置失败常常看起来像容量短缺，但应通过调度配置解决，而不是采购硬件。
第四类原因是运行中的工作负载在等别的东西。GPU计算会在CPU预处理、数据加载、PCIe传输和网络往返期间闲置。一个等待缓慢分词步骤或从远程存储取KV缓存的LLM推理服务器会显示低 %SM活动，但该GPU并不能为其他负载的推理请求所用，它被阻塞在另一层。文章称这类最难只凭GPU指标诊断：一个已被调度并处于活动状态的工作负载若持续低计算，通常意味着瓶颈在GPU之外，增加GPU数量无济于事，修复手段包括提高CPU资源、调整批处理配置、改善存储延迟或重新设计数据管道。
文章建议用nvidia-smi dmon或DCGM指标观察计算利用率随时间的变化：在短周期内于 0% 和高计算之间循环的负载，很可能在 0% 期间受CPU制约；持续低计算却在积极接收请求的负载，则可能在等I/O或网络。这两种模式都不同于分配短缺，需要不同的补救措施。
- 独占整卡：设备插件默认按整卡分配给单个Pod，占用方不管用多少，其他Pod都无法使用。
- 显存占满：低计算活动不代表显存可用；量化可以降低显存需求，从而改变共置可行性。
- 放置约束：节点亲和性、拓扑分布、污点与容忍度会排除可用硬件，表现为容量短缺。
- 应用阻塞：CPU预处理、数据加载、PCIe、网络或KV缓存延迟会让GPU空转，增加GPU无用。
四种分配模式的取舍对比
文章比较了Kubernetes中四种GPU工作负载分配模式，称每种解决的是共享问题的不同版本，也各自带有决定其是否适配给定工作负载的约束，没有一种普遍正确。
时间切片在任何NVIDIA GPU上可用，包括不支持MIG的较老代际如T4和V100。NVIDIA GPU Operator的时间切片文档明确指出副本之间没有内存或故障隔离：一个耗尽VRAM或令CUDA上下文崩溃的工作负载，会影响同一设备上所有共置负载。这一约束把时间切片限制在合计内存占用能舒适放进设备VRAM的工作负载范围内。
MIG在三种共享方法中提供最强隔离保证。每个分区有物理上分离的内存系统路径，包括片上交叉开关端口、L2缓存组、内存控制器和DRAM地址总线，一个实例的缓存抖动不会影响另一个实例的延迟。NVIDIA MIG用户指南记录每块物理GPU最多 7 个实例，使用固定规格定义每个分区的计算与内存分配，这些规格在运行时不能动态调整，因此分区决策在配置时作出。文章特别提醒，MIG实例之间不支持NVLink，依赖GPU间高带宽通信的多卡训练任务不应把MIG当作这些工作负载的直接替代共享方案。
MPS与前两者不同：时间切片在不同CUDA上下文之间随时间切换，MPS让多个CUDA进程同时在同一批SM上执行。NVIDIA MPS文档把该架构描述为一个轻量级运行时，包括控制守护进程、服务器进程和内置在libcuda.so中的客户端库。从CUDA 11.0起提供的带SM分区的MPS可按命名空间配置SM和内存分区，在不要求MIG兼容硬件的情况下给管理员比基础时间切片更多的隔离；Volta及更新架构增加进程级故障隔离；物理内存在所有MPS配置中仍然共享。
文章还提到Cast AI支持把MIG与时间切片组合使用：一块A100分成 7 个MIG实例，每个实例再配置 4 个时间切片副本，就能向Kubernetes调度器呈现 28 个逻辑GPU槽位。文章称这是高密度配置，部署前需要仔细的工作负载画像，但这个算术说明了共享方法选择与硬件采购同等重要。
- 独占分配：全隔离、任意NVIDIA GPU可用；适合大模型、多卡训练、需要完整设备带宽的延迟敏感推理；代价是没有共享、间歇性负载浪费容量。
- 时间切片：时间多路复用，N个副本共享一块物理GPU；无内存或故障隔离；DCGM-Exporter无法把指标归因到容器；适合小模型、间歇推理、需求波动的批处理任务。
- MIG：硬件分区，每块物理GPU最多 7 个实例；有硬件隔离内存路径；仅支持Ampere及更新架构（A100、A30、H100、H200、Blackwell B200/GB200），T4、V100、A10不可用；规格固定不可动态调整，实例间不支持NVLink。
- MPS：多个CUDA进程并发共享SM；基础配置无内存隔离，带SM分区的版本从CUDA 11.0起提供，Volta及更新增加进程级故障隔离，物理内存仍共享；Cast AI MPS目前仅在GCP GKE可用，AWS和Azure支持在路线图上。
诊断顺序与一个Kubernetes示例场景
文章给出的诊断顺序按最简到最复杂排列，找到约束就停止，后续步骤只会增加噪音。第一步用kubectl检查各节点的分配状态：如果所有节点显示 0 个可用GPU且工作负载在排队，属于分配短缺，GPU共享是相关解法类别；如果部分节点显示有空闲GPU槽位而工作负载仍在排队，跳到第三步检查放置约束。
第二步在计算活动低但设备已被完全分配的节点上运行nvidia-smi，把每块设备的已用内存与总内存对比。低 %SM加上接近零的空闲内存，说明约束是VRAM而不是计算；此时时间切片帮不上忙，内存分区（MIG，或带SM分区的MPS）才是相关路径，前提是硬件和云厂商兼容。第三步用kubectl describe pod检查待处理Pod的事件，查找MatchNodeSelector、InsufficientResource或TaintToleration；如果放置规则挡住了本可落地的GPU，修复在调度配置而非硬件采购。第四步用nvidia-smi dmon -s u或DCGM指标在代表性请求周期内采集时间序列，判断负载是受CPU制约还是在等I/O或网络。第五步核实目标共享方法的硬件与云厂商兼容性。
文章还构造了一个说明分配问题的假设场景，并说明它不代表任何具体集群的实测性能：一个节点有 4 块GPU，每块独占给一个推理服务，每个服务处理突发学生查询，高峰计算活动 15%，非高峰低于 3%。第五个推理服务部署后进入Pending，调度器发现节点上nvidia.com/gpu为 0，于是排队。
若改为时间切片（每块GPU 4个副本），每块GPU向调度器呈现 4 个槽位而不是 1 个，第五个服务可以调度，但能否放入取决于VRAM是否够用。文章明确写道，切换到时间切片不保证任何特定吞吐提升；它改变的是从调度器视角看的设备可用性。总延迟是改善还是变差，取决于各服务请求重叠频率、每个模型占用的VRAM，以及是否有模型的SM活动呈突发性从而在高峰窗口产生争用，唯一知道答案的方法是针对具体负载组合进行测试。
文章最后称Cast AI支持全部三种共享方法，带自动装箱，且不需要修改工作负载清单。
- 先查分配：kubectl get nodes查看nvidia.com/gpu可分配数量，全为 0 且有排队即分配短缺。
- 再查显存：nvidia-smi对比used memory与total memory；低 %SM加近零空闲内存意味着VRAM限制而非计算限制。
- 三查放置：kubectl describe pod查看MatchNodeSelector、InsufficientResource、TaintToleration。
- 四查时间序列：nvidia-smi dmon或DCGM区分CPU制约、I/O或网络等待。
- 五查兼容性：确认目标共享方法所需的硬件代际与云厂商支持。