Lambda przygotowuje scheduler Run:ai typu open source do usługi Kubernetes

Lambda poinformowała 13 października 2026 roku, że współpracuje z NVIDIA, aby udostępnić scheduler GPU Run:ai, opublikowany jako oprogramowanie open source, jako pełnoprawną zarządzaną opcję w ramach Lambda Kubernetes Service (LKS), będącej częścią planowanej biblioteki schedulerów dostarczanych jako zarządzane komponenty.

Plan opisano w opublikowanym 13 października 2026 roku wpisie na blogu Lambda. „Cieszymy się z decyzji NVIDIA o udostępnieniu Run:ai jako oprogramowania open source i pracujemy nad tym, by stał się pełnoprawną opcją w Lambda Kubernetes Service (LKS)” — poinformowała firma. Lambda podała, że obsługuje Run:ai w swojej infrastrukturze od 2022 roku. Jej celem jest ułatwienie wdrażania i obsługi funkcji Run:ai za pośrednictwem LKS, tak aby zespoły zyskały większą kontrolę nad przydzielaniem i współdzieleniem zasobów GPU.

NVIDIA udostępniła scheduler jako oprogramowanie open source w 2025 roku

NVIDIA ogłosiła 1 kwietnia 2025 roku, zgodnie z komunikatem NVIDIA, udostępnienie na licencji Apache 2.0 schedulera KAI Scheduler — rozwiązania do planowania zadań GPU, natywnie obsługującego Kubernetes i pierwotnie opracowanego w ramach platformy Run:ai. NVIDIA poinformowała, że scheduler nadal jest pakowany i dostarczany jako część platformy NVIDIA Run:ai.

Według NVIDIA scheduler stale przelicza wartości sprawiedliwego udziału oraz dostosowuje limity kwotowe i ograniczenia w czasie rzeczywistym, łącząc planowanie grupowe (gang scheduling), współdzielenie GPU i hierarchiczne kolejki. Wbudowany mechanizm grupowania podów automatycznie łączy obciążenia z takimi platformami jak Kubeflow, Ray, Argo i Training Operator. NVIDIA opisuje cykl planowania, w którym tworzony jest zrzut stanu klastra Kubernetes, obliczany jest sprawiedliwy udział dla każdej kolejki w ramach etapów ustalania należnych limitów kwotowych i obsługi przekroczeń tych limitów, a następnie stosowane są działania polegające na przydzielaniu, konsolidowaniu, odzyskiwaniu i wywłaszczaniu zasobów, aby dostosować bieżące przydziały do obliczonego stanu.

Współdzielenie GPU i planowanie z uwzględnieniem limitów kwotowych w Run:ai

Lambda opisała zróżnicowane wymagania, jakie rozwój AI stawia przed procesorami GPU: sesje debugowania mogą wymagać tylko części jednego GPU, ewaluacje mogą obejmować wiele niezależnych zadań, a trening rozproszony może wymagać jednocześnie dużej liczby ściśle połączonych GPU. Wymagania zmieniają się w miarę przechodzenia od wstępnych pomysłów przez eksperymenty do środowiska produkcyjnego. Gdy małe zadania otrzymują całe procesory GPU, badacze muszą czekać, a zarezerwowane zasoby pozostają niewykorzystane; zespoły mogą też odkryć, że ich eksperymenty utknęły za zarezerwowanymi, lecz bezczynnymi procesorami GPU innej grupy.

Jak opisuje Lambda, Run:ai to scheduler GPU dla Kubernetes, który rozszerza możliwości domyślnego schedulera Kubernetes na dwa sposoby: umożliwia współdzielenie GPU, dzięki czemu na jednym procesorze GPU może działać więcej niż jedno obciążenie, oraz planowanie z uwzględnieniem limitów kwotowych, które gwarantuje każdemu zespołowi określony przydział, a zarazem pozwala zespołom pożyczać od siebie niewykorzystane zasoby.

Dokumentacja NVIDIA dotycząca ułamków GPU wyjaśnia, że ułamki dzielą pamięć GPU na mniejsze części, które mogą współdzielić różne obciążenia. Wymagany rozmiar pamięci jest egzekwowany dla każdego obciążenia, tak aby nie mogło ono przekroczyć swojego limitu ani naruszać dostępu do pamięci przydzielonej innemu obciążeniu. Każdy pod otrzymuje własną, odrębną wirtualną przestrzeń adresową pamięci — rozwiązanie to dokumentacja określa mianem „logicznego GPU”.

Zgodnie z dokumentacją ułamki domyślnie wykorzystują mechanizm dzielenia czasu NVIDIA do współdzielenia mocy obliczeniowej GPU, a ułamki wieloprocesorowe przydzielają taką samą część pamięci na kilku procesorach GPU w obrębie jednego węzła. Na przykład model korzystający z 8 GPU i wymagający 40 GB pamięci na każdym z nich może otrzymać przydział 8×40 GB zamiast pełnej pamięci każdego procesora GPU, pozostawiając 40 GB na każdym z nich do dyspozycji innych obciążeń w tym węźle. Dokumentacja zaznacza, że ułamków GPU i trybu Multi-Instance GPU (MIG) nie można używać w tym samym węźle.

Dokumentacja NVIDIA dotycząca koncepcji planowania zadań podaje, że każdy nowo utworzony pod jest przypisywany do grupy podów, a planowanie grupowe oznacza, że obciążenie składające się z wielu podów jest albo planowane w całości, albo w całości pozostaje w oczekiwaniu. Dla każdego projektu i działu w każdej puli węzłów tworzona jest kolejka planowania; limity kwotowe wynikające z należnego udziału określają, jakie obciążenia niewywłaszczalne mogą działać, natomiast zasoby przekraczające przyznany limit są dostępne wyłącznie dla obciążeń podlegających wywłaszczeniu. Scheduler oblicza wartość sprawiedliwego udziału dla każdego projektu i działu w każdej puli węzłów. Gdy jedna kolejka wykorzystuje mniej niż wynosi jej sprawiedliwy udział, a inna go przekracza, scheduler przenosi zasoby między kolejkami, aby przywrócić równowagę; w ramach tego procesu może wywłaszczać obciążenia podlegające wywłaszczeniu, które przekroczyły przyznany limit. Może także odzyskiwać zasoby między projektami i działami, a administratorzy mogą ustawiać dla każdej puli węzłów strategie rozmieszczania polegające na upakowaniu zadań lub ich rozproszeniu.

Automatyczne przywracanie sprawności węzłów w LKS

Lambda zwróciła uwagę, że współdzielenie zasobów i wywłaszczanie zakładają, iż działający pod spodem procesor GPU jest sprawny, a przy dużej skali nie można tego uznać za pewnik: akceleratory zgłaszają błędy XID, połączenia NVLink i PCIe ulegają pogorszeniu, wiersze pamięci są remapowane, a przepustowość portów InfiniBand spada poniżej oczekiwanego poziomu. Scheduler nie potrafi odróżnić sprawnego GPU od takiego, który ulega awarii, więc nadal wysyła zadania do węzła, który je przerywa.

Lambda poinformowała, że funkcja automatycznego przywracania sprawności jest już dostępna w LKS. Firma podała, że monitoruje każdy węzeł pod kątem takich usterek i zgłasza każdą z nich jako standardowy warunek węzła Kubernetes. Gdy taki warunek zostanie spełniony, węzeł jest odgradzany od nowych zadań, uruchomione zadania są z niego usuwane, a usterka zostaje naprawiona automatycznie albo zgłoszona do naprawy sprzętu. Węzeł wraca do pracy dopiero po ponownej walidacji.

Dokumentacja zarządzanego Kubernetes firmy Lambda opisuje tę usługę jako środowisko Kubernetes obsługujące procesory GPU i InfiniBand (RDMA), ze współdzieloną pamięcią masową trwałego przechowywania danych we wszystkich węzłach klastra 1-Click Cluster. NVIDIA GPU Operator i NVIDIA Network Operator są instalowane z wyprzedzeniem, a usługa stale przeprowadza kontrole, aby sprawdzać, czy procesory GPU, sieć i pamięć masowa działają prawidłowo. Obejmuje też automatyczne naprawianie węzłów, które pozwala wykrywać problemy ze sprzętem i usuwać ich skutki.

Plan rozwoju biblioteki zarządzanych harmonogramów

Lambda określiła planowanie zadań GPU jako warstwę, którą celowo pozostawia otwartą, i poinformowała, że kolejnym krokiem w rozwoju LKS będzie stworzenie tego, co nazywa biblioteką oprogramowania AI: harmonogramów działających w Kubernetes, w tym Slurm i Run:ai, dostarczanych jako zarządzane komponenty, które Lambda sprawdza pod kątem zgodności z własnym sprzętem i aktualizuje, zamiast zmuszać klientów do samodzielnego składania ich z wykresów Helm. Run:ai jest jednym z głównych celów tej biblioteki, a Lambda poinformowała, że współpracuje z NVIDIA, aby to osiągnąć.

Według Lambda to właśnie udostępnienie kodu źródłowego na otwartej licencji umożliwia takie podejście: firma może pakować, testować i utrzymywać Run:ai bezpośrednio w LKS, zamiast przekazywać klientom zestaw instrukcji integracji. Lambda poinformowała, że dąży do integracji działającej od razu po instalacji, w ramach której przejmie odpowiedzialność za pakowanie, walidację i bieżącą obsługę.

Lambda, która prowadzi również własne otwarte badania, poinformowała, że ceni sobie możliwość analizowania, dostosowywania i ulepszania narzędzi, od których zależy, oraz określiła decyzję NVIDIA jako rozszerzenie tej swobody na orkiestrację.