许多AI工作负载只需要一小部分GPU资源。为每个任务分配整块设备会导致大量算力闲置，而通过GPU共享，平台团队可以用现有基础设施支持更多工作负载。
NVIDIA GPU已经支持多种共享方式。多实例GPU（MIG）将一块GPU拆分为硬件隔离的多个实例，对应用程序完全透明；时间切片让多个进程轮流使用GPU，但不具备内存强制隔离能力；多进程服务（MPS）则允许多个进程在各自独立的地址空间中并发运行（即sm共享）。
CUDA 13.4引入了一种新的时间共享模式，在对应用程序透明的前提下强制实施内存边界，与MPS中已有的计算共享模式（sm共享）形成互补。
此次CUDA版本更新带来了以下能力：
精确的内存配额：工作负载申请一定大小的内存，CUDA会将其严格限定在该范围内。超出该大小的分配请求将失败，效果如同运行在一块更小的GPU上。
弹性区间：工作负载获得一个保证的最小值，以及在内存空闲时可扩展到的最大值。
计算模式选择：每个工作负载可以选择使用sm共享模式，而不是默认的时间共享模式。
透明的内存限制：每个工作负载只能看到GPU内存的一部分。
缺失的一环：如何在Kubernetes中实现
CUDA提供了内存强制隔离的能力，但Kubernetes集群本身无法独立利用这一能力。在每个GPU节点上，需要有组件来完成以下工作：
运行并监管这些功能所依赖的守护进程
在进程启动前，为每个Pod容器应用内存限制和计算模式
报告每个分片的实际使用情况，而不是整块GPU的使用情况
这项工作需要在节点层面完成，与具体是哪个调度器分配的工作负载无关。
GPU分片：一个开源Kubernetes Operator
一个名为gpu-fractioning的新开源Kubernetes Operator，目前托管在GitHub上的KAI Scheduler组织下。它与提供驱动和容器运行时配置的NVIDIA GPU Operator协同运行。
GPU Fractioning Operator承担三项工作：
在每个GPU节点上设置并运行MPS
为每个工作负载应用其内存限制和计算模式
按分片而非按整块GPU测量内存和计算使用情况
调度器如何将GPU分配信息传递给Operator
开发者在Pod的YAML文件中写入资源和模式注解。调度器为工作负载选定GPU后，会将其内存分配量和计算共享模式记录在每个容器对应的Pod注解中。GPU Fractioning Operator读取这些注解，并对分配到的GPU进行配置，以应用该工作负载的内存限制和计算模式。
任何能够写入这些注解的Kubernetes调度器，都可以借助CUDA实现GPU分片的强制隔离。调度器自身仍需承担本职工作：选择一块有足够空闲内存的GPU，并确保同一块GPU上不会混用不同的计算模式。
结合KAI Scheduler使用GPU Fractioning
KAI Scheduler是首个与gpu-fractioning完成集成的调度器。从v0.18.0版本开始，KAI Scheduler提供了一种名为NvFractions的GPU共享模式。KAI Scheduler负责决定每个工作负载获得哪块GPU的哪一部分，并写入相应注解，而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注解来描述一个分片工作负载。
有四个重要的注解，分别回答四个问题：
1. 需要多少内存
2. 工作负载可以扩展到多大
3. 计算资源如何共享
4. 涉及多少块GPU
需要多少内存：资源请求
有两种方式申请内存：
1. 以绝对大小申请：使用NVIDIA提供的每容器注解，并采用标准的Kubernetes单位：
容器名称（app）作为键的一部分，因此始终能够精准指向正确的容器。
2. 以GPU占比申请：使用KAI Scheduler已有的注解：
gpu-fraction: "0.5"
可以扩展到多大：限额
这项能力是KAI Scheduler的新特性。工作负载可以声明一个保证的最小值（请求值）以及在内存空闲时可扩展到的最大值。使用哪个限额注解，取决于你如何书写请求：
限额是可选的。如果省略，则限额等于请求值，工作负载将被严格限制在其申请的数量上。占比形式的限额必须大于gpu-fraction的值，且小于1。
计算资源如何共享：时间切片还是sm共享
现在计算资源也可以被划分。设n为共享同一块GPU的工作负载数量：无论采用哪种方式，每个工作负载大致获得1/n的计算资源，区别在于是轮流使用还是同时运行。
时间切片是串行的：工作负载轮流使用整块GPU，当每个工作负载都用满自己的时间片时，各自大约获得1/n的时间。某个工作负载未用完的时间会被其他工作负载平均分享。这是默认模式。每个工作负载运行在各自独立的错误域中，即具备完整的错误隔离能力。
sm共享是并行的：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"
该请求适用于每一块设备。例如40Gi的请求加上四块设备的设置，意味着在四块GPU上各获得40Gi。
综合示例：GPU分片的实际应用
示例一：在四块GPU上以sm共享方式申请绝对大小并预留扩展空间：
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上以时间切片（默认模式）方式申请半块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
这是一个开发或批处理任务的示例，例如笔记本环境或小规模微调任务，需要在两块GPU上各保证获得一半资源，并可在内存空闲时扩展至80%。时间切片为每个工作负载提供独立的错误域，因此某个任务崩溃不会影响其邻近任务。在容器中运行nvidia-smi应该能看到两块GPU，每块都显示该工作负载所分配的内存份额。
开始使用
KAI Scheduler和GPU Fractioning Operator均已在GitHub上的KAI Scheduler组织下开源发布，并提供了三种共享机制的安装与配置说明（详见管理员和用户指南）。欢迎加入Slack频道或每两周一次的社区会议，提出问题并参与贡献。
关于CUDA 13.4的更多信息，请参阅相关发布公告。
你也可以在2026年11月9日至12日于美国犹他州盐湖城举行的KubeCon + CloudNativeCon NA 2026大会期间参与交流。
