# 借助 NVIDIA CUDA 13.4 在 Kubernetes 中实现按显存强制的 GPU 共享 - 原标题：Memory-Enforced GPU Sharing in Kubernetes with NVIDIA CUDA 13.4 - 类型：博客 - 来源：developer.nvidia.com - 发布时间：2026-10-28 - 首次精选：2026-10-29 23:09 - 分级：值得看 - 学习层级：深入 - 主题：[inference-hardware-memory]()（第 21 位）、[model-serving-compute]()（第 52 位） - 原文链接：[https://developer.nvidia.com/blog/memory-enforced-gpu-sharing-in-kubernetes-with-nvidia-cuda-13-4]() - 本站页面：[https://oplearnx.com/resources/pk\_e133f7209904]() ## 摘要 NVIDIA 技术博客，作者 Ekin Karabulut、David Lifshitz、Hagay Sharon，2026 年 10 月 27 日发布。文章介绍挂在 KAI Scheduler 组织下的开源 GPU Fractioning Operator，它与 NVIDIA GPU Operator 配合在每台 GPU 节点上配置并监管 MPS，按工作负载施加显存上限与计算模式，并按 GPU 切片而非整卡计量使用量；CUDA 13.4 引入对应用透明的显存边界强制，支持精确显存额、保证下限加可突发上限、时间切片与 SM 共享两种计算模式，KAI Scheduler v0.18.0 通过 NvFractions 模式写入 Pod 注解来落实这些设置。 ## 中文精读 ### 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.\.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.\.gpu-memory.limit\`（如 "80Gi"），比例申请用 \`kai.scheduler/container.\.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 开关启用，负载用注解声明绝对值、比例、可选突发上限与计算模式。 --- 来源：LearnMap · 学径（https://oplearnx.com）