Ai2 9 жовтня 2026 року описала, як замінила пріоритетний планувальник GPU-кластерів системою бюджетів часу та ієрархічного розподілу ресурсів.
Ремонтів, що потребували участі людини, стало на 74% менше, а зайнятість кластера (occupancy) залишилася на рівні 98%, за даними Ecosistema Startup, яке переказує результати Ai2. Частка часу, протягом якого GPU були призначені задачам, не змінилася. Змінилися правила розподілу цього часу між командами.
Що пішло не так із пріоритетним планувальником?
Пріоритетний планувальник Ai2 дозволяв командам без витрат із бюджету ставити HIGH-пріоритет і захищати задачі від витіснення (preemption). Ai2 керує тисячами GPU NVIDIA H100, B200 і B300 у кластерах від 88 до 1024 карт для близько 150 дослідників. Заявок на GPU в будь-який момент у 2–3 рази більше, ніж доступних карт, за даними Ai2.
Дослідники залишали порожні задачі працювати, щоб підключатися до них для налагодження в реальному часі: запуск нової debug-задачі займав надто багато часу. Згодом 100% запланованих задач мали HIGH-пріоритет, і нижчі рівні не отримували GPU-часу взагалі. Чергові інженери витрачали більшість часу на опрацювання тікетів, домовляючись про зупинку захищених від витіснення задач на хостах із відомими проблемами.
Спершу Ai2 посилювала контроль над пріоритетами, потім віддала важливим проєктам монополії на набори GPU. Через це карти простоювали: команди були готові до експериментів у різний час, тож одна могла не використовувати свої ресурси, поки інша стояла в черзі.
Ai2 називає конкуренцію за дефіцитний спільний ресурс «трагедією спільних ресурсів» і нагадує статтю Ghodsi зі співавторами 2011 року про Dominant Resource Fairness. У наведеному там прикладі пошукова компанія видавала окремі машини лише за умови високого завантаження, а користувачі вставляли в код нескінченні цикли, щоб штучно підвищити цей показник.
Як працює схема з бюджетами GPU-часу?
Нова схема Ai2 розподіляє частки GPU-часу між проєктами та дослідниками через ієрархію бюджетів. Керівники визначають ці частки заздалегідь відповідно до дослідницьких пріоритетів. Проєкт A1 у прикладі Ai2 має гарантовану частку 35% загальної потужності незалежно від кількості інших проєктів у черзі.
Кожен запит на GPU-час потребує бюджету, щоб отримати захист від витіснення. Порожня задача тепер витрачає бюджет своєї команди. Ai2 прагне зробити маніпуляції з планувальником дорожчими для команди, ніж обговорення більшого бюджету.
Ecosistema Startup описує два механізми розподілу часу:
- Ієрархічний fair-share із ковзним вікном, за замовчуванням 7 днів. Планувальник упорядковує задачі за співвідношенням фактичного споживання та виділеного бюджету. Команда, яка раніше використала менше своєї частки, може згодом тимчасово отримати більше ресурсів. За описом видання, подібний підхід застосовують SLURM Fair Tree і YARN Fair Scheduler.
- Контракт time-slicing. Кожна задача заявляє мінімальний час роботи, протягом якого її захищено від витіснення. Після цього планувальник може перерозподілити ресурси й повернути задачу в чергу. Якщо мінімум дорівнює нулю, задача не витрачає бюджет, але її можуть перервати будь-коли.
Контракт зменшив навантаження на чергових інженерів. Коли хост потребує ремонту, система чекає, поки задачі відпрацюють свій мінімальний час, і автоматично звільняє хост. Ecosistema Startup пов’язує з цим скорочення кількості ремонтів, що потребували участі людини, на 74%.
Що показали 30 днів тестування в продакшні?
Планувальник Ai2 забезпечив командам 98% GPU-годин, належних їм за бюджетами, за результатами 30-денного тестування, наведеними Ecosistema Startup. Поетапний запуск у кластерах почався наприкінці липня 2026 року. Із 15 команд 13 отримали щонайменше 95% належного часу, найнижчий результат становив 90%.
Час очікування p90 для debug-задач скоротився з 2 годин до 30 секунд. Симуляція на історичному журналі задач прогнозувала скорочення з 6 годин до 5 хвилин. Початкові значення в симуляції та продакшні відрізнялися, тому ці результати не варто трактувати як однаковий експеримент.
Ai2 перевіряла гіпотезу, що короткі debug-задачі на 1–2 GPU з мінімальним часом роботи до 15 хвилин швидше отримуватимуть ресурси, бо для них легше знайти вільне місце в кластері. За переказом Ecosistema Startup, результати в продакшні підтвердили цю гіпотезу.
На найбільшому кластері H100 медіанний час очікування в черзі скоротився з 5 хвилин до 24 секунд, а p90 — з 2,8 до 1,8 години. Попит при цьому залишався у 2–3 рази вищим за доступну потужність.
Зайнятість кластера становила 98% до і після зміни. Із наданого GPU-часу 18% припадало на задачі без виділеного бюджету: вони займали вільні ресурси, коли команди з бюджетом не були готові запускати свої задачі.
Дослідник Chris Clark описав суб’єктивне враження від системи як 30% додаткових обчислювальних ресурсів. За його словами в переказі Ecosistema Startup, команда може компенсувати попереднє недовикористання своєї частки, тимчасово запускаючи більше задач без витіснення. Це оцінка користувача, а не виміряне збільшення потужності кластера.
Наведені результати походять від Ai2; надані джерела не містять незалежної перевірки цих показників.
Що сталося з інтерактивними сесіями?
Інтерактивні сесії Ai2 втрачали стан, який зберігався в пам’яті, після витіснення. У старій системі сесії для аналізу даних і тестування коду могли тривати до тижня. У новій системі верхня межа мінімального захищеного часу роботи становила 8 годин, після яких планувальник міг перервати сесію.
Ai2 запланувала окремий CPU-кластер поруч із локальним сховищем для підготовки даних і dev-сесій. Також інститут працює над відновлюваними сесіями: їх можна буде перервати для обслуговування або перерозподілу ресурсів і відновити на іншому хості без ручного відтворення стану.
