Журнал · Rit.work

ReplaySSM перестаёт записывать состояние SSM на каждом токене

ReplaySSM хранит недавние входы вместо промежуточных состояний и ускоряет декодирование гибридных моделей на Mamba-2 и Gated DeltaNet.

Rit.work
Студия разработки
12 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Гибридные языковые модели с SSM научились обслуживать быстрее, сохранив те же вычисления с точностью до различий плавающей точки. В препринте Ze-Wei Liou и его коллег, который не прошёл рецензирование и где все числа получили сами авторы, ReplaySSM ускорил стандартное декодирование в 1,20–1,47 раза относительно оптимизированного vLLM. Для серверных команд это способ снять ограничение памяти без замены модели или её архитектуры.

Почему постоянное состояние всё равно тормозит декодирование

Модели пространства состояний, или SSM, не хранят для каждого прошлого токена отдельные ключи и значения, как Transformer. Вместо этого они сворачивают историю в рекуррентное состояние постоянного размера. Его объём не растёт вместе с контекстом, но на каждом шаге модель читает состояние из памяти GPU, обновляет и записывает обратно.

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

ReplaySSM хранит контрольную точку состояния и небольшой буфер недавних входов SSM. На обычном шаге система добавляет вход в буфер и восстанавливает нужный результат из контрольной точки и накопленных записей. Полное состояние записывается только после заполнения окна; в экспериментах использовали окно на 16 шагов.

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

То же представление упрощает опережающее декодирование (speculative decoding). Лёгкая модель предлагает несколько токенов, основная проверяет их вместе, а неподтверждённый хвост нужно отменить. Обычный SSM не умеет дёшево возвращаться назад, поэтому vLLM сохраняет снимок состояния для каждого предложенного токена. ReplaySSM оставляет входы в буфере и при отказе просто передвигает указатель на последнюю принятую запись.

Где ReplaySSM дал выигрыш

Реализацию добавили в vLLM и проверили на гибридных моделях Nemotron-3-Nano-4B, Nemotron-3-Super-120B-A12B, Qwen3.5-4B и Qwen3.5-122B-A10B. В них использовались два варианта SSM — Mamba-2 и Gated DeltaNet. Небольшие модели запускали на H100, крупные — на B300.

Основные замеры проводили при серверном размере пакета 256. В таком режиме ReplaySSM с опережающим декодированием обеспечил примерно в 1,8 раза большую пропускную способность, чем соответствующий режим vLLM на крупных моделях. Выигрыш возник не только из-за дешёвого отката: при проверке предложенных токенов система вычисляет выходы напрямую и не создаёт промежуточное состояние для каждого из них.

Разделение также помогает при хранении состояния с пониженной точностью. ReplaySSM держит более точную контрольную точку для рекуррентных обновлений и отдельную копию с пониженной точностью для вычисления выходов. Ошибка округления второй копии поэтому не попадает в следующие обновления; на самой длинной проверенной генерации расхождение выходных распределений снизилось в 13–36 раз по сравнению с одной общей контрольной точкой пониженной точности.

Границы результатов задаёт выбранная конфигурация: метод проверяли в vLLM на Mamba-2 и Gated DeltaNet, на указанных моделях и GPU, при высокой серверной нагрузке. Это не сравнение качества архитектур и не обещание такого же ускорения при малом пакете. Каждому шагу по-прежнему требуется читать контрольную точку, а работа с буфером добавляет собственные вычисления.

Меняет ли работа планы серверной команды

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

Наибольший смысл проверка имеет там, где декодирование идёт большими пакетами и упирается в пропускную способность памяти GPU. Команде потребуется сопоставить текущие формы SSM-слоёв с реализацией ReplaySSM, встроить изменённые ядра и повторить замеры на своих длинах ответов и профиле нагрузки. Оптимальный размер буфера зависит от баланса между редкими записями контрольной точки и растущей стоимостью повторного применения входов.

Для чистых Transformer-моделей работа планов не меняет: у них нет такого рекуррентного состояния и откат уже выполняется через указатель в кеше ключей и значений. Для новых гибридных моделей вывод иной — формат состояния становится частью серверной архитектуры. Сохранять его после каждого токена необязательно, даже если рекуррентная формула записана именно так.

Источники

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу