NVIDIA CUDA 13.4新增内存强制隔离，KAI Scheduler推出GPU分数化共享
NVIDIA技术博客介绍，CUDA 13.4为时间共享模式加入对应用透明的内存边界；开源Kubernetes operator gpu-fractioning负责在节点上落实这些限制，KAI Scheduler v0.18.0起提供NvFractions模式并写入相应Pod注解。
AI解读：CUDA 13.4的新增能力是内存强制：工作负载申请指定内存量后，CUDA将其限制在该额度内，超过额度的分配会失败，效果类似在更小的GPU上运行。
除固定内存量外，CUDA 13.4还支持“最低保障 + 空闲时可增长上限”的范围模式，以及按容器选择sm-sharing或默认time-slicing的计算共享模式。
CUDA只提供内存强制能力，Kubernetes集群还需在每台GPU节点上运行并监管相关守护进程、在容器启动前应用限制、按分数而非整卡上报用量。
开源operator gpu-fractioning托管在GitHub的KAI Scheduler组织下，与NVIDIA GPU Operator并列运行，负责启动MPS、应用每个工作负载的内存限制和计算模式、按分数计量内存和计算使用。
KAI Scheduler从v0.18.0起提供NvFractions共享模式，由调度器选择GPU切片并写入Pod注解，gpu-fractioning在节点上读取注解并执行；其他共享模式仍然可用，管理员按集群选择一种。
同一块GPU一次只能运行一种计算模式，KAI Scheduler按GPU而非按节点跟踪，因此一个节点可以在不同GPU上同时承载两种模式。
NVIDIA技术博客介绍了CUDA 13.4与开源Kubernetes operator gpu-fractioning的组合：CUDA负责内存强制，operator负责在节点上落实每个容器的内存限制和计算模式。KAI Scheduler从v0.18.0起提供名为NvFractions的GPU共享模式，成为首个与gpu-fractioning集成的调度器。
CUDA 13.4带来什么
据NVIDIA技术博客，CUDA 13.4在已有的MPS计算共享模式（sm-sharing）之外，新增一种带内存强制的时间共享模式。应用无需感知这一边界，只会看到GPU内存的一部分。
内存可以按两种方式申请：一种是精确数量，工作负载申请某个大小后CUDA将其固定在该额度，超出额度的分配会失败；另一种是范围，即保障一个最低值，并允许在内存空闲时增长到某个上限。
- 精确内存量：超过申请额度的分配失败，与在更小GPU上运行表现一致。
- 范围：工作负载获得保证的最低内存，以及内存空闲时可增长的上限。
- 计算模式：每个工作负载可选择sm-sharing，而不是默认的time-slicing。
- 透明内存限制：每个工作负载只看到整卡内存的一部分。
Kubernetes侧缺少的环节与operator
博客指出，CUDA提供内存强制能力，但Kubernetes集群无法直接使用。每台GPU节点上需要有组件运行并监管相关守护进程、在进程启动前应用每个Pod容器的内存限制和计算模式，并按分数而非整卡上报实际用量。
新的开源operator gpu-fractioning托管在GitHub的KAI Scheduler组织下，与提供驱动和容器运行时配置的NVIDIA GPU Operator并列运行。它承担三项工作：在每台GPU节点上设置并运行MPS；应用每个工作负载的内存限制和计算模式；按分数而非按GPU计量内存和计算使用。
调度器如何传递分配结果
按照博客描述的流程，开发者在Pod YAML中写入资源和模式注解，调度器选定GPU后，把内存分配和计算共享模式记录到按容器划分的Pod注解中。gpu-fractioning读取这些注解，在分配的GPU上应用限制。
博客称，任何能写入这些注解的Kubernetes调度器都可以借助CUDA执行GPU分数限制。调度器仍需自行选择空闲内存足够的GPU，并且不能在同一块GPU上混用计算模式。
- nvidia.com/container.<name>.gpu-memory.request：保证的GPU内存。
- nvidia.com/container.<name>.gpu-memory.limit：容器可增长到的上限。
- nvidia.com/container.<name>.gpu-compute.mode：time-slicing（默认）或sm-sharing。
- nvidia.com/container.<name>.gpus.devices：容器被分配到的GPU。
KAI Scheduler的NvFractions模式
KAI Scheduler是首个与gpu-fractioning集成的调度器。从v0.18.0起，它提供NvFractions共享模式：调度器决定每个工作负载获得哪块GPU的哪个切片并写入注解，gpu-fractioning在节点上执行。安装时可通过helm参数global.nvFractions.set=true启用，这会同时把gpu-fractioning作为依赖安装。
内存申请既可写成绝对大小，也可用KAI Scheduler已有的gpu-fraction注解按整卡比例申请。上限注解与申请方式对应：绝对大小用nvidia.com/container.<name>.gpu-memory.limit，比例用kai.scheduler/container.<name>.gpu-memory.portion.limit。博客说明上限是可选项，省略时上限等于申请值，比例上限必须大于gpu-fraction且小于 1。
- 计算共享：time-slicing让工作负载轮流使用整块GPU，各自处于独立错误域；sm-sharing将流式多处理器（SM）分给多个工作负载并行运行，共享同一错误域。
- 博客称两种模式下每个工作负载大致获得 1/n的计算能力，区别在于轮流执行还是一起执行。
- 跨多卡：gpu-fraction-num-devices设为 4 时，申请量应用于每块GPU，例如 40Gi的申请会在四块GPU上各获得 40Gi。
- 同一块GPU不能混用两种计算模式，调度器按GPU跟踪这一约束。
示例与已知边界
博客给出两个示例：一个推理服务跨四块GPU，每块保证 40Gi、空闲时最多用 60Gi，并采用sm-sharing；另一个开发或批处理任务在每块GPU上保证一半、空闲时最多到 80%，采用默认的time-slicing，适用于笔记本或小型微调等场景。
博客提醒，sm-sharing将工作负载放入同一错误域，应只用于彼此可信、可一起运行的工作负载；time-slicing则为每个工作负载提供独立错误域，一个任务崩溃不会影响邻居。在容器内运行nvidia-smi时，应显示两块GPU，各自带有该工作负载的内存分数份额。