TurboQuant: как Google сжал KV-кэш в 5-6 раз и обвалил акции памяти на $90 млрд

В марте 2026 года Google опубликовал пост про алгоритм квантизации KV-кэша — и это спровоцировало биржевую панику вокруг производителей памяти. Разбираем, что именно произошло и зачем тебе об этом знать.

Почему инвесторы испугались одного поста

Акции Micron, SanDisk, Samsung, SK Hynix и других производителей памяти за одну неделю суммарно потеряли около $90 млрд капитализации. Логика паники простая: если LLM начнут тратить в разы меньше памяти, спрос на железо упадет.

Алгоритм, который всё это спровоцировал, называется TurboQuant. Он принят на ICLR 2026, уже есть рабочие реализации - и это не маркетинг, а конкретный инструмент, который можно попробовать сегодня.

В чем была проблема с KV-кэшем

Когда LLM генерирует текст, на каждом шаге она учитывает все предыдущие токены. Чтобы не пересчитывать их заново, модель сохраняет промежуточные вычисления - это KV-кэш (Key-Value cache). Без него инференс был бы в разы медленнее.

Проблема: KV-кэш растет линейно с длиной контекста.

Конкретные числа: у Llama 3.1 70B при контексте 128K токенов KV-кэш в формате BF16 занимает около 40 ГБ (при использовании Grouped Query Attention с 8 KV-головами). Сама модель в BF16 весит порядка 140 ГБ. Итого один запрос требует 180 ГБ памяти - это не помещается на H100 (80 ГБ) даже в одиночку.

Если нужно параллельно обслуживать четырех пользователей на контексте 128K, только под KV-кэш уйдет 160 ГБ - больше, чем весят сами параметры модели.

Где это бьет больнее всего

Три сценария, где проблема становится критической:

• RAG с большими документами. Попытка загрузить в контекст кодовую базу или длинный PDF забивает всю VRAM еще до первого запроса.
• Агентские циклы. Многошаговый диалог с вызовом инструментов быстро раздувает контекст. Память заканчивается, историю приходится обрезать - агент теряет контекст последних трех шагов.
• Батчинг в нагруженных сервисах. KV-кэш каждого пользователя фиксируется в памяти. Чем длиннее диалоги, тем меньше параллельных сессий влезает на одну GPU.

Что пробовали раньше

Методы уже существовали, но у каждого был компромисс:

• GQA (Grouped Query Attention) - уменьшает количество KV-голов, активно используется в Llama 2, Qwen2 и других. Работает хорошо, но зашита в архитектуру.
• Sliding Window Attention - каждый слой смотрит только на фиксированное окно недавних токенов. KV-кэш перестает расти бесконечно, но контекст режется.
• MLA у DeepSeek - архитектурное решение, сжимает KV до латентных векторов и убирает около 93% кэша. Но требует переобучения.

Все эти подходы либо требуют переобучения (дорого и долго), либо режут контекст и ухудшают результаты.

Как работает TurboQuant

TurboQuant предлагает другое: просто сжать то, что уже есть, без изменения архитектуры, калибровки и файн-тюнинга. Берешь модель, включаешь метод - KV-кэш сжимается в 5-6 раз.

В основе две идеи.

Случайное вращение. Перед квантизацией вектор умножается на случайную ортогональную матрицу. После этого компоненты вектора становятся почти независимыми и распределены предсказуемо - из произвольного сложного распределения получается что-то близкое к нормальному.

Оптимальный квантизатор для известного распределения. Если распределение данных известно, можно заранее просчитать оптимальную сетку квантизации (Lloyd-Max квантизатор) - не равномерную, а такую, где ошибка минимальна именно для этого распределения. Кодбук считается один раз, хранится статично, никакой калибровки под конкретную модель не нужно.

Комбинация этих двух идей дает доказуемый результат: алгоритм находится в пределах ~2,7x от теоретического минимума ошибки квантизации. Это называется near-optimal.

Есть и третий компонент - QJL-коррекция остатка. Теоретически он обоснован, но на практике сообщество выяснило: в наивной реализации через стандартный attention softmax экспоненциально усиливает дисперсию от 1-bit коррекции, и результат становится хуже. В vLLM PR #38479 проблему решили через norm correction (варианты с суффиксом _nc).

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

Если ты деплоишь LLM в продакшн или гоняешь модели локально - TurboQuant стоит проверить. Сжатие KV-кэша в 5-6 раз без переобучения означает: либо больше параллельных сессий на той же GPU, либо более длинные контексты без OOM, либо возможность запустить модель на железе, где раньше не хватало памяти.

Алгоритм принят на ICLR 2026, реализация уже есть в vLLM - смотри PR #38479 с вариантами _nc. Подробный разбор с математикой и практическими примерами - в источнике на Habr.

Источник: Selectel на Habr, 15 августа

FAQ

Нужно ли переобучать модель под TurboQuant? Нет. Это одно из главных отличий от методов вроде MLA у DeepSeek - никакого файн-тюнинга и калибровки не требуется.

Где попробовать прямо сейчас? Реализация есть в vLLM (PR #38479). Используй варианты с суффиксом _nc для корректной работы norm correction.

Насколько ухудшается качество модели? Авторы заявляют near-optimal distortion rate - в пределах ~2,7x от теоретического минимума ошибки. Конкретные цифры деградации под твою модель и задачу - стоит проверять отдельно на своих данных.