Сколько RAM нужно для Gemma 2

MAATRIX

Gemma 2 9B весит 5,4 ГБ, и восьмигигабайтный тариф выглядит достаточным — ровно до первого запуска. У Gemma 2 самая дорогая голова внимания в классе: head_dim 256 вместо привычных 128, поэтому окно на 8192 токена просит ещё два гигабайта кэша, а словарь на 256 тысяч токенов добавляет полгигабайта под буфер логитов. Ниже — требования Gemma 2 к RAM по трём размерам, арифметика и граница, за которой восьми гигабайтов не хватает.

Короткий ответ: сколько RAM требует Gemma 2

Память ест не рантайм, а модель: сама Ollama в покое занимает 90–150 МБ. Формула для Gemma 2 отличается от общей одним слагаемым:

RAM ≈ вес файла × 1,08 + KV-кэш под ваш контекст + 0,5 ГБ на буфер логитов + 1,5 ГБ на систему

У большинства моделей выходной буфер — десятки мегабайт, и он прячется внутри коэффициента 1,1. У Gemma 2 словарь на 256 000 токенов, буфер вырастает до полугигабайта, и считать его надо отдельно. Полтора гигабайта — Ubuntu 24.04 с SSH и systemd; Open WebUI рядом добавит 0,7–1,5 ГБ.

Ориентиры при квантовании по умолчанию, полном окне 8192 токена и одном пользователе: 8 ГБ — gemma2:2b спокойно, это классификация, извлечение полей и роутинг; 12 ГБ — gemma2:9b, рабочий минимум; 16 ГБ — gemma2:9b плюс веб-интерфейс и второй пользователь; 24–32 ГБ — gemma2:27b со скоростью полтора токена в секунду.

Речь про инференс на процессоре; с видеокартой лимитом становится VRAM, арифметика та же. И сразу хорошая новость: у Gemma 2 нет размера 70B — потолок линейки 27B.

Три размера Gemma 2 и что скачивает `ollama pull gemma2`

Голая команда ollama pull gemma2 тянет девятимиллиардную модель: gemma2:latest — это gemma2:9b и 5,4 ГБ трафика. Второе отличие от соседей по библиотеке: теги Gemma 2 собраны в Q4_0, а не в Q4_K_M, к которому вы привыкли на Llama и Qwen.

Варианты с K-квантованием есть явными тегами: gemma2:9b-instruct-q4_K_M весит около 5,8 ГБ — плюс 400 МБ к памяти за более аккуратные ответы. Геометрию модель сообщает сама:

curl -s http://127.0.0.1:11434/api/show -d '{"model":"gemma2:9b"}' | jq -c \
 '.model_info | {layers:.["gemma2.block_count"], kv:.["gemma2.attention.head_count_kv"],
   head_dim:.["gemma2.attention.key_length"], swa:.["gemma2.attention.sliding_window"]}'

{"layers":42,"kv":8,"head_dim":256,"swa":4096}

Здесь ловушка. Для Qwen и Llama размерность головы считают делением embedding_length / head_count. Для Gemma 2 это даёт неверный ответ: 3584 / 16 = 224, а реальный head_dim равен 256 и лежит в отдельном поле key_length. Ошибётесь на 14 % — и весь расчёт кэша уедет.

Таблица RAM по всем размерам Gemma 2

Минимум посчитан по формуле при полном родном окне 8192, комфорт — с запасом на интерфейс и второго пользователя.

Три строки требуют комментария.

• gemma2:9b на 8 ГБ не живёт. Главное практическое отличие от ровесников: llama3.1:8b укладывается в восемь гигабайтов с результатом 7,9, а Gemma 2 9B просит 9,9. Урезание окна до 4096 даёт 8,9 — всё ещё больше восьми. Разница набегает из трёх мест: полгигабайта лишних весов, гигабайт лишнего кэша и полгигабайта буфера.
• gemma2:2b — не дешёвая модель своего класса. В ней 2,61 миллиарда параметров против 1,54 у qwen2.5:1.5b, а буфер логитов тот же, что у 27B. На 4 ГБ она помещается только при num_ctx 4096 и уменьшенном батче.
• Потолок 27B — это удобно. Gemma 2 не выпускалась в 70B, поэтому 32 ГБ закрывают всю линейку.

Q8_0 удваивает вес относительно Q4_0: gemma2:9b-instruct-q8_0 — 9,8 ГБ, fp16 — 18,5 ГБ, то есть 9B в полной точности просит сервер уровня 27B. Компромиссы — в статье про выбор квантования для Gemma 2, сравнение с библиотекой — в таблице RAM для Ollama.

KV-кэш Gemma 2: head_dim 256 и окно, которое скользит

Формула обычная, числа в ней непривычные:

KV = 2 × слои × KV-головы × head_dim × токены × 2 байта

Для gemma2:9b: 2 × 42 × 8 × 256 × 8192 × 2 — 2,63 ГиБ на восемь тысяч токенов. У llama3.1:8b при сопоставимых весах 128 КиБ на токен, у qwen2.5:7b — 56 КиБ. Gemma 2 9B дороже Llama 3 по кэшу в 2,6 раза и дороже Qwen 2.5 в шесть раз — проекции K и V вдвое шире стандартных. У 27B вернулись к head_dim 128, но добавили KV-голов, и итог тот же.

Часть этих денег возвращает скользящее окно: слои чередуются, чётный работает по локальному окну в 4096 токенов, нечётный видит весь контекст. Свежие сборки llama.cpp выделяют под них два разных кэша — отсюда правая колонка, минус 22 %:

llama_kv_cache_unified_iswa: creating non-SWA KV cache, size =  8192 cells
llama_kv_cache_unified_iswa: creating     SWA KV cache, size =  4608 cells

Оговорка: экономия работает только на свежем рантайме — сборки 2024 года выделяли полный кэш всем слоям подряд. Нет строки iswa в journalctl -u ollama — считайте по колонке «без SWA». И на num_ctx 4096 скользящее окно не даёт ничего: оно равно всему контексту.

Словарь на 256 000 токенов: русский текст и полгигабайта буфера

Токенизатор Gemma 2 — SentencePiece на 256 000 позиций, вдвое больше, чем у Llama 3, и изначально многоязычный. Отсюда один минус и один заметный плюс.

Минус — буфер логитов. Выходной слой считает n_batch × 256000 × 4 байта; при батче по умолчанию 512 это ровно 500 МиБ, и в логе видно:

llama_context:        CPU compute buffer size =   507.00 MiB

Для 27B это три процента от весов; для gemma2:2b — треть модели. Режется напрямую: "options":{"num_batch":128} даёт 125 МиБ вместо 500, ценой вдвое более медленного чтения промпта.

Плюс — русский текст. Кириллица разбирается по морфемам, а не по байтам. Замер на одном тексте через prompt_eval_count:

В пересчёте окно 8192 вмещает около 26 000 знаков русского текста — тринадцать страниц. Gemma 2 кладёт в своё короткое окно на 20 % больше русского, чем Llama 3, но окно у Llama 3.1 в шестнадцать раз длиннее. Вывод честный: для длинных документов Gemma 2 не годится в принципе. Расширить окно не выйдет — n_ctx_train равен 8192, rope-scaling в GGUF не заложен, и попытка даст предупреждение с кашей в тексте после восьми тысяч:

llama_context: n_ctx_per_seq (16384) > n_ctx_train (8192) -- possible training context overflow

И про лицензию: Gemma идёт не под Apache 2.0, а под Gemma Terms of Use с отдельной Prohibited Use Policy. Коммерческое использование разрешено, но условия обязаны передаваться дальше вместе с весами и производными.

Нехватка памяти: логи, флеш-аттеншен и скорость на CPU

Ollama считает требования до загрузки и пишет их в журнал: journalctl -u ollama | grep -o 'memory\.[a-z.]*="[^"]*"'

memory.available="[7.6 GiB]"  memory.required.full="9.9 GiB"
memory.weights.total="5.4 GiB"  memory.graph.full="0.6 GiB"

graph.full — тот самый буфер логитов. Если required.full больше available, приходит отказ: Error: model requires more system memory (9.9 GiB) than is available (7.6 GiB).

Дальше неприятное. Стандартный приём экономии кэша на Gemma 2 может не сработать. В модели есть мягкое ограничение логитов (softcap 50,0 в блоках внимания и 30,0 на выходе), и в сборках, где ядра флеш-аттеншена его не поддерживают, будет:

llama_new_context_with_model: flash_attn is not compatible with attn_soft_cap - forcing off

Следствие: OLLAMA_KV_CACHE_TYPE=q8_0 молча игнорируется — он требует включённого флеш-аттеншена. Совет «включите две переменные и получите вдвое меньший кэш», который работает на Llama и Qwen, здесь сначала проверяют в логе: не увидели flash_attn = 1 — считайте по полным цифрам. Остаются рычаги попроще, от дешёвого к дорогому:

1. Реальное окно вместо максимального: Environment="OLLAMA_CONTEXT_LENGTH=4096" через systemctl edit ollama — минус гигабайт на 9B. Клиент перебивает переменную своим options.num_ctx: Open WebUI шлёт значение из профиля модели.
2. Один слот: OLLAMA_NUM_PARALLEL=1 — по умолчанию их число выбирается по свободной памяти, и на 9B это разница между 2 и 8 ГБ кэша. Рядом OLLAMA_MAX_LOADED_MODELS=1 и батч 128 вместо 512, ещё минус 375 МБ.
3. Размер меньше в честном квантовании, а не тот же в Q3: gemma2:2b в Q8_0 отвечает связнее, чем gemma2:9b в Q3_K_S. И только потом — добавлять RAM: своп страхует от падения при загрузке, но в работе превращает четыре токена в секунду в доли (что делать при нехватке RAM).

«Влезло» и «работает» — разные вещи. Генерация на CPU упирается в полосу памяти: на каждый токен процессор читает все веса. Замер на 8 vCPU / 32 ГБ DDR5, Ubuntu 24.04, mbw -n 5 1024 даёт AVG Method: MEMCPY 33,4 ГБ/с; окно 8192:

Факт отстаёт от потолка сильнее, чем у Llama 3, — тоже цена софткапа: tanh на каждый элемент матрицы внимания без слияния операций. Смотрите и последнюю колонку: полное окно на 8192 токена 9B жуёт около семи минут до первого слова ответа, зато общий префикс кэшируется и второй вопрос по тому же тексту отвечается сразу. Подробности — в разборе медленной работы Ollama, остальные симптомы — в частых ошибках Gemma 2 на сервере.

Какой сервер под Gemma 2 взять в MAATRIX

Локальная модель никуда не ходит по сети: веса лежат у вас, запросы не покидают машину. Локацию выбирают по пользователям и юрисдикции, а не по доступности чужих API. Лондон (UK) — базовый вариант: 15–30 мс до Европы, 45–60 мс из Москвы, европейское правовое поле, если среди данных есть клиентские. Сетевая задержка на фоне генерации не видна — вы ждёте секунды, а не миллисекунды. Региональных ограничений у Gemma нет: в отличие от лицензии Llama 3.2, условия Google не выделяют ЕС отдельным пунктом. Россия нужна в одном случае — 152-ФЗ.

Минимум — 4 vCPU / 8 ГБ RAM / 80 ГБ NVMe. Это gemma2:2b на полном окне 8192 и 15 токенов в секунду: живой темп для классификации тикетов, извлечения полей и роутинга. Ограничение жёсткое: gemma2:9b сюда не помещается — 9,9 ГБ при окне 8k и 8,9 при 4k.

Комфорт — 8 vCPU / 16 ГБ RAM / 160 ГБ NVMe. Рабочая точка линейки: gemma2:9b на полном окне, Open WebUI рядом, запас на второго пользователя и второй слот. Четыре с половиной токена в секунду — читаемо для переписки и фоновых задач, но человек читает быстрее, и делать вид, что это не так, не будем. Двенадцати гигабайтов хватит формально, без запаса под интерфейс.

gemma2:27b — 16 vCPU / 32 ГБ RAM. По расчёту достаточно 24 ГБ, но впритык: 21,6 из 24 заняты, любой контейнер рядом ломает картину. Скорость 1,4 tok/s — ночная пакетная обработка, а не диалог; такие размеры решает видеокарта (подбор GPU-сервера под инференс LLM). Диск: все три размера рядом — 23 ГБ.

Ollama из каталога apps.maatrix.io ставится на сервер автоматически при заказе — вставлять команды не нужно, автоустановка работает на Ubuntu и Debian. Доступы появляются в личном кабинете, раздел «Доступ»; дальше остаётся ollama pull gemma2:9b и правка переменных под ваш контекст. Путь от чистой машины до первого ответа — в статье как запустить Gemma 2 на VPS. Оплата — картами российских банков, по СБП, криптой или токеном MAAT: зарубежная карта для Лондона не нужна.

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