Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинную генерацию в гибридных LLM удалось ускорить без дообучения и изменения весов. В препринте, который не прошёл рецензирование и содержит замеры самих авторов, лучший результат достиг 2,23 раза на контексте в 256 тысяч токенов. Для серверов с длинными диалогами это даёт путь к большему потоку токенов, но не сокращает память под контекст.
Какие части контекста читает каждый слой
Гибридные LLM чередуют полное внимание с более дешёвыми линейными слоями или скользящим окном. Полное внимание позволяет новому токену обратиться ко всему предыдущему контексту, поэтому с каждым шагом читает всё больше данных. На длинной последовательности немногочисленные полные слои становятся главным источником задержки.
Предложенная схема ограничивает только эти слои. Каждый из них читает начало запроса длиной 256 токенов, недавний фрагмент в скользящем окне и страницы контекста, которые Quest считает наиболее подходящими для текущего запроса. Разные головы внимания могут выбирать разные страницы, поэтому модель не обязана заранее решать, какую далёкую часть контекста сохранить.
Выбор далёких страниц обновляется через 32 шага генерации. Между обновлениями окно расширяется, чтобы новые токены не выпали из доступной области. Так система тратит меньше времени на сам отбор, но продолжает находить сведения за пределами недавнего фрагмента.
Размер окна и бюджет Quest задают отдельно для каждого слоя. Их ищет NSGA-II — алгоритм многокритериального поиска, который одновременно повышает точность и снижает расчётную стоимость декодирования. Он проверяет кандидатов на небольшом наборе примеров и оставляет несколько вариантов: с приоритетом качества, скорости или баланса между ними.
Веса модели, предварительная обработка запроса и полный KV-кэш остаются прежними. Метод сокращает объём данных, который слои читают при генерации очередного токена, но не освобождает память: любая страница контекста может понадобиться позже.
Ускорение растёт вместе с длиной контекста
Проверка охватила 21 длинноконтекстный набор данных и модели семейств Qwen3.5, Gemma 4, gpt-oss и Ornith. В выборку вошли плотные модели и модели со смесью экспертов; замеры проводили на A100 и GB200. Это проверка серверного декодирования уже выпущенных гибридных моделей, а не способ ускорить обучение или обычный Transformer, состоящий только из полного внимания.
При размере пакета четыре и контексте 64 тысячи токенов Qwen3.5 ускорилась до 1,26 раза. Средняя точность лучших конфигураций отличалась от исходных моделей не более чем на 0,5 процентного пункта, а на отдельных наборах статистически значимого ухудшения не обнаружили.
На более длинном контексте разрыв увеличивался, потому что исходное полное внимание продолжало дорожать с каждым токеном, а разреженная схема читала ограниченный объём данных. У плотных моделей среднего размера выигрыш оказался меньше: заметную часть времени они тратили на чтение весов, которое новый метод не ускоряет. У gpt-oss поиск также сохранил большинство слоёв с полным вниманием, поэтому резерв для ускорения остался небольшим.
Отдельный опыт с оптимизацией программных ядер подтвердил не только рост синтетической пропускной способности. Разреженная конфигурация поддерживала более стабильную скорость по мере удлинения диалога, хотя качество сгенерированных оптимизаций зависело от конкретной задачи. Этот опыт дополняет тесты, но не заменяет проверку на рабочем наборе запросов.
Когда стоит менять схему инференса
Работа меняет планы команд, у которых гибридная LLM регулярно генерирует ответы поверх длинной истории: в агентных циклах, работе с крупными документами или продолжительных сеансах разработки. Здесь можно сначала проверить разреженное внимание, не заказывая дообучение и не создавая новую версию весов. Реализация встроена в vLLM как расширение, поэтому эксперимент затрагивает слой инференса.
Настройка всё же не бесплатна. Поиск конфигурации для одной модели занимал до 60 GPU-часов, а полученные параметры зависят от слоёв и самой модели. Команде понадобится собственный набор запросов, который отражает рабочие задачи: глобальная конфигурация окна может ускорить генерацию, но потерять сведения, важные именно для продукта.
Для коротких запросов все проверенные конфигурации работали медленнее исходной модели, поскольку отбор страниц создаёт накладные расходы. Метод имеет смысл, когда длинный контекст занимает заметную долю нагрузки. Если сервер упирается в объём KV-кэша и число одновременных запросов, эта работа проблему не решает: память остаётся прежней.
Практический вывод — не менять архитектуру продукта целиком, а добавить отдельный опыт для длинноконтекстного контура. Следует сравнить задержку, поток токенов и качество на реальных диалогах, а затем проверить, не ограничивает ли систему чтение весов или память. На моделях со смесью экспертов и компактных плотных моделях шанс получить выигрыш выше, чем на плотных моделях, где внимание занимает меньшую часть времени.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
