Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Для LLM научились ускорять работу с длинным контекстом, не обучая отдельный механизм отбора токенов. В препринте Preferred Networks, который не проходил рецензирование и приводит замеры самих авторов, предварительная обработка контекста в миллион токенов стала почти втрое быстрее. Метод можно добавить к готовой модели, но для этого нужны собственный индекс ключей, раскладка памяти и вычислительные ядра.
Блок объединяет похожие ключи из разных частей запроса
Обычное плотное внимание сопоставляет каждый запрос со всеми доступными ключами. На длинном контексте это дорого и при первичной обработке запроса, когда модель строит кэш ключей и значений, и при генерации, когда каждый новый токен читает этот кэш.
Разреженное внимание оставляет только часть ключей. Главная проблема возникает до самого вычисления внимания: нужно быстро определить полезные токены и расположить их в памяти так, чтобы GPU не тратил время на разрозненные чтения.
Предложенный метод строит отдельный индекс для каждого запроса, слоя и KV-головы. Нормализованные ключи распределяются сферическим методом k-средних по семантическим блокам. «Семантический» здесь означает сходство в пространстве ключей: рядом могут оказаться слова одной темы, цифры идентификаторов или другие токены из далёких друг от друга мест документа.
Средний блок в основной конфигурации содержит 2048 токенов. Для каждого запроса модель сравнивает его не со всеми ключами, а с центрами блоков, выбирает наиболее подходящие группы и затем вычисляет обычное внимание по исходным ключам и значениям внутри них. Бюджет выбранных токенов равен K=L/16, где L — длина контекста.
Токены текущего фрагмента и недавняя история проходят без отбора. В начале запроса, когда доступный префикс ещё короткий, используется плотное внимание: построение и применение индекса там стоило бы дороже сэкономленных вычислений.
Крупные блоки компенсируют неточный отбор скоростью
Маленькие блоки точнее выделяют нужные токены, но увеличивают число центров и операций выбора. Крупный блок может захватить лишнее, зато его дешевле оценить и прочитать. Освободившееся время позволяет увеличить бюджет токенов и вернуть часть потерянной точности.
При предварительной обработке соседние запросы часто выбирают разные блоки. Вместо объединения всех выбранных токенов метод собирает вместе запросы, которым нужен один и тот же блок. GPU загружает ключи и значения блока один раз и использует их для всей группы.
Сами ключи и значения заранее перекладываются в памяти по блокам, хотя их исходные позиции разбросаны по документу. Один индекс затем обслуживает и первичную обработку, и генерацию. Для нового токена нужно прочитать выбранные блоки, а не весь исходный запрос.
На контексте 512K полная модель обрабатывала вход в 2,3–2,4 раза быстрее плотного варианта, а генерировала токены в 1,7–2 раза быстрее. На RULER-5 старшая Qwen3.5-35B-A3B получила 84,2 балла против 84,4 у плотного внимания.
На LongBench-v2 разреженный вариант старшей модели уступил плотному, а на MRCR разрыв вырос на самой длинной проверке. Qwen3.5-4B сильнее ошибалась в задачах, где нужно найти несколько отдельных ключей, но всё равно обошла плотную Qwen3.5-2B на всех трёх наборах при сопоставимой задержке.
Метод меняет план оптимизации, но не снимает инженерные риски
Работа показывает практический путь для команд, которым нужен контекст на сотни тысяч токенов, но которые не могут переобучать модель вместе с селектором. Веса остаются прежними, поэтому один и тот же экземпляр модели можно сравнить с плотным режимом без отдельного цикла обучения.
Это не переключатель в настройках сервера. Выигрыш зависит от кластеризации ключей, блочной укладки KV-кэша, группировки запросов и специализированных ядер выбора. Реализация встроена в vLLM, но перенос в другой стек потребует воспроизвести весь путь данных, а не только формулу отбора.
Основные замеры проводились на Qwen3.5-4B и Qwen3.5-35B-A3B с одним NVIDIA H200, размером пакета в один запрос и форматом BF16. Метод заменял только слои полного внимания в гибридных моделях; отдельно его проверили на Nemotron 3.5 Lightning. Качество оценивали на RULER, MRCR и LongBench-v2, поэтому работа прежде всего подтверждает поиск информации и ответы по длинным документам в этих условиях.
Метод не меняет асимптотику предварительной обработки: число блоков и бюджет растут вместе с контекстом, поэтому вычисления остаются квадратичными, только с меньшим коэффициентом. Для продукта это аргумент в пользу пилота на реальных документах и длинах запросов, а не обещание неограниченного контекста.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
