基于 NVIDIA CUDA 13.4 在 Kubernetes 中实现内存强制的 GPU 共享
借助开源 GPU Fractioning Operator 与 KAI Scheduler 大规模实施单工作负载内存限制
2026 年 10 月 27 日
许多 AI 工作负载仅需使用部分 GPU 资源。若为每个负载分配整张设备，会导致算力闲置；而 GPU 共享技术能让平台团队利用现有基础设施承载更多工作负载。
NVIDIA GPU 目前已支持多种共享方案。多实例 GPU（MIG）可将 GPU 拆分为对应用透明的硬件隔离实例；时间片轮转机制允许多个进程交替执行，但缺乏内存限制；多进程服务（MPS）则允许它们在独立的地址空间内并发运行（即 sm-sharing）。
CUDA 13.4 新增了一种对应用透明的时间共享模式，用于强制执行内存边界。该模式与 MPS 中已有的计算共享模式（sm-sharing）并行存在。
此次 CUDA 版本更新带来了以下特性：
- 精确内存配额：工作负载申请指定大小的内存后，CUDA 会严格锁定该额度。超出此范围的内存分配将直接失败，行为类似于在显存更小的 GPU 上运行。
- 弹性内存范围：工作负载可获得一个保底的最小值，并在显存空闲时动态扩展至设定的最大值。
- 独立计算模式：各工作负载可选择启用 sm-sharing 模式进行计算，而非使用默认的时间共享模式。
- 透明内存限制：每个工作负载仅能感知到所分配的那部分 GPU 显存。
关键缺失环节：从 Kubernetes 落地实施
CUDA 提供了内存强制执行能力，但 Kubernetes 集群无法单独调用该功能。在每个 GPU 节点上，必须有组件负责以下工作：
- 启动并监控这些功能所依赖的守护进程
- 在进程启动前，为每个 Pod 容器应用内存限制与计算模式
- 上报各显存分区的实际使用情况，而非整张 GPU 的总用量
此类节点级任务应与调度器无关，无论工作负载由何种调度策略分配。
GPU Fractioning：一款开源 Kubernetes Operator
全新的开源 Kubernetes Operator——gpu-fractioning 已托管于 GitHub 上的 KAI Scheduler 组织下。该组件与 NVIDIA GPU Operator 协同运行，后者负责提供驱动与容器运行时环境配置。
GPU Fractioning Operator 主要承担三项职责：
- 在所有 GPU 节点上部署并运行 MPS 服务
- 为各工作负载应用内存限制与计算模式
- 按显存分区粒度统计内存与计算资源的实际消耗，而非按整卡统计
调度器如何向 Operator 传递 GPU 分配信息
开发者需在 Pod YAML 中声明资源与模式注解。随后，调度器为工作负载选定 GPU，并将内存分配量与计算共享模式写入对应容器的 Pod 注解中。GPU Fractioning Operator 读取这些注解后，即可对分配的 GPU 进行配置，以落实工作负载的内存限制与计算模式：
| 注解（Annotation） | 含义（Meaning） |
|---|---|
nvidia.com/container..gpu-memory.request | 保证的显存大小（Guaranteed GPU memory） |
nvidia.com/container..gpu-memory.limit | 容器最大可增长的显存上限（Maximum the container may grow into） |
nvidia.com/container..gpu-compute.mode | 时间片轮转（time-slicing，默认）或 SM 共享（sm-sharing） |
nvidia.com/container..gpus.devices | 容器被分配的 GPU 设备（Which GPUs the container was assigned） |
表 1：GPU Fractioning Operator 读取的每个容器级 Pod 注解，用于执行 GPU 显存分配
任何能够写入这些注解的 Kubernetes 调度器均可配合 CUDA 强制执行 GPU 显存分配。调度器仍需履行其核心职责：选择拥有足够空闲显存的 GPU，并确保同一张 GPU 上不会混用不同的计算模式。
在 KAI Scheduler 中使用 GPU Fractioning
KAI Scheduler 是首个集成 gpu-fractioning 的调度器。自 v0.18.0 版本起，KAI Scheduler 引入了名为 NvFractions 的 GPU 共享模式。该调度器会决定每个工作负载具体使用哪张 GPU 的哪个切片，并写入相应的注解（参见上方的表 1），随后 gpu-fractioning 会在节点层面强制执行这些配置。
KAI Scheduler 的其他共享模式依然可用，管理员可为每个集群单独选择一种。在安装 KAI 时即可启用该功能：
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 作为依赖项一并安装。此后，你只需通过 Pod 注解即可描述一个分片化的工作负载。
共有四个关键注解，分别对应以下四个问题：
- 需要多少显存？
- 工作负载最多能扩展到多大？
- 如何共享计算资源？
- 跨几张 GPU 运行？
显存需求：Request（请求值）
申请显存有两种方式：
- 指定绝对大小：使用每容器级的 NVIDIA 注解与标准的 Kubernetes 单位： 容器名称（app）包含在键名中，因此始终能精准定位到正确的容器。
- 按 GPU 比例申请：使用 KAI Scheduler 现有的注解：
gpu-fraction: "0.5"
扩展上限：Limit（限制值）
此功能为 KAI Scheduler 新增。工作负载可声明一个保证的最小值（即 request）以及显存空闲时可突发增长的最大值（limit）。具体使用哪种 limit 注解，取决于你编写 request 的方式：
| 请求类型 | 注解 | 示例 |
|---|---|---|
| 绝对大小 | nvidia.com/container..gpu-memory.limit | “80Gi” |
| 按比例 | kai.scheduler/container..gpu-memory.portion.limit | “0.8” |
表 2：针对不同显存请求类型应使用的 Limit 注解
Limit 为可选参数。若未提供，则 limit 默认等于 request，工作负载将被严格限制在其申请的显存范围内。按比例设置的 limit 必须大于 gpu-fraction 的值且小于 1。
计算共享：时间片轮转或 SM 共享
图 1. 时间片轮转（Time-slicing）将 GPU 的时间进行划分；SM 共享（SM-sharing）则将流式多处理器（SM）进行划分。
现在计算资源也可以进行切分了。假设共享一张 GPU 的工作负载数量为 n，无论采用哪种方式，每个工作负载大约都能获得 1/n 的计算能力。两者的区别仅在于它们是轮流执行还是并行运行。
时间切片（Time-slicing）采用串行模式：所有计算任务在整张 GPU 上轮流执行。当每个任务都使用其完整份额时，每个任务大约获得 1/n 的时间。一个任务未使用的剩余时间会平均分配给其他任务。这是默认模式。每个任务运行在独立的错误域中，即实现完全的故障隔离。
SM 共享（SM-sharing）采用并行模式：GPU 的流式多处理器（SM）会在多个计算任务之间划分，所有任务同时持续运行。系统不会预先划定固定份额。GPU 硬件会根据任务的实际需求动态分配和释放 SM。
当所有任务都处于繁忙状态时，资源分配比例大致稳定在 1/n。当某个任务进入空闲状态时，其占用的 SM 会转移给其他任务，单个活跃任务甚至可以独占全部 SM。在此模式下，所有任务共享同一个错误域。
计算模式现已明确支持，并可针对每个容器单独设置：
nvidia.com/container.app.gpu-compute.mode: "sm-sharing" # 或 "time-slicing"
共享 GPU 同一时间只能运行一种计算模式，因此 KAI Scheduler 绝不会将时间切片任务与 SM 共享任务调度到同一张 GPU 上。KAI Scheduler 按 GPU 粒度进行跟踪（而非节点粒度），这意味着单个节点可以在不同的 GPU 上同时托管这两种模式。
如何确定使用的 GPU 数量
若要在多个设备上获取分数容量，请添加以下配置：
gpu-fraction-num-devices: "4"
该请求适用于每个设备。例如，配置为 4 个设备且请求 40Gi 显存时，每张 GPU 都会分配 40Gi。
综合示例：GPU 分片配置
基于 SM 共享模式，在四张 GPU 上配置绝对容量并预留突发空间：
apiVersion: v1
kind: Pod
metadata:
name: inference
labels:
kai.scheduler/queue: default-queue
annotations:
nvidia.com/container.app.gpu-memory.request: "40Gi"
nvidia.com/container.app.gpu-memory.limit: "60Gi" # 可选
nvidia.com/container.app.gpu-compute.mode: "sm-sharing" # 可选，默认为 time-slicing
gpu-fraction-num-devices: "4" # 可选，默认为 1
spec:
schedulerName: kai-scheduler
containers:
- name: app
image: nvcr.io/nvidia/cuda:13.0.2-base-ubuntu24.04
这是一个跨四张 GPU 部署的推理服务。它要求每张 GPU 保证分配 40Gi 显存，当相邻任务空闲时可最高使用 60Gi，并且会与其他任务并行运行而非排队等待。由于 SM 共享会将所有任务置于同一个错误域中，因此仅建议将此模式用于彼此信任、可安全共存的任务。
基于时间切片模式（默认），在两张 GPU 上各分配一半容量，并允许最高扩展至 80%：
metadata:
annotations:
gpu-fraction: "0.5"
gpu-fraction.limit: "0.8" # 可选
nvidia.com/container.app.gpu-compute.mode: "time-slicing" # 可选
gpu-fraction-num-devices: "2" # 可选
spec:
schedulerName: kai-scheduler
containers:
- name: app
此配置适用于开发环境或批处理作业（例如 Jupyter Notebook 或小规模微调任务）。它需要保证两张 GPU 各自的一半容量，并在显存空闲时最高可扩展至 80%。时间切片模式会为每个任务提供独立的错误域，因此单个任务崩溃不会影响相邻任务。在容器内执行 nvidia-smi 命令时，应显示两张 GPU，且每张 GPU 均展示该任务的分数显存占用。
快速入门
KAI Scheduler 与 GPU Fractioning Operator 均托管于 GitHub 的 KAI Scheduler 组织下，所有三种共享机制的安装与配置说明请参阅管理员指南与用户指南。欢迎加入 Slack 频道或参加双周社区会议，提出问题并参与贡献。
如需了解 CUDA 13.4 的更多信息，请参阅相关公告。
您也可以在 2026 年 11 月 9 日至 12 日于犹他州盐湖城举办的 KubeCon + CloudNativeCon NA 2026 期间参与活动。
