Исследование · NVIDIA Technical Blog
ReplaySSM: ускорение гибридных моделей начинается с лишних записей в память
12 октября 2026 года NVIDIA описала ReplaySSM — способ хранить состояние гибридной модели через контрольную точку и недавние входы. В испытаниях выиграли большие пакеты запросов, тогда как пакет из одного запроса ускорения не получил. Это полезное различие для выбора режима работы общего локального сервера.
Что это меняет для покупателя
Покупателю стоит связать ускорение с реальной одновременной нагрузкой команды. ReplaySSM даёт основание оценивать конкретный режим вычислительного движка: его обращение с состоянием, проверку черновых токенов и точность обновлений. Название модели само по себе этих свойств сервера не определяет.
Постоянное состояние тоже перегружает память
В исследовании NVIDIA и Dao AI Lab рассматриваются гибридные модели, чередующие слои SSM и внимания. SSM — модель пространства состояний: при генерации она поддерживает состояние фиксированного размера. У слоя внимания используется KV-кеш, сохраняющий данные предыдущих токенов и растущий с контекстом. Постоянный размер состояния выглядит привлекательным, но не гарантирует быстрого получения следующего токена.
Обычное исполнение SSM на каждом шаге загружает полное состояние, обновляет его и записывает обратно. При обслуживании больших пакетов перенос этих данных может ограничивать скорость сильнее арифметики. Авторы показывают такой узкий участок у гибридных моделей. Следовательно, для оценки производительности полезно знать, сколько данных движок перемещает между вычислением очередных токенов, даже если размер самого состояния не растёт.
Контрольная точка вместо постоянной перезаписи
ReplaySSM хранит контрольную точку состояния вместе с небольшим буфером недавних входов. На обычном шаге новый вход добавляется в буфер, а выход вычисляется из него и контрольной точки. Полная запись обновлённого состояния происходит при заполнении окна. Так получение ответа отделяется от обновления данных, которые будут нужны следующим шагам.
В основных испытаниях использовалось окно из 16 записей. Контрольная точка всё ещё читается на каждом шаге, но записывается один раз за окно. Авторы описывают примерно двукратное сокращение доминирующего трафика состояния. Выходы соответствуют обычному исполнению с возможными различиями вычислений с плавающей точкой. Это изменение порядка работы с памятью, поэтому его ценность зависит от того, насколько память ограничивает конкретную нагрузку.
Большой пакет выигрывает, одиночный запрос — отдельный случай
NVIDIA сравнивала реализацию ReplaySSM в vLLM с собственными ядрами vLLM при подобранной конфигурации запуска. Испытывались Nemotron-3-Nano-4B и Qwen3.5-4B с весами BF16 на одном H100, а также Nemotron-3-Super-120B-A12B и Qwen3.5-122B-A10B с весами NVFP4 на одном Blackwell Ultra B300. Каждая модель работала на одной GPU без тензорного параллелизма.
При состоянии FP32, окне 16 и пакете 256 весь шаг декодирования ускорился в 1,20–1,47 раза среди четырёх моделей. При пакете 1 ускорения в этих тестах не было: доминировали другие источники задержки. Для команды это содержательный ориентир. Сервер с большой совместной нагрузкой и персональный чат с редкими обращениями могут получить разную пользу от одной оптимизации.
Черновики больше не требуют отдельных снимков
Спекулятивное декодирование предлагает несколько черновых токенов, проверяет их основной моделью и оставляет принятый фрагмент. Обычному SSM трудно отменять обновления состояния; описанный обходной путь сохраняет снимок после каждого чернового токена. ReplaySSM помещает входы в буфер и фиксирует принятый фрагмент перемещением указателя. Это меняет и проверку черновиков, и расход памяти на откат.
На запросах GSM8K, с четырьмя черновыми токенами от MTP-головы каждой модели, окном 16 и состоянием FP32, две модели класса 120B при пакете 512 показали пропускную способность в 1,85 и 2,10 раза выше спекулятивного vLLM. Каждая работала на одном B300; длины принятых фрагментов были согласованы. Эти результаты характеризуют конкретный режим обслуживания. Для запросов по программным исправлениям или документам потребуется измерение собственной нагрузки.
Четыре бита требуют разделения точности
У состояния есть ещё одна особенность: ошибка округления может снова попадать в следующее обновление. ReplaySSM позволяет разделить точность чтения для вычисления выхода и точность рекуррентной контрольной точки. Низкоточная копия используется для чтений, а дальнейшие обновления опираются на отдельную, более точную копию. Поэтому точность весов, кеша внимания и состояния следует рассматривать раздельно.
На GPQA-Diamond при обычном декодировании и окне 16 базовая точность Nemotron-3-Super-NVFP4 с состоянием FP32 составила 79,3%. Общая контрольная точка NVFP4 со стохастическим округлением теряла 12,5 процентного пункта. Чтения NVFP4 с отдельной рекуррентной точкой FP16 и стохастическим округлением теряли 1,4 пункта. Для Nano-4B последняя схема оставляла потерю 6,7 пункта: восстановление качества различается между моделями. Для загруженного общего сервера конкретный выбор — режим ReplaySSM с раздельной точностью состояния, проверенный на своей модели и характерной длине ответов.
Что проверить до выбора системы
- Какой SSM-режим действительно активен в используемом движке и как это видно в диагностике?
- Как распределены реальные размеры пакетов, включая часы с малым числом обращений?
- Сколько памяти в текущем режиме занимают снимки черновых состояний при пиковой нагрузке?
- Какие длинные ответы позволят заметить потерю качества после изменения точности состояния?
Выводы для покупателя — наша редакционная интерпретация. Публикация не подтверждает скорость или совместимость конкретной сборки из каталога.