Запись архива

RLT предлагает переносить состояние декодера между токенами — пока без кода и тестов

В техническом описании Recurrent Looped Transformer предложена архитектура, которая сохраняет финальное состояние рекуррентного декодера между токенами. Конфигурация с 48 слоями энкодера и 48 слоями декодера выполняет 96 логических блоков на токен, однако код, веса и результаты испытаний пока не опубликованы.

Схема энкодера и рекуррентного декодера Recurrent Looped Transformer
Схема энкодера и рекуррентного декодера Recurrent Looped Transformer
2457-Santiago de Mens en Malpica (Coruña) | by jl.cernadas | openverse | by

13 сентября 2026 года издание MarkTechPost сообщило о техническом описании Recurrent Looped Transformer — RLT. Автором идеи назван Ифань Чжан (Yifan Zhang), представленный изданием как исследователь из Принстонского университета.

RLT должен передавать финальное скрытое состояние декодера от одного токена к следующему и сохранять послойный кэш внимания со скользящим окном. Состояние не сбрасывается при переходе от пользовательского запроса к ответу модели.

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

Как RLT замыкает вычисления между токенами

В обычной декодерной LLM результат последнего слоя для токена t не поступает напрямую на первый слой при обработке токена t+1. Предыдущие позиции влияют на продолжение главным образом через сохранённые ключи и значения механизма внимания.

RLT добавляет явную рекуррентную связь. Архитектура разделена на причинный энкодер и рекуррентный декодер. Энкодер обрабатывает последовательность с каузальной маской и создаёт представление e_t для каждого токена. Из этих представлений формируется память ключей и значений, доступная декодеру через кросс-внимание.

Полное состояние декодера для позиции t записывается как H_t = (s_t, C_t^D). Здесь s_t — финальный выход декодера, а C_t^D — кэш ключей и значений для внимания со скользящим окном на всех слоях декодера.

Перед обработкой следующего токена представление энкодера e_t объединяется с предыдущим выходом s_{t-1} с помощью управляемого вентилями слияния. Затем каждый декодерный блок выполняет три основные операции:

  • причинное внимание со скользящим окном по активациям декодера;
  • кросс-внимание к памяти энкодера;
  • преобразование в полносвязной сети.

Размер окна W включает текущий токен, поэтому на каждом слое сохраняется не более W−1 исторических записей. Начальное состояние задаётся один раз перед токеном начала последовательности, после чего рекуррентная цепочка продолжается через запрос, сообщения инструментов и ответ модели.

Откуда взялись 96 блоков на токен

В эталонной конфигурации описаны 48 слоёв энкодера и 48 слоёв декодера. Они используют совместимые параметры внимания и полносвязных сетей, которые могут разделяться между двумя частями архитектуры. В результате при обработке токена выполняются 96 логических блоков.

Это число нельзя напрямую сравнивать с глубиной стандартного трансформера. У RLT декодерные блоки содержат дополнительное кросс-внимание, поэтому вычислительная стоимость энкодерного и декодерного блока различается. Кроме того, 96 логических блоков не обязательно означают 96 независимых наборов параметров: предложение опирается на повторное использование весов.

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

Формулировка «неограниченная глубина» здесь не означает бесконечный объём вычислений для одного токена. На каждом шаге по-прежнему выполняется фиксированное число блоков. Увеличивается длина пути, по которому информация и градиенты могут проходить во времени.

Обучение потребует полного контроля над состоянием

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

Это различие существенно для разработчиков обучающих систем. Если исключить внешние токены из функции потерь, но сохранить их влияние на состояние, последующие ответы всё равно будут зависеть от вычислений на этих позициях.

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

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

Связь с предыдущими рекуррентными архитектурами

Идея обратной связи между последовательными позициями уже исследовалась. В работе Feedback Transformer верхнеуровневые представления прошлых позиций используются как обратная связь для последующих вычислений. RLT отличается тем, что передаёт финальный выход декодера на следующий шаг вместе с его послойным кэшем и сохраняет эту цепочку во время обработки промпта.

Повторное применение одного набора преобразований на разных шагах глубины известно по Universal Transformers. RLT объединяет похожий принцип повторного использования параметров с рекурсией по токенам.

Организация памяти энкодера сопоставляется с архитектурой YOCO — You Only Cache Once, где ключи и значения для глобального внимания вычисляются и кэшируются один раз. Эти публикации подтверждают исследовательский контекст, однако не являются независимой проверкой заявлений о RLT.

Что проверять перед практическими выводами

Главный открытый вопрос — справится ли обучение с длинной рекуррентной цепочкой. Полное распространение ошибки через последовательность увеличивает требования к памяти, а сокращённый вариант может нарушить предполагаемую передачу состояния. Без профилирования неизвестно, компенсирует ли повторное использование параметров дополнительные операции декодера.

Для оценки RLT понадобятся как минимум четыре группы результатов:

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

Упоминание 96 блоков само по себе не доказывает более глубокое рассуждение. Аналогично, ограниченное окно внимания декодера ещё не гарантирует экономию памяти всей системы: необходимо учитывать память энкодера, рекуррентное состояние и активации, нужные для обучения.

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

Источники