Google presenta TurboQuant: compresión de caché KV 6x para LLMs sin pérdida de precisión

Google Research представила TurboQuant — алгоритм сжатия KV-кэша для больших языковых моделей, который должен снять одно из главных ограничений длинного контекста. По данным компании, метод сокращает потребление памяти минимум в шесть раз и в отдельных конфигурациях ускоряет вычисление attention до восьми раз без потери качества на тестовых задачах.

Почему KV-кэш тормозит

Когда LLM работает с длинным контекстом, она хранит промежуточные ключи и значения в KV-кэше, чтобы не пересчитывать их заново на каждом токене. Это экономит вычисления, но быстро упирается в память: чем больше модель и чем длиннее диалог или документ, тем сильнее растет объем кэша. В результате узким местом становится не только сам GPU, но и обмен данными между быстрой SRAM и HBM-памятью. Для inference это особенно болезненно, потому что длинные запросы начинают стоить заметно дороже и по latency, и по железу.

Google сравнивает KV-кэш с «высокоскоростной цифровой шпаргалкой», которую модель использует вместо повторных вычислений.

Обычная квантизация частично решает проблему, но у нее есть свой побочный эффект: вместе со сжатыми данными приходится хранить дополнительные константы квантизации. Эти накладные биты съедают часть выгоды, особенно когда речь идет о миллиардах значений внутри длинного контекста. Именно на этом месте Google и строит TurboQuant: идея не просто сжать векторы сильнее, а убрать лишний служебный overhead, который мешает получить реальную экономию памяти.

Как устроен TurboQuant TurboQuant состоит из двух этапов.

Сначала используется PolarQuant: алгоритм случайно вращает векторы, переводит их в более удобное представление и затем квантует координаты по отдельности. Такой подход позволяет сохранить основную структуру исходных данных без сложной подстройки под каждый блок. Затем включается второй слой — Quantized Johnson-Lindenstrauss, или QJL.

Он берет остаточную ошибку после первого этапа и кодирует ее одним дополнительным битом так, чтобы убрать систематическое смещение при вычислении inner product и attention score. Практически это важно по двум причинам. Во-первых, TurboQuant остается data-oblivious: ему не нужны датасеты для калибровки, дополнительное обучение или fine-tuning под конкретную модель.

Во-вторых, метод подходит для online-сценариев, где кэш нужно сжимать прямо во время инференса, а не готовить офлайн отдельный пайплайн. Google подчеркивает, что такая схема полезна не только для LLM, но и для векторного поиска, где тоже нужно быстро и дешево хранить и сравнивать большие массивы эмбеддингов. Сам TurboQuant компания готовит к презентации на ICLR 2026.

Какие результаты получила

Google Google тестировала TurboQuant на LongBench, Needle In A Haystack, ZeroSCROLLS, RULER и L-Eval, используя открытые модели Gemma и Mistral. По данным компании, TurboQuant сохраняет качество на длинноконтекстных задачах и одновременно заметно уменьшает KV-кэш. В блоге Google акцент сделан на 3-битной квантизации без потери качества на протестированных бенчмарках, а в abstract статьи на arXiv отдельно отмечено полное сохранение качества на 3,5 битах на канал и лишь небольшая деградация на 2,5 битах.

минимум 6-кратное сокращение памяти под KV-кэш до 8-кратного ускорения вычисления attention logits на H100 в 4-битной конфигурации по сравнению с неквантованными 32-битными ключами отсутствие необходимости в дообучении, fine-tuning или калибровочных наборах данных сильные результаты и в vector search: TurboQuant обошел базовые методы PQ и RabbiQ по recall на датасете GloVe Отдельно Google делает ставку на применение метода в поиске. TurboQuant, PolarQuant и QJL уменьшают не только расход памяти, но и время на построение индекса, при этом сохраняя точность поиска ближайших соседей. Это делает технологию интересной не только для генеративных моделей, но и для любой инфраструктуры, где нужно работать с огромными коллекциями векторов: от семантического поиска до рекомендательных систем и retrieval-слоя AI-продуктов.

Что это значит

TurboQuant показывает, что следующий большой выигрыш для LLM может прийти не от новых параметров модели, а от более умной работы с памятью. Если подход Google подтвердится в продакшене и появится в популярных inference-стеках, длинный контекст станет дешевле, быстрее и доступнее даже без апгрейда железа. Для разработчиков это шанс уместить более длинные сессии и RAG-сценарии в тот же бюджет GPU, а для пользователей — получить более стабильные ответы на больших документах и длинных диалогах.