Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Долгую историю работы LLM-агента научились держать доступной, даже когда она не помещается в память GPU и штатное окно модели. В нерецензированном препринте, где все числа получили сами авторы, с KVMem доля успешных запусков Qwen3.8-27B на DeepSWE выросла с 43,8% до 48,4%. Для локальных агентов это предлагает альтернативу ранней суммаризации: сохранять вычисленное состояние прошлых шагов и возвращать лишь нужную часть.
Как история превращается в виртуальную память
LLM во время чтения запроса рассчитывает кэш ключей и значений (KV-кэш). В нём остаётся внутреннее представление уже обработанных токенов, поэтому при генерации модель не пересчитывает весь запрос заново. У длительного агента этот кэш растёт вместе с диалогами, файлами, выводом инструментов и журналами команд.
Обычная суммаризация заменяет старую историю коротким текстом. Она освобождает контекст, но заранее решает, какие детали пригодятся позже. Поиск по исходной истории может вернуть пропущенный фрагмент, однако модели придётся снова обработать его и построить тот же KV-кэш.
KVMem сохраняет старые участки сразу в виде блоков KV и распределяет их между памятью GPU, оперативной памятью и NVMe-накопителем. Для каждого блока система строит компактный индекс на основе сигналов внимания той же модели. Перед генерацией очередного ответа она сопоставляет текущий запрос с индексами и загружает подходящие блоки в GPU.
Рабочий набор обновляется на границе шага агента: после первичной обработки нового запроса, но до генерации ответа. Во время самой генерации набор не меняется. Если выбранные блоки раньше занимали другие позиции, KVMem пересчитывает их позиционное представление и собирает хронологически согласованное рабочее окно.
Большая виртуальная рабочая область не расширяет окно контекста самой модели. Каждый вызов по-прежнему видит ограниченную выборку из истории. Кроме того, сохранённый KV-кэш рассчитывался в прежнем окружении, поэтому его повторное использование не полностью равно новой обработке исходного текста, а поиск может пропустить нужный блок.
Что изменилось в задачах с длинной историей
KVMem проверяли на LongMemEval, MemoryAgentBench и AgentLongBench, а также на полных траекториях программного агента DeepSWE. В парном сравнении DeepSWE использовали первые шестнадцать задач в исходном порядке и запускали каждую по четыре раза. Для обеих конфигураций сохранили модель, среду агента, параметры генерации и проверку решений.
Сравнение показывает не только рост доли решённых задач. Среднее время первичной обработки входа сократилось на 55,1%, потому что агент загружал готовые KV-блоки вместо повторного чтения найденного текста. Полное время работы агента уменьшилось на 12,8%, то есть выигрыш на обработке контекста сохранился на уровне всей траектории.
На контролируемых тестах KVMem сопоставляли со скользящим окном, одной суммаризацией и суммаризацией с поиском по исходному тексту. Система стабильно обходила первые два варианта, а относительно поиска с суммаризацией обычно сохраняла или повышала качество при меньших расходах на восстановление контекста.
Где KVMem меняет архитектуру агента
На ноутбуке с RTX 5090 Laptop GPU и 24 ГБ видеопамяти система запускала варианты Qwen3.6-27B и Qwen3.8-27B с виртуальной рабочей областью на миллион токенов. Скорость достигала примерно 50 генерируемых токенов в секунду. Это показывает, что длительный локальный агент может хранить историю, которая не помещается в GPU, без постоянного сведения прошлых действий в краткий пересказ.
Работа меняет планы команд, которые самостоятельно запускают модель и строят агентов для долгих программных, аналитических или операционных задач. В такой системе историю стоит рассматривать как отдельный ресурс: активная часть остаётся на GPU, недавно востребованные блоки — в оперативной памяти, остальные — на накопителе.
За это придётся платить объёмом хранения. KV-состояние заметно крупнее исходного текста, а рост рабочей области увеличивает размер индекса и расходы на поиск. Архитектуре также нужен контроль над распределением KV-памяти, переносом блоков и восстановлением позиций.
Поверх закрытого облачного API KVMem прозрачно не подключить: API не даёт управлять внутренним кэшем модели. Поэтому для продукта на внешней модели вывод пока ограничен общим принципом — не уничтожать вычисленную историю раньше времени. Практическое внедрение требует собственного контура запуска или поддержки такой виртуализации со стороны поставщика модели.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
