Когда в марте 2026 года Google опубликовала статью об алгоритме сжатия памяти для языковых моделей, рынок производителей памяти отреагировал паникой: акции Micron, SanDisk, Samsung, SK Hynix за

Когда в марте 2026 года Google опубликовала статью об алгоритме сжатия памяти для языковых моделей, рынок производителей памяти отреагировал паникой: акции Micron, SanDisk, Samsung, SK Hynix за неделю потеряли почти 90 миллиардов долларов капитализации. Инвесторы решили, что если модели начнут тратить в разы меньше памяти, то и железо понадобится не в таких объёмах. Герой этой статьи — алгоритм TurboQuant. И хотя называть его революцией было бы преувеличением, штука действительно интересная, уже есть рабочие реализации, и если вы деплоите LLM в продакшн или просто гоняете модели локально, вам стоит разобраться, что из заявленного правда, а что нет.

Чтобы понять, зачем нужен TurboQuant, нужно разобраться с KV-кэшем. Когда LLM генерирует текст, на каждом шаге она учитывает все предыдущие токены. Чтобы не пересчитывать их заново, модель сохраняет промежуточные вычисления в памяти — это и есть KV-кэш (Key-Value cache). Без него инференс был бы в разы медленнее и дороже. Но есть проблема: KV-кэш растёт линейно с длиной контекста. Для Llama 3.1 70B при контексте 128K токенов KV-кэш в формате BF16 занимает около 40 ГБ, а сама модель весит порядка 140 ГБ. Итого один запрос требует 180 ГБ памяти — это не помещается даже на H100 с его 80 ГБ. Если же обслуживать четырёх пользователей на контексте 128K, только под KV-кэш уйдёт 160 ГБ — больше, чем весят параметры модели.

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

Проблему пытались решать по-разному. GQA уменьшает количество KV-голов — работает и активно используется ещё со времён Llama 2. Sliding Window Attention ограничивает окно недавних токенов, чтобы кэш переставал расти бесконечно. MLA от DeepSeek сжимает KV до латентных векторов и убирает около 93% кэша. Но все эти методы либо требуют переобучения модели, что дорого и сложно, либо режут контекст, ухудшая результаты.

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

Первая — случайное вращение. Перед квантизацией вектор умножается на случайную ортогональную матрицу. После такого вращения компоненты вектора становятся почти независимыми и распределены предсказуемо: из произвольного и сложного распределения получаем что-то близкое к нормальному. Вторая — оптимальный квантизатор для известного распределения (Lloyd-Max). Если мы знаем, как распределены данные, то можно заранее просчитать оптимальную сетку квантизации — не равномерную, а такую, где ошибка минимальна именно для этого распределения. Кодбук считается один раз, хранится статично и не требует калибровки под конкретную модель. Комбинация даёт результат: алгоритм доказуемо находится в пределах примерно 2,7 раза от теоретического минимума ошибки квантизации — это называют near-optimal.

Есть и третий компонент — QJL-коррекция остатка. Теоретически он красив, но на практике сообщество выяснило: в наивной реализации через стандартный attention softmax экспоненциально усиливает дисперсию от 1-bit коррекции, и результат становится хуже. В vLLM проблему решили через norm correction, в форках llama.cpp QJL чаще всего просто отключают или упрощают. Главное, что нужно запомнить: алгоритм data-oblivious — ему не нужны калибровочные данные, не нужен файн-тюнинг, он сразу работает на любой трансформерной модели.

Теперь про цифры. Google заявляла «up to 8x speedup on H100 GPUs». Но реально ваш инференс не станет в восемь раз быстрее в 99% случаев. Восьмикратный рост измерен относительно FP32, который никто в проде не использует. Относительно реально рабочего FP16-бейзлайна это примерно 4x. И это ускорение только attention, а не end-to-end инференса. В реальном пайплайне attention — лишь часть времени, есть ещё линейные слои, sampling, IO. Wall-clock времени от токена до токена в методике нет, а сообщество намерило overhead на префил порядка 21–27 мс на квантизацию — не катастрофа, но и не бесплатно.

Тогда, может, нас всех оверхайпнули? На самом деле нет, потому что реальная ценность TurboQuant не в скорости, а в памяти. Сжать KV-кэш в пять раз — значит впихнуть в одну GPU контекст, который раньше не влезал. Например, на Llama 3.1 70B это разница между примерно 109K токенов и примерно 536K токенов на 34 ГБ VRAM.

На бенчмарках LongBench и Needle-in-a-Haystack результаты впечатляют: модель Llama-3.1-8B-Instruct при квантовании до 3,5 бит набирает 50,06 балла на LongBench — ровно столько же, сколько в оригинальном FP16, а на Needle держит 0,997 на контексте вплоть до 104K токенов. То есть на длинном контексте качество не разваливается.

Но есть нюансы. Все замеры проводились на небольших моделях до примерно 12B параметров: Llama-3.1-8B, Mistral-7B, Gemma. Данных для архитектур масштаба 70B+ в исследовании нет вовсе, и переносимость на крупные модели остаётся открытым вопросом. Сообщество провело самостоятельные тесты: на модели 104B с пресетом turbo3 прирост перплексии составил всего +3,6%. Но «мы сами проверили, вроде работает» — не замена нормального бенчмарка. Также в исследовании отсутствует классическая база: метрики WikiText-2 perplexity и MMLU — без них нормально сравнить метод с конкурентами в одной системе координат не получится.

Ещё один нюанс: ключи и значения в KV-кэше — не одно и то же. У Qwen2.5, например, нормы ключей на порядки больше норм значений. Поэтому симметричная квантизация с одинаковой разрядностью для K и V — это костыль: ключам по-хорошему нужно больше бит. Асимметричные пресеты вроде K8V4, появившиеся в vLLM и форках llama.cpp, — тому доказательство.

TurboQuant — далеко не единственный метод сжатия KV-кэша и даже не обязательно лучший для вашего сценария. Есть метод KVTC, построенный на иной философии: это своего рода аналог JPEG для KV-кэша. Разработчики заявляют о сжатии вплоть до 20 раз против 5–6x у TurboQuant, с потерей точности менее одного процентного пункта. KVTC тестировался на куда более широкой линейке моделей — от 1,5B до 70B. Явный минус — необходимость однократной калибровки примерно на 200K токенов. Для продакшен-сервисов с фиксированной моделью это не проблема, а вот для локального сценария «скачал GGUF и запустил» уже больно.

Есть RotorQuant — community-проект, который решает конкретную проблему TurboQuant: умножение на полную d?d ортогональную матрицу — это 16 384 операций для d=128. RotorQuant заменяет её математической хитростью, дающей около 100 операций. Вращение выполняется в 10–31 раз быстрее, а сам алгоритм требует в 44 раза меньше параметров при сопоставимом качестве attention: косинусное сходство 0,990 против 0,991 у TurboQuant. Минус: пока проигрывает по качеству и находится на ранней стадии. Но если авторы «дожмут» качество, проект может стать дефолтным выбором для мобильных и edge-сценариев.

Есть KIVI — проверенный бейзлайн, представленный на ICML 2024 и уже встроенный в экосистему Hugging Face Transformers. Метод использует асимметричную 2-битную квантизацию: поканальную для ключей и потокеновую для значений. Такой подход сжимает KV-кэш в 16 раз, снижая пиковое потребление видеопамяти примерно в 2,6 раза. Для продакшена, где стабильность важнее максимального сжатия, — вполне хороший вариант.

Комьюнити уже создало более 15 реализаций TurboQuant — от простых Python-пакетов до специализированных Metal-шейдеров. Если вы гоняете модели локально через llama.cpp, ваш основной вариант — TheTom/turboquant_plus: самый зрелый форк с поддержкой Metal, CUDA и CPU, протестированный на моделях от 1,5B до 104B. Есть пресеты turbo2 (2-bit) со сжатием в 6,4 раза и увеличением перплексии.

Главный вывод: TurboQuant — это не про ускорение инференса в 8 раз, а про память. Он позволяет впихнуть в GPU контекст, который раньше не влезал, и делает это без калибровки и файн-тюнинга, работая на любой трансформерной модели. На маленьких моделях качество на длинном контексте не страдает, на больших — пока открытый вопрос, но первые тесты сообщества обнадёживают. Альтернатив хватает: KVTC для максимального сжатия с калибровкой, KIVI для стабильного продакшена, RotorQuant для edge-сценариев в будущем.

Так что в следующий раз, когда увидите заголовок про очередной «прорыв», не спешите паниковать. Смотрите на методику: на чём меряли, относительно чего, какие модели, есть ли end-to-end замеры. TurboQuant действительно полезен, но его место — не «сделать всё в 8 раз быстрее», а «влезть туда, куда раньше не влезало». А какой из методов сжатия KV-кэша вы уже пробовали в своих проектах, и был ли эффект сопоставим с заявленным?

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: