KVBoost сократил задержку до первого токена LLM в 4,49 раза за счёт переиспользования KV-кэша

Большие языковые модели на архитектуре трансформера тратят много времени на первый токен ответа, потому что KV-тензоры (ключи и значения внимания) приходится пересчитывать заново для каждого запроса. Существующие системы префиксного кэширования снижают эту стоимость, но работают только тогда, когда промпты совпадают в начале, по общему непрерывному префиксу. Если одинаковый фрагмент содержания встречается не в начале запроса, а где-то дальше, такое кэширование его не подхватывает.

Представленная система KVBoost переиспользует KV-кэш кусками (чанками) для decoder-моделей, совместимых с библиотекой HuggingFace, независимо от того, в каком месте промпта стоит совпадающий фрагмент. В основе, схема с двумя типами хешей: один хеш кодирует позиционную идентичность фрагмента (префиксный хеш), второй, идентичность по содержимому (контентный хеш). Это позволяет находить как точные, так и приближённые совпадения кэша.

Проблема в том, что при склейке независимо закэшированных чанков на границах между ними возникают ошибки внимания, модель "видит" контекст на стыке чанков иначе, чем при сквозном пересчёте. Для этого KVBoost предлагает две стратегии починки: SelectiveRecompute заново кодирует только пограничные участки чанков, а CacheBlendRecompute сначала делает пробный проход, находит токены с наибольшим отклонением и пересчитывает именно их. Дополнительно система использует асимметричное квантование KV-кэша (int8/int4), адаптивное разбиение текста на чанки и вытеснение записей кэша по важности при фиксированном бюджете памяти.

В оценке на модели Qwen/Qwen2.5-3B на 1000 задачах по локализации багов в коде KVBoost показал задержку до первого токена 142,4 мс против 639,1 мс у сравниваемого варианта, сокращение в 4,49 раза, при этом точность не упала (99,2% против 99,1%). Отдельно, по сравнению именно с классическим префиксным кэшированием, KVBoost оказался быстрее на 16% (абсолютные цифры этого сравнения в тексте не приводятся). Авторы описывают KVBoost как практичный слой ускорения инференса с ограниченным потреблением памяти, совместимый с моделями на позиционных эмбеддингах RoPE и не требующий изменения архитектуры модели.

Ключевые факты

Классическое префиксное кэширование KV работает только при совпадении промптов по общему начальному префиксу, при совпадении контента не в начале запроса выгоды нет
KVBoost переиспользует KV-кэш чанками независимо от позиции за счёт схемы с двумя хешами: отдельно по позиции (префиксный хеш) и отдельно по содержимому (контентный хеш)
Для стыков между независимо закэшированными чанками, две стратегии починки: SelectiveRecompute (пересчёт граничных участков) и CacheBlendRecompute (пробный проход плюс пересчёт токенов с наибольшим отклонением)
На Qwen/Qwen2.5-3B и 1000 задачах по локализации багов задержка до первого токена упала в 4,49 раза (142,4 мс против 639,1 мс) без потери точности (99,2% против 99,1%), а против классического префиксного кэширования выигрыш составил 16%
Система также включает асимметричное квантование KV-кэша (int8/int4), адаптивное разбиение на чанки и вытеснение по важности при фиксированном бюджете памяти; совместима с RoPE-моделями без изменения архитектуры

Почему это важно

Задержка до первого токена, одна из главных болевых точек инференса LLM, и переиспользование KV-кэша давно используется для её снижения. Но классическое префиксное кэширование ловит только совпадения в самом начале запроса. KVBoost снимает это ограничение: за счёт раздельного хеширования позиции и содержимого фрагмента система находит и переиспользует совпадающий контент, где бы он ни стоял в промпте, а две отдельные стратегии починки решают проблему ошибок внимания на стыках склеенных чанков, из-за которых наивное чанковое кэширование обычно теряет точность.

Кому это важно

В первую очередь тем, кто строит или эксплуатирует инфраструктуру инференса LLM, движки обслуживания запросов, RAG-системы, кодовых и агентных ассистентов, где один и тот же контекст (документ, фрагмент кода, системный промпт) регулярно повторяется в разных запросах, но не всегда оказывается в начале строки. Сама оценка KVBoost проведена на задаче локализации багов в коде, типичном сценарии для инструментов разработки на базе LLM.

Как это применить

KVBoost задуман как программный слой поверх decoder-моделей, совместимых с HuggingFace и построенных на позиционных эмбеддингах RoPE, без изменения архитектуры самой модели, то есть теоретически встраивается в существующий стек инференса. Система рассчитана на работу в условиях ограниченного бюджета памяти: квантование KV-кэша (int8/int4), адаптивное разбиение на чанки и вытеснение записей по важности сделаны именно для этого. В тексте не названы ни лицензия, ни ссылка на код, ни условия использования, судить о готовности к внедрению по этим параметрам нельзя.

Можно ли доверять

Это препринт на arXiv, то есть результаты не прошли рецензирование. В тексте не указаны ни авторы, ни их организация, ни дата публикации, судить об аффилиации некому. При этом заявленные цифры получены не абстрактно: конкретная модель (Qwen/Qwen2.5-3B), конкретная задача и объём выборки (1000 примеров) названы явно, что позволяет в принципе воспроизвести и проверить результат, если появится код.

Риски и подводные камни

Оценка проведена на одной модели (Qwen2.5-3B) и одной задаче (локализация багов), перенос результата на другие модели и типы нагрузки в тексте не показан. Из явных сравнений с другими системами назван только обобщённый "prefix caching", без указания конкретной реализации; чем именно является базовый вариант для цифр 639,1 мс и 99,1% точности, в тексте не расшифровано. Публикация выпуска кода или артефактов не упоминается, из-за чего независимая проверка результатов пока невозможна. Сама природа приближённого сопоставления кэша по контентному хешу теоретически несёт риск редких ошибок совпадения, даже если на данном бенчмарке точность не пострадала.