Lambda 为 Kubernetes 服务准备开源 Run:ai 调度器

Lambda 于 2026 年 10 月 13 日表示，正与 NVIDIA 合作，将开源的 Run:ai GPU 调度器作为 Lambda Kubernetes Service (LKS) 上的正式托管选项。LKS 计划推出一系列以托管组件形式提供的调度器。

这一计划见于Lambda 于 2026 年 10 月 13 日发布在其博客上的一篇文章。“我们欢迎 NVIDIA 决定将 Run:ai 开源，目前正努力使其成为 Lambda Kubernetes Service (LKS) 上的正式选项，”该公司表示。Lambda 称，自 2022 年起便已在其基础设施上支持 Run:ai，并表示其目标是通过 LKS 让团队更轻松地采用和运营 Run:ai 的各项功能，从而更好地掌控 GPU 算力的分配与共享方式。

NVIDIA 于 2025 年将该调度器开源

根据NVIDIA 的公告，NVIDIA 于 2025 年 4 月 1 日根据 Apache 2.0 许可证开源发布了 KAI Scheduler。这是一款原先在 Run:ai 平台内部开发、原生适用于 Kubernetes 的 GPU 调度解决方案。NVIDIA 表示，该调度器仍作为 NVIDIA Run:ai 平台的一部分进行打包和交付。

据 NVIDIA 介绍，该调度器会持续重新计算公平份额，并实时调整配额和限制；它将 gang 调度、GPU 共享和分层排队结合起来，而内置的 podgrouper 会自动将工作负载与 Kubeflow、Ray、Argo 和 Training Operator 等框架关联起来。NVIDIA 描述的调度周期会先获取 Kubernetes 集群的快照，再通过应得配额和超额配额阶段计算每个队列的公平份额，随后执行分配、整合、回收和抢占操作，使当前分配与计算所得的状态保持一致。

Run:ai 中的 GPU 共享与配额调度

Lambda 介绍了 AI 开发对 GPU 的多样化需求：调试可能只需要一块 GPU 的部分算力；评估可能需要扩展为大量相互独立的作业；分布式训练则可能需要一次性使用大量紧密互联的 GPU。随着工作从早期构想到实验再到投入生产，需求也会随之变化。如果小型作业独占整块 GPU，研究人员就只能等待，而预留的算力却闲置不用；团队也可能发现，自己的实验被其他团队预留却处于空闲状态的 GPU 卡住。

按照 Lambda 的说法，Run:ai 是一款适用于 Kubernetes 的 GPU 调度器，在默认 Kubernetes 调度器的基础上增加了两项功能：GPU 共享允许多个工作负载在同一块 GPU 上运行；基于配额的调度则为每个团队提供有保障的资源分配，同时允许团队相互借用闲置算力。

NVIDIA 的GPU 分配比例文档指出，分配比例可以将 GPU 内存划分为更小的区块，供多个工作负载共享，并会强制执行每个工作负载所请求的内存大小，使其既不能超过申请量，也不能占用其他工作负载的内存。每个 Pod 都有独立的虚拟内存地址空间；文档将这种安排称为“逻辑 GPU”。

根据文档，分配比例默认使用 NVIDIA 的时间切片技术共享 GPU 计算资源；多 GPU 分配比例则会在单个节点内的多块 GPU 上分配相同的比例。例如，某个使用 8 块 GPU、每块需要 40GB 内存的模型，可以分配到 8×40GB，而不是每块 GPU 的全部内存，这样该节点上每块 GPU 都会剩余 40GB，可供其他工作负载使用。文档指出，GPU 分配比例与 Multi-Instance GPU (MIG) 模式不能在同一节点上同时使用。

NVIDIA 的调度器概念文档指出，每个新建的 Pod 都会被分配到一个 Pod 组；所谓 gang 调度，是指由多个 Pod 组成的工作负载要么全部获得调度，要么全部处于等待状态。每个节点池中的每个项目和部门都会创建一个调度队列；应得配额限定了不可抢占工作负载可运行的资源，而超额配额资源仅供可抢占工作负载使用。调度器会为每个节点池中的各个项目和部门计算公平份额值；当一个队列低于其公平份额、另一个队列高于其公平份额时，调度器便会在队列间转移资源以重新平衡，这一过程可能会抢占超额使用配额的可抢占工作负载。调度器还可以在项目和部门之间回收资源，管理员也可以针对每个节点池设置紧凑装箱或分散放置策略。

LKS 中的节点自动修复

Lambda 指出，共享和抢占都以底层 GPU 状态正常为前提，但在大规模环境中，这并非理所当然：加速器会出现 XID 错误，NVLink 和 PCIe 链路会劣化，内存行会被重新映射，InfiniBand 端口的速率也可能低于预期。调度器无法区分状态正常的 GPU 和发生故障的 GPU，因此仍会继续向有问题的节点发送作业，而这些作业会被丢弃。

Lambda 表示，LKS 已开始提供自动修复功能。该公司称，系统会监控每个节点是否存在此类故障，并将每项故障作为标准 Kubernetes 节点状态公开；状态条件触发时，节点会被隔离，不再接收新任务，正在运行的作业会被清空，随后系统会自动修复故障或将其升级至硬件维修。只有重新验证通过后，该节点才会恢复服务。

Lambda 的托管式 Kubernetes 文档将这项服务描述为一种 Kubernetes 环境，支持 GPU 和 InfiniBand（RDMA），并在 1-Click Cluster 的所有节点之间提供共享的持久化存储。服务预装了 NVIDIA GPU Operator 和 NVIDIA Network Operator，并持续进行验证，以确认 GPU、网络和存储运行正常；此外，还会自动修复节点，以检测并恢复硬件故障。

托管式调度器库路线图

Lambda 将 GPU 调度描述为自己有意保持开放的层，并表示 LKS 的下一步目标是打造其所称的 AI 软件库：其中包括可在 Kubernetes 上运行的调度器，例如 Slurm 和 Run:ai；这些调度器将作为托管组件交付，由 Lambda 在自家硬件上进行验证并保持更新，而不必让客户手动通过 Helm chart 组装。Run:ai 是该软件库的重点支持对象，Lambda 表示正在与 NVIDIA 合作实现这一目标。

Lambda 表示，开源发布使这种做法成为可能：公司可以直接在 LKS 中打包、测试和维护 Run:ai，而不是只向客户提供一套集成说明。Lambda 表示，其目标是实现开箱即用的集成，并由公司负责打包、验证和持续运营。

Lambda 自己也开展开放式研究。公司表示，能够检查、调整并改进自己所依赖的工具对其很重要，并称 NVIDIA 的决定将这种自由延伸到了编排领域。