Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинные ответы для обучения с подкреплением по проверяемой награде (RLVR) научились генерировать быстрее, не меняя распределение примеров, по которым затем обновляют модель. Хотя препринт не рецензирован и числа получили сами авторы, S3R повысил сквозную скорость обучения Qwen3 на 35–39% при сопоставимом качестве. Для команд это превращает разреженное внимание из рискованной замены политики в черновой этап с точной проверкой.
Почему поправка к отдельному ответу не исправляет всю группу
RLVR обучает модель на ответах, для которых награду можно проверить автоматически: например, сверить математический результат. В групповой относительной оптимизации GRPO модель генерирует несколько ответов на один запрос, а преимущество каждого ответа вычисляет относительно наград остальных участников группы.
Разреженное внимание ускоряет генерацию, потому что на каждом шаге читает не весь кэш ключей и значений, а выбранную часть истории. В измеренных нагрузках работа внимания занимала 72–76% времени вычислительных ядер при авторегрессионной генерации. Однако модель с урезанным контекстом меняет вероятности токенов и начинает выдавать другую выборку ответов.
Поправить вероятность каждого готового ответа недостаточно. Даже точный вес вернёт правильный вклад самого ответа, но его преимущество всё ещё зависит от соседей по группе, которые пришли из изменённого распределения. Поэтому обновление параметров в среднем отличается от обновления на ответах плотной модели.
В эксперименте прямое разреженное семплирование становилось нестабильным даже с поправкой во время обучения. Проблема здесь не сводится к неточной формуле или плохо подобранному порогу: приближение меняет состав группы до того, как GRPO сравнит награды.
Как разреженный черновик сохраняет ответы плотной модели
S3R использует разреженное внимание только для предложения следующих токенов. Затем та же модель запускает полное внимание, параллельно проверяет предложенный блок и применяет точное семплирование: принимает подходящие токены, а после первого отклонения выбирает исправляющий токен из остаточного распределения.
Черновик и проверяющая модель используют один снимок параметров. Отдельную модель не нужно обучать, развёртывать и синхронизировать после каждого обновления политики. Разреженный бюджет влияет на стоимость предложений и долю принятых токенов, но при соблюдении процедуры не влияет на итоговое распределение ответов.
Больше доступного контекста не обязательно означает большую скорость. В отдельном прогоне увеличение бюджета черновика в десять раз повысило согласие с проверяющей моделью, но замедлило генерацию на 23% относительно более разреженного варианта: дополнительные чтения кэша стоили дороже, чем сэкономили принятые токены.
Полная проверка всё равно требует хранить всю историю. S3R заменяет только чтения во время чернового прохода, а не полный кэш. После проверки система пересчитывает плотные состояния для принятой части блока и использует оценки внимания, чтобы выбрать историю для следующего черновика.
Когда S3R меняет планы команды
Метод проверяли на Qwen3-1.7B и Qwen3-8B в задачах длинного математического рассуждения. Сравнивали полный цикл обучения с обычной авторегрессионной генерацией и несколькими вариантами опережающего декодирования. Итог относится прежде всего к нагрузкам, где длинный контекст делает чтение кэша одной из главных статей времени.
Для такой системы S3R предлагает иной порядок оптимизации. Вместо прямого разреженного семплирования с последующей компенсацией можно оставить стандартное обучение на распределении плотной политики, а приближение ограничить предложением токенов. Это снимает отдельный риск для GRPO: состав групп не меняется из-за способа ускорения.
Но одной замены декодера недостаточно. При нехватке памяти полный кэш приходится выгружать и возвращать, поэтому выигрыш может исчезнуть в передачах данных. Авторы добавили планировщик, который снижает параллелизм при росте очереди восстановления и снова повышает его, когда память освобождается; число переданных страниц кэша на тысячу токенов сократилось с 18 до 1,3.
Практический вывод — рассматривать S3R как связку алгоритма и инфраструктуры. Он наиболее уместен, если профиль показывает преобладание внимания, ответы достаточно длинные, а команда готова управлять полным кэшем между черновым и проверочным проходами. Для короткой генерации стоимость проверки может не окупиться, поэтому решение начинается с измерения времени внимания, принятой длины блока и обмена кэшем.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
