CUDA 13.4 显存配额落地：Kubernetes 共享 GPU 的 4 个检查点

2026 年 10 月 27 日，NVIDIA 发布 CUDA 13.4 在 Kubernetes 中执行显存配额的技术方案，并同步开源 GPU Fractioning Operator。它值得现在关注，是因为此前的小时级 GPU 共享主要解决“多个进程能不能同时运行”，而这次补上了“每个任务到底能用多少显存”这一层约束，并且能接入 Kubernetes 调度流程。

但它并不是给 Pod 加一个 nvidia.com/gpu: 1 就结束了。真正决定配额能否生效的，是调度器、节点 Operator、CUDA 内存机制和共享模式能否对齐。

这次变化究竟补上了哪块缺口

NVIDIA 在官方技术博客中先比较了三种 GPU 共享方式。硬件隔离的 MIG 会把 GPU 划分成独立实例；time-slicing 让多个进程轮流使用 GPU，但没有显存执行边界；MPS 则允许多个进程并发运行，并提供 sm-sharing 计算模式。

CUDA 13.4 增加的能力可以归纳为两项：应用无须改代码即可看到显存边界；每个工作负载既可以申请固定显存，也可以在保留保证值的同时，设置允许借用空闲显存的上限。超出边界时，行为类似在一块更小的 GPU 上申请过量内存，分配会失败。

这里的关键变化不是 Kubernetes 发明了一种新调度算法，而是 CUDA 终于提供了可由节点组件执行的资源契约。

一块 GPU 如何被切出多份配额

新增的 GPU Fractioning Operator 位于 KAI Scheduler 组织下，职责限定在 GPU 节点。它与 NVIDIA GPU Operator 并行运行：后者负责驱动和容器运行时环境，前者负责启动并监管 MPS、应用每个工作负载的显存上限和计算模式，以及按“分片”而不是整卡统计使用情况。

KAI Scheduler 从 v0.18.0 开始提供 NvFractions 模式。调度器先选择 GPU，再把容器资源写进 Pod 注解，由 GPU Fractioning Operator 读取并落实到节点：

metadata:
  annotations:
    nvidia.com/container.<name>.gpu-memory.request: "<请求的保证显存>"
    nvidia.com/container.<name>.gpu-memory.limit: "<允许增长的上限>"
    nvidia.com/container.<name>.gpu-compute.mode: "time-slicing"
    nvidia.com/container.<name>.gpus.devices: "<调度器分配的 GPU>"

其中，request 表示保证显存，limit 表示可以增长到的最大值；计算模式可选 time-slicing 或 sm-sharing。这四个注解不是普通资源申请。调度器负责决定哪个任务落在哪块 GPU，Operator 则负责让节点上的 CUDA 进程遵守已经作出的决定。

管理员可以在安装 KAI Scheduler 时打开这一模式：

helm upgrade -i kai-scheduler oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler 
  -n kai-scheduler --create-namespace 
  --set global.nvFractions.set=true

官方说明这一步也会安装 GPU Fractioning Operator。不过，是否适合当前集群，不能只看 Helm 命令能否执行，还要继续检查后面的三个边界。

配额生效前的第一个检查点：注解是否完整

最直接的故障是“调度器已经接纳任务，但 Operator 读不到完整契约”。例如容器有显存 request，却没有 limit；或者只写了设备分配，没有说明计算模式；更隐蔽的情况是容器名称与注解中的 <name> 没有完全对应。

因此，部署后应把 Pod 注解当成需要检查的配置结果，而不是只检查 YAML 模板。至少要确认：

• 同一个容器下的 request、limit 和设备分配同时存在；
• request 不高于 limit；
• 计算模式与调度器的放置策略一致；
• 注解落在调度器和 Operator 共同约定的位置。

官方博客还特别说明，调度器不能在同一块 GPU 上混放不同计算模式。按官方口径推下来，节点侧 Operator 即使成功写入显存限制，也不应被当作调度正确性的替代品。

第二个检查点：硬边界与借用边界是否被混淆

NVIDIA 的 MPS 内存分区文档进一步展示了显存限制背后的两档阈值。硬上限对应分配时检查，超过后会返回内存不足；软上限则是压力阈值，越过后申请仍可能成功，但客户端会成为被驱逐候选，只有在真实内存压力下才可能被驱逐。

文档还说明了两类后端：存在 DMEM cgroup 控制器时，内核负责原生执行硬、软限制；没有时，驱动使用 misc 后端进行内部核算。文档列出的 DMEM 路径要求内核为 6.14 或更新版本。

这与官方博客描述的“保证值加可突发上限”并不矛盾，但能帮助读者避免一个误解：申请量、借用量和可依赖量不是同一个概念。request 应当代表调度决策可以依赖的保证值；limit 更适合作为资源回收边界，而不应被任务当作永久独占容量。

这是我对文档机制与博客用语的对照理解，不是 NVIDIA 对 Kubernetes 注解映射规则的额外声明。实际 request 与 limit 如何转换为 MPS 的软、硬阈值，仍应以当前 Operator 文档和实际 Pod 配置为准。

第三个检查点：共享成功不等于性能可预测

time-slicing 与 sm-sharing 的差别，不只是注解里的两个名称。前者让任务轮流获得计算资源，后者让任务并发运行并共享流式多处理器的计算能力。对普通 AI 用户而言，这会影响延迟、吞吐和故障隔离预期。

官方博客没有给出统一性能倍数，因此不能据此声称 sm-sharing 一定快于 time-slicing，或者某种模式更适合推理。我的经验判断是，迁移时至少应分别测量单任务完成时间、批量吞吐和显存不足时的失败行为；这是工程验证建议，不是 NVIDIA 的性能承诺。

第四个检查点：调度器能力与集群兼容性

GPU Fractioning Operator 的设计并不绑定 KAI Scheduler。官方博客明确表示，任何能够写入规定 Pod 注解的 Kubernetes 调度器都可以使用这项能力。因此，团队不必因为没有采用 KAI Scheduler 就直接判定方案不可用，但必须自行验证三件事：能否选择显存充足的 GPU，能否正确写注解，能否避免在同一块 GPU 上混放计算模式。

KAI Scheduler 是首个集成方案，管理员指南应与当前集群版本一起核对。需要特别留意的是，文章描述的是 v0.18.0 引入 NvFractions，而安装参数、默认行为和依赖组件仍可能随版本变化。升级前应查看仓库当前说明，不宜直接复用旧安装命令而不做差异检查。

我的判断是，这套方案短期更适合已经以 Kubernetes 运行多租户推理、且小任务较多、需要提高显存利用率的平台。它不是免费获得额外显存：共享同一物理 GPU 的任务仍然竞争算力和带宽，调度与监控能力也需要配套建设。

从 Demo 到生产：建议按这个顺序验证

第一次验证不必直接接入线上流量。可以先选择一个非关键工作负载，检查 Pod 是否获得完整注解、显存 request 与 limit 是否按预期生效，再分别触发固定上限和借用空闲显存两种行为。

第二步应做故障注入：让任务申请超过上限的显存，确认它得到内存不足错误；同时观察邻居任务是否受到软阈值压力影响。这里不应把单次演示结果推广成稳定性能结论。

第三步再验证调度边界，包括设备分配是否正确、同卡计算模式是否一致，以及 Operator 重启后配置能否恢复。最后才应逐步增加共享任务数量，并同时记录显存、计算利用率、延迟和失败率。

按这个顺序检查，读者最终应得到四项可操作产物：一份完整注解清单、一种软硬阈值验证方法、一套 time-slicing 与 sm-sharing 对照指标，以及一条从单机验证到多租户接入的上线路径。

参考来源

• CUDA 13.4 GPU Sharing in Kubernetes: Hard Memory Limits | explainx.ai Blog

• CUDA 13.4 Enforces GPU Fractions Inside Kubernetes

• NVIDIA Technical Blog：Memory-Enforced GPU Sharing in Kubernetes with NVIDIA CUDA 13.4

• GPU Fractioning Operator GitHub Repository

• NVIDIA MPS 文档：Memory Partitioning

• KAI Scheduler GPU Sharing Admin Guide

• NVIDIA GPU Operator Repository