借助 NVIDIA CUDA 13.4 在 Kubernetes 中实现按显存强制的 GPU 共享

中文精读

原文约 2,601 词 · 11 节

1. 背景：为什么需要显存强制的 GPU 共享

   • 很多 AI 工作负载只需要 GPU 的一小部分，若每个负载独占整卡，容量会闲置；共享 GPU 可以让平台团队用现有基础设施服务更多负载。
   • NVIDIA GPU 已有多种共享方式：MIG（多实例 GPU）把 GPU 切成对应用透明的硬件隔离实例；time-slicing 让多进程轮流使用但没有显存强制；MPS（多进程服务）让多个进程在各自地址空间中并发运行（sm-sharing）。
   • CUDA 13.4 新增了对应用透明的显存边界强制，并提供新的时间共享模式，与 MPS 已有的计算共享模式（sm-sharing）并存。
   • CUDA 发布带来的四点：精确显存额度（超量分配会像在小显存 GPU 上一样失败）、区间式额度（保底最小值加可在空闲时增长的最大值）、可选的每负载计算模式、以及对每个负载透明的显存上限。
   • 文章由 Ekin Karabulut、David Lifshitz、Hagay Sharon 撰写，发布于 2026 年 10 月 27 日，主题是用开源 GPU Fractioning Operator 与 KAI Scheduler 在规模化场景下强制每工作负载的显存限制。

2. 缺失的一环：如何从 Kubernetes 落地

   • CUDA 提供了显存强制能力，但 Kubernetes 集群本身无法直接使用它。
   • 每个 GPU 节点上需要有组件来：运行并监管这些特性依赖的守护进程。
   • 还要在进程启动前为每个 Pod 容器施加显存限制和计算模式。
   • 并且要按每个分片而非整卡来上报实际用量。
   • 这些工作属于节点层职责，与哪个调度器放置了该负载无关。

3. GPU fractioning：开源 Kubernetes Operator

   • 新的开源 Kubernetes Operator `gpu-fractioning` 托管在 GitHub 的 KAI Scheduler 组织下，与负责驱动和容器运行时配置的 NVIDIA GPU Operator 相邻运行。
   • 其职责之一是：在每个 GPU 节点上安装并运行 MPS。
   • 其职责之二是：施加每个工作负载的显存限制与计算模式。
   • 其职责之三是：按分片（fraction）而非按整卡来计量显存与计算用量。

4. 调度器如何把 GPU 分配结果传给 Operator

   • 开发者在 Pod YAML 中写资源与模式注解；调度器为负载选定 GPU，并在每容器 Pod 注解中记录显存分配与计算共享模式。
   • GPU Fractioning Operator 读取这些注解，配置被分配的 GPU 以施加该负载的显存限制与计算模式。
   • 四类注解分别表示：保底显存（`nvidia.com/container.<name>.gpu-memory.request`）、可增长到的上限（`.gpu-memory.limit`）、计算模式（`.gpu-compute.mode`，time-slicing 为默认或 sm-sharing）、以及容器被分配到哪些 GPU（`.gpus.devices`）。
   • 任何能写入这些注解的 Kubernetes 调度器都能借助 CUDA 实现 GPU 分片强制；调度器自身仍要负责挑选空闲显存足够的 GPU，并且不把不同计算模式混在同一张 GPU 上。

5. 在 KAI Scheduler 中使用 GPU Fractioning

   • KAI Scheduler 是首个与 `gpu-fractioning` 集成的调度器，从 v0.18.0 起提供名为 `NvFractions` 的 GPU 共享模式。
   • 分工是：KAI Scheduler 决定每个负载拿到哪张 GPU 的哪一片并写入注解，`gpu-fractioning` 在节点上执行这些约束。
   • KAI Scheduler 的其他共享模式仍然可用，管理员按集群选择其一；在安装 KAI 时通过 Helm 参数 `global.nvFractions.set=true` 启用。
   • 该开关还会把 `gpu-fractioning` 作为依赖一并安装，之后用 Pod 注解描述分片负载。
   • 四个关键注解分别回答：需要多少显存、可以增长到多少、计算如何共享、跨几张 GPU。

6. 需要多少显存：request

   • 方式一：使用 NVIDIA 的每容器注解配合标准 Kubernetes 单位写绝对大小，容器名（如 `app`）是注解键的一部分，因此总能精确作用到目标容器。
   • 方式二：沿用 KAI Scheduler 已有的注解，以占整卡比例的方式申请，例如 `gpu-fraction: "0.5"`。

7. 可以增长到多少：limit

   • 这是 KAI Scheduler 的新能力：负载可以声明保底最小值（request）以及显存空闲时可突发达到的最大值。
   • 用哪种 limit 注解取决于 request 的写法：绝对大小用 `nvidia.com/container.<name>.gpu-memory.limit`（如 "80Gi"），比例申请用 `kai.scheduler/container.<name>.gpu-memory.portion.limit`（如 "0.8"）。
   • limit 是可选的；若省略，limit 等于 request，工作负载被严格限制在所申请的量上。
   • 比例形式的 limit 必须大于 `gpu-fraction` 且小于 1。

8. 计算如何共享：时间共享还是 sm-sharing

   • 计算现在也可以切分。设 n 为共享一张 GPU 的负载数，两种模式下每个负载大致都得到 1/n 的计算能力，区别只在于轮流执行还是一起执行。
   • time-slicing 是串行的：各负载轮流占用整卡，全部满负荷时各得约 1/n 的时间，某个负载未用的时间由其余负载均分；这是默认模式，每个负载处于独立错误域，错误完全隔离。
   • SM-sharing 是并行的：GPU 的流处理器（SM）在各负载间分配并同时持续运行，不预先切分，由硬件按需分配与回收；全部繁忙时约为 1/n，某个负载空闲时其 SM 让给其他负载，单个活跃负载可用满全部 SM，但此模式下各负载共享同一错误域。
   • 计算模式现在按容器显式设置，例如 `nvidia.com/container.app.gpu-compute.mode: "sm-sharing"` 或 `"time-slicing"`。
   • 一张共享 GPU 同一时间只运行一种计算模式，因此 KAI Scheduler 不会把 time-slicing 与 sm-sharing 负载放到同一张 GPU 上；该限制按 GPU 而非按节点跟踪，所以一个节点上不同 GPU 可以分别承载两种模式。

9. 使用多少张 GPU

   • 要在多张设备上获得分片容量，可加上 `gpu-fraction-num-devices: "4"`。
   • 申请量对每张设备分别生效：40Gi 的申请配四张设备，意味着在四张 GPU 上各获得 40Gi。

10. 综合示例：GPU 分片配置

    • 示例一：绝对大小、允许突发、跨四张 GPU、使用 SM-sharing，Pod 的 `schedulerName` 为 `kai-scheduler`。
    • 该示例是一个横跨四张 GPU 的推理服务，每张 GPU 保底 40Gi、邻居空闲时最多可用 60Gi，与其他负载并行而非排队等待；由于 SM-sharing 让负载处于同一错误域，只应用于彼此可信的负载。
    • 示例二：半张 GPU、可增长到 80%、跨两张 GPU、使用默认 time-slicing，适用于 notebook 或小规模微调等开发、批处理任务。
    • time-slicing 下每个负载有独立错误域，某个任务崩溃不影响邻居；在容器内运行 `nvidia-smi` 应显示两张 GPU，各带该负载的分片显存份额。
    • 两个示例都比较了可选注解省略与否，例如计算模式、limit 与设备数量都可省略（默认分别为 time-slicing、等于 request、1）。

11. 快速上手与后续步骤

    • KAI Scheduler 与 GPU Fractioning Operator 都托管在 GitHub 的 KAI Scheduler 组织下，三种共享机制的安装与配置说明见管理员指南和用户指南。
    • 可通过 Slack 频道和双周社区会议提问与参与贡献。
    • 关于 CUDA 13.4 的更多信息可参阅其发布公告。
    • 也可在 2026 年 11 月 9–12 日于犹他州盐湖城举行的 KubeCon + CloudNativeCon NA 2026 期间参与。
    • AI 生成的摘要指出：GPU Fractioning Operator 与 GPU Operator 并行运行、按分片而非整卡计量；CUDA 13.4 提供对应用透明的显存边界强制；KAI Scheduler v0.18.0 通过 NvFractions 模式写入每容器注解；管理员可用 Helm 开关启用，负载用注解声明绝对值、比例、可选突发上限与计算模式。