一起资讯网

核心要点

• 利用率误区：GPU计算利用率仅反映硅片忙碌程度，不代表设备可用性或内存状态。5%的利用率可能意味着设备已被完全占用。
• 独占机制：Kubernetes默认将整块GPU独占分配给Pod。即使工作负载空闲，其他任务也无法使用该设备。
• 排队根源：看似空闲GPU旁出现排队，通常源于独占分配、内存耗尽、放置约束或应用层瓶颈，仅第一种可通过GPU共享解决。
• 技术权衡：时间片共享、MIG和MPS在内存隔离、硬件要求及可观测性上各有优劣，无万能方案。
• 诊断逻辑：须按“分配状态→内存占用→放置约束→应用瓶颈”顺序排查，严禁跳跃。
• 自动化支持：Cast AI支持上述三种共享方法，具备自动装箱能力，且无需修改工作负载清单。

GPU利用率的真相与盲区

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

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

下表厘清了四项常被归为“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共享存在风险，如无内存隔离的时间片共享可能导致延迟尖峰。建议采用“先测试后提交”策略：

1. 单节点起步：在非生产命名空间中，通过ConfigMap在单节点启用时间片共享。从两个副本开始，逐步增加。
2. 测量尾部延迟：关注p95和p99延迟，而非平均值。若p99超出SLO，说明该配置不可行。
3. 评估MIG/MPS：对延迟敏感负载，评估MIG的硬件隔离优势。在A100上，3g.20gb配置文件提供确定性吞吐量。
4. 调整VRAM预分配：vLLM默认预分配90% VRAM。在时间片共享场景中，需通过--gpu-memory-utilisation标志降低此比例，为邻居留出余地。
5. 确认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。