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. The company has supported Run: ai on its infrastructure since 2022 and now plans to package, validate and operate it inside LKS. For teams renting GPU capacity, this matters because sharing, quotas and fault handling would arrive as maintained components rather than manual setup.
How Run: ai sharing and quotas work
Details appeared in an October 13, 2026 post on Lambda's blog, where the company welcomed NVIDIA's decision to open-source Run: ai. Lambda described a planned library of schedulers delivered as managed components, with schedulers that run on Kubernetes, Slurm and Run: ai among them. NVIDIA had announced the open-source release of the KAI Scheduler, originally developed within the Run: ai platform, under the Apache 2.0 license on April 1, 2025. NVIDIA said the scheduler continues to be packaged as part of the NVIDIA Run: ai platform.
Run: ai goes beyond the default Kubernetes scheduler in two ways cited by Lambda: GPU sharing, which lets several workloads run on one GPU, and quota-based scheduling, which gives each team a guaranteed allocation while allowing borrowing of idle capacity. NVIDIA's GPU fractions documentation says fractions divide GPU memory into smaller chunks with enforced request sizes, giving each pod a separate virtual address space called a "logical GPU". Fractions use time-slicing for compute by default, and multi-GPU fractions can allocate 8x40GB across eight GPUs, leaving 40GB per GPU for other work. Fractions and Multi-Instance GPU mode cannot run on the same node.
The scheduling cycle captures a snapshot of the cluster, computes fair share per queue through deserved-quota and over-quota phases, then applies allocate, consolidation, reclaim and preempt actions. Every new pod joins a pod group, and gang scheduling means a multi-pod workload is either fully scheduled or fully pending. A queue is created for each project and department per node pool, deserved quotas bound non-preemptible work, and over-quota capacity goes only to preemptible work. A built-in podgrouper links workloads to Kubeflow, Ray, Argo and the Training Operator, and administrators can set bin-pack or spread placement per node pool.
What this means for AI infrastructure buyers
For companies training and evaluating models on shared clusters, the practical effect is higher utilization without manual coordination of who may use idle GPUs. Debugging that needs part of one GPU, evaluations that fan out into many jobs, and distributed training that needs many tightly connected GPUs could coexist under guaranteed quotas with borrowing. Small teams gain predictable access plus a chance to use spare capacity, while large organizations get department-level quotas and rebalancing when one queue sits below fair share and another exceeds it. Shared storage, GPU with InfiniBand RDMA support and preinstalled NVIDIA GPU and Network Operators in 1-Click Clusters reduce assembly work.
The limits sit in hardware health, placement choices and operational ownership. Lambda noted that sharing and preemption assume a healthy GPU, yet accelerators throw XID errors, NVLink and PCIe links degrade, memory rows get remapped and InfiniBand ports drop below expected rates. LKS already ships auto-remediation that exposes faults as Kubernetes node conditions, cordons the node, drains jobs and returns it only after revalidation or hardware repair. Buyers still need to confirm which scheduler version is validated, how preemptible jobs are marked, which placement strategy applies per pool, and whether MIG or fractions fit their nodes.
The marker to watch is Lambda's out-of-the-box integration in which it owns packaging, validation and ongoing operations for Run: ai inside LKS. Its appearance would show that open-source licensing translates into a maintained scheduler library rather than integration instructions. If follow-up releases keep the component current against Lambda hardware, procurement of GPU orchestration will shift from Helm assembly to selecting a supported option.
