Идея Looped Transformer — одна из самых обсуждаемых архитектурных тем последнего времени. В новом техническом отчёте её предлагают развернуть иначе: цикл теперь растягивается не внутри одного токена, а между токенами. Архитектура получила название Recurrent Looped Transformer, и суть в том, что декодер становится рекуррентным — причём и для запроса, и для ответа.
От цикла внутри токена к циклу между токенами
Классический looped-подход прокручивает одни и те же блоки несколько раз, чтобы «додумать» представление конкретного токена. Здесь ставка другая: состояние переходит от токена к токену, и именно эта цепочка становится источником дополнительных вычислений. Один и тот же переход между состояниями повторяется вдоль всей последовательности.
Для практика разница принципиальная. Раньше рост «размышления» ограничивался фиксированным числом прогонов внутри шага. Теперь он привязан к длине контекста — чем длиннее последовательность, тем больше вычислительных шагов проходит сигнал.
Как устроен поток данных
Каузальный энкодер формирует общую KV-память (кеш ключей и значений для механизма attention, доступный всем шагам). Дальше для каждого нового токена декодер объединяет три вещи:
- представление этого токена, полученное от энкодера;
- собственное финальное скрытое состояние от предыдущего токена;
- кеш недавних активаций со скользящим окном.
То есть декодер не начинает с чистого листа на каждом шаге — он тащит за собой и результат энкодера, и собственную историю. Скользящее окно при этом ограничивает, сколько именно прошлых активаций удерживается в памяти.
Арифметика глубины: 48 слоёв превращаются в 48t
Возьмём декодер из 48 слоёв. После обработки t токенов путь вычислений проходит уже через 48t блоков декодера — при том что каждый отдельный токен по-прежнему прогоняется через фиксированное число блоков.
Это ключевой компромисс всей конструкции: глубина вычислений растёт вместе с длиной последовательности, а стоимость обработки одного токена остаётся постоянной. Аккуратный способ получить больше «времени на подумать», не раздувая сеть вширь и не увеличивая число слоёв до неприличных величин.
Один переход состояний на весь пайплайн
Автор подчёркивает универсальность механизма: один и тот же переход между состояниями используется и в предварительном обучении, и в SFT (supervised fine-tuning, дообучение на размеченных примерах), и в генерации, и при повторном воспроизведении в RL.
Отдельно отмечу деталь, которая важна для тех, кто работает с агентами и длинными диалогами: на границе между запросом и ответом состояние не сбрасывается. Модель не «забывает», что она только что прочитала промпт, — контекст запроса остаётся частью той же рекуррентной цепочки.
Вторая деталь касается RL replay. Состояния там строятся заново с текущими весами модели, а не переиспользуются из прошлых запусков. Это устраняет известную головную боль: устаревшие состояния, посчитанные старой версией весов, больше не подмешиваются в обучение.
Что пока не измерено
Здесь стоит притормозить. Это именно архитектурное предложение, а не подтверждённый результат. Автор прямо пишет, что прирост в рассуждениях, ускорение на железе и масштабирование RL — это цели, которые ещё не были измерены.
И это честная позиция. В вайбкодинге мы привыкли, что скорость итераций важнее идеальной строгости, но в архитектурных исследованиях цена ошибки другая: красивая схема может упереться в память, в latency или в то, что выигрыш просто не материализуется. Пока нет цифр — нет и оснований планировать на этой архитектуре продакшн. Но следить за направлением стоит: идея растить глубину вычислений вместе с длиной контекста выглядит куда естественнее, чем бесконечное наращивание числа слоёв.
Выводы
- Recurrent Looped Transformer делает декодер рекуррентным для каждого токена, включая и запрос, и ответ.
- Каузальный энкодер даёт общую KV-память, а декодер на каждом шаге объединяет представление токена, своё предыдущее финальное скрытое состояние и кеш недавних активаций со скользящим окном.
- При декодере из 48 слоёв путь вычислений после t токенов проходит через 48t блоков, хотя каждый токен обрабатывается фиксированным числом блоков: глубина растёт с длиной последовательности, стоимость токена — нет.
- Один переход состояний обслуживает предварительное обучение, SFT, генерацию и RL replay; состояние не сбрасывается на границе запроса и ответа, а при RL replay пересобирается с актуальными весами.
- Заявленные выигрыши в рассуждениях, скорости на железе и масштабировании RL пока не измерены — это архитектурное предложение, а не подтверждённый результат.