Революция на рынке ОЗУ откладывается. Праотец TurboQuant раскрыл все нюансы и написал жалобу в комитет по этике

Инженеры Google пообещали сократить потребление памяти ^[1] в 8 раз. Рынок ОЗУ тут же отреагировал: акции покатались вниз. Финансовые аналитики, как и всё ИИ-сообщество в те дни, не учли несколько технических нюансов.

О них стало известно благодаря Цзяньян Гао — одному из создателей RaBitQ. Этот алгоритм можно назвать прототипом TurboQuant. Сходство настолько сильное, что в сторону Google отправилась официальная жалоба. 

Разбираемся.

Шум из-за TurboQuant

24 марта 2026 года Google Research опубликовала статью о TurboQuant — алгоритме, который сжимает KV-кэш языковых моделей до 3 бит без переобучения и без заметной потери качества.

26 марта рынок отреагировал продажами в секторе памяти. SK Hynix потерял 6,23%, Samsung — 4,8%, американские бумаги Micron и SanDisk упали примерно на 5% и 8% соответственно. Логика ^[2] простая: если большим моделям нужно в шесть раз меньше видеопамяти, спрос на HBM и DRAM для дата-центров может сократиться.

Что такое KV-кэш и почему он проблема

Когда трансформер генерирует текст, он на каждом шаге вычисляет так называемые ключи и значения (Key и Value) для всех токенов в контексте. Хранить их повторно не нужно — они кэшируются. Это KV-кэш.

На коротких контекстах KV-кэш почти не требует мощностей. На длинных — это главный пожиратель памяти, причём он растёт линейно с длиной текста. Llama 3 70B при 128 тысячах токенов контекста занимает KV-кэшем десятки гигабайт — иногда больше, чем сами веса модели. Это узкое место любого инференса с длинным контекстом: именно из-за KV-кэша нельзя просто «дать больше RAM» и запустить больше одновременных запросов.

Квантование весов модели — GPTQ, AWQ, методы семейства Q4_K_M из llama.cpp — давно решают проблему хранения самой модели. Но KV-кэш устроен иначе: векторы в нём эфемерны, уникальны для каждого запроса, появляются в реальном времени. Офлайн-калибровка здесь не работает. Нужен алгоритм, который квантует любой вектор мгновенно, без предварительного знания о данных.

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

Алгоритм состоит из двух этапов.

Первый — PolarQuant. Перед квантованием каждый вектор умножается на случайную ортогональную матрицу. Это перераспределяет энергию вектора равномерно по всем координатам: после поворота каждая координата следует предсказуемому статистическому распределению. Теперь к ней можно применить оптимальный квантователь (Lloyd-Max), рассчитанный один раз из теории вероятностей, — одинаковый для любой модели, любого слоя, любой головы. Никаких калибровочных данных не нужно.

Второй этап — QJL (Quantized Johnson-Lindenstrauss). Обычное квантование вносит систематическую ошибку ^[3]: скалярные произведения слегка занижаются, и эта ошибка накапливается на длинных контекстах. QJL берёт остаток от первого этапа и кодирует его знак одним битом. Это делает оценку скалярных произведений несмещённой — без накопленного дрейфа.

Вместе это даёт 3-битное представление KV-кэша при минимальных потерях точности. По заявлению авторов, на задачах типа Needle-in-a-Haystack (поиск конкретного факта в очень длинном тексте) результаты при 3 битах неотличимы от полной точности на Llama-3.1-8B и семействах Gemma и Mistral. Ускорение вычисления логитов внимания ^[4] на H100 — до 8x. Снижение потребности ^[5] в VRAM под KV-кэш — как минимум 6x.

Что здесь важно оговорить

Несколько вещей фактура об алгоритме аккуратно замалчивает.

Маленькие модели страдают. Сообщество уже проверило: на моделях до 3B параметров агрессивное сжатие до 3 бит заметно ухудшает качество — появляются повторения ^[6], деградирует связность текста. Золотой стандарт для большинства задач — 4 бита, где потери при 8B+ практически незаметны.

Официального кода нет. Google Research опубликовала блогпост и препринт, но официальная реализация ожидается только во втором квартале 2026 года. В production-фреймворках — vLLM, llama.cpp, SGLang — TurboQuant пока не интегрирован. Сообщество уже написало несколько реализаций на PyTorch и Triton, некоторые хорошо воспроизводят цифры из статьи, но говорить о промышленном применении пока рано.

Есть научная полемика. Автор RaBitQ — более раннего алгоритма, тоже использующего случайный поворот перед квантованием — опубликовал открытый комментарий ^[7], где зафиксировал три точки расхождения с тем, как их работа описана в статье TurboQuant.

Три конкретных претензии: TurboQuant скрывает методологическое сходство с RaBitQ, называет его теорию «субоптимальной» без оснований, и в бенчмарках сравнивал свой алгоритм на GPU A100 с RaBitQ на однопоточном Python. Что характерно, второй автор TurboQuant ещё в январе 2025 года сам писал команде RaBitQ с просьбой помочь отладить их же код — то есть был хорошо знаком с тем, что потом описал неточно. Жалоба подана в комитет по этике ICLR, технический отчёт готовится к публикации на arXiv. Google пока публично не ответил.

Рыночная паника — преувеличение. Аргумент о падении спроса на DRAM работает только в специфической логике: KV-кэш — лишь часть памяти дата-центра, вокруг которой есть ещё веса моделей, обучение ^[8], другие задачи. Один алгоритм для инференса не меняет структуру рынка памяти. Аналитики, которые это понимают, восстановили котировки за несколько сессий.

Почему это всё равно важно

TurboQuant — не революция в духе «теперь всё будет по-другому», но честный технический прогресс в конкретном узком месте.

Задача квантования KV-кэша сложнее квантования весов именно из-за онлайн-природы: нельзя один раз посчитать и забыть, нужно обрабатывать каждый вектор в реальном времени. То, что авторы получили алгоритм без калибровки, работающий при 3 битах с формальными гарантиями близости к информационно-теоретическому пределу — это честный вклад.

Для инференса с длинными контекстами (32k токенов и выше) это может снизить стоимость одного токена или, при том же железе, увеличить пропускную способность в разы. Для локального запуска больших моделей это шаг к тому, чтобы 70B-модели стали доступны на оборудовании, которое сейчас для этого не предназначено.

Когда Google выпустит официальный код и алгоритм начнут интегрировать в стандартные стеки — вот тогда будет повод говорить о реальных последствиях для индустрии.