Lambda готовит планировщик Run:ai с открытым исходным кодом для своего сервиса Kubernetes

13 октября 2026 года Lambda сообщила, что работает с NVIDIA над тем, чтобы планировщик GPU Run:ai с открытым исходным кодом стал полноценной управляемой опцией в Lambda Kubernetes Service (LKS), которая войдет в запланированную библиотеку планировщиков, поставляемых в качестве управляемых компонентов.

Об этом плане Lambda сообщила в публикации в своем блоге от 13 октября 2026 года. «Мы приветствуем решение NVIDIA открыть исходный код Run:ai и работаем над тем, чтобы этот планировщик стал полноценной опцией в Lambda Kubernetes Service (LKS)», — заявила компания. Lambda сообщила, что поддерживает Run:ai на своей инфраструктуре с 2022 года, и описала свою цель как упрощение внедрения и эксплуатации возможностей Run:ai через LKS, чтобы команды получили больше контроля над распределением ресурсов GPU и совместным доступом к ним.

NVIDIA открыла исходный код планировщика в 2025 году

1 апреля 2025 года NVIDIA объявила о выпуске KAI Scheduler с открытым исходным кодом под лицензией Apache 2.0 — решения для планирования задач GPU, созданного специально для Kubernetes и первоначально разработанного в рамках платформы Run:ai, согласно объявлению NVIDIA. NVIDIA сообщила, что планировщик по-прежнему включен в платформу NVIDIA Run:ai и поставляется в ее составе.

По данным NVIDIA, планировщик непрерывно пересчитывает значения справедливой доли и корректирует квоты и ограничения в режиме реального времени, сочетая групповое планирование, совместное использование GPU и иерархическое управление очередями. Встроенный группировщик подов автоматически связывает рабочие нагрузки с такими фреймворками, как Kubeflow, Ray, Argo и Training Operator. NVIDIA описывает цикл планирования, в ходе которого создается снимок состояния кластера Kubernetes, для каждой очереди рассчитывается справедливая доля с учетом квот в пределах этой доли и превышения квоты, а затем применяются действия по выделению, консолидации и возврату ресурсов, а также вытеснению задач, чтобы привести текущее распределение ресурсов в соответствие с рассчитанным состоянием.

Совместное использование GPU и планирование по квотам в Run:ai

Lambda описала, насколько различаются потребности разработки ИИ в ресурсах GPU: для отладки может быть достаточно части одного GPU, оценка моделей может потребовать запуска множества независимых заданий, а распределенное обучение — одновременно большого количества тесно связанных GPU. При этом потребности меняются по мере того, как работа проходит путь от первых идей через эксперименты к промышленной эксплуатации. Если небольшим заданиям выделяют целые GPU, исследователям приходится ждать, пока зарезервированные ресурсы простаивают; кроме того, команды могут обнаружить, что их эксперименты заблокированы из-за зарезервированных, но не используемых GPU другой группы.

По описанию Lambda, Run:ai — это планировщик GPU для Kubernetes, который расширяет возможности стандартного планировщика Kubernetes в двух отношениях: совместное использование GPU позволяет запускать на одном GPU более одной рабочей нагрузки, а планирование на основе квот гарантирует каждой команде выделенную долю ресурсов и позволяет командам заимствовать простаивающие ресурсы друг у друга.

В документации NVIDIA о разделении GPU на доли указано, что память GPU делится на небольшие части, которыми могут совместно пользоваться несколько рабочих нагрузок. Для каждой нагрузки принудительно соблюдается заданный размер запрашиваемой памяти: она не может использовать больше запрошенного объема или занимать память, выделенную другой нагрузке. Каждый под получает отдельное виртуальное адресное пространство памяти; в документации такая организация называется «логическим GPU».

Согласно документации, по умолчанию для совместного использования вычислительных ресурсов GPU между долями применяется временное разделение NVIDIA. При использовании долей на нескольких GPU одинаковый размер доли выделяется на нескольких GPU в пределах одного узла. Например, модели, использующей 8 GPU и требующей 40 ГБ памяти на каждом, можно выделить 8×40 ГБ вместо всей памяти каждого GPU, оставив на каждом GPU по 40 ГБ для других рабочих нагрузок на этом узле. В документации отмечается, что доли GPU и режим Multi-Instance GPU (MIG) нельзя использовать на одном и том же узле.

В документации NVIDIA о принципах работы планировщика указано, что каждому вновь созданному поду назначается группа подов, а групповое планирование означает, что рабочая нагрузка, состоящая из нескольких подов, либо планируется целиком, либо целиком остается в ожидании. Для каждого проекта и отдела в каждом пуле узлов создается очередь планирования; квоты в пределах справедливой доли ограничивают объем ресурсов, доступный непрерываемым рабочим нагрузкам, а ресурсы сверх квоты могут использовать только прерываемые рабочие нагрузки. Планировщик рассчитывает значение справедливой доли для каждого проекта и отдела в каждом пуле узлов. Если одна очередь использует меньше своей справедливой доли, а другая превышает свою, планировщик перераспределяет ресурсы между очередями для балансировки; при этом могут вытесняться прерываемые рабочие нагрузки, использующие ресурсы сверх квоты. Планировщик также может возвращать ресурсы между проектами и отделами, а администраторы могут настраивать для каждого пула узлов стратегии размещения с максимальным уплотнением или равномерным распределением.

Автоматическое восстановление узлов в LKS

Lambda отметила, что совместное использование ресурсов и вытеснение задач предполагают исправное состояние GPU, но в масштабных системах это не гарантировано: на ускорителях возникают ошибки XID, соединения NVLink и PCIe деградируют, строки памяти переназначаются, а пропускная способность портов InfiniBand падает ниже ожидаемого уровня. Планировщик не может отличить исправный GPU от неисправного и поэтому продолжает отправлять задания на узел, который их теряет.

По словам 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 распространяет эту свободу и на оркестрацию.