Инженеры Google пообещали сократить потребление памяти в 8 раз. Рынок ОЗУ тут же отреагировал: акции покатались вниз. Финансовые аналитики, как и всё ИИ-сообщество в те дни, не учли несколько технических нюансов.
О них стало известно благодаря Цзяньян Гао — одному из создателей RaBitQ. Этот алгоритм можно назвать прототипом TurboQuant. Сходство настолько сильное, что в сторону Google отправилась официальная жалоба.
Разбираемся.
Шум из-за TurboQuant
24 марта 2026 года Google Research опубликовала статью о TurboQuant — алгоритме, который сжимает KV-кэш языковых моделей до 3 бит без переобучения и без заметной потери качества.
26 марта рынок отреагировал продажами в секторе памяти. SK Hynix потерял 6,23%, Samsung — 4,8%, американские бумаги Micron и SanDisk упали примерно на 5% и 8% соответственно. Логика простая: если большим моделям нужно в шесть раз меньше видеопамяти, спрос на 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). Обычное квантование вносит систематическую ошибку: скалярные произведения слегка занижаются, и эта ошибка накапливается на длинных контекстах. QJL берёт остаток от первого этапа и кодирует его знак одним битом. Это делает оценку скалярных произведений несмещённой — без накопленного дрейфа.
Вместе это даёт 3-битное представление KV-кэша при минимальных потерях точности. По заявлению авторов, на задачах типа Needle-in-a-Haystack (поиск конкретного факта в очень длинном тексте) результаты при 3 битах неотличимы от полной точности на Llama-3.1-8B и семействах Gemma и Mistral. Ускорение вычисления логитов внимания на H100 — до 8x. Снижение потребности в VRAM под KV-кэш — как минимум 6x.
Что здесь важно оговорить
Несколько вещей фактура об алгоритме аккуратно замалчивает.
Маленькие модели страдают. Сообщество уже проверило: на моделях до 3B параметров агрессивное сжатие до 3 бит заметно ухудшает качество — появляются повторения, деградирует связность текста. Золотой стандарт для большинства задач — 4 бита, где потери при 8B+ практически незаметны.
Официального кода нет. Google Research опубликовала блогпост и препринт, но официальная реализация ожидается только во втором квартале 2026 года. В production-фреймворках — vLLM, llama.cpp, SGLang — TurboQuant пока не интегрирован. Сообщество уже написало несколько реализаций на PyTorch и Triton, некоторые хорошо воспроизводят цифры из статьи, но говорить о промышленном применении пока рано.
Есть научная полемика. Автор RaBitQ — более раннего алгоритма, тоже использующего случайный поворот перед квантованием — опубликовал открытый комментарий, где зафиксировал три точки расхождения с тем, как их работа описана в статье TurboQuant.
Три конкретных претензии: TurboQuant скрывает методологическое сходство с RaBitQ, называет его теорию «субоптимальной» без оснований, и в бенчмарках сравнивал свой алгоритм на GPU A100 с RaBitQ на однопоточном Python. Что характерно, второй автор TurboQuant ещё в январе 2025 года сам писал команде RaBitQ с просьбой помочь отладить их же код — то есть был хорошо знаком с тем, что потом описал неточно. Жалоба подана в комитет по этике ICLR, технический отчёт готовится к публикации на arXiv. Google пока публично не ответил.
Рыночная паника — преувеличение. Аргумент о падении спроса на DRAM работает только в специфической логике: KV-кэш — лишь часть памяти дата-центра, вокруг которой есть ещё веса моделей, обучение, другие задачи. Один алгоритм для инференса не меняет структуру рынка памяти. Аналитики, которые это понимают, восстановили котировки за несколько сессий.
Почему это всё равно важно
TurboQuant — не революция в духе «теперь всё будет по-другому», но честный технический прогресс в конкретном узком месте.
Задача квантования KV-кэша сложнее квантования весов именно из-за онлайн-природы: нельзя один раз посчитать и забыть, нужно обрабатывать каждый вектор в реальном времени. То, что авторы получили алгоритм без калибровки, работающий при 3 битах с формальными гарантиями близости к информационно-теоретическому пределу — это честный вклад.
Для инференса с длинными контекстами (32k токенов и выше) это может снизить стоимость одного токена или, при том же железе, увеличить пропускную способность в разы. Для локального запуска больших моделей это шаг к тому, чтобы 70B-модели стали доступны на оборудовании, которое сейчас для этого не предназначено.
Когда Google выпустит официальный код и алгоритм начнут интегрировать в стандартные стеки — вот тогда будет повод говорить о реальных последствиях для индустрии.
ссылка на оригинал статьи https://habr.com/ru/articles/1028924/