Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Общий контекст между LoRA-агентами научились переиспользовать так, чтобы каждый агент сохранял свою специализацию и не обрабатывал всю историю заново. В нерецензированном препринте Seoul National University, где все числа получили сами авторы, PReCache сократил время до первого токена до 3,1 раза и увеличил пропускную способность одного запроса до 2,3 раза. Для систем с длинными цепочками агентов это переносит оптимизацию из обучения моделей в слой исполнения.
Почему общий KV-кэш мешает специализации агентов
Система с несколькими LoRA-агентами держит одну базовую модель и подключает к ней небольшие адаптеры для разных ролей. Например, один агент планирует действия, другой вызывает инструменты, а третий проверяет результат. Такой подход экономит память на весах модели, но не устраняет повторную обработку общей истории.
Во время обработки контекста модель создаёт KV-кэш — сохранённые ключи и значения механизма внимания. Благодаря ему при генерации следующего токена не приходится снова вычислять представления всех предыдущих токенов. В агентной системе к этому контексту относятся запрос, результаты инструментов и ответы агентов на прошлых шагах.
Если каждый агент строит собственный кэш, вычисления повторяются при каждой смене роли. Чем длиннее траектория, тем больше времени уходит не на новый ответ, а на чтение уже обработанной истории.
Передать следующему агенту весь готовый кэш тоже нельзя без потерь. Кэш зависит не только от общей базовой модели, но и от активного LoRA-адаптера. Следующий агент получает представления, сформированные под чужую роль, поэтому его собственный адаптер влияет на результат слабее.
Предыдущие методы выбирают слои или токены, которые нужно пересчитать. Малый объём пересчёта экономит ресурсы, но хуже восстанавливает поведение агента; большой приближает вычислительную стоимость к отдельной обработке контекста. Другой вариант разделяет базовую и специфичную для адаптера части кэша, но всё равно прогоняет накопленную историю через базовую модель ради компактной части.
Как PReCache предвычисляет кэш каждой роли
PReCache делит кэш на общую базовую часть и низкоранговую часть, которая соответствует конкретному LoRA-адаптеру. Низкоранговая означает, что данные проходят через узкое представление адаптера и занимают заметно меньше места, чем полные скрытые состояния модели.
Вариант PreLRShared строит такие компактные кэши сразу для всех агентов, когда новый фрагмент контекста впервые проходит через модель. Для этого скрытое состояние умножают на входную матрицу каждого адаптера. Когда очередь доходит до следующего агента, его низкоранговый кэш уже готов: базовую модель запускают только для нового фрагмента, а не для всей траектории.
Однако общая часть кэша всё ещё наследует влияние адаптера, который первым обработал фрагмент. ReBaseShared устраняет эту зависимость дополнительным проходом с отключёнными адаптерами. Получается нейтральный базовый кэш, к которому при работе агента добавляется его собственная низкоранговая часть.
Для последовательного исполнения авторы предлагают отложенный проход: нейтральный кэш строится после завершения хода агента и до запуска следующего. При параллельном обслуживании адаптированный и нейтральный пути входят в один пакет запросов. Первый вариант меньше влияет на задержку отдельной цепочки, второй лучше переносит очередь при высокой нагрузке.
Где результаты меняют архитектурный план
PreLRShared дал максимальное ускорение времени до первого токена в 3,1 раза и рост пропускной способности на запрос в 2,3 раза относительно исполнения без общего кэша. ReBaseShared лучше сохранил точность среди проверенных способов совместного использования: среднее снижение составило 1,1 процентного пункта. На самой длинной траектории его пиковое потребление памяти оставалось в пределах 2% от варианта, который напрямую переиспользует полный кэш.
Метод проверяли на LLaMA-3.1-8B-Instruct и Ministral-8B-Instruct, в том числе на агентных траекториях HotpotQA. Последовательное исполнение измеряли на одной A6000, конкурентное обслуживание — на одной A100. Сравнение охватывало исполнение без общего кэша, прямое переиспользование, разделение базового и низкорангового кэшей, а также методы, которые пересчитывают выбранные слои или токены.
PReCache касается систем, где несколько существующих LoRA-адаптеров работают поверх одной базовой модели и регулярно читают общую растущую историю. В таком проекте можно сохранить адаптеры и не закладывать отдельное обучение ради совместимого кэша. Менять придётся сервер исполнения: он должен разделять части KV-кэша, получать скрытые состояния и заранее применять к ним матрицы всех агентов.
Выбор между двумя вариантами зависит от допустимого компромисса. PreLRShared подходит, когда задержка важнее и небольшой сдвиг поведения можно проверить на прикладных сценариях. ReBaseShared добавляет нейтральный проход, зато ближе сохраняет точность исходного исполнения. Максимальные ускорения относятся к длинным траекториям и выбранному оборудованию, поэтому в план внедрения стоит включить замер на реальном распределении длины контекста и частоте смены агентов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
