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

Узкое место в агентном RL

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

Развязанная архитектура Tunix

Tunix решает эту проблему, распределяя два этапа — генерацию траекторий и оптимизацию стратегии — по отдельным пулам оборудования.

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

Итоговый эффект — конвейер обучения, в котором TPU заняты почти всё время, приближая загрузку к 100%.

Технические трудности и способы их преодоления Tunix

Эпизоды переменной длины и рекомпиляция XLA

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

Масштабирование массивных моделей на множество чипов TPU

Обучение агентов с более чем 70 миллиардами параметров требует распределения весов и данных между несколькими узлами TPU. Tunix использует примитив ShardMap в JAX для шардирования как параметров модели, так и активаций, позволяя Learner держать всю модель в памяти, сохраняя при этом высокую скорость подачи данных. Такая стратегия шардирования делает возможным обучение моделей, которые ранее были недоступны для одного TPU pod.

Устаревшие градиенты в развязанных конвейерах

Когда акторы опережают Learner, предоставляемые ими данные могут стать «устаревшими» относительно текущей стратегии. Tunix смягчает этот дрейф с помощью двух механизмов: importance sampling перевзвешивает старые образцы, чтобы отразить их актуальность, а настраиваемый порог устаревания отбрасывает траектории, возраст которых превышает заданный предел. Вместе они обеспечивают стабильность обучения даже при асинхронной работе конвейера.

На что стоит обратить внимание при внедрении

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

Потенциальные недостатки

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

Итог

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