Как запустить Gemma 2 на VPS

MAATRIX

Gemma 2 на VPS без видеокарты разворачивается за полчаса и отвечает лучше, чем ждёшь от девяти миллиардов параметров. Но у модели три особенности, о которых узнают уже после запуска: окно всего 8192 токена, KV-кэш втрое тяжелее, чем у ровесников, и привычные приёмы экономии памяти на ней молча не работают. Ниже — путь от чистой Ubuntu до рабочего API с командами, цифрами и честными границами.

Три размера Gemma 2 на VPS: 2B, 9B или 27B

В библиотеке Ollama модель называется gemma2. Первое, что стоит знать: дефолтное квантование здесь Q4_0, а не Q4_K_M, как у большинства соседей по каталогу. Короткое gemma2 — псевдоним для gemma2:9b, это 5,4 ГБ.

Теги -instruct-q4_K_M (5,8 ГБ у девятки) точнее на длинных текстах ценой 400 МБ памяти — компромиссы разобраны в статье о том, какое квантование выбрать для Gemma 2.

Две вещи, которые лучше знать до pull:

• Русского нет в официальном списке. Google в карточке модели заявляет для Gemma 2 английский. На практике 9B отвечает по-русски прилично — лучше Llama 3 того же класса, — но без явного указания языка сползает в английский, а 2B на русском откровенно слаб. Это эмерджентная способность, а не поддерживаемая функция.
• Лицензия не Apache. Gemma идёт по Gemma Terms of Use: коммерческое использование разрешено, но ограничения из Prohibited Use Policy вы обязаны передавать всем, кому раздаёте модель или её дообученную версию. И никакой мультимодальности: Gemma 2 — только текст.

Проверка сервера и установка: команды и первый запуск

Дальше считаем, что у вас чистая Ubuntu 24.04 LTS или Debian 13 и доступ под root.

systemd-detect-virt              # kvm — годится, lxc/openvz — нет
grep -m1 -o avx2 /proc/cpuinfo   # пусто — минус половина скорости
curl -fsSL https://ollama.com/install.sh | sh
ollama --version                 # ollama version is 0.33.4

Контейнерная виртуализация показывает в free память всей ноды, а лимит режет cgroup: Ollama решит, что 9B влезает, и упадёт на середине загрузки весов с signal: killed. Скрипт установки заводит пользователя ollama, юнит /etc/systemd/system/ollama.service и демон на 127.0.0.1:11434. Веса ложатся в /usr/share/ollama/.ollama/models — на корневой раздел, а не в домашний каталог. Переносите их переменной OLLAMA_MODELS с одной оговоркой: новый каталог должен принадлежать пользователю ollama (chown -R ollama:ollama /mnt/models), иначе ollama pull падает на записи блоба с permission denied.

После ollama pull gemma2:9b проверьте, что именно приехало:

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

  Parameters
    stop    "<start_of_turn>"
    stop    "<end_of_turn>"

context length 8192 — потолок модели, а не то, что вам выдадут в работе. Не хватает памяти — Ollama скажет прямым текстом ещё до загрузки весов: Error: model requires more system memory (9.8 GiB) than is available (7.1 GiB). Первый прогон делайте с ollama run gemma2:9b --verbose: он печатает prompt eval rate и eval rate. Проблемы самой установки разобраны отдельно: почему Ollama не запускается.

Контекст 8192 и KV-кэш: где Gemma 2 съедает память

Здесь главное отличие Gemma 2 от Qwen, Llama и Mistral. Окно у неё 8192 токена — примерно шесть страниц текста, — и расширить его нельзя, это предел обучения. По умолчанию Ollama открывает и того меньше, 4096, а лишнее с начала промпта отрезает молча, без ошибки.

Второй сюрприз — цена окна. У Gemma 2 9B 42 слоя, 8 KV-голов и размер головы 256 вместо привычных 128. Расход на токен: 2 × 42 слоя × 8 голов × 256 × 2 байта = 336 КБ. У Llama 3 8B выходит 128 КБ — при похожем размере весов Gemma 2 ест кэша в 2,6 раза больше.

Правый столбец обманчив: 27B при втрое большем числе параметров жрёт кэша чуть больше девятки — у неё размер головы 128, а не 256. Архитектуры внутри одной линейки разные, переносить прикидки с модели на модель нельзя.

Полное окно у девятки стоит 2,6 ГБ поверх 5,4 ГБ весов. Вывод: gemma2:9b с контекстом 8k требует около 10 ГБ и на восьмигигабайтной машине не живёт. Свежие сборки llama.cpp экономят — половина слоёв Gemma 2 работает со скользящим окном 4096, и кэш для них обрезается, около 2 ГБ вместо 2,6 ГБ, — но считайте по верхней границе. Общая арифметика памяти собрана в таблице RAM для Ollama.

Окно задаётся через drop-in юнита (Environment="OLLAMA_CONTEXT_LENGTH=8192") или на запрос через options.num_ctx. Ставить больше 8192 вредно: в журнале появится n_ctx_per_seq (16384) > n_ctx_train (8192) -- possible training context overflow, а качество тихо поедет. Сколько токенов реально доехало, показывает поле prompt_eval_count в ответе /api/chat.

Flash Attention и soft-capping: почему привычные оптимизации не работают

Стандартный совет для Ollama — включить OLLAMA_FLASH_ATTENTION=1 и квантовать KV-кэш до q8_0, это режет память кэша вдвое. На Gemma 2 приём не работает, и предупреждения вы не получите.

Причина в архитектуре: Gemma 2 ограничивает логиты (soft-capping) — attn_logit_softcapping 50.0 внутри внимания и final_logit_softcapping 30.0 на выходе. Ядро Flash Attention с этим несовместимо, и рантайм отключает оптимизацию сам:

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

Дальше цепочка: квантование KV-кэша в llama.cpp работает только поверх Flash Attention. Она выключена — значит, OLLAMA_KV_CACHE_TYPE=q8_0 тоже не применяется. Вы планируете 1,3 ГБ под кэш, получаете 2,6 ГБ и ловите signal: killed там, где по расчётам был запас. На Gemma 2 память экономят двумя честными способами: уменьшают num_ctx или берут модель поменьше.

Второй эффект — большой словарь на 256 128 токенов, вдвое больше, чем у Qwen и Llama 3. Для русского это хорошо: кириллица режется примерно вдвое экономнее, чем у старых моделей с 32-тысячным словарём. Но словарь раздувает буфер вычислений — у gemma2:9b он около 500 МБ против полутора сотен у моделей с компактным словарём. Проверить: journalctl -u ollama -b | grep "compute buffer", а последствия — dmesg -T | grep -i "out of memory" со строкой Killed process 4712 (ollama runner). Эти полгигабайта не видны ни в весе файла, ни в таблицах RAM, и именно они превращают «должно влезть впритык» в OOM.

Отдельно про 27B: масштабирование запросов перед вниманием у неё другое (query_pre_attn_scalar 144 против 256), и ранние GGUF-сборки это игнорировали — модель работала, но отвечала хуже 9B. Увидели такое — обновите Ollama и перекачайте веса, а не чините промптом.

Шаблон Gemma: нет системной роли, свои стоп-токены и русский язык

Gemma 2 размечает диалог не так, как все, и об это спотыкаются интеграции:

<start_of_turn>user
Текст запроса<end_of_turn>
<start_of_turn>model

Роли system в шаблоне Gemma нет вообще. В transformers передача системного сообщения заканчивается ошибкой jinja2.exceptions.TemplateError: System role not supported. Ollama проблему прячет: её шаблон подклеивает системный текст в начало первого пользовательского хода. Работает, но инструкция не «висит» над диалогом, как у Qwen или Llama, — она живёт одним сообщением в начале и вымывается из окна по мере роста истории. Забыла модель через двадцать реплик, что должна отвечать по-русски, — это не деградация весов, а особенность шаблона.

FROM gemma2:9b
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
PARAMETER top_p 0.95
PARAMETER top_k 64
PARAMETER stop "<start_of_turn>"
PARAMETER stop "<end_of_turn>"
SYSTEM """Отвечай только на русском, кратко и по делу. Не хватает данных — скажи прямо."""

Собирается командой ollama create gemma-ru -f Modelfile, весов не копирует — новая модель ссылается на те же блобы. Значения top_k 64 и top_p 0.95 взяты из конфигурации генерации, которую Google кладёт рядом с весами; температура 0,7 против дефолтных 0,8 снижает склонность девятки пересказывать вопрос перед ответом.

Две строки stop — не украшение. Когда модель тянут не из библиотеки, а из своего GGUF-файла (FROM ./gemma-2-9b-it-Q4_K_M.gguf), стоп-токены не наследуются, и модель, ответив, начинает беседовать сама с собой: выдаёт <start_of_turn>user и следующий вопрос от вашего имени. Второй подвох ручного импорта — двойной <bos>: если шаблон дописывает токен начала, уже подставленный токенизатором, качество падает без единой ошибки в логах.

Скорость на CPU, отдача по API и защита порта

Без видеокарты скорость упирается не в частоту процессора, а в пропускную способность памяти: чтобы выдать один токен, надо прочитать все веса. Отсюда прикидка — токенов в секунду ≈ пропускная способность ÷ размер весов: при реальных для виртуалки 25–30 ГБ/с и 5,4 ГБ весов выходит около пяти токенов в секунду, и добавление ядер этого не изменит.

Замеры на 8 vCPU / 16 ГБ RAM, Ubuntu 24.04, окно 8k, один пользователь:

Разброс по поколениям процессоров — до 30%, это порядок величины, а не обещание. Что ещё влияет: OLLAMA_NUM_PARALLEL больше единицы умножает KV-кэш на число слотов (четыре слота у девятки при 8k — это 10 ГБ вместо 2,6 ГБ), а после пяти минут простоя модель выгружается, и следующий запрос ждёт весов 4–8 секунд из дискового кэша и до полуминуты с холодного. Остальные узкие места — в разборе, почему Ollama медленно генерирует токены.

Постоянные настройки — OLLAMA_CONTEXT_LENGTH=8192 и OLLAMA_NUM_PARALLEL=1 — кладите в drop-in (systemctl edit ollama), а не в сам юнит: обновление Ollama перезаписывает ollama.service целиком. Адрес OLLAMA_HOST оставьте локальным: у Ollama нет никакой авторизации, ни ключей, ни паролей, и открытый в интернет порт 11434 сканеры находят за часы. Наружу — только через Nginx с TLS и паролем, обязательно с proxy_buffering off;, иначе стриминг превращается в минуту пустого экрана.

ufw allow 22/tcp && ufw allow 443/tcp && ufw deny 11434/tcp && ufw enable

Приложениям доступен OpenAI-совместимый путь /v1/chat/completions: system-сообщение туда слать можно, Ollama сама переложит его в шаблон Gemma. Но поля num_ctx в схеме OpenAI нет, и Ollama его игнорирует — клиентам на этом пути окно достаётся только из переменной окружения или из вашей сборки. И считайте бюджет: системный промпт Open WebUI забирает 300–800 токенов, три фрагмента из базы знаний — до 3 500, история на десять реплик — ещё 2 500, плюс запас на ответ. Восьми тысяч уже нет, так что для RAG берите два фрагмента вместо пяти. Стыковка с веб-интерфейсом разобрана отдельно: почему Open WebUI не видит Ollama.

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

Gemma 2 без видеокарты — задача про объём и скорость памяти, а не про количество ядер. Отсюда три честные границы.

Минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Уверенно живёт только gemma2:2b: 1,6 ГБ весов, 0,8 ГБ кэша при полном окне, 17–22 токена в секунду — хватает на классификацию обращений, извлечение полей из писем, короткие ответы бота. Скажу прямо: девятка на 8 ГБ не помещается — 5,4 ГБ весов, 2,6 ГБ кэша и полгигабайта буфера упираются в потолок ещё до системы. Формально она стартует с окном 2048 на голой машине, но первый же Docker рядом заканчивается OOM.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 100–160 ГБ NVMe. Целевая конфигурация для gemma2:9b с полным окном 8192: около 9 ГБ на модель с кэшем и буферами, 2–3 ГБ на Open WebUI с Postgres, запас на вторую модель на диске.

Под 27B: 16 vCPU, 32–48 ГБ RAM, от 200 ГБ NVMe. Модель влезет и будет отвечать умнее, но 1,5 токена в секунду — это ночные прогоны, а не диалог. И общий предел процессорного инференса: интерактивный чат на пять человек VPS без GPU не вытянет, каждый будет ждать минутами. Тут нужна видеокарта, и это честнее сказать заранее, чем продать вам 48 ГБ памяти.

Ollama есть в каталоге приложений MAATRIX, и ставить его руками не нужно: при заказе сервера он разворачивается автоматически на Ubuntu или Debian, демон поднят и в автозапуске, доступы появляются в личном кабинете в разделе «Доступ». Вам остаётся ollama pull gemma2:9b и настройка окна с шаблоном из третьей и пятой секций.

Локация — Лондон. Причина практическая: пятигигабайтный слой из реестра Ollama из российских сетей регулярно рвётся на середине, а ollama run hf.co/... для GGUF-сборок с Hugging Face попросту не отвечает — с лондонской площадки оба источника идут на полной скорости канала. Пинг из Москвы 40–60 мс на фоне пяти токенов в секунду — погрешность, зато сервер стоит в европейском правовом периметре, что важно, если через модель проходят рабочие документы. Нужно хранение персональных данных по 152-ФЗ — берите площадку в России: на саму Gemma это не влияет, только на скорость скачивания весов.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Великобритании.

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