核心要点

利用率误区：GPU 计算利用率仅反映硅片忙碌程度，不代表设备可用性或内存状态。5% 的利用率可能意味着设备已被完全占用。

独占机制：Kubernetes 默认将整块 GPU 独占分配给 Pod。即使工作负载空闲，其他任务也无法使用该设备。

排队根源：看似空闲 GPU 旁出现排队，通常源于独占分配、内存耗尽、放置约束或应用层瓶颈，仅第一种可通过 GPU 共享解决。

技术权衡：时间片共享、MIG 和 MPS 在内存隔离、硬件要求及可观测性上各有优劣，无万能方案。

诊断逻辑：须按 " 分配状态→内存占用→放置约束→应用瓶颈 " 顺序排查，严禁跳跃。

自动化支持：Cast AI 支持上述三种共享方法，具备自动装箱能力，且无需修改工作负载清单。

GPU 利用率的真相与盲区

"GPU 利用率 " 常被混用于指代至少四种不同指标，这是导致运维误诊的主因。大多数仪表盘显示的 " 计算利用率 "，即给定时间内活跃流式多处理器（SM）的百分比。该数据仅表明芯片繁忙程度，无法反映设备是否可接纳新工作负载。

加载至 VRAM 的模型会持续占用内存。例如，推理服务可能每分钟仅处理一个请求，计算活动维持在 5%，但设备已被分配且内存被占用。此时，Kubernetes 调度器视该 GPU 为 " 不可用 "，而监控面板却显示其近乎 " 空闲 "。

下表厘清了四项常被归为 "GPU 利用率 " 的指标及其实际含义：

指标	测量内容	指示内容	不指示内容
计算利用率 ( %SM )	活跃 SM 百分比	芯片忙碌程度	设备可用性、内存占用或分配状态
内存利用率	已用 VRAM 量	模型权重和 KV 缓存占用空间	计算能力是否闲置
分配状态	nvidia.com/gpu 资源计数	调度器眼中的设备可用性	设备内部实际使用情况
请求吞吐量	每秒处理请求数	工作负载活跃水平	底层硬件资源竞争情况

Cast AI 发布的《2026 年 Kubernetes 优化报告》分析了 2025 年 1 月至 2026 年 4 月期间数万个工作集群。数据显示，在未优化前，平均 GPU 计算利用率仅为 5%。尽管某集群在 136 个 H200 GPU 上保持了 49% 的利用率，但这属于特例。5% 的平均值反映了集群范围内普遍存在的过度配置和利用不足。然而，这并不意味着 95% 的容量可立即回收。每块 GPU 均需独立诊断，方可确定其真实状态。

工作负载为何在 " 空闲 "GPU 旁排队？四大成因

Kubernetes 调度器基于节点上的 nvidia.com/gpu 资源计数判断 GPU 是否 " 可用 "，而非依据芯片活动百分比。即便计算活动低迷，以下四种情况仍会导致队列堆积。

1. 工作负载独占整个设备

NVIDIA Kubernetes Device Plugin 默认采用独占分配模式。当 Pod 请求 nvidia.com/gpu: 1 时，即在生命周期内获得物理设备的独家所有权。无论该负载实际消耗多少资源，其他 Pod 均无法介入。

这是推理集群中 " 排队伴随空闲 " 现象的最常见成因。一组模型各自持有专用 GPU，虽仅服务于低频请求，导致设备计算活动低于 10%，但新工作负载因检测到 nvidia.com/gpu: 0 可用而被迫等待。Kubernetes 集群自动扩缩容器可新增节点，却无法回收现有节点的空闲容量。解决此问题需改变设备向调度器呈现的方式，即引入 GPU 共享机制。

2. 内存被占用，而非未充分利用

低计算利用率不等于内存可用。例如，一个 70B 参数的 FP16 模型仅权重便需约 140GB VRAM，若加上 KV 缓存，需求更高，至少需两块 A100 80GB GPU。即便是一个 13B FP16 模型（约占 26GB），虽可放入单块 A100，但其持续占用 VRAM。此时计算利用率可能仅报 8%，但设备已无法接纳新负载。

在配置共享前，务必检查量化策略。INT4 量化的 7B 模型仅需约 4GB，远低于 FP16 版本的 14GB。若总内存需求超出设备容量，时间片共享将导致部署失败或不稳定，因其复用计算权限但不划分内存。

建议先通过 nvidia-smi 检查内存占用。若空闲内存接近零，瓶颈在于 VRAM 容量而非计算调度。此时，提供硬件隔离内存分区的 MIG 可能是更优解，但需兼容硬件并调整调度方式。

3. 放置规则排除可用硬件

调度失败有时并非因 GPU 全部分配，而是因节点亲和性、拓扑分布约束或污点容忍度等放置规则限制。例如，指定需要 A100 的请求不会落在空闲的 H100 节点上；若工作负载请求的时间片副本数超过单节点供给且不跨节点分布，即便集群总容量充足，调度也会失败。

诊断此类问题需运行 kubectl describe pod <pending-pod>，查看 Events 部分是否有 MatchNodeSelector、InsufficientResource 或 TaintToleration 等错误。此类故障需通过调整调度配置解决，而非采购硬件。

4. 运行中的工作负载受外部阻塞

低计算读数也可能源于 GPU 外部的瓶颈，如 CPU 预处理、数据加载、PCIe 传输或网络往返。等待慢速分词或远程 KV 缓存的 LLM 推理服务器，其 %SM 活动虽低，但 GPU 并未空闲，而是在不同层级被阻塞。

若工作负载在短突发间于 0% 和高计算值间循环，可能受 CPU 限制；若持续接收请求却保持低计算，则可能受 I/O 或网络限制。增加 GPU 数量对此类问题无效，需优化 CPU 资源、批处理配置或数据管道。

Kubernetes GPU 分配实例解析

假设一个四 GPU 节点，每个 GPU 独占分配给一个推理服务。各服务处理突发查询，峰值计算活动 15%，非高峰低于 3%。当第五个服务部署时，因节点显示 nvidia.com/gpu: 0 可用而进入 Pending 状态。

启用时间片共享后，每个 GPU 可向调度器广告四个槽位，使第五个服务得以调度。但总延迟是否改善，取决于请求重叠频率、VRAM 占用及突发 SM 活动竞争情况。唯一确定答案的方法是进行测试。

专用 GPU、时间片共享、MIG 与 MPS 对比

Kubernetes 中存在四种 GPU 分配模型，各有适用场景与限制：

时间片共享：适用于所有 NVIDIA GPU（包括 T4、V100 等旧世代）。副本间无内存或故障隔离，VRAM 耗尽或 CUDA 上下文崩溃会影响同设备所有负载。仅适用于内存足迹 comfortably 适应设备 VRAM 的场景。

MIG ( Multi-Instance GPU ) ：提供最强隔离保证。每个分区拥有物理分离的内存路径（交叉开关、L2 缓存、内存控制器等）。A100 等 Ampere 架构 GPU 最多支持七个实例。缺点是配置文件固定，运行时不可动态调整，且实例间不支持 NVLink，不适用于依赖高带宽通信的多 GPU 训练作业。

MPS ( Multi-Process Service ) ：允许多个 CUDA 进程并发执行。结合 SM 分区（CUDA 11.0+），可提供比时间片共享更多的隔离，且无需 MIG 兼容硬件。Volta 及以上架构支持进程级故障隔离，但物理内存仍共享。

Cast AI 支持混合使用 MIG 和时间片共享。例如，将单个 A100 划分为七个 MIG 实例，每个实例配置四个时间片副本，从而向 Kubernetes 呈现 28 个逻辑 GPU 槽位。这种高密度配置需在部署前进行详尽的工作负载分析。

购买更多 GPU 前的诊断步骤

请按以下顺序排查瓶颈，找到活跃约束后即止：

步骤 1：检查节点间分配状态

运行：kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.'nvidia.com/gpu'

若所有节点可用 GPU 为 0 且负载排队，存在分配短缺，GPU 共享是潜在方案。若有可用槽位仍排队，转入步骤 3。

步骤 2：检查已分配设备的内存占用

在低计算活动但完全分配的节点上运行 nvidia-smi。若空闲内存接近零，瓶颈为 VRAM。时间片共享无效，需考虑 MIG 或带 SM 分区的 MPS。

步骤 3：检查待处理 Pod 的放置故障

运行：kubectl describe pod <pending-pod-name>

查找 Events 中的调度失败原因。若因放置规则导致，需调整调度配置。

步骤 4：观察运行负载的计算活动

使用 nvidia-smi dmon -s u 或 DCGM 指标收集时间序列。若 %SM 在 0 和高值间循环，可能受 CPU 限制；若持续低值，可能受 I/O 或网络限制。

步骤 5：验证硬件与提供商兼容性

时间片共享通用；MIG 需 Ampere 及以上架构；Cast AI MPS 目前在 GCP GKE 上运行。选择 unsupported 方案将导致配置错误。

注意可观测性限制：启用时间片共享时，DCGM-Exporter 无法关联每个容器的 GPU 指标。需依赖推理服务器原生遥测（如 vLLM 的 /metrics 端点）监控每个请求的 GPU 内存使用和队列深度。

如何安全测试 GPU 共享

在生产环境启用 GPU 共享存在风险，如无内存隔离的时间片共享可能导致延迟尖峰。建议采用 " 先测试后提交 " 策略：

单节点起步：在非生产命名空间中，通过 ConfigMap 在单节点启用时间片共享。从两个副本开始，逐步增加。

测量尾部延迟：关注 p95 和 p99 延迟，而非平均值。若 p99 超出 SLO，说明该配置不可行。

评估 MIG/MPS：对延迟敏感负载，评估 MIG 的硬件隔离优势。在 A100 上，3g.20gb 配置文件提供确定性吞吐量。

调整 VRAM 预分配：vLLM 默认预分配 90% VRAM。在时间片共享场景中，需通过 --gpu-memory-utilisation 标志降低此比例，为邻居留出余地。

确认 VRAM 适配：确保共调度负载的总 VRAM 需求不超过设备内存，否则将引发 OOM。

GPU 共享与放置自动化的价值

手动配置的共享策略难以适应模型发布和负载变化。Cast AI 通过自动化层解决此问题：

自动化共享：共享配置位于节点模板而非工作负载清单中，现有 Pod 无需修改即可迁移至共享设备。时间片共享可将每 GPU 副本数扩展至 48。

智能放置：基于动态资源分配（DRA），Cast AI 自动选择共享配置并在共享 / 分区 GPU 间分布负载，无需手动设置节点选择器。

方法选择：根据 VRAM 约束自动选择时间片共享、MIG 或 MPS。例如，单个 A100 可呈现 28 个逻辑槽位，但需经测试确保延迟达标。

案例：ALLEN Digital 通过共享实现 71% 成本降低

ALLEN Digital 在 SageMaker 上运行七款 ML 模型，每款独占 GPU 实例，导致高昂计费。迁移至 EKS 并使用 Cast AI 的 Kimchi Inference 后，通过 GPU 时间片共享、节点装箱及 Spot 实例组合，成本较 SageMaker 降低 71%，且延迟保持不变。

其中，时间片共享贡献约 20 个百分点的成本节省，模型合并至共享实例贡献 30-40 个百分点，Spot 实例及资源调整贡献剩余部分。尽管 BGE-M3 初期遇到兼容性问题，经两天调整后，延迟甚至优于 SageMaker 基线。

结论

看似空闲 GPU 旁的排队现象，极少源于硬件短缺，多为调度、分配、内存或应用层配置问题。遵循 " 分配→内存→放置→应用 " 的诊断序列，可精准定位瓶颈。GPU 共享仅解决分配案例；VRAM 约束需 MIG 或 MPS；放置故障需调整调度配置；应用瓶颈需优化 CPU 或数据管道。跳过中间步骤直接购买 GPU，往往无法解决等待问题。

常见问题

问：为什么 GPU 工作负载在利用率低时会排队？

答：Kubernetes 默认独占分配 GPU。即使工作负载计算活动仅 5%，只要其持有设备，其他 Pod 便无法使用。低利用率不等于可用容量。

问：GPU 分配和 GPU 利用率有什么区别？

答：分配是 Kubernetes 调度状态（可用 / 不可用）；利用率是运行中负载的计算活动或内存占用。设备可被完全占用（对新负载不可用）同时报告低计算利用率。

问：Kubernetes 工作负载可以共享一个 GPU 吗？

答：可以，但需更改默认配置。支持时间片共享（软件复用）、MIG（硬件隔离分区，需 Ampere+）和 MPS（并发 CUDA 进程）。每种方法均有不同的隔离属性和硬件要求。

问：MIG 与时间片共享有何不同？

答：MIG 在硬件级别划分 GPU，提供内存和故障隔离，但实例间无 NVLink，且需特定硬件。时间片共享是软件级时间复用，通用性强但无内存隔离。

问：GPU 共享会影响推理延迟吗？

答：是的。时间片共享可能在突发请求时增加尾部延迟。MIG 通过硬件隔离消除干扰，但牺牲灵活性。MPS 介于两者之间。生产环境启用前必须进行真实负载测试。

问：团队应该在什么时候添加 GPU 而不是共享现有容量？

答：仅在排除分配、内存和放置约束后。若设备内存饱和、负载无法忍受共享延迟或请求量超出共享吞吐上限，才需新增 GPU。

【星途科讯 图文丨 LCC 首发于 ZAKER 科技，转载请注明出处】