Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
KV-кэш научились хранить с запасом точности, но при каждом шаге генерации читать только те данные, которые нужны текущему запросу. В препринте команды Amazon и UC Berkeley, который не проходил рецензирование и содержит собственные замеры авторов, ReadKV сократил задержку одного слоя на 39% относительно TurboQuant. Подход меняет архитектуру длинного контекста: объём кэша и трафик при чтении больше не обязаны совпадать.
Один кэш даёт разную точность разным запросам
Обычная квантизация задаёт одну разрядность для хранения и чтения. Если значение записано четырьмя битами, каждый следующий запрос получает те же четыре бита независимо от того, какая часть записи влияет на ответ.
ReadKV разделяет эти бюджеты. Кэш ключей и значений (KV-кэш) хранит каждый скаляр как путь по дереву квантования. Короткий префикс пути даёт грубое восстановление, а дополнительные биты последовательно уточняют значение. Запись при этом не меняется: разные запросы читают из неё префиксы разной длины.
Чтение проходит последовательно. Сначала текущий запрос определяет, какие каналы ключей сильнее влияют на оценки внимания. ReadKV выделяет им больше битов, восстанавливает ключи и вычисляет распределение внимания между токенами.
Затем это распределение задаёт точность значений. Токены с большим весом внимания получают более длинные префиксы, остальные — более короткие. Так запрос управляет сначала точностью каналов ключей, а затем точностью значений отдельных токенов.
Бюджет распределяет жадный алгоритм: каждый следующий бит отправляется туда, где он сильнее всего уменьшает калиброванную оценку ошибки. Для случая, когда польза от очередного уточнения постепенно убывает, работа доказывает точность такого распределения внутри каждого этапа.
Теоретическая часть также показывает семейства задач, где зависящее от запроса чтение даёт меньшую ошибку, чем любой способ заранее выбрать одинаковые участки записи. Это не доказывает преимущество на произвольной LLM, но объясняет, почему хранить дополнительные разряды может быть полезно, даже если большинство запросов их не прочитает.
Четыре прочитанных бита почти сохранили качество восьмибитного кэша
Качество проверяли на шести базовых моделях с текстами C4. При хранении восьми бит и чтении в среднем четырёх перплексия выросла не более чем на 0,66%. Перплексия показывает, насколько уверенно модель предсказывает следующий токен: чем она ниже, тем лучше.
При одинаковом бюджете чтения ReadKV работал точнее, чем кэш, который хранит и полностью читает фиксированную низкую разрядность. Разница возникает из-за сохранённого запаса: текущий запрос может потратить больше точности на важный канал или токен, не увеличивая средний объём чтения.
Проверки на вопросах с длинным контекстом и поиске спрятанного ключа дополнили замеры перплексии. В них участвовали две модели, настроенные выполнять инструкции. Эти опыты проверяют полезность выборочного чтения для поиска информации, но не заменяют системный тест полного сервера генерации.
Аппаратный результат относится к NVIDIA A10G, контексту из 8192 токенов, пакету из одного запроса и одному слою модели. ReadKV сравнивали с TurboQuant и плотным чтением Dense, начиная с уже готового кэша. Такой стенд изолирует затраты на выбор, восстановление и внимание, но не показывает задержку всей модели.
Планы меняются только там, где узким местом стал трафик кэша
Работа не обосновывает немедленную замену действующего формата KV-кэша. Она предлагает сначала разделить две метрики: сколько данных сервер удерживает в памяти и сколько переносит при каждом шаге генерации. Фиксированная квантизация связывает их одной разрядностью, хотя они влияют на систему по-разному.
ReadKV имеет смысл рассматривать для длинных контекстов и крупных пакетов, когда чтение кэша переносит больше данных, чем загрузка весов. Дополнительная точность увеличивает размер сохранённой записи, зато не обязана попадать в быстрый путь каждого запроса. Редко используемые уровни уточнения потенциально можно держать в более медленной памяти.
Цена подхода — более сложный формат данных и вычисления между чтениями. Серверу нужно выбрать глубину префиксов, восстановить ключи, получить внимание и только после этого запросить значения. Без специализированных ядер промежуточные буферы и выбор адресов могут съесть экономию от меньшего трафика.
Практический следующий шаг — не менять квантизатор целиком, а проверить раздельные бюджеты на собственном профиле нагрузки. Такой прототип должен измерять задержку полной модели, фактический трафик памяти и число запросов, помещающихся на ускорителе. Если систему ограничивают веса или вычисления, а не KV-кэш, преимущество выборочного чтения останется теоретическим.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
