Google Research выпустили TurboQuant - новый алгоритм сжатия данных, который сокращает объём кэш-памяти LLM как минимум в 6 раз и даёт ускорение до 8 раз. При этом заявляется отсутствие потерь в точности, что напрямую влияет на эффективность работы ИИ.

Если эти цифры подтверждаются на практике - это очень серьёзный прорыв, потому что inference в современных LLM всё чаще упирается не в вычисления, а в память и пропускную способность.
Думаю, будет правильно первым делом дать ссылку на оригинальную публикацию от самих Google с подробным описанием алгоритма:
https://research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression
Теперь давайте разберёмся, что это за алгоритм с таким громким названием и за счёт чего он вообще работает.
Что за KV-cache и на что он влияет?
Когда LLM (например, GPT-4 или Gemini) генерирует текст, она делает это токен за токеном, каждый раз учитывая весь предыдущий контекст через механизм attention. Пересчитывать всё заново на каждом шаге было бы слишком дорого, поэтому модель сохраняет промежуточные представления - Key и Value - в специальный кэш.
Это сильно ускоряет генерацию, но создаёт новую проблему: KV-cache растёт линейно вместе с длиной контекста. Чем длиннее диалог, тем больше данных нужно хранить и постоянно читать из памяти.
И здесь возникает, говоря по-русски, bottleneck. Со временем инференс упирается не в вычисления, а в пропускную способность памяти: GPU начинает «ждать данные», вместо того чтобы считать. Это увеличивает задержки, повышает стоимость и ограничивает длину контекста.

Сразу напрашивается сжать этот KV-cache. Но сделать это аккуратно сложно: эти данные напрямую участвуют в вычислении attention, и любая ошибка в них сразу влияет на качество модели. Именно эту задачу решает TurboQuant, который пытается сильно сжать KV-cache так, чтобы модель этого почти не заметила.
Как работает TurboQuant
Ключевая идея TurboQuant в том, чтобы сжимать данные с учётом того, как они будут использоваться в attention.
Алгоритм состоит из двух этапов:
На первом этапе применяется метод Полярного Квантования - PolarQuant. Перед сжатием векторы случайным образом «поворачиваются» - это упрощает их структуру и делает данные более удобными для квантования. После этого вектор переводится в полярное представление: вместо привычных координат модель оперирует радиусом (силой сигнала) и углом (его направлением).

Это даёт неожиданный эффект. В таком представлении данные становятся более «предсказуемыми», и их можно сжимать гораздо эффективнее без необходимости хранить дополнительные параметры (тот самый overhead, который обычно портит жизнь классическим методам). На этом этапе сохраняется основная информация о векторе - его смысловое ядро.
Но после сжатия неизбежно остаётся небольшая ошибка. Здесь включается второй этап - QJL (Quantized Johnson-Lindenstrauss // Квантованное Преобразование Джонсона-Линденштраусса). QJL работает как аккуратный корректор. Он кодирует остаточную ошибку буквально в 1 бит на значение и при этом делает это так, чтобы не искажались расстояния между векторами. Это важно, потому что attention как раз и основан на сравнении таких представлений.
В итоге получается интересная комбинация:
• PolarQuant даёт сильное сжатие
• QJL аккуратно подчищает ошибки
И в итоге получается эффективное сжатие без заметной потери качества.
Насколько это работает?
В статье приводятся довольно сильные результаты. Во-первых, KV-cache удаётся уменьшить как минимум в 6 раз. Это уже само по себе серьёзно, учитывая, сколько памяти он обычно занимает.

Во-вторых, за счёт уменьшения объёма данных ускоряется и сама работа модели. Заявляется до 8x ускорения, особенно на современных GPU вроде H100. Здесь важно понимать, что выигрыш идёт не из «магии алгоритма», а из более прозаичной вещи - нужно просто меньше читать из памяти.

Интересно, что авторам удалось опуститься до 3 бит на значение без дополнительного обучения модели. Обычно такие уровни сжатия требуют fine-tuning, но здесь, судя по описанию, удалось обойтись без него.
По качеству тоже всё выглядит аккуратно: на бенчмарках для длинного контекста и задачах вроде «needle-in-a-haystack» (когда нужно найти маленький факт в огромном тексте) деградации практически нет.
Конечно, без потерь в реальных системах почти не бывает. Но даже небольшое ухудшение при таком огромном выигрыше в ресурсах - вполне приемлемый компромисс.
Резюме
Сегодня основная стоимость инференса - это не столько вычисления, сколько память и её пропускная способность. Поэтому любые улучшения в работе с KV-cache конвертируются во вполне прикладные вещи: снижение стоимости запросов, рост throughput и возможность работать с более длинными контекстами.
Кроме того, такие методы открывают дорогу к более эффективному запуску моделей на ограниченном железе - от небольших GPU до edge-устройств. И важно, что TurboQuant применим не только к LLM: те же идеи лежат в основе векторного поиска, на котором строятся современные поисковые и рекомендательные системы.

Можно сказать, что TurboQuant - хороший пример того, как серьёзные улучшения в AI происходят не только за счёт новых моделей, но и за счёт глубокой оптимизации инфраструктуры вокруг них. Это сильная инженерная работа, которая аккуратно использует математику, чтобы выжать максимум из уже существующих подходов.
Если заявленные результаты подтвердятся на продакшене, такие методы вполне могут стать стандартом для инференса LLM в ближайшие годы. Модели станут сильнее, вычисления дешевле и трава зеленее.
P.S.
Спасибо, что вместе со мной решили разобраться с новым прорывом Google. Эту статью я в первую очередь написал для себя, чтобы лучше понять, что это такое и как работает. Буду очень рад обратной связи и вашей поддержке.
И также у меня есть небольшой Telegram-канал, где я пишу о проблемах работы с данными, цифровой экологии, интересном из мира AI и IT - в первую очередь интересном для меня, но надеюсь, и вас зацепит и вы решите остаться.
Комментарии (10)

Petr_axeman
25.03.2026 23:01Говоря по-русски, bottleneck
Сильное утверждение. Текст точно не написан ИИ, и конечно же "честно честно проходил вычитку.

meliksetyan Автор
25.03.2026 23:01Я рад, что вы оценили прикол.
Либо это я сейчас не выкупил ваш сарказм.

murkin-kot
25.03.2026 23:01А почему только кэш?
Сами сетки давно пора сжимать. Да, на обработке запроса будут потери, но это же копейки, процентов 10 при и так очень большой скорости (в сравнении с генерацией). Зато генерацию это ускорит в разы.
В общем гуглы как-то примитивно к вопросу подошли. Сказали А, нужно и Б сказать.

memfd
25.03.2026 23:01Друзья, скрестим пальцы, что это хоть немного собьёт цены на RAM/VRAM память..

Zombieleaver
25.03.2026 23:01это позволить увеличить мощность за так - теперь они могут дешевле все это обрабатывать, спрос то не будет уменьшаться, больше приятности что для локальных моделей это будет бустом

maaGames
25.03.2026 23:01Не собьёт. Там экономии сотни мегабайт для 32КБ контекста (KV было 600МБ, стало 150МБ? при самой модели 34ГБ). Если проигнорировать производительность и ухудшение качества, то в настройках LLM можно для KV кэша включить Q4 квантизацию, вместо FP16, и получить примерно такой же выигрыш (уменьшится ровно в 4 раза). Просто чтобы примрено оценить на реальных моделях, сколько памяти удастся выиграть. У TurboQuant сжатие обещают без ухудшения качества, да ещё и рост скорости и это круто, но на потребности в памяти это никак не скажется, цены из-за этого не упадут.
Triton5
Уменьшение размера KV-кеша напрямую снимает основное ограничение для увеличения контекстного окна т.е. количество памяти VRAM под KV кэш, так что это очень хорошо.
Petr_axeman
Проблема в том что внимание в контексте очень неравномерное, так что если к примеру контекст увеличится в 2 раза, возможно мы получим ещё больший разрыв во внимании модели к краям и к центру контекста.