NVIDIA передає OpenShell до CNCF і додає інструменти з відкритим кодом для ШІ-фабрик

NVIDIA оголосила 10 листопада 2026 року на KubeCon + CloudNativeCon, що передає своє середовище виконання для безпеки агентів OpenShell до пісочниці Cloud Native Computing Foundation (CNCF) і випускає три компоненти з відкритим кодом для платформи DSX AI Factory Platform.

Ці оголошення поєднують управління агентами з інфраструктурою, необхідною для їх ефективного запуску. NVIDIA також долучається до створеного Google проєкту Agent Substrate і додає до DSX Kubernetes Engine, Kubernetes Recipes і Snapshot — рішення для виконання сесій, керування кластерами та відновлення після збоїв під час інференсу.

OpenShell переходить до управління спільнотою

OpenShell застосовує детерміновані засоби контролю, коли автономні агенти користуються інструментами, отримують доступ до сервісів інференсу та виконують робочі навантаження. Агенти працюють у пісочницях з ізоляцією на рівні ядра, де доступ до файлової системи, мережі, процесів і облікових даних постачальників регулюється декларативними політиками YAML. Облікові дані додаються лише до запитів, адресованих схваленим кінцевим точкам, а формальна верифікація перевіряє, чи надасть запропонована зміна політики новий ризикований доступ, перш ніж її буде схвалено.

Середовище виконання ліцензоване за Apache 2.0. За даними NVIDIA, ним скористалися сотні організацій, за менш ніж рік надійшли десятки тисяч внесків, а в управлінні пісочницею братимуть участь організації, які інтегрують його у свої продукти. Перехід іще триває: у повідомленні проєкту зазначено, що розробка переходить до організації ai-openshell, а код, проблеми та запити на злиття на час переходу залишатимуться в NVIDIA/OpenShell.

Agent Substrate допомагає задіяти ресурси під час простою

Agent Substrate дає змогу зменшити витрати на підтримання активності сесій агентів. Агенти часто чекають на запити, результати роботи інструментів або відповіді моделей; окремий попередньо запущений под Kubernetes утримує ресурси під час таких пауз, тоді як повторне створення пода призводить до втрати стану й нового холодного запуску. NVIDIA і Google також спільно працюють над інтеграцією OpenShell для агентів, що працюють у різних хмарних середовищах і локальних системах.

Архітектура Agent Substrate дає змогу розміщувати багато сесій зі збереженням стану на меншому пулі попередньо запущених робочих вузлів. Система створює контрольні точки для неактивних сесій, зокрема зберігає стан пам’яті та файлової системи, звільняє їхні робочі вузли й відновлює сесії на доступних вузлах, не проходячи звичайний процес створення пода Kubernetes повторно. Робочі вузли залишаються звичайними подами Kubernetes, тому й надалі діють правила планування кластера, квоти та політики розміщення. Серед цільових робочих навантажень — помічники для програмування, середовища навчання з підкріпленням і короткочасні дослідницькі пісочниці на GPU.

NVIDIA розробляє сумісність із Dynamo для інференсу та KAI Scheduler для спільного використання ресурсів кластера. Dynamo може надавати прогнозований час до першого токена та дані про насиченість пулу GPU, щоб Agent Substrate міг вирішити, чи залишити агента активним, призупинити його або відновити. API досі змінюються, підтримку GPU перебудовують на основі Kubernetes Dynamic Resource Allocation, а деякі частини інтеграції з Dynamo мають експериментальний статус.

DSX додає керування кластерами та пришвидшує відновлення

NVIDIA Kubernetes Engine і NVIDIA Kubernetes Recipes доступні у відкритій попередній версії за ліцензією Apache 2.0. NVIDIA зазначає, що їхні API, конфігурація та поведінка можуть змінюватися, і поки що не рекомендує використовувати їх у робочих середовищах. NVKR створює відтворювані образи вузлів і контейнерів, двійкові файли та чарти Helm із джерел, для яких зафіксовано версії, і записує використані вхідні дані. NVKE використовує ці артефакти для розгортання кластерів і керування ними через REST API та контролери, хоча кожен проєкт можна впроваджувати окремо.

NVKE створює кластери для робочих навантажень клієнтів з окремими площинами керування Kubernetes, екземплярами etcd і пулами вузлів. Системи отримують ресурси на базі фізичних серверів через NVIDIA Infra Controller і його постачальника Cluster API — CAPNICo; перш ніж отримати облікові дані для приєднання, вузол має надати атестовану ідентичність SPIFFE. Firmus і SK Telecom інтегрують ці проєкти у свої ШІ-фабрики, а Mirantis, Netris, OpenNebula Systems, Rafay, Spectro Cloud і vCluster планують інтеграцію зі своїми інфраструктурними платформами, керованими пропозиціями Kubernetes або засобами автоматизації мереж.

NVIDIA Snapshot допомагає долати холодний запуск інференсу, створюючи контрольну точку з повністю ініціалізованого робочого навантаження, яка зберігає пам’ять CPU та GPU. Для відновлення потрібні та сама модель GPU і той самий драйвер; повторно завантажувати ваги, виконувати компіляцію та захоплювати граф CUDA не потрібно.

За даними NVIDIA, на GPU B200 із файловим сховищем VAST NFS відновлення тривало від 3,6 до 42,7 секунди в різних конфігураціях vLLM, SGLang і TensorRT LLM, що у 8–36 разів швидше за холодний запуск. Тестували моделі від 600 мільйонів параметрів і конфігурації з вісьмома GPU та контрольними точками обсягом майже 1 ТБ. Створення контрольної точки тривало від 15 секунд до 5,5 хвилини, а в кожній протестованій конфігурації створення контрольної точки разом із відновленням займало менше часу, ніж один холодний запуск.

Ці показники не відображають час запуску всієї машини: підготовка інфраструктури та завантаження образу контейнера не входять до вимірюваного етапу відновлення. Кеш ключів і значень також очищають перед створенням кожної контрольної точки, а не зберігають в артефакті, тож результати стосуються відновлення ініціалізованого робочого навантаження на сумісній інфраструктурі.

У власному тесті GLM-5.3 компанія Crusoe використала на NVIDIA HGX B300 контрольну точку, що містила 594 ГБ стану GPU. Crusoe виміряла час відновлення стану GPU: 15,0 секунди з локального NVMe проти 33,3 секунди з NFS. Коли артефакт зберігався на NVMe, від створення pod до його готовності минула 31 секунда, тоді як холодний запуск тривав приблизно вісім хвилин. Це свідчить, що сховище є важливим чинником швидкості відновлення. Crusoe також передала до основних гілок проєктів зміни для підвищення продуктивності й діагностики.

У сукупності ці проєкти переносять більшу частину площини керування фабрикою ШІ та шляху відновлення у відкриті репозиторії, але перебувають на різних етапах зрілості: перехід OpenShell до нової моделі управління ще не завершено, Agent Substrate продовжує розвиватися, а NVKE і NVKR залишаються попередніми версіями. Бенчмарки Snapshot демонструють найчіткіше виміряне покращення в роботі, тоді як вимоги до сумісності та результати Crusoe щодо сховища показують, що швидше відновлення залежить і від повторно використовуваного стану робочого навантаження, і від інфраструктури навколо нього.