Какое квантование выбрать для Gemma 2

MAATRIX

У gemma2:9b в библиотеке Ollama полтора десятка вариантов одного файла — от 3,8 до 18,5 ГБ. И короткий тег здесь даёт не то, что у соседей по каталогу: дефолт у Gemma 2 — Q4_0, легаси-схема из первых версий llama.cpp, а не привычный Q4_K_M. Ниже — сколько весит каждый уровень у 2B, 9B и 27B, где Gemma 2 ломается раньше других моделей и какой тег качать под вашу память.

Дефолтный тег `gemma2` — это Q4_0, а не Q4_K_M

Первое, что стоит сделать до всех рассуждений, — посмотреть, что уже скачано.

$ ollama show gemma2:9b
  Model
    architecture        gemma2
    parameters          9.2B
    context length      8192
    quantization        Q4_0

Q4_0 — не опечатка. Почти вся библиотека Ollama по короткому тегу отдаёт Q4_K_M, а gemma2 во всех трёх размерах отдаёт Q4_0: так были собраны первые официальные GGUF от Google, и теги с тех пор не переехали.

Разница не косметическая. Q4_0 — блок из 32 весов и один множитель fp16 на весь блок; сетка симметричная, без сдвига, и если веса в блоке смещены в одну сторону, половина уровней квантования простаивает. Q4_K — суперблок из 256 весов на восемь подблоков, у каждого свой 6-битный масштаб и свой 6-битный сдвиг, причём сами масштабы тоже квантуются. Асимметричная сетка ловит смещённые распределения, и ошибка на тех же четырёх битах меньше. Суффиксы _S и _M — не про биты, а про то, сколько отдельных тензоров подняли уровнем выше.

Переход на K-квант стоит 400 МБ диска и одну команду:

ollama pull gemma2:9b-instruct-q4_K_M

Дефолт оправдан ровно в одном случае — процессоры ARM (Ampere Altra, AWS Graviton). Там llama.cpp на лету перепаковывает блоки Q4_0 под инструкции i8mm и sdot и жуёт промпт в разы быстрее K-квантов; отдельные теги Q4_0_4_4 и Q4_0_8_8 для этого больше не нужны и из сборок убраны. На x86 с AVX2 выигрыша нет.

Сколько весит каждый уровень: таблица по трём размерам

Размеры GGUF для instruct-версий. Последняя колонка — то, ради чего написана следующая секция: сколько внутри файла девятки занимает одна матрица словаря.

Шаг между соседними уровнями — 10–15 %, а не «вдвое»: между Q4_K_S и Q4_K_M у девятки 300 МБ, экономить на этом бессмысленно. У двойки квантование почти не имеет смысла — от q4_K_M до q8_0 всего 1,1 ГБ, а на машине, где живёт 2B, помещается и восьмибитная версия. И ни один квант не спасает 27B: даже Q2_K — это 11,3 ГБ весов плюс 2,9 ГБ KV-кэша при полном окне, то есть машина от 16 ГБ ради полутора токенов в секунду. Полная арифметика памяти — в таблице RAM для Ollama, здесь только файл весов.

Связанный словарь на 256 128 токенов: где Gemma 2 не как все

Вот чем Gemma 2 отличается от Qwen, Llama и Mistral. Словарь у неё 256 128 токенов — вдвое больше, чем у ровесников. И эмбеддинги связанные: одна матрица работает и таблицей входных векторов, и выходной проекцией на логиты, отдельного тензора output.weight в файле нет. Считаем 256 128 × размер скрытого состояния:

Почти четверть двойки — это словарь: жать gemma2:2b ниже Q6_K означает портить главный тензор модели ради нескольких сотен мегабайт. llama.cpp про опасность знает и держит token_embd.weight на Q6_K во всех K-квантах начиная с Q3_K_M — те самые 753 МБ, которые не меняются от Q3_K_M до Q6_K. Проверить в своём файле:

pip install gguf
ollama show gemma2:9b --modelfile | grep '^FROM'   # путь к блобу
gguf-dump --no-tensors /usr/share/ollama/.ollama/models/blobs/sha256-ff1d1fc78170
# token_embd.weight  -  [ 3584, 256128 ],  type = Q6_K

Ниже Q3_K_M защита снимается. В Q3_K_S и Q2_K llama.cpp роняет словарь вместе со всем остальным: 753 МБ превращаются в 395 и 302 МБ. Страдают редкие токены, а кириллица у Gemma 2 живёт как раз в хвосте словаря. И поскольку матрица связанная, ошибка бьёт дважды — на входном векторе и на логитах того же токена. Здесь у Gemma 2 обрыв, а не плавная деградация.

Сборки с суффиксом _L — самое дешёвое улучшение. Q4_K_L и Q5_K_L у сторонних сборщиков отличаются от _M ровно одним: словарь поднят до Q8_0. Для девятки это +222 МБ (5,8 → 6,0 ГБ) и заметная прибавка на редкой лексике и русском. В библиотеке Ollama таких тегов нет, они на Hugging Face.

Замер на русском: на каком уровне начинает сыпаться

Прогон: 60 задач на русском — сжать абзац на 300–400 слов, переформулировать, вытащить поля из письма. Один сервер (8 vCPU / 16 ГБ, Ubuntu 24.04), temperature 0, фиксированный seed, num_ctx 8192, модель gemma2:9b-instruct-*.

Дефолт проигрывает своему же классу: q4_0 и q4_K_M почти одного размера, но 55/60 против 58/60 по языку и вдвое больше мусора вроде «конфигурaция» с латинской a посередине.

Обрыв у Gemma 2 наступает раньше, чем у соседей по каталогу. На q3_K_M модель сползает в английский примерно на каждом четвёртом ответе. Причина не только в кванте: русского нет в официальном списке языков Gemma 2, Google заявляет английский, и русский здесь — эмерджентная способность без запаса прочности. То, что у Qwen 2.5 на Q3_K_M выглядит как лёгкое ухудшение стиля, у Gemma 2 выглядит как смена языка на середине ответа.

Чем больше модель, тем спокойнее сжатие: у 27B словарь — 4,3 % параметров, и Q4_K_M там ближе к своему fp16, чем Q4_K_M девятки к своему. Платить приходится скоростью — 1,4–1,8 токена в секунду на процессоре. Оговорка про метод: это один прогон одного набора, порядок уровней воспроизводится устойчиво, абсолютные цифры гуляют на два-три пункта.

Скорость и KV-кэш: почему квантование даёт меньше, чем обещает

Генерация на процессоре упирается в пропускную способность памяти: чтобы выдать токен, надо прочитать все веса, отсюда токенов/с ≈ полоса памяти ÷ размер файла. Замер на 8 vCPU, DDR4 с реальными 28–30 ГБ/с, окно 8192, один пользователь:

Обработка промпта считается батчем и упирается в арифметику, поэтому от кванта почти не зависит. А генерация растёт медленнее, чем падает файл: от q8_0 к q2_K размер сокращается в 2,6 раза, скорость — в 2,3. Виноваты те же 753 МБ словаря: они зафиксированы на Q6_K и читаются на каждый токен независимо от уровня — 13 % трафика в Q4_K_M и уже 16 % в Q3_K_M. Плюс буфер вычислений: из-за огромного словаря у Gemma 2 он около 500 МБ против полутора сотен у моделей с компактным словарём. Итог: спуск ниже Q4_K_M покупает 15–20 % скорости ценой обвала качества из таблицы выше. Прочие причины медленной генерации — в разборе, почему Ollama медленно генерирует токены.

Второй квант, о котором обычно вспоминают, — KV-кэш. У девятки он стоит 336 КБ на токен, то есть 2,63 ГиБ при полном окне 8192. Стандартный рецепт OLLAMA_FLASH_ATTENTION=1 плюс OLLAMA_KV_CACHE_TYPE=q8_0 режет это вдвое — но на Gemma 2 не работает и не предупреждает об этом. Модель использует ограничение логитов внутри внимания, оно несовместимо с ядром Flash Attention, и рантайм отключает оптимизацию сам:

journalctl -u ollama -b | grep -i flash_attn
# flash_attn is not compatible with attn_soft_cap - forcing off

Квантование кэша живёт только поверх Flash Attention. FA выключен — значит, q8_0 для кэша не применился, и запланированные 1,31 ГБ остались 2,63 ГБ. Реальный бюджет памяти для девятки (веса + буфер 0,5 ГБ + кэш):

Отсюда правило, специфичное для Gemma 2: шаг кванта вверх стоит примерно столько же памяти, сколько удвоение окна. q5_K_M → q6_K — плюс 1,0 ГБ, окно с 4096 до 8192 — плюс 1,3 ГБ. Покупки сопоставимые, и под RAG почти всегда выгоднее окно.

Какой квант под задачу и как его скачать без ошибок

Сначала по бюджету памяти — на фиксированном объёме всегда стоит вопрос «модель побольше пожатее или поменьше поточнее».

Правило «следующий размер в Q4 лучше предыдущего в Q8» на линейке Gemma 2 работает наполовину. Между 2b-q8_0 и 9b-q4_K_M — да, девятка выигрывает с отрывом. Между 9b-q6_K и 27b-q4_K_M — уже нет: 27B на процессоре втрое медленнее, а прирост качества скромный. Поправки по типу задачи:

• Чат и суммаризация на русском — рабочий минимум Q4_K_M, ровнее Q5_K_M. Дефолтный Q4_0 меняйте в первый же день.
• Классификация, теги, извлечение полей — gemma2:2b-instruct-q8_0. Короткий выход и жёсткий набор вариантов прощают многое, но у двойки словарь занимает 23 % параметров, поэтому вниз идти нельзя: 2b в Q4 путает падежи и рода.
• RAG и длинные документы — память отдавайте окну, а не кванту: Q4_K_M с полными 8192 полезнее, чем Q6_K с четырьмя тысячами.
• Свой дообученный GGUF — квантуйте после слияния адаптера, из fp16. И помните, что при импорте своего файла не наследуются стоп-токены <start_of_turn> и <end_of_turn>, из-за чего модель начинает беседовать сама с собой; разбор — в статье как запустить Gemma 2 на VPS.

Качается уровень полным тегом, и регистр в нём значим — Ollama имена не нормализует:

ollama pull gemma2:9b-instruct-q5_K_M     # верно
ollama pull gemma2:9b-instruct-q5_k_m     # Error: pull model manifest: file does not exist

Две ловушки в именах. Первая — слово text: теги вида gemma2:9b-text-q4_K_M содержат базовую модель без инструктивного дообучения, она просто продолжает текст и не останавливается; проверяется мгновенно — у ollama show для такого тега в блоке Parameters нет строк stop. Вторая — переквантовать скачанное не выйдет: Ollama жмёт только из F16/F32 и отвечает Error: quantization is only supported for F16 and F32 models, так что «скачал q8_0, сожму сам» начинается с выкачивания 18,5 ГБ fp16. Сборок _L в библиотеке нет, за ними идут на Hugging Face: ollama run hf.co/bartowski/gemma-2-9b-it-GGUF:Q5_K_L.

На видеокарте формат другой. Под vLLM для Gemma 2 есть AWQ- и FP8-сборки, GGUF там не нужен. Гарантированная грабля: ограничение логитов поддерживает не каждый бэкенд внимания, и запускать модель нужно с VLLM_ATTENTION_BACKEND=FLASHINFER. Иначе soft-capping игнорируется — сервер поднимется, ошибок не будет, а качество тихо просядет. Когда стоит уходить с Ollama — в сравнении Ollama против vLLM.

Какой сервер под выбранный квант взять в MAATRIX

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

Минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Здесь живёт gemma2:2b-instruct-q8_0 — 2,8 ГБ весов, 0,81 ГБ кэша при полном окне, 17–22 токена в секунду. Хватает на классификацию обращений, извлечение полей из писем и короткие ответы бота. Скажу прямо: девятка сюда не влезает ни в одном кванте, который стоит запускать. Q3_K_M формально помещается в 7,9 ГБ при 8k — это ноль запаса под систему, а качество на русском там уже 47 ответов из 60.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 100–160 ГБ NVMe. Целевая конфигурация: gemma2:9b-instruct-q5_K_M или q6_K с полным окном — 9,7–10,7 ГБ, остаётся на Open WebUI с Postgres и на систему. Главное преимущество тарифа — появляется собственно выбор: три кванта девятки рядом на диске (q4_K_M, q5_K_M, q6_K) занимают 20 ГБ, и сравнивать их можно на своих текстах, а не на чужих таблицах.

Под 27B: 16 vCPU, 32–48 ГБ RAM, от 200 ГБ NVMe. q4_K_M — 16,8 ГБ, q5_K_M — 19,4 ГБ. Модель отвечает заметно умнее девятки, но 1,4–1,8 токена в секунду означают ночные прогоны, а не диалог. Интерактивный чат на нескольких человек процессорный VPS не вытянет ни на каком кванте — тут нужна видеокарта, и честнее сказать это заранее.

Ollama из каталога apps.maatrix.io ставится автоматически при заказе сервера — вставлять команды не нужно, автоустановка работает на Ubuntu и Debian, демон поднят и в автозапуске. Доступы появляются в личном кабинете, в разделе «Доступ»; дальше остаётся один ollama pull с нужным тегом.

Локация — Лондон. Сетевая задержка локальной модели безразлична: веса лежат у вас, наружу ничего не ходит. Важно, откуда вы их качаете. Десятигигабайтный слой q8_0 из российских сетей регулярно рвётся на середине, а hf.co для _L-сборок часто просто не отвечает — с лондонской площадки и то и другое идёт на полной скорости канала. Заодно 15–30 мс до пользователей в ЕС и европейский правовой периметр, если через модель проходят рабочие документы. Российская площадка нужна в одном случае: персональные данные россиян и 152-ФЗ.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Великобритании. Не уверены в уровне — напишите задачу, язык и нужное окно, подберём связку «размер + квант + тариф» без переплаты.

Частые вопросы