Gemma 2 на сервере: частые ошибки и решения

MAATRIX

Gemma 2 ставится одной командой, а дальше начинается: signal: killed на девятимиллиардной модели там, где Llama 3.1 8B работала спокойно, num_ctx 32768 без всякого эффекта и System role not supported при переезде с Ollama на vLLM. Почти все частые ошибки Gemma 2 — не поломка сервера, а три особенности линейки: окно ровно 8192 токена, head_dim 256 и логит-softcapping. Разберём их по порядку — со строками из журналов и арифметикой памяти.

Сначала определите, какая Gemma у вас на самом деле

Половина вопросов снимается на этом шаге: «Gemma» — это два разных поколения, и под рукой обычно оказывается не то, что человек имел в виду.

Отсюда три ежедневные ошибки. ollama pull gemma2:12b отвечает Error: pull model manifest: file does not exist — двенадцатимиллиардной Gemma 2 не существует, 12B появилась только в третьем поколении; то же с gemma2:4b и gemma2:1b. ollama run gemma2 тянет девятку на 5,4 ГБ, а не малышку. Теги с -text- — базовые веса без инструктивного дообучения: gemma2:9b-text-q4_K_M не отвечает на вопросы, а продолжает ваш текст.

Проверка занимает одну команду:

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

  Capabilities
    completion

Два поля здесь важны. context length 8192 — это потолок, а не значение по умолчанию. В Capabilities только completion: строки tools нет и не будет.

Архитектуру gemma2 Ollama понимает с версии 0.1.47; на старых сборках получите Error: llama runner process has terminated: error loading model: unknown model architecture: 'gemma2'. Обновление — curl -fsSL https://ollama.com/install.sh | sh: перезаписываются бинарник и юнит, веса и drop-in остаются.

Честный контекст: Gemma 2 вышла в июне 2024 года, знания её там и заканчиваются, а текущую дату она назовёт 2024 годом. Не привязаны к ней промптами, дообучением или зафиксированным бенчмарком — берите Gemma 3. Дальше — про случаи, когда нужна именно двойка.

Окно 8192 — потолок модели, а не настройка Ollama

Ollama по умолчанию открывает 4096 токенов и честно предупреждает об этом в журнале:

n_ctx_per_seq (4096) < n_ctx_train (8192) -- the full capacity of the model
will not be utilized

Поднять до 8192 правильно. А вот выставить больше — бессмысленно: модель на длинное окно не обучали, и llama.cpp меняет тон сообщения.

n_ctx_per_seq (32768) > n_ctx_train (8192) -- possible training context overflow

Ошибки не будет — будет молчаливая деградация: после 9–10 тысяч токенов Gemma 2 повторяет абзацы, теряет нить и путает, кто что сказал. Растягивание RoPE не спасает: в конфиге Gemma 2 секции rope_scaling нет вовсе, rope_theta равна 10 000, ни YaRN, ни линейное масштабирование в веса не заложены.

Вторая тонкость касается уже самих 8192. Gemma 2 чередует слои: чётные видят скользящее окно в 4096 токенов, нечётные — весь контекст. Даже внутри разрешённого окна дальнюю часть документа обрабатывает половина слоёв. Практический вывод: важное кладите в конец промпта.

Рабочий drop-in для systemd:

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_KEEP_ALIVE=30m"

Дальше sudo systemctl daemon-reload && sudo systemctl restart ollama. Через /v1/chat/completions размер окна не задаётся — в схеме OpenAI такого поля нет, только переменная окружения или PARAMETER num_ctx 8192 в Modelfile. Если правки вообще не применяются, причина обычно не в Gemma: разбор в статье про частые ошибки Ollama.

Почему 9B ест больше памяти, чем Llama 8B: head_dim 256

Типичная жалоба: «llama3.1:8b работала на 8 ГБ, а gemma2:9b того же класса падает». Дело не в лишнем миллиарде параметров, а в геометрии внимания. У Gemma 2 9B head_dim равен 256 — вдвое больше привычных 128, при восьми KV-головах и 42 слоях. Кэш на один токен окна: 2 × 42 × 8 × 256 × 2 байта = 344 064 байта, то есть 336 КБ. У Llama 3.1 8B — 128 КБ. Разница в 2,6 раза при почти одинаковых весах.

Складываем для девятки на полном окне: 5,4 ГБ весов + 2,7 ГБ кэша + около 0,5 ГБ вычислительных буферов ≈ 8,6 ГБ. На машине с 8 ГБ это заканчивается одним из двух:

Error: model requires more system memory (8.9 GiB) than is available (7.4 GiB)
Error: llama runner process has terminated: signal: killed

Вторая строка — работа OOM-killer, подтверждение в dmesg -T | tail -5: Out of memory: Killed process 1042 (ollama_llama_se). Кэш выделяется целиком при загрузке, поэтому падение происходит сразу, а не «под нагрузкой». Добивает множитель параллелизма: свежие сборки Ollama сами выбирают OLLAMA_NUM_PARALLEL — 1 или 4, и четыре слота превращают 8192 в 32 768 ячеек кэша, то есть в 11 ГБ. Фиксируйте единицу явно.

Поправка в вашу пользу: в свежих сборках llama.cpp под слои со скользящим окном выделяется укороченный кэш, и реальный расход при 8192 ближе к 1,7–2 ГБ вместо 2,7. Проверяйте не по таблице, а по журналу и по ollama ps:

sudo journalctl -u ollama -n 300 | grep -iE "KV self size|n_ctx_per_seq|kv_cache"
ollama ps

ollama ps показывает фактически занятый объём в колонке SIZE:

NAME         ID              SIZE      PROCESSOR    UNTIL
gemma2:9b    ff02c3702f32    8.4 GB    100% CPU     29 minutes from now

Раскладка по всем размерам и квантам — в таблице RAM для Gemma 2.

Soft-capping: почему flash attention и квантование KV-кэша не работают

Gemma 2 ограничивает логиты через тангенс: attn_logit_softcapping = 50.0 внутри внимания и final_logit_softcapping = 30.0 на выходе. Без этого модель выдаёт бессвязный текст. Последствий два, и оба неочевидные.

Ollama и llama.cpp. Ядра flash attention во многих сборках softcap не реализуют, поэтому llama.cpp снимает ускорение сам:

llama_new_context_with_model: flash_attn is not compatible with attn_soft_cap - forcing off

Дальше следствие, на котором спотыкаются все, кто переносит настройки с Llama: квантование KV-кэша требует включённого flash attention. Раз он принудительно снят, OLLAMA_KV_CACHE_TYPE=q8_0 для Gemma 2 просто игнорируется — молча, без предупреждения. Приём, экономивший половину кэша на Llama, здесь не работает, и память надо планировать на полный fp16. В части сборок поддержку softcap в FA уже добавили, но проверять это надо по приведённой строке в journalctl -u ollama, а не по надежде.

vLLM. Здесь ошибка громкая:

ValueError: Please use Flashinfer backend for models with logits_soft_cap (i.e., Gemma-2).
Otherwise, the output might be wrong. Set Flashinfer backend by
export VLLM_ATTENTION_BACKEND=FLASHINFER.

А если бэкенд не умеет чередующееся скользящее окно, vLLM пишет Disabling sliding window and capping the max length to the sliding window size (4096) и тихо урезает окно вчетверо: ваш --max-model-len 8192 станет 4096, и узнаете вы об этом только из лога старта.

Transformers. Нужна версия не ниже 4.42, иначе ValueError: The checkpoint you are trying to load has model type 'gemma2' but Transformers does not recognize this architecture. И грузите с attn_implementation="eager": SDPA и FlashAttention-2 softcap не применяют — ошибки не будет, качество просядет молча.

Самосборный GGUF. Если веса конвертировали старым convert_hf_to_gguf.py, ключей softcapping в файле может не быть: модель говорит, но плывёт и зацикливается. Проверка на месте — pip install gguf, затем:

gguf-dump --no-tensors /usr/share/ollama/.ollama/models/blobs/sha256-<хэш> | grep -i softcap

Путь блоба даёт ollama show --modelfile gemma2:9b | grep '^FROM', а в выводе должны быть обе строки: gemma2.attn_logit_softcapping = 50.0 и gemma2.final_logit_softcapping = 30.0.

Отдельная засада у 27B: запросы там масштабируются не на корень из head_dim, а на корень из 144 — в конфиге query_pre_attn_scalar = 144 при head_dim = 128. Ранние конвертации лета 2024 года множитель брали неверно, и 27B отвечала заметно хуже девятки. Если ощущение ровно такое — не отлаживайте промпты, перекачайте модель из библиотеки Ollama.

Шаблон Gemma: роль `model`, запрет на system и чередование

Разметка диалога у Gemma своя и вольностей не прощает:

<start_of_turn>user
Привет<end_of_turn>
<start_of_turn>model
Здравствуйте!<end_of_turn>

Роль ассистента здесь буквально называется model. Пишете в ручном промпте <start_of_turn>assistant — модель получает распределение, которого не видела при обучении, и отвечает многословно и не по делу.

Реплика заканчивается токеном <end_of_turn> — это 107, тогда как <eos> равен 1, а <bos> — 2. В сторонних GGUF стоп-токеном нередко объявлен только <eos>: до него модель не доходит, печатает <start_of_turn>user и продолжает диалог за вас. Лечится Modelfile:

FROM ./gemma-2-9b-it-Q4_K_M.gguf
TEMPLATE """{{ содержимое ollama show --template gemma2:9b }}"""
PARAMETER stop "<end_of_turn>"
PARAMETER stop "<start_of_turn>"
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
SYSTEM """Отвечай по-русски, кратко и по делу."""

Шаблон не сочиняйте: ollama show --template gemma2:9b > gemma2.tmpl отдаёт проверенный вариант.

Системной роли у Gemma 2 нет. Официальный jinja-шаблон Google её не игнорирует, а падает:

jinja2.exceptions.TemplateError: System role not supported

Отсюда классическое «в Ollama работало, в vLLM сломалось»: собственный шаблон Ollama приклеивает SYSTEM к первому пользовательскому ходу, а официальный отвечает 500 на любой запрос с "role": "system". Уходите на vLLM или TGI — переносите системный текст в начало первого сообщения пользователя сами.

Роли обязаны чередоваться. Два сообщения user подряд — типичная схема, когда приложение шлёт контекст отдельной репликой, — дают TemplateError: Conversation roles must alternate user/assistant/user/assistant/.... Склеивайте такие сообщения в один ход. И последнее: если в ответе видны сами теги <end_of_turn> или <start_of_turn>model, вы стучитесь в /api/generate с "raw": true и получаете поток как есть — для диалога нужен /api/chat, он снимает служебные токены сам.

Инструменты, JSON и русский язык

Вызова функций у Gemma 2 нет — ни специальных токенов, ни ветки в шаблоне. Ollama отвечает прямо:

Error: gemma2:9b does not support tools (status code: 400)

Это ломает bind_tools в LangChain, узел AI Agent в n8n и любой каркас, рассчитывающий на нативные tool-calls. Обходные пути через «опиши вызов в JSON» на девятке работают процентов на семьдесят — для продакшена мало. Нужны инструменты — берите модель, которая их заявляет: Qwen 2.5 или Llama 3.1.

Строгий JSON при этом получить можно. Параметр format включает грамматику на уровне сэмплера и поддержки со стороны модели не требует:

curl -s http://127.0.0.1:11434/api/chat -d '{"model":"gemma2:9b","stream":false,
 "messages":[{"role":"user","content":"Разбери адрес: Лондон, Бейкер-стрит, 221Б"}],
 "format":{"type":"object","required":["city","street","house"],
  "properties":{"city":{"type":"string"},"street":{"type":"string"},
                "house":{"type":"string"}}}}' | jq -r .message.content

Невалидный JSON становится физически невозможен. Заодно поднимите num_predict: при обрезке по длине объект придёт синтаксически битым, и виновата будет не модель. Картинки Gemma 2 не понимает вовсе — она текстовая, массив images уйдёт в никуда; зрение это Gemma 3 от 4B и выше.

Русский — сильная сторона линейки, но с оговорками. Google заявляет преимущественно англоязычный корпус, однако словарь у Gemma — 256 000 записей против 128 256 у Llama 3, и кириллица режется заметно экономнее. Замеряется одной командой:

curl -s http://127.0.0.1:11434/api/chat -d '{"model":"gemma2:9b",
 "messages":[{"role":"user","content":"<абзац русского текста на 1000 знаков>"}],
 "options":{"num_predict":1},"stream":false}' | jq .prompt_eval_count

Тысяча знаков русского даёт примерно 290–320 токенов (у Llama 3.1 на том же тексте — 350–380), то есть окно 8192 вмещает около 26–28 тысяч знаков. По качеству честно: gemma2:9b пишет по-русски глаже, чем Llama 3.1 8B, — падежи и согласование держатся на тексте длиннее абзаца. А gemma2:2b русский понимает, но ошибается в роде и окончаниях и срывается в английский; это классификатор и извлекатель фактов, а не автор.

Зацикливание. Дефолтная temperature 0.8 в Ollama для Gemma 2 великовата: модель уходит в перечисления и повторы абзацев. Спокойнее всего она держится на temperature 0.7, top_p 0.9, top_k 64, repeat_last_n 256. Предупреждение из практики: repeat_penalty выше 1.15 на русском ломает морфологию — штрафуя уже использованные токены, модель начинает избегать правильных окончаний.

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

Три четверти разобранного упирается не в конфиги, а в память: 336 КБ кэша на токен и невозможность его квантовать правкой YAML не лечатся.

Минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Здесь комфортно живёт gemma2:2b на полном окне 8192 — 1,6 ГБ весов плюс 0,85 ГБ кэша, около 19 токенов в секунду. Девятка тоже запустится, но только с num_ctx 4096 и без Open WebUI с Postgres рядом; на полных 8192 будет signal: killed. Ограничение честное, и оно про Gemma, а не про площадку: Llama 3.1 8B в тот же объём укладывается, Gemma 2 9B — нет.

Рабочий вариант: 8 vCPU, 16 ГБ RAM, 120–160 ГБ NVMe. Целевая конфигурация для gemma2:9b на полном окне: 5,4 ГБ весов, до 2,7 ГБ кэша, 2–3 ГБ на веб-интерфейс с базой и место под вторую модель. Замер такой машины (EPYC, DDR4-3200, без видеокарты) — ollama run gemma2:9b --verbose:

prompt eval count:    31 token(s)
prompt eval rate:     38.94 tokens/s
eval count:           244 token(s)
eval rate:            5.91 tokens/s

Восемь ядер нужны не ради скорости печати — она упирается в пропускную способность памяти, — а ради чтения промпта: документ на 8000 токенов обрабатывается около трёх с половиной минут, и всё это время клиент ждёт первого байта. Поэтому proxy_read_timeout 600s; в Nginx обязателен, иначе поймаете 504 на ровном месте.

Комфорт: 16 vCPU, 32 ГБ RAM, от 200 ГБ NVMe. Две модели одновременно при OLLAMA_MAX_LOADED_MODELS=2 и запас на индекс для RAG. Про 27B скажу прямо: 16 ГБ весов и 2,9 ГБ кэша в 32 ГБ помещаются, но на процессоре она выдаёт около 1,3 токена в секунду — ответ на 300 токенов пишется четыре минуты. Как фоновый обработчик очереди годится, как чат для людей — нет.

Ollama есть в каталоге приложений MAATRIX, и ставить её руками не нужно: при заказе сервера она разворачивается автоматически на Ubuntu или Debian, юнит поднят и в автозапуске, версия свежая — та, что понимает архитектуру gemma2. Доступы появляются в личном кабинете, в разделе «Доступ»; останется ollama pull gemma2:9b и drop-in из второго раздела. Путь с нуля — в статье как запустить Gemma 2 на VPS, выбор уровня сжатия — в разборе квантования для Gemma 2.

Локация — Лондон. Причина практическая: пятигигабайтные слои с registry.ollama.ai и веса с Hugging Face из российских сетей рвутся регулярно, а репозиторий google/gemma-2-9b-it вдобавок закрыт согласием с условиями Google — без него придёт Access to model google/gemma-2-9b-it is restricted. С британского адреса качается и то и другое. Второй довод специфичен для Gemma: если вы строите гибрид «локальная модель на потоке, Gemini API на сложных случаях», из России Google отвечает User location is not supported for the API use, а из Лондона — нормально. Пинг из Москвы 40–60 мс на фоне шести токенов в секунду незаметен, до аудитории в ЕС — единицы миллисекунд. Если вы под 152-ФЗ, берите площадку в России, но веса выкачайте заранее.

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

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