NVIDIA ogłosiła 13 października 2026 r. udostępnienie całej platformy Run:ai jako open source — wraz z płaszczyzną sterowania (control plane) i usługami klastrowymi. Run:ai działa na Kubernetes i służy do zarządzania zasobami GPU oraz orkiestracji obciążeń AI, czyli koordynowania ich uruchamiania i obsługi.
Co obejmuje wydanie open source
Kompletna instalacja Run:ai składa się z płaszczyzny sterowania oraz co najmniej jednego klastra Run:ai. Płaszczyzna sterowania centralizuje zarządzanie zasobami, przesyłanie obciążeń, monitorowanie i analitykę; usługi klastrowe rozszerzają możliwości planowania i zarządzania obciążeniami w Kubernetes. NVIDIA opisała zakres wydania, a dokumentacja instalacji przedstawia architekturę platformy.
Oficjalne repozytorium wskazuje Apache License 2.0 dla kodu oprogramowania. Część zagnieżdżonego kodu i zasobów stron trzecich ma osobne licencje wymienione w repozytorium. Run:ai w GitHub
NVIDIA udostępnia obrazy platformy open source i wykresy Helm w NGC bez klucza API. Pobranie Community Product wymaga jednak zaakceptowania właściwej umowy licencyjnej NVIDIA oraz warunków dotyczących konkretnego produktu. Community Product nie wymaga płatnej subskrypcji Run:ai ani uprawnienia do wsparcia, ale nie obejmuje wsparcia technicznego NVIDIA dla przedsiębiorstw. Wydanie Support-Entitled wymaga klucza API NGC i zapewnia umowy SLA dotyczące wsparcia oraz inne uprawnienia.
Do czego służą komponenty Run:ai
NVIDIA wskazuje cztery niezależnie wdrażane komponenty. Każdy odpowiada za inną część pracy z obciążeniami AI i zasobami GPU.
| Komponent | Funkcja | Granica lub zależność |
| KAI Scheduler | Planuje uruchamianie obciążeń GPU. Obsługuje m.in. planowanie grupowe, sprawiedliwy podział zasobów i kwoty, rozmieszczanie z uwzględnieniem topologii, współdzielenie GPU oraz Dynamic Resource Allocation. | Może działać w istniejącym klastrze bez pełnej platformy Run:ai. |
| GPU Fractioning Operator | Integruje z Kubernetes natywne dla CUDA ułamkowe przydziały GPU i udostępnia metryki dla poszczególnych podów. Sterownik CUDA egzekwuje limit pamięci GPU dla przydzielonej części. | Nie zależy od konkretnego schedulera; wykorzystuje możliwości dostępne w CUDA 13.4. |
| KAI Resource Management | Porządkuje zasoby według projektów i działów oraz zarządza przydziałami, gwarancjami, współdzieleniem, sprawiedliwym podziałem i kwotami. Grupuje sprzęt w pule węzłów. | Można go łączyć z KAI Scheduler. |
| Workload Map | Biblioteka Go do opisywania i zarządzania różnymi typami obciążeń Kubernetes, m.in. ich wykrywania, stanu, kondycji i integracji z politykami. Może działać offline na nieustrukturyzowanych obiektach. | Samodzielnie nie planuje ani nie kolejkuje zadań, nie skaluje ich automatycznie i nie przenosi obciążeń między klastrami. |
NVIDIA opisuje funkcje i granice tych komponentów w ogłoszeniu o wydaniu. W praktyce zespół może dobrać KAI Scheduler do planowania zadań, GPU Fractioning Operator do dzielenia zasobów GPU, a KAI Resource Management do organizowania przydziałów w zespołach. Workload Map porządkuje opisy obciążeń, ale nie zastępuje schedulera.
Jak wygląda wdrożenie Run:ai
Płaszczyzna sterowania i pierwszy klaster mogą działać w tym samym klastrze Kubernetes. Można też umieścić je w osobnych klastrach — wtedy potrzebują łączności sieciowej. NVIDIA opisuje wdrożenia na Kubernetes i OpenShift, zarówno w środowiskach połączonych z siecią, jak i odizolowanych.
Dokumentacja NVIDIA wymienia trzy ścieżki instalacji: Guided Installation, Manual Helm i Base Command Manager. Ta ostatnia jest przeznaczona wyłącznie dla wydania Support-Entitled. Szczegóły wdrożenia i dostępu
Co zapewnia operator
Samodzielne wdrożenie oznacza, że operator dostarcza i obsługuje sprzęt, system operacyjny, dystrybucję Kubernetes, sieć oraz pamięć masową. Dokumentacja NVIDIA wymienia też GPU Operator i Prometheus wśród wymagań wstępnych. NVIDIA odpowiada za obrazy platformy Run:ai i wykresy Helm, ale udostępnienie oprogramowania nie zapewnia infrastruktury ani wsparcia enterprise.
Dla zespołu oceniającego platformę kluczowe są więc dwie osobne decyzje: który komponent odpowiada potrzebom klastra oraz czy organizacja sama zapewni jego infrastrukturę i obsługę, czy wybierze wydanie z uprawnieniami do wsparcia NVIDIA.
