TurboQuant неделю спустя: что показали первые бенчмарки и реализации

Прошла неделя с момента публикации TurboQuant — алгоритма Google Research для сжатия KV-кеша LLM до 3–4 бит. Мы уже разбирали, как он работает технически. Теперь — что из этого вышло на практике: первые бенчмарки показали, что Q8 с rotation почти не теряет качество (37,1% vs 37,9% на AIME25), сообщество создало рабочие реализации для llama.cpp, но скорость пока падает в 3–8 раз.

TurboQuant — алгоритм квантизации KV-кеша (Key-Value cache), промежуточного буфера, в котором LLM хранят контекст разговора. Сжимает его с 16 до 3–4 бит на значение без переобучения модели. Статья принята на ICLR 2026 (arXiv:2504.19874).

Первые бенчмарки: что показали числа

Один из первых тестов опубликован на r/LocalLLaMA — результаты на математическом бенчмарке AIME25 (чем выше — тем лучше). Связанный PR в llama.cpp подтверждает данные:

• F16 KV-кеш (без сжатия): 37,9%
• Q8_0 без rotation: 31,7% — потеря 6,2 п.п.
• Q8_0 с rotation (TurboQuant): 37,1% — почти полное восстановление
• Q4_0 без rotation: 2,0% — катастрофическая деградация
• Q4_0 с rotation: 21,7% — значительное улучшение, но всё ещё далеко от F16

Вывод: при 8-битной квантизации KV-кеша rotation практически полностью компенсирует потерю качества. При 4-битной — улучшение радикальное (с 2% до 21,7%), но до lossless ещё далеко. Безопасный минимум на сегодня — Q8 с rotation для K-тензоров и Q4 для V-тензоров.

Проблема K-тензоров: не всё сжимается одинаково

Разработчик inference-движка Llaminar провёл детальный анализ cosine similarity между сжатым и эталонным FP32-выходом на нескольких моделях. Главный вывод: K-тензоры (Key) и V-тензоры (Value) ведут себя при квантизации принципиально по-разному.

V-тензоры хорошо переносят 4-битное сжатие. K-тензоры — нет. Причина: K-тензоры имеют значительно более высокие нормы векторов по сравнению с V. Измерения показывают соотношение K/V-норм до 100–180x у современных моделей (Qwen2.5, GPT-2). Ошибка квантизации масштабируется с квадратом нормы, поэтому K-тензорам нужно больше бит для сохранения точности.

Практическая рекомендация: TQ8 для K-тензоров + TQ4 для V-тензоров. Это даёт хорошую экономию памяти при минимальной потере качества — компромисс, который подтверждён и бенчмарками, и cosine similarity анализом.

Где TurboQuant действительно меняет правила

Главный выигрыш — не скорость генерации (она пока даже падает), а объём контекста, который помещается в память. Расчёт из обсуждения llama.cpp для модели 70B Q4_K_M с 34 ГБ свободной VRAM:

• FP16 KV-кеш: ~109K токенов
• Q8 KV-кеш: ~218K токенов (2x)
• TurboQuant TQ3: ~536K токенов (5x)

Это значит: одна видеокарта с 48 ГБ памяти может работать с контекстом, который раньше требовал 3–4 карты. Для владельцев MacBook с Apple Silicon — локальная модель на 16 ГБ RAM теперь «видит» в 3–5 раз больше текста при той же скорости.

Реализации TurboQuant: кто уже попробовал

Официального кода от Google нет (ожидается во 2-м квартале 2026). Но сообщество уже создало рабочие реализации, а в vLLM открыт активный PR на нативную интеграцию:

• llama.cpp — минимум 3 независимых форка. Обсуждение интеграции в основную ветку. Флаги зависят от форка: --cache-type-k turbo3 (TheTom) или tq3_0 (другие форки)
• MLX — адаптация для Apple Silicon (M1–M5)
• PyTorch + Triton — reference-реализации для CUDA. Один разработчик получил побитово идентичный выход на Gemma 3 4B при 2-битной точности на RTX 4090
• vLLM — активный PR на нативную интеграцию TurboQuant как опции KV-кеша

Главная проблема текущих реализаций — скорость. Операция поворота вектора (rotation) пока не оптимизирована: сложность O(d²) вместо O(d log d). Замедление составляет 3–8x по сравнению с обычным Q8 KV-кешем. Разработчики работают над оптимизацией через преобразование Уолша–Адамара (Walsh-Hadamard transform), которое снизит сложность до O(d log d).

Реализации TurboQuant очень зависят от качества кода. Я видел vibecoded-реализации со скрытыми багами, которые убивали производительность.

DistanceSolar1449разработчик, r/LocalLLaMA

Реакция рынка

В день публикации TurboQuant 25 марта 2026 года акции производителей памяти снизились: SK Hynix потеряла 6,2%, Samsung — 4,8%, Micron — 3,4%. Логика рынка: если inference требует в 6 раз меньше памяти — спрос на HBM снижается. Но это упрощение: TurboQuant сжимает только KV-кеш, а не веса модели, и дешёвый inference увеличивает спрос на LLM в целом.

Что это значит для вас

Если вы запускаете LLM локально через llama.cpp, Ollama или LM Studio — в ближайшие месяцы ожидайте нативную поддержку TurboQuant. Практический эффект:

• Длинные контексты без нового железа — ваша текущая видеокарта или MacBook сможет работать с 3–5x большим контекстом
• Оптимальная конфигурация — TQ8 для K + TQ4 для V. Чистый TQ4 для обоих пока даёт заметную деградацию на K-тензорах
• Скорость пока не выигрыш — текущие реализации замедляют генерацию в 3–8 раз. Ждите оптимизированных ядер с Walsh-Hadamard transform
• Комбинируйте с квантизацией весов — TurboQuant сжимает KV-кеш, а не веса. Q4-модель + TQ4-кеш = максимальная экономия памяти

Выводы

TurboQuant — не серебряная пуля, но значимый шаг для локального inference. Rotation при Q8 KV-кеше работает почти без потерь. Q4 пока проблемный для K-тензоров, но V-тензоры сжимаются хорошо. Главный практический выигрыш — длинные контексты на существующем железе без покупки новых карт.

Скорость текущих реализаций — слабое место, но алгоритм публичен всего неделю, и оптимизации уже в работе. Через пару месяцев TurboQuant, скорее всего, станет стандартной опцией в llama.cpp и его производных.

Ссылки: Блог Google Research | Обсуждение в llama.cpp | Наш разбор алгоритма