Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Extender научился сохранять контекст Transformer между обращениями без отдельного полноразмерного кэша ключей и значений для каждого слоя. В препринте University of Illinois Chicago, который не прошёл рецензирование и содержит замеры самого автора, постоянная память внимания у крупнейшей модели оказалась в 104 раза меньше, а качество на длинном контексте — выше, чем у сопоставимого Transformer. Для систем с множеством приостановленных диалогов это меняет хранение состояния, но не пиковую память во время генерации.
Каждый слой дописывает признаки вместо перезаписи общего потока
Обычный Transformer передаёт данные между слоями через остаточный поток. Каждый слой добавляет к нему результат своих вычислений, а следующий получает смесь исходных признаков и всех предыдущих изменений.
Механизм внимания строит из этого потока ключи и значения. Поскольку вход у каждого слоя свой, при генерации приходится хранить отдельный KV-кэш для каждого слоя и токена. Его размер растёт вместе с шириной модели, числом слоёв и длиной контекста.
Extender оставляет остаточный поток для предсказания следующего токена, но добавляет второй канал. Каждый слой дописывает в него обычно 32 признака, не меняя записи предыдущих слоёв. Отсюда определение «лог-структурированный»: канал растёт как журнал, куда можно только добавлять новые записи.
Запрос внимания по-прежнему использует остаточный поток, а ключи и значения строятся из нового канала. В результате все слои могут опираться на один общий журнал признаков вместо набора полноразмерных состояний. Финальный прогноз при этом строится только из обычного остаточного потока.
При активной генерации Extender восстанавливает ключи и значения из компактного журнала и временно держит их в памяти. Между обращениями этот KV-кэш можно удалить, сохранив только журнал, а перед продолжением диалога — вычислить заново. Поэтому архитектура сокращает память покоя, но во время самого обращения требует примерно столько же памяти, сколько стандартный Transformer.
Экономия памяти не ухудшила короткий контекст
Extender и эталонный Llama-подобный Transformer обучали с нуля на одинаковых данных и проверяли в трёх масштабах; крупнейшая модель содержала 924 млн параметров. Короткий контекст оценивали на наборе DCLM CORE, а длинный — на RULER. Подробные испытания длинного контекста проводили только для крупнейшей модели, без дополнительного обучения следовать инструкциям или решать задачи RULER.
На коротких задачах Extender в целом совпал с эталонным Transformer. Это существенная часть результата: компактный канал не заставил модель отказаться от обычного остаточного потока и не ухудшил базовые языковые способности в выбранных тестах.
На RULER Extender в среднем опережал Transformer после обучения на длинных последовательностях. Особенно заметным преимущество оказалось в задачах, где нужно найти несколько ключей в большом контексте. Исключением стало отслеживание переменных: там обычный Transformer победил уверенно, что указывает на разную склонность архитектур к отдельным типам операций.
При контексте 64 тыс. токенов постоянное состояние Extender занимало около 109 МБ против 11,3 ГБ у стандартного многоголового внимания. Речь именно о данных, которые сервер должен сохранить между обращениями, а не обо всей памяти модели или рабочей памяти одного прохода.
Дополнительные эксперименты показали, что разделение каналов нельзя заменить одним компактным входом. Когда запрос внимания получал только журнал либо только остаточный поток, качество на длинном контексте снижалось. Лучше работала схема, где запрос видит оба источника, а ключи и значения — компактный журнал.
Планы меняются для сервисов с приостановленными сессиями
Extender стоит учитывать командам, которые проектируют собственную модель и рассчитывают хранить много длительных диалогов, агентных процессов или пользовательских сессий. В таких системах активных генераций может быть мало, но обычные KV-кэши всех ожидающих сессий продолжают занимать GPU или оперативную память. Компактное постоянное состояние позволяет освободить KV-кэш после ответа и восстановить его при следующем обращении.
Для одного непрерывного запроса выигрыш слабее. Временный KV-кэш всё равно нужен, а его восстановление добавляет вычисления. Работа измеряет память и качество, но не приводит замеры задержки и пропускной способности такого восстановления, поэтому экономию памяти пока нельзя напрямую перевести в стоимость обслуживания.
Базой для сравнения служит обычное многоголовое внимание. Производственные модели часто уже уменьшают KV-кэш через группировку голов, сжатие или повторное использование данных между слоями, поэтому заявленный разрыв нельзя переносить на них без отдельного теста. При этом эксперименты показывают, что Extender совместим с группированными запросами: архитектурный подход можно сочетать с существующим сокращением рабочей памяти.
Для команды, которая выбирает готовую модель или внешний API, работа не требует менять стек: Extender меняет устройство и обучение самой модели. Для разработчиков собственной LLM вывод практичнее — компактную память между обращениями теперь можно проверять как отдельное архитектурное решение, не заменяя softmax-внимание и не жертвуя качеством короткого контекста.
Масштаб проверки пока ограничен моделями меньше миллиарда параметров и двумя наборами задач. Поэтому Extender уже подходит для прототипа сервера с большим числом сохранённых сессий, но ещё не доказывает тот же баланс памяти, скорости и качества на крупных производственных моделях.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
