Lambda 籌備把開源 Run:ai GPU 排程器列為 Lambda Kubernetes Service 的託管選項

Lambda said on October 13, 2026 that it is working with NVIDIA to make the open-sourced Run:ai GPU scheduler a first-class managed option on Lambda Kubernetes Service (LKS), part of a planned library of schedulers delivered as managed components.

The plan appeared in an October 13, 2026 post on Lambda’s blog. “We welcome NVIDIA’s decision to open-source Run:ai, and we’re working to make it a first-class option on Lambda Kubernetes Service (LKS),” the company stated. Lambda said it has supported Run:ai on its infrastructure since 2022, and described its goal as making Run:ai’s capabilities easier to adopt and operate through LKS so that teams gain more control over how GPU capacity is allocated and shared.

NVIDIA Open-Sourced the Scheduler in 2025

NVIDIA announced the open-source release of the KAI Scheduler, a Kubernetes-native GPU scheduling solution originally developed within the Run:ai platform, under the Apache 2.0 license on April 1, 2025, according to NVIDIA’s announcement. NVIDIA said the scheduler continues to be packaged and delivered as part of the NVIDIA Run:ai platform.

According to NVIDIA, the scheduler recalculates fair-share values on an ongoing basis and adjusts quotas and limits in real time, combining gang scheduling, GPU sharing, and hierarchical queuing, while a built-in podgrouper automatically connects workloads with frameworks including Kubeflow, Ray, Argo, and the Training Operator. NVIDIA describes a scheduling cycle that captures a snapshot of the Kubernetes cluster, computes a fair share for each queue through deserved-quota and over-quota phases, and then applies allocate, consolidation, reclaim, and preempt actions to bring current allocations in line with the computed state.

GPU Sharing and Quota Scheduling in Run:ai

Lambda described the varied demands AI development places on GPUs: debugging sessions may need only part of one GPU, evaluations can fan out into many independent jobs, and distributed training can require large numbers of tightly connected GPUs at once, with requirements shifting as work moves from early ideas through experiments to production. When small jobs receive whole GPUs, researchers wait while reserved capacity goes unused, and teams can find their experiments stuck behind another group’s reserved but idle GPUs.

Run:ai, as Lambda describes it, is a GPU scheduler for Kubernetes that goes beyond the default Kubernetes scheduler in two ways: GPU sharing, which lets more than one workload run on a single GPU, and quota-based scheduling, which gives each team a guaranteed allocation while letting teams borrow idle capacity from one another.

NVIDIA’s GPU fractions documentation states that fractions divide GPU memory into smaller chunks that multiple workloads can share, with each workload’s requested memory size enforced so that it cannot exceed its request or encroach on another workload’s memory. Each pod receives its own separate virtual memory address space, an arrangement the documentation calls a “logical GPU.”

Fractions use NVIDIA’s time-slicing to share GPU compute by default, according to the documentation, and multi-GPU fractions allocate the same fraction size across several GPUs within a single node: a model that uses 8 GPUs and requires 40GB of memory per GPU, for example, can be allocated 8×40GB rather than the full memory of each GPU, leaving 40GB on each GPU available to other workloads on that node. The documentation notes that GPU fractions and Multi-Instance GPU (MIG) mode cannot be used on the same node.

NVIDIA’s scheduler concepts documentation states that every newly created pod is assigned to a pod group, and that gang scheduling means a workload made up of multiple pods is either fully scheduled or fully pending. A scheduling queue is created for each project and department per node pool; deserved quotas bound what non-preemptible workloads can run, while over-quota resources are available only to preemptible workloads. The scheduler computes a fairshare value for each project and department per node pool, and when one queue sits below its fairshare while another exceeds it, the scheduler shifts resources between queues to rebalance, a process that can preempt over-quota preemptible workloads. It can also reclaim resources between projects and departments, and administrators can set bin-pack or spread placement strategies per node pool.

Node Auto-Remediation in LKS

Lambda noted that sharing and preemption both assume the GPU underneath is healthy, and that at scale this is not a given: accelerators throw XID errors, NVLink and PCIe links degrade, memory rows get remapped, and InfiniBand ports drop below their expected rate. A scheduler cannot distinguish a healthy GPU from a failing one, so it continues sending jobs to a node that drops them.

Lambda said auto-remediation is already shipping in LKS. The company said it monitors every node for such faults and exposes each one as a standard Kubernetes node condition; when a condition fires, the node is cordoned against new work, running jobs are drained, and the fault is either corrected automatically or escalated to hardware repair, with the node returning to service only after it revalidates.

Lambda’s Managed Kubernetes documentation describes the service as a Kubernetes environment with GPU and InfiniBand (RDMA) support and shared persistent storage across all nodes in a 1-Click Cluster. The NVIDIA GPU Operator and NVIDIA Network Operator come preinstalled, and the service runs continuous validation to verify that GPUs, networking, and storage are functioning correctly, alongside automated node remediation to detect and recover from hardware issues.

The Managed Scheduler Library Roadmap

Lambda described GPU scheduling as the layer it deliberately leaves open, and said LKS is next headed toward what it calls an AI software library: schedulers that run on Kubernetes, Slurm and Run:ai among them, shipped as managed components that Lambda validates against its own hardware and keeps current, instead of customers assembling them by hand from Helm charts. Run:ai is a first-class target for that library, and Lambda said it is working with NVIDIA to get there.

According to Lambda, the open-source release is what enables this approach: the company can package, test, and maintain Run:ai inside LKS itself rather than handing customers a set of integration instructions. Lambda said it is aiming for an out-of-the-box integration in which it owns packaging, validation, and ongoing operations.

Lambda, which produces open research of its own, said it values being able to inspect, adapt, and improve the tools it depends on, and described NVIDIA’s decision as extending that freedom to orchestration.