Система Tunix від Google усуває вузьке місце, яке заважало ефективному використанню TPU у масштабному агентному навчанні з підкріпленням (RL). Відокремлюючи процес генерації даних про взаємодію від процесу оновлення стратегії (policy), Tunix підвищує рівень використання TPU з одноцифрових показників до майже повної потужності, кардинально скорочуючи марнування обчислювальних ресурсів.

Вузьке місце в агентному RL

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

Розділена архітектура Tunix

Tunix вирішує цю проблему, переносячи два етапи — генерацію траєкторій та оптимізацію стратегії — на окремі пули обладнання.

  • Асинхронні актори (Asynchronous actors) працюють на недорогих CPU або GPU. Кожен актор постійно взаємодіє зі своїм призначеним середовищем, записує дії та спостереження, а потім передає отримані траєкторії у спільне сховище.
  • Безперервні учні (Continuous learners) займають виділені TPU Pods. Учень забирає пакети даних із центрального буфера та виконує оновлення градієнта, не чекаючи завершення розгортання (rollout) жодного окремого актора.
  • Високопродуктивний буфер (High-throughput buffer) розташований посередині, виконуючи роль зони підготовки траєкторій. Оскільки учень може зчитувати дані так само швидко, як буфер може їх постачати, TPU ніколи не простоює.

Загальним результатом є конвеєр навчання, де TPU зайняті майже весь час, що наближає рівень використання до 100%.

Технічні перешкоди та те, як Tunix їх долає

Епізоди змінної довжини та перекомпіляція XLA

Компілятор XLA в JAX оптимізує роботу для фіксованих форм тензорів. Однак агентні завдання створюють послідовності різної довжини, що зазвичай призводить до дорогих перекомпіляцій. Tunix пакує коротші послідовності разом і групує епізоди схожої довжини в «кошики» (buckets), підтримуючи стабільність форм достатньо довго, щоб XLA міг повторно використовувати скомпільовані ядра. Результатом є стабільна пропускна здатність без накладних витрат на компіляцію, які в іншому випадку паралізували б продуктивність.

Масштабування масивних моделей на багато чипів TPU

Навчання агентів із понад 70 мільярдами параметрів вимагає розподілу ваг і даних між кількома вузлами TPU. Tunix використовує примітив ShardMap у JAX для шардування як параметрів моделі, так і активацій, що дозволяє учню тримати всю модель у пам'яті, одночасно подаючи їй дані на високій швидкості. Така стратегія шардування робить можливим навчання моделей, які раніше були недосяжними для одного TPU pod.

Застарілі градієнти у розділених конвеєрах

Коли актори випереджають учня, дані, які вони надають, можуть стати «застарілими» відносно поточної стратегії. Tunix пом'якшує цей розрив за допомогою двох механізмів: зважування за допомогою важливості вибірки (importance-sampling) перераховує старіші зразки, щоб відобразити їхню релевантність, а конфігурований поріг застарілості відкидає траєкторії, вік яких перевищує встановлений ліміт. Разом вони забезпечують стабільність навчання навіть під час асинхронної роботи конвеєра.

На що варто звернути увагу при впровадженні

  • Аудит затримки – Перевага розділення залежить від часу відгуку середовища. Командам слід вимірювати загальну затримку (end-to-end latency) і переконатися, що пули акторів масштабовані так, щоб буфер був постійно заповненим.
  • Проєктування пулу воркерів – Недорогі CPU або GPU можуть обслуговувати багато акторів, але надмірне навантаження на них може спричинити конфлікти за ресурси мережі або сховища. Необхідно створити збалансований пул, який відповідає швидкості запису в буфер.
  • Надійність буфера – Центральне сховище має витримувати високу швидкість читання та запису, не стаючи новим вузьким місцем. Вибір системи зберігання з низькою хвостовою затримкою (tail latency) та достатньою пропускною здатністю є обов'язковою частиною архітектури.

Потенційні недоліки

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

Підсумок

Tunix демонструє, що основною витратою в агентному RL є не сама модель, а час простою, спричинений синхронними циклами взаємодії. Перенісши роботу з розгортання (rollout) на дешеве обладнання та забезпечивши безперервне живлення TPU pod через високопродуктивний буфер, Google перетворила проблему використання нижче 10% на робочий процес із майже повною потужністю.