Моделі та платформи ШІ
Lambda готує планувальник Run:ai з відкритим вихідним кодом для сервісу Kubernetes
Додайте Unite.AI до бажаних джерел у Google
13 жовтня 2026 року Lambda повідомила, що співпрацює з NVIDIA, аби зробити планувальник графічних процесорів Run:ai з відкритим вихідним кодом повноцінною керованою опцією в Lambda Kubernetes Service (LKS) — частиною запланованої бібліотеки планувальників, які надаватимуться як керовані компоненти.
Про цей план повідомили у дописі в блозі Lambda від 13 жовтня 2026 року. «Ми вітаємо рішення NVIDIA відкрити вихідний код Run:ai та працюємо над тим, щоб зробити його повноцінною опцією в Lambda Kubernetes Service (LKS)», — заявила компанія. Lambda повідомила, що підтримує Run:ai у своїй інфраструктурі з 2022 року, а мета компанії — спростити впровадження й експлуатацію можливостей Run:ai через LKS, щоб команди мали більше контролю над розподілом і спільним використанням ресурсів графічних процесорів.
NVIDIA відкрила вихідний код планувальника у 2025 році
1 квітня 2025 року NVIDIA оголосила про випуск KAI Scheduler із відкритим вихідним кодом — рішення для планування завдань на графічних процесорах, створеного для Kubernetes і спершу розробленого в межах платформи Run:ai, — за ліцензією Apache 2.0, як повідомила NVIDIA. NVIDIA заявила, що планувальник і надалі входитиме до складу платформи NVIDIA Run:ai та постачатиметься як її частина.
За даними NVIDIA, планувальник постійно перераховує показники справедливого розподілу й коригує квоти та ліміти в режимі реального часу, поєднуючи групове планування, спільне використання графічних процесорів і ієрархічну систему черг. Вбудований podgrouper автоматично пов’язує робочі навантаження з такими фреймворками, як Kubeflow, Ray, Argo і Training Operator. NVIDIA описує цикл планування, під час якого знімається копія стану кластера Kubernetes, для кожної черги обчислюється справедлива частка з урахуванням етапів належної квоти та перевищення квоти, а потім виконуються дії з розподілу, консолідації, повернення та витіснення ресурсів, щоб узгодити поточний розподіл із розрахованим станом.
Спільне використання графічних процесорів і планування за квотами в Run:ai
Lambda описала різноманітні потреби розробки ШІ в ресурсах графічних процесорів: для налагодження може вистачити частини одного графічного процесора, оцінювання може передбачати запуск багатьох незалежних завдань, а розподілене навчання може одночасно потребувати великої кількості тісно пов’язаних між собою графічних процесорів. Потреби змінюються в міру того, як робота переходить від перших задумів до експериментів і виробничого середовища. Якщо невеликим завданням виділяють цілі графічні процесори, дослідникам доводиться чекати, поки зарезервовані ресурси простоюють; команди також можуть виявити, що їхні експерименти заблоковані через зарезервовані, але не задіяні графічні процесори іншої групи.
За описом Lambda, Run:ai — це планувальник графічних процесорів для Kubernetes, який має дві переваги над стандартним планувальником Kubernetes: спільне використання графічних процесорів, що дає змогу запускати на одному графічному процесорі кілька робочих навантажень, і планування за квотами, яке гарантує кожній команді виділений обсяг ресурсів, водночас дозволяючи командам позичати невикористані ресурси одна в одної.
У документації NVIDIA щодо часток ресурсів графічного процесора зазначено, що пам’ять графічного процесора можна поділити на менші частини, спільно використовувані кількома робочими навантаженнями. Обсяг пам’яті, запитаний кожним навантаженням, обмежується: він не може перевищувати запитаний обсяг або займати пам’ять, призначену іншому навантаженню. Кожен pod отримує окремий простір віртуальних адрес пам’яті; у документації таку конфігурацію названо «логічним графічним процесором».
Згідно з документацією, за замовчуванням частки використовують механізм розподілу обчислювальних ресурсів графічного процесора NVIDIA з поділом часу. Частки для кількох графічних процесорів виділяють однаковий обсяг на кожному з них у межах одного вузла: наприклад, моделі, яка використовує 8 графічних процесорів і потребує 40 ГБ пам’яті на кожному, можна виділити 8×40 ГБ замість усієї пам’яті кожного графічного процесора, залишивши по 40 ГБ на кожному для інших робочих навантажень цього вузла. У документації зазначено, що частки графічних процесорів і режим Multi-Instance GPU (MIG) не можна використовувати на одному вузлі одночасно.
У документації NVIDIA з основних понять планувальника зазначено, що кожен новостворений pod призначається до групи pod-ів, а групове планування означає, що робоче навантаження з кількох pod-ів або запускається повністю, або повністю залишається в черзі очікування. Для кожного проєкту й відділу в кожному пулі вузлів створюється черга планування; належні квоти обмежують обсяг ресурсів, доступний для непереривних робочих навантажень, тоді як ресурси понад квоту доступні лише для робочих навантажень, які можна перервати. Планувальник обчислює показник справедливого розподілу для кожного проєкту й відділу в кожному пулі вузлів; якщо одна черга використовує менше за свою справедливу частку, а інша — більше, планувальник перерозподіляє ресурси між чергами для балансування. Унаслідок цього можуть перериватися робочі навантаження, які можна перервати й які використовують ресурси понад квоту. Планувальник також може повертати ресурси між проєктами й відділами, а адміністратори можуть налаштувати для кожного пулу вузлів стратегію розміщення з ущільненням або рівномірним розподілом.
Автоматичне відновлення вузлів у LKS
Lambda зауважила, що спільне використання ресурсів і витіснення завдань передбачають справний графічний процесор, але у великих масштабах це не гарантовано: прискорювачі видають помилки XID, канали NVLink і PCIe деградують, рядки пам’яті перемаповуються, а пропускна здатність портів InfiniBand падає нижче очікуваного рівня. Планувальник не може відрізнити справний графічний процесор від несправного, тож продовжує надсилати завдання на вузол, який їх відхиляє.
Lambda повідомила, що автоматичне відновлення вже впроваджується в LKS. Компанія стверджує, що відстежує такі несправності на кожному вузлі та відображає їх як стандартний стан вузла Kubernetes. Щойно спрацьовує відповідна умова, вузол ізолюється від нових завдань, запущені завдання виводяться з нього, а несправність автоматично усувається або передається на ремонт обладнання. Вузол повертається до роботи лише після повторної перевірки.
Документація Lambda щодо керованого Kubernetes описує сервіс як середовище Kubernetes із підтримкою GPU та InfiniBand (RDMA) і спільним постійним сховищем для всіх вузлів кластера 1-Click Cluster. NVIDIA GPU Operator і NVIDIA Network Operator встановлюються заздалегідь, а сервіс постійно перевіряє, чи належно працюють GPU, мережа та сховище, і автоматично усуває проблеми на вузлах, щоб виявляти апаратні несправності й відновлювати роботу після них.
План розвитку бібліотеки керованих планувальників
Lambda описала планування GPU як рівень, який вона свідомо залишає відкритим, і повідомила, що наступним кроком для LKS стане те, що компанія називає бібліотекою програмного забезпечення для ШІ: планувальники, які працюють на Kubernetes, зокрема Slurm і Run:ai, постачатимуться як керовані компоненти, перевірені Lambda на власному обладнанні та своєчасно оновлювані, замість того щоб клієнти самостійно збирали їх із діаграм Helm. Run:ai — один із ключових компонентів цієї бібліотеки, і Lambda повідомила, що працює з NVIDIA, щоб цього досягти.
За словами Lambda, саме випуск програмного забезпечення з відкритим кодом уможливлює такий підхід: компанія може інтегрувати Run:ai в LKS, тестувати й підтримувати його там, а не просто надавати клієнтам набір інструкцій з інтеграції. Lambda повідомила, що прагне забезпечити готову до використання інтеграцію, взявши на себе пакування, перевірку та подальшу експлуатацію.
Lambda, яка сама створює відкриті дослідницькі розробки, повідомила, що цінує можливість перевіряти, адаптувати й удосконалювати інструменти, від яких залежить, і зазначила, що рішення NVIDIA поширює цю свободу й на оркестрацію.
