Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Новый движок SparseEngine позволяет запускать разные способы разреженного внимания и переносить сокращённую историю между ходами LLM-агента. В работе Jitai Hao, Quansheng Gu, Qiang Huang и Jun Yu, которая не прошла рецензирование и содержит замеры самих авторов, движок ускорил обработку агентских сценариев до 2,24 раза. Для продуктовой команды это не готовая замена vLLM, а архитектурный шаблон для систем, где длинная история уже упирается в память GPU.
Контракт жизненного цикла отделяет метод от движка
При генерации модель сохраняет в KV-кэше ключи и значения для ранее обработанных токенов. Чем длиннее диалог агента, тем больше памяти занимает этот кэш и тем больше данных приходится просматривать механизму внимания на каждом следующем шаге.
Разреженные методы сокращают работу по-разному. Quest выбирает нужные страницы кэша для текущего запроса, H2O удаляет записи во время генерации, KIVI хранит их с меньшей числовой точностью, а DeltaKV восстанавливает часть данных по требованию. Универсальный движок не может навязать им один физический формат кэша и один порядок обновлений.
SparseEngine проводит границу по жизненному циклу модели. Общая часть планирует запросы, формирует непрерывные пакеты и распределяет память. Конкретный метод получает точки расширения до и после внимания, после слоя и после шага генерации. Через них он решает, когда оценивать важность токенов, что удалять и какие служебные данные обновлять.
За физическое состояние отвечает отдельный CacheManager. Метод сам задаёт формат KV, размещение в памяти, соответствие позиций ячейкам и правила освобождения места. AttentionView затем представляет выбранные или восстановленные данные в виде, который может обработать реализация внимания. Благодаря такому разделению движок поддерживает пятнадцать методов из четырёх семейств без отдельных версий модели под каждый из них.
Сокращённая история сохраняется между запросами
Обычное кэширование префикса предполагает, что для совпавшего начала запроса сохранился полный KV-кэш. Методы с физическим удалением нарушают это условие: логическая история диалога остаётся прежней, но части соответствующих ключей и значений уже нет.
Chain Cache разделяет эти два представления. Он хранит логический префикс сессии для проверки совпадения, а рядом — оставшиеся KV-записи и внутреннее состояние метода. Когда агент продолжает диалог, движок присоединяет сохранённое состояние и обрабатывает только новый хвост, не восстанавливая удалённую часть истории.
Второй механизм позволяет приложению указать участок истории, который можно проредить. Политика выбирает полезные позиции, CacheManager освобождает остальные физические ячейки, но логический префикс не меняется. Так можно отдельно обрабатывать результаты инструментов, старые рассуждения или ответы модели, не ломая повторное использование совпавшей истории.
Авторы проверили качество на LongBench, AIME, SWE-bench Lite и Claw-Eval, а производительность — на моделях семейств Llama, Qwen и GLM с несколькими архитектурами внимания. Для сравнения использовали vLLM, Vortex, HiSparse и Tangram; оборудование включало серверные и потребительские GPU NVIDIA. Такой набор охватывает длинные контексты и многошаговых агентов, но результат зависит от выбранного разреженного метода и его бюджета кэша.
Главный выигрыш приходит от освобождённой памяти
При больших пакетах физическое удаление KV дало более чем десятикратный рост суммарной скорости генерации относительно vLLM. При одинаковом числе параллельных запросов ускорение превысило 2,5 раза. Разница важна: первый результат частично возникает потому, что сокращённый кэш позволяет одновременно обслуживать больше запросов, второй лучше показывает ускорение одного и того же режима нагрузки.
На полном воспроизведении агентских сценариев максимальный выигрыш составил 2,24 раза. Этот тест учитывал обработку входной истории, генерацию, планирование и имитацию ожидания инструментов, поэтому он ближе к реальному циклу агента, чем изолированный замер декодирования.
Общий интерфейс сам по себе не сохраняет качество. На SWE-bench Lite H2O решил 13% задач против 25% у полного внимания, тогда как Quest и OmniKV остались около исходного уровня. Значит, SparseEngine воспроизводит поведение подключённого метода, но не устраняет его компромисс между объёмом кэша и качеством.
Командам стоит перенять границы компонентов, а не сразу менять движок
Работа меняет планы команд, которые строят агентов с длинными сессиями, частыми вызовами инструментов и повторным использованием истории. В такой системе логический журнал диалога лучше не связывать с физическим KV-кэшем: первый нужен приложению и сопоставлению префиксов, второй можно удалять, сжимать или хранить с меньшей точностью.
Практичный следующий шаг — выделить три интерфейса: управление сессией, принадлежащее методу состояние кэша и представление данных для внимания. Затем стоит прогнать собственные трассы при фиксированном числе параллельных запросов и отдельно проверить максимальную пропускную способность. Это покажет, ускоряет ли выбранная разреженность вычисления или лишь освобождает память для большего пакета.
Переход оправдан, если стоимость длинного KV-кэша уже ограничивает параллелизм. Для коротких запросов или сценариев без продолжительных сессий Chain Cache не решает основной узкий участок, а добавление нового слоя управления состоянием потребует отдельной проверки корректности освобождения и повторного присоединения памяти.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
