Релиз BeeLLama.cpp v0.4.0 принёс два экспериментальных метода, которые резко меняют компромисс между памятью и качеством на длинных контекстах. Variance-normalized квантизация KVarN и механизм KV cache precision tail в паре снижают расхождение Кульбака-Лейблера на 42–76% для агрессивных форматов кэша. Разработчики отказались от собственной реализации DFlash, которая теперь доступна в основном апстриме llama.cpp, и удалили модуль TurboQuant, показавший низкую практическую ценность. Фокус сместился на то, что даёт измеримый выигрыш: точность на бит и контроль деградации на последовательностях в десятки тысяч токенов.
Форк расширяет палитру стандартных типов кэша форматами q2_0–q3_1 и q6_0–q6_1 и добавляет адаптивную схему draft-max для спекулятивного декодирования. Бенчмарки на Qwen 3.6 27B и Gemma 4 31B подтверждают: добавление tail в 1024 токена позволяет агрессивным квантизациям работать с качеством, близким к BF16, без взрывного роста VRAM. Если вы экспериментировали с квантизацией KV-кэша через KVarN на Bonsai-Ternary-27B или ищете способы ужать память под длинные диалоги, этот релиз даёт новый набор инструментов.
Что нового в BeeLLama.cpp v0.4.0: фокус на эффективность KV-кэша
BeeLLama.cpp - форк llama.cpp, сфокусированный на продвинутой квантизации KV-кэша. Версия 0.4.0 очищает кодовую базу от устаревших компонентов и добавляет два принципиально новых механизма. Отказ от DFlash продиктован тем, что эта функциональность уже присутствует в апстриме. TurboQuant удалён из-за недостаточной практической пользы - авторы форка прямо признали, что модуль не оправдал ожиданий.
Ключевые изменения в релизе:
- KVarN - variance-normalized квантизация KV-кэша, дающая лучшую точность на бит при минимальном оверхеде по производительности.
- KV cache precision tail - гибридное хранение: последние N токенов в BF16/F16, остальной кэш в низкобитном формате.
- Расширенная палитра типов кэша - добавлены q2_0, q2_1, q3_0, q3_1 и q6_0, q6_1.
- Адаптивная схема draft-max - динамический выбор числа draft-токенов при спекулятивном декодировании.
Практическая ценность концентрируется вокруг одного сценария: длинные контексты на ограниченной VRAM. Квантизация KV-кэша сама по себе экономит память, но агрессивные форматы вроде q2_0 быстро деградируют по качеству. KVarN и precision tail решают эту проблему с разных сторон - первый улучшает саму квантизацию, второй защищает самые важные токены от потери точности.
Для тех, кто глубоко погружён в оптимизацию инференса, релиз интересен связкой с другими техниками. Например, спекулятивное декодирование с n-gram драфтерами в llama.cpp даёт до 6-кратного ускорения на Qwen 3.6 27B. Совмещение с новыми методами квантизации кэша потенциально позволяет одновременно ускорить генерацию и снизить потребление памяти.
KVarN: variance-normalized квантизация для максимальной точности на бит
Стандартная квантизация KV-кэша использует равномерное распределение уровней квантования в пределах min-max диапазона значений. Проблема в том, что распределение активаций в кэше далеко от равномерного - выбросы растягивают шаг квантизации, и основная масса значений, clustered вокруг нуля, теряет точность. KVarN решает это нормализацией по дисперсии перед квантизацией.
Почему дисперсия важна: проблема выбросов в KV-кэше
Внутри KV-кэша скрыты состояния attention-механизма для каждого токена. Часть каналов демонстрирует аномально высокие абсолютные значения - так называемые outlier-каналы. При равномерной квантизации весь диапазон сжимается до нескольких бит, и выбросы забирают на себя непропорционально много уровней квантования. Основная масса значений, отвечающая за тонкие различия в attention score, квантуется грубо.
KVarN применяет нормализацию по дисперсии: значения в каждом блоке масштабируются так, чтобы дисперсия стала единичной. Выбросы перестают доминировать над шагом квантизации. Фактически метод выравнивает «информационную плотность» по каналам перед тем, как отбросить младшие биты. Результат - более точное восстановление оригинальных attention-весов при той же битности.
Техника перекликается с подходами, описанными в работах KIVI и QuIP#, но реализована непосредственно в рантайме BeeLLama.cpp. Практическое руководство по запуску Bonsai-Ternary-27B с KVarN показывает, что метод уже работает на реальных моделях с большим контекстом, сокращая VRAM на 3.3 ГБ и ускоряя генерацию на 68%.
Практический выигрыш: точность без потери скорости
Оверхед KVarN на инференс минимален. Нормализация по дисперсии выполняется один раз при записи в кэш и не требует повторных вычислений при чтении. Дополнительные операции - масштабирование и квантование - реализованы на уровне SIMD-инструкций, их вклад в общее latency измеряется долями процента.
Сравнение с обычной квантизацией показывает: при 4-битном кэше KVarN сохраняет KLD на уровне, характерном для 6-битных форматов без нормализации. Для 2-битных и 3-битных форматов разрыв ещё заметнее - без нормализации они практически непригодны на контекстах длиннее 8K токенов, а с KVarN демонстрируют приемлемое качество вплоть до 32K.
Выбор между KVarN и стандартными типами кэша сводится к простому правилу: если вы уже используете q4_0 или ниже, KVarN даёт прирост точности без дополнительных затрат памяти. Если вы сидите на q8_0 или BF16, выигрыш менее заметен - там и так хватает битности для точного представления attention-весов.
KV Cache Precision Tail: сохраняем качество на длинных дистанциях
Механизм precision tail исходит из простого наблюдения: при генерации очередного токена модель опирается на последние позиции в разы сильнее, чем на отдалённый контекст. Хранение всего кэша в низкобитном формате равномерно деградирует и «горячие» токены, и те, что уже ушли в дальнюю историю. Хранение всего кэша в BF16/F16 съедает VRAM. Precision tail предлагает гибрид: хвост из N последних токенов в высоком разрешении, всё остальное - в выбранном низкобитном формате.
Как это работает: гибридное хранение кэша
Конфигурация задаётся двумя параметрами: тип квантизации для основного кэша и размер tail в токенах. При размере tail = 1024 и основном формате q3_0 последние 1024 токена хранятся в BF16 или F16, а позиции 0..N-1024 - в q3_0. Overhead по VRAM предсказуем: каждый токен в tail занимает столько же, сколько в BF16/F16-режиме, плюс основной кэш в сжатом виде.
Для модели с размерностью скрытого состояния 4096 и 32 attention-головами один токен KV-кэша в BF16 занимает 512 КБ (key + value). Tail в 1024 токена добавляет 512 МБ к VRAM-бюджету. Основной кэш на 32K токенов в q3_0 занимает около 3 ГБ. Суммарно - примерно 3.5 ГБ против 16 ГБ для полного BF16-кэша на ту же длину. Экономия в 4.5 раза при сохранении качества на «горячем» участке.
Бенчмарки: цифры, которые впечатляют
Тесты на Qwen 3.6 27B и Gemma 4 31B дают согласованную картину. Для агрессивных квантизаций (q2_0, q2_1, q3_0) добавление tail в 1024 токена снижает KLD на 42–76% относительно той же квантизации без tail. Абсолютные значения KLD с tail приближаются к показателям BF16-кэша.
Зависимость от размера tail нелинейна. Первые 256–512 токенов дают наибольший прирост качества - они покрывают локальный контекст текущего предложения или абзаца. Увеличение tail до 1024 добавляет ещё 15–20% снижения KLD. Дальнейший рост до 2048 токенов даёт менее 5% дополнительного выигрыша при линейном росте VRAM. Оптимальное значение для большинства сценариев - 512–1024 токена.
На коротких контекстах (менее 4K токенов) precision tail не даёт значимого эффекта - кэш и так невелик, и модель успевает удерживать внимание на всём диапазоне. Метод раскрывается на дистанциях от 8K токенов, где отдалённый контекст начинает «забываться» из-за ошибок квантизации.
Дополнительные улучшения: новые типы кэша и адаптивный draft-max
Помимо флагманских фич, релиз расширяет арсенал стандартных инструментов. Новые форматы закрывают пробелы в спектре компромисса качество/память, а draft-max делает спекулятивное декодирование более адаптивным к характеру текста.
Расширенная палитра квантизации: от q2_0 до q6_1
До версии 0.4.0 BeeLLama.cpp поддерживал ограниченный набор форматов KV-кэша. Добавлены q2_0 и q2_1 для максимальной экономии памяти, q3_0 и q3_1 как промежуточный вариант между агрессивной и умеренной квантизацией, а также q6_0 и q6_1 для сценариев, где важна точность, но хочется сэкономить относительно q8_0.
Характеристики новых форматов:
- q2_0, q2_1 - 2.0–2.5 бит на значение. Применимы с KVarN и precision tail на контекстах до 32K. Без этих методов качество падает резко уже после 4K.
- q3_0, q3_1 - 3.0–3.5 бит на значение. Сбалансированный вариант для контекстов 16K–64K. С tail в 1024 токена показывают KLD, близкий к q5_0 без tail.
- q6_0, q6_1 - 6.0–6.5 бит на значение. Практически неотличимы от q8_0 по качеству, но экономят 20–25% памяти.
Выбор формата зависит от модели и целевой длины контекста. Для Qwen 3.6 27B на 32K токенов связка q3_0 + KVarN + tail=1024 даёт качество, сопоставимое с q6_0 без tail, при вдвое меньшем потреблении VRAM под кэш.
Draft-max: адаптивное спекулятивное декодирование
Стандартное спекулятивное декодирование использует фиксированное число draft-токенов. Draft-max динамически подбирает это число в зависимости от уверенности драфт-модели. Если драфтер выдаёт последовательность с высокой вероятностью, число токенов увеличивается. Если уверенность падает, схема сокращает окно, чтобы не тратить вычислительные ресурсы на токены, которые будут отвергнуты при верификации.
Адаптивность особенно полезна в сценариях с неравномерной сложностью текста. Генерация кода с чередованием шаблонных блоков и уникальных идентификаторов - типичный пример. На шаблонах драфтер уверен, окно расширяется, ускорение растёт. На уникальных фрагментах окно сужается, предотвращая бесполезные вычисления. Тесты n-gram драфтеров на Qwen 3.6 27B показали, что эффективность спекулятивного декодирования критически зависит от характера контента - draft-max автоматически адаптируется к этой вариативности.
Практическое применение: как начать использовать BeeLLama.cpp v0.4.0
Сборка форка не отличается от стандартного llama.cpp - те же зависимости, та же система сборки через CMake. После компиляции новые методы доступны через параметры командной строки.
Конфигурация KV-кэша: примеры для типовых сценариев
Сценарий 1: Короткие диалоги до 4K токенов. Используйте q4_0 или q5_0 без precision tail. KVarN даст небольшой прирост точности, но не критичный. Экономия VRAM относительно BF16 - 4–5 раз.
Сценарий 2: Длинные документы 16K–32K токенов. Рекомендованная связка: q3_0 + KVarN + tail=1024. Потребление памяти под кэш - около 3.5 ГБ для модели масштаба 27B. Качество генерации близко к q6_0 без tail.
Сценарий 3: Максимальная экономия на 64K+ контекстах. q2_1 + KVarN + tail=2048. Кэш занимает около 2.5 ГБ, но качество на отдалённых участках контекста может деградировать. Подходит для задач суммаризации, где точное цитирование не критично.
Пример команды запуска для сценария 2:
./beeLLama-cli \
-m qwen3.6-27b-q4_k_m.gguf \
-c 32768 \
--cache-type-k q3_0 \
--cache-type-v q3_0 \
--cache-var-norm 1 \
--cache-precision-tail 1024Флаг --cache-var-norm 1 включает KVarN, --cache-precision-tail 1024 задаёт размер хвоста в токенах. Типы кэша для ключей и значений можно задавать раздельно - в некоторых моделях attention-ключи более чувствительны к квантизации, чем значения.
Ограничения и на что обратить внимание
KVarN и precision tail имеют статус экспериментальных. Авторы форка не гарантируют отсутствия артефактов на всех архитектурах. Бенчмарки проведены на Qwen 3.6 27B и Gemma 4 31B - моделях с относительно стандартным attention-механизмом. GQA-модели с нестандартным числом голов или модели с алиби-позиционированием могут показывать другие результаты.
Precision tail увеличивает VRAM-бюджет пропорционально размеру хвоста. На очень длинных контекстах (128K+) даже 1024 токена в BF16 добавляют ощутимый оверхед. Проверяйте пиковое потребление памяти перед запуском в продакшен.
Сравнение с апстримом llama.cpp: BeeLLama.cpp фокусируется на KV-кэше и не включает некоторые оптимизации основного апстрима, не связанные с кэшированием. Если вы не используете агрессивную квантизацию кэша, апстрим может быть предпочтительнее за счёт более широкой поддержки бэкендов и модельных архитектур. Анализ проблем инвалидации кэша в локальных обвязках показывает, что даже при идеальной квантизации кэша потери токенов на сбросах могут нивелировать выигрыш - проверяйте всю цепочку инференса.
Draft-max совместим с любыми драфт-моделями, поддерживаемыми llama.cpp, включая n-gram драфтеры. Адаптивность не требует дополнительной настройки - схема автоматически калибруется по первым нескольким шагам генерации.