
要点
- CUDA 13.4 对应用透明地强制精确或最小/最大显存;超额分配会像在更小 GPU 上一样失败,并可选默认 time-slicing 或 sm-sharing 计算模式。
- KAI Scheduler 组织下的开源 gpu-fractioning 与 NVIDIA GPU Operator 并列运行:监管 MPS、落实 Pod 注解,并按份额而非整卡计量。
- KAI Scheduler v0.18.0 的 NvFractions(Helm global.nvFractions.set=true)写出契约;密化仍要求单 GPU 一种计算模式,并接受 sm-sharing 会合并错误域。
许多推理服务、笔记本与小规模微调只需要一张 GPU 的一部分。整卡分配浪费容量;没有硬显存上限的共享,则会招来越界分配的噪声邻居。
NVIDIA 2026 年 10 月 27 日的开发者博客称,CUDA 13.4 以透明的显存边界强制补上这一缺口,而新的开源 GPU Fractioning Operator 与 KAI Scheduler 的 NvFractions 模式,把该契约接到 Kubernetes。 主张并不是 MIG 过时,而是:当平台团队要密化多租户 GPU 时,软 time-slicing 与硬件分区不再是仅有的诚实选项。
[1]CUDA 此前已有 MIG(硬件隔离实例)、经典 time-slicing(轮转但无显存强制)以及 MPS sm-sharing(并发地址空间)。 CUDA 13.4 增加对应用透明的显存边界:工作负载可申请精确显存,或保证最小值并在空闲时突发到最大值;超过上限的分配会失败,如同在更小 GPU 上。 计算模式可显式选择——默认 time-slicing,或 sm-sharing——且每个工作负载只看到自己的分数显存视图。
Kubernetes 仍需要节点侧管道。托管在 KAI Scheduler GitHub 组织下的 gpu-fractioning 算子,与 NVIDIA GPU Operator 并列运行:在每台 GPU 节点上搭建并监管 MPS,在进程启动前落实各 Pod 容器的显存上限与计算模式,并按份额报告内存与算力使用。 凡能写入文档化注解的调度器都可驱动强制;KAI Scheduler v0.18.0 是首个集成路径,通过 Helm 开关启用 NvFractions,并作为依赖安装该算子。
目前最硬的证据是 NVIDIA 文档化的注解契约与模式规则,而非第三方密化基准。 每容器键包括 nvidia.com/container.<name>.gpu-memory.request 与 .limit、.gpu-compute.mode(time-slicing 或 sm-sharing),以及 .gpus.devices。 工作负载可用绝对大小(如请求 40Gi、上限 60Gi)或 KAI 比例分数(gpu-fraction: "0.5" 及可选比例上限),再用 gpu-fraction-num-devices 把同一每卡请求铺到多卡。
Time-slicing 串行且保持独立错误域,未用时间会再分配;sm-sharing 并行,SM 动态分配,全忙时大致落到 1/n,但工作负载共享同一错误域。 KAI 不会在同一张 GPU 上混放两种模式,但同一节点可在不同 GPU 上分别运行。 管理员用 helm upgrade … --set global.nvFractions.set=true 启用。 另据 CUDA Toolkit 13.4 公告,MPS V3 提供可脚本 CLI、命名服务器、TOML 配置、SM 分区控制以及与 cgroup 集成的 GPU 显存上限——与编排叙事一致,但该文是更广的工具包发行说明,并非 Kubernetes 密化研究。
反对把此事当作普遍密化胜利的有力说法是 MIG:硬件隔离实例本就能提供透明硬分区,无需依赖会写注解的调度器。 若团队需要强隔离且 GPU/SKU 使 MIG 运维更干净,软件分数带来的增量可能有限。
新路径也是纯注解契约:调度器漏写或错写键,强制就不完整;集群必须标准化写入方(文档上首个是 KAI NvFractions),并接受 time-slicing 与 sm-sharing 不能共卡。 sm-sharing 合并错误域,对不信任多租户打包是真实代价。 最后,两篇帖子都没有独立的占用率、干扰或每 token 成本数字——只有机制与示例。把加密收益当作设计主张,直到平台团队公布自身前后对比。
[1]买单的是要把推理副本、交互笔记本与小规模微调塞进多租户 GPU、又要挡住显存超售的平台团队。 受益的也是同一批人——若分数请求能取代整卡预留,而不再指望应用自觉限流。
财务与容量规划应与头条一并听到约束:注解纪律、每 GPU 单一计算模式,以及 sm-sharing 的共享故障域。 缺了这些,「分数 GPU」仍只是调度标签,而不是可执行边界。
[1]未来半年要看:其他 Kubernetes 调度器是否在生产写出同一套 NVIDIA 注解;集群是否公布 NvFractions 下的密化与干扰指标;运维是否对不信任租户默认 time-slicing、把 sm-sharing 留给可信打包。 若这些落地,显存强制共享会与 MIG 并列成为标准打包工具;若不然,CUDA 13.4 的边界在 CUDA 层仍真实,作为集群级契约却依旧偏薄。
[1]