TurboQuant: Google ужал KV-кэш в 5 раз и вышел на теоретический предел

KV-кэш — это та самая структура данных, которая не даёт длинному контексту в LLM захлебнуться. Без него каждый новый токен заставляет модель пересчитывать ключи и значения для всех предыдущих; с ним — нет, и латентность падает на порядки. Цена удобства — память: при длинном контексте или большом числе параллельных пользователей KV-кэш съедает столько же VRAM, сколько и сама модель.

Google Research выкатил алгоритм, который режет этот кэш в 4,5–5 раз и при этом не теряет в качестве — TurboQuant. Работа, авторы которой Amir Zandieh и Vahab Mirrokni, принимается на ICLR 2026 и уже в апреле получила статус must-read у инженеров, занимающихся инференсом больших моделей.

Зачем это нужно

Длинный контекст — главный товар, которым frontier-лаборатории торгуют последние два года. Gemini, Claude и GPT соревнуются за то, у кого окно длиннее: 1M, 2M, 10M токенов. Но за каждым миллионом контекста стоят гигабайты VRAM на KV-кэш, и именно они ограничивают, сколько одновременных пользователей помещается на одну GPU. Это давно стало основной статьёй расходов на инференс — больше, чем сами веса.

Существующие подходы — Grouped-Query Attention, PagedAttention, простая INT8/INT4-квантизация — уменьшают расход, но платят за это либо точностью, либо требованиями к перекалибровке модели. TurboQuant обещает то, чего не было раньше: компрессия до 3 бит на канал без потерь, без файнтюна и с ускорением вычислений.

Как это работает: две стадии и одна хитрость

Алгоритм состоит из двух последовательных этапов. Первый — PolarQuant — берёт каждый KV-вектор и выполняет случайное ортогональное вращение. После такого вращения «выбросы» (outliers — значения, которые в десятки раз больше остальных и обычно убивают точность квантизации) размазываются по всем координатам. Распределение становится изотропным, близким к гауссову, и каждая координата подчиняется известному Beta-распределению.

Зная распределение заранее, можно один раз посчитать оптимальные «уровни» квантизации (Lloyd-Max codebook) и переиспользовать их для всех векторов в инференсе. Это даёт основной выигрыш по памяти и убирает необходимость онлайн-калибровки.

Вторая стадия — Residual Correction — занимается тем, что традиционная квантизация выкидывает: ошибкой первого этапа. Вместо того чтобы хранить остаток в полной точности, TurboQuant спрашивает у него только знак (+1 или −1) после случайной проекции. Это так называемый Quantized Johnson-Lindenstrauss Transform (QJL), который при правильном масштабировании даёт несмещённую оценку attention-скоров. Дополнительно сохраняется L2-норма остатка как один скаляр на вектор.

В итоге для каждого токена в кэше лежат три вещи: индексы Lloyd-Max-кодбука, биты знаков QJL и одна нормирующая константа. Авторы формально доказывают, что эта схема достигает теоретического оптимума — никакой алгоритм с тем же бюджетом битов не может сохранить attention-произведения лучше.

Цифры

Тестировали на длинно-контекстных бенчмарках — LongBench, Needle In A Haystack, ZeroSCROLLS, RULER, L-Eval — на открытых LLM Gemma и Mistral, а также на Llama-3.1-8B-Instruct.

Параметр	Базовая модель	TurboQuant
Бит на канал KV	16 (FP16)	3–3,5
Сжатие KV-кэша	1×	4,5–5×
Скорость attention logits (H100, 4-bit)	1×	до 8×
Точность на длинном контексте	базовая	без потерь
Файнтюн модели	не нужен	не нужен

На Needle-in-Haystack-задачах TurboQuant даёт идеальные результаты при сокращении памяти как минимум в 6 раз. На векторном поиске (GloVe, d=200) обходит классические PQ и RabbiQ по 1@k recall, причём без больших кодбуков и без подгонки под датасет.

8-кратное ускорение attention-логитов на H100 при 4-битном TurboQuant против 32-битного незажатого варианта — это не косметика. Это означает, что развёрнуть тот же сервис можно либо на меньшем числе GPU, либо обслуживать больше пользователей на тех же.

Почему это важно прямо сейчас

Инференс LLM — это сейчас основной центр затрат frontier-лабораторий. Anthropic, OpenAI, Google открыто говорят, что упираются в compute. Любая техника, которая снижает расход VRAM на токен в три-пять раз без качественных потерь, прямо переводится в маржу или в более длинные контексты для пользователя.

Дополнительный бонус — TurboQuant работает на любой обученной модели без файнтюна. Это значит, что её можно прикрутить к уже задеплоенным сервисам, не пересчитывая веса. Для команд, которые держат собственные инференс-стэки на Llama, Qwen или Gemma, это рабочий путь к удвоению-утроению пропускной способности уже сейчас.

Есть и второй фронт применения — векторный поиск. Эмбеддинги в больших RAG-системах хранятся в FP16 или FP32, и базы на миллиарды векторов превращаются в терабайтные индексы. TurboQuant позволяет ужать их до тех же 3 бит на канал, сохранив 1@k recall. Это отдельная история, но потенциал не меньший: семантический поиск Google и многих других продуктов держится именно на таких индексах.

Что дальше

Сама работа — лишь часть линейки. У Google в той же серии — QJL (AAAI 2025) и PolarQuant (AISTATS 2026), как самостоятельные алгоритмы. Open-source реализации уже появляются: на GitHub лежит scrya-com/rotorquant, а энтузиаст из сообщества реализовал TurboQuant на Zig для оффлайн-вектор-квантизации.

Появляются и производные. Группа исследователей уже адаптировала TurboQuant под protein-LLM (TurboESM, 3-битная квантизация KV-кэша для ESM-моделей). Это намекает, что метод приживётся не только в текстовых LLM, но и в биологии, химии, поиске и любой задаче, где attention-механизм встречается с большим контекстом.

Одно техническое следствие — давление на индустрию памяти. Если KV-кэш можно ужать впятеро без потерь, спрос на сверхдорогую HBM-память при том же объёме инференса падает. Это не отменяет рост AI-датацентров, но меняет соотношение: при прочих равных, лаборатории смогут размещать больше пользователей на той же железе. И именно это, а не очередной бенчмарк, определит экономику следующего года.