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

MAATRIX

Ollama ставится одной строкой, и ровно поэтому её поломки выглядят загадочно: сервис в статусе active (running), а curl отвечает 403; модель скачалась, но ollama list пуст; чат работал неделю и вдруг стал падать с signal: killed. На сервере это шесть повторяющихся сценариев, каждый опознаётся по строке в логе. Ниже — как за пять команд понять, какой из них ваш.

Сначала диагностика: пять команд, которые называют причину

Ollama — демон плюс тонкий клиент: ollama run шлёт HTTP-запрос на http://127.0.0.1:11434 процессу под systemd. Отсюда правило отладки: текст в терминале — пересказ, причина в журнале демона. Сообщение Error: something went wrong, please see the ollama server logs for details ровно это и значит.

ollama -v                            # версия и доступность демона
systemctl status ollama --no-pager   # жив ли сервис, под каким пользователем
ss -tlnp | grep 11434                # на каком адресе слушает
ollama ps                            # что загружено в память
journalctl -u ollama -n 200 --no-pager | grep -iE 'error|warn|oom'

Первая команда делит проблемы надвое:

ollama version is 0.12.11
Warning: could not connect to a running Ollama instance

Есть предупреждение — сервис не поднят или слушает не там. ss даёт вторую развилку:

LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1043,fd=3))

127.0.0.1 означает, что снаружи не подключится никто, каким бы правильным ни был фаервол; *:11434 — что API открыт интернету.

Переменные окружения не применяются — самая частая ошибка

Причина половины обращений «сделал по инструкции, не работает». Человек делает export OLLAMA_HOST=0.0.0.0:11434, перезапускает сервис — ничего не меняется: export живёт в шелл-сессии, а демон стартует из systemd и не читает ни ~/.bashrc, ни /etc/environment.

Рабочий способ один: sudo systemctl edit ollama.service откроет пустой /etc/systemd/system/ollama.service.d/override.conf:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/mnt/data/ollama/models"
Environment="OLLAMA_KEEP_ALIVE=24h"

Секция [Service] обязательна: без неё systemd молча проигнорирует файл. Затем sudo systemctl daemon-reload && sudo systemctl restart ollama и единственная надёжная проверка — systemctl show ollama --property=Environment:

Environment=PATH=/usr/local/bin OLLAMA_HOST=0.0.0.0:11434 OLLAMA_KEEP_ALIVE=24h

Нет переменной в выводе — дальше идти бессмысленно. И правьте именно drop-in: обновление через curl -fsSL https://ollama.com/install.sh | sh перезаписывает /etc/systemd/system/ollama.service целиком, а ollama.service.d не трогает.

Двойной смысл OLLAMA_HOST. Для демона это «где слушать», для клиента — «куда подключаться»: OLLAMA_HOST=0.0.0.0:11434 ollama list бесполезна, клиент пойдёт стучаться в 0.0.0.0. Для удалённого сервера — URL целиком: OLLAMA_HOST=http://10.8.0.3:11434 ollama list.

Второй процесс. ollama serve, запущенный руками «чтобы наверняка с переменными», отвечает Error: listen tcp 127.0.0.1:11434: bind: address already in use — порт держит systemd-инстанс, он же и обрабатывает запросы.

Честно про 0.0.0.0. У Ollama нет ни аутентификации, ни ключей, ни лимитов: открыв порт наружу, вы отдаёте процессор и диск любому, кто просканирует 11434. Закрывайте фаерволом, а лучше вешайте демон на WireGuard (OLLAMA_HOST=10.8.0.1:11434):

sudo ufw allow from 203.0.113.10 to any port 11434 proto tcp
sudo ufw deny 11434/tcp

`ollama pull` обрывается: реестр, диск и битые blob'ы

Не отвечает реестр. Из российских сетей registry.ollama.ai нестабилен:

Error: pull model manifest: Get "https://registry.ollama.ai/v2/library/qwen3/manifests/8b": dial tcp 34.120.132.20:443: i/o timeout

Коварнее вариант, когда загрузка замирает: pulling 6a0746a1ec1a: 43% ▕████ ▏ 2.0 GB/4.7 GB 0 B/s --. pull возобновляемый и продолжит с места обрыва, но на модели в 5–20 ГБ это съедает вечер. За рубежом проблемы нет вовсе; в РФ — добавьте в drop-in Environment="HTTPS_PROXY=http://10.8.0.1:3128" и обязательно Environment="NO_PROXY=localhost,127.0.0.1,::1", иначе запросы клиента к демону тоже уйдут в прокси.

Кончился диск.

Error: max retries exceeded: write /usr/share/ollama/.ollama/models/blobs/sha256-6a0746a1ec1a-partial: no space left on device

Смотрим df -h / и du -sh /usr/share/ollama/.ollama/models. Четыре модели среднего размера — уже 30–40 ГБ, а ollama rm удаляет только тег, оставляя слои. Выносим каталог на отдельный диск:

sudo systemctl stop ollama
sudo rsync -a /usr/share/ollama/.ollama/models/ /mnt/data/ollama/models/
sudo chown -R ollama:ollama /mnt/data/ollama
sudo systemctl edit ollama.service     # Environment="OLLAMA_MODELS=/mnt/data/ollama/models"
sudo systemctl daemon-reload && sudo systemctl start ollama

Про chown забывают чаще всего и получают Error: mkdir /mnt/data/ollama/models: permission denied: демон работает под системным пользователем, не под root. На AlmaLinux и Rocky добавляется SELinux: нужен корректный контекст, иначе запись запрещена и при верных правах.

Runner умирает: OOM, контекст и «signal: killed»

Самая пугающая группа: сервис жив, а запросы падают. Клиент видит одно из двух:

Error: llama runner process has terminated: signal: killed
Error: POST predict: Post "http://127.0.0.1:39337/completion": EOF

Второе — подпроцесс умер посреди генерации. Подтверждение ищем в ядре командой sudo dmesg -T | grep -i "killed process":

[Wed Aug 26 11:04:21 2026] Out of memory: Killed process 4821 (ollama) total-vm:9812344kB, anon-rss:7482112kB, UID:998

Если Ollama считает заранее, она отказывается вежливо: Error: model requires more system memory (9.4 GiB) than is available (5.2 GiB).

А когда «вчера работало, сегодня нет» — виноват контекст: веса занимают фиксированный объём, а KV-кэш растёт линейно и его почти никто не считает. Для llama3.1:8b: 8 KV-голов × 128 измерений × 2 (ключи и значения) × 2 байта fp16 = 4 КБ на токен на слой, слоёв 32 — итого 128 КБ на токен контекста. Значит, num_ctx=4096 — это 0,5 ГБ поверх весов, а num_ctx=32768 — уже 4 ГБ, и на машине с 8 ГБ RAM вчерашняя рабочая модель сегодня выносится OOM-киллером.

Добивают два множителя: кэш выделяется на num_ctx × OLLAMA_NUM_PARALLEL токенов (при четырёх слотах 8192 превращаются в 32768), а длинный промпт или загруженный документ поднимает num_ctx сам.

Что делать:

• Ограничить контекст: OLLAMA_CONTEXT_LENGTH=8192 в drop-in (есть с ветки 0.6) либо PARAMETER num_ctx 8192 в Modelfile.
• Сжать кэш: OLLAMA_FLASH_ATTENTION=1 плюс OLLAMA_KV_CACHE_TYPE=q8_0 уменьшают его вдвое. Честно: на большинстве задач разница незаметна, на длинных рассуждениях видна.
• Снизить OLLAMA_NUM_PARALLEL до 1–2 и взять квантизацию поменьше: q4_K_M вместо q8_0 — вдвое меньше весов.

Swap спасёт от падения, но инференс с весами в swap идёт со скоростью, при которой ответа проще ждать завтра — подробнее про нехватку RAM. Отдельный случай — exit status 127 вместо signal: killed: это не память, а отсутствующая библиотека, рядом в журнале будет error while loading shared libraries: libcudart.so.12.

API отвечает 403, 404 и 500 — что за каждым кодом

403 при живом сервисе. Примета: curl с сервера работает, а интерфейс на соседнем домене — нет. Воспроизводится так:

curl -sI -H 'Origin: https://chat.example.com' http://10.8.0.3:11434/api/tags | head -1

Вернётся 403. Дело в заголовке Origin: браузер его шлёт, curl без -H — нет, а Ollama пускает только локальные источники. Лечится строкой Environment="OLLAMA_ORIGINS=https://chat.example.com". Значение * работает, но означает «любой сайт в браузере может дёргать ваш API» — перечисляйте домены.

404 про модель. Запрос к /api/chat с телом {"model":"llama3.1",...} отвечает {"error":"model \"llama3.1\" not found, try pulling it first"}, хотя модель скачана. Дело в теге: llama3.1 разворачивается в llama3.1:latest, а тянули вы llama3.1:8b — разные записи. Копируйте имя из колонки NAME в ollama list.

404 page not found без JSON. Это про путь: OpenAI-совместимый слой живёт на /v1, базовый URL в библиотеках — http://host:11434/v1. Ключ API нужен любой непустой — на пустой строке клиенты падают.

Под нагрузкой всё встаёт: очередь, keep_alive и обрыв стриминга

Сначала отделите «сломалось» от «работает как задумано»: ollama run qwen3:8b --verbose печатает в конце строку eval rate:. На 8 vCPU и DDR4 без видеокарты это около 7.52 tokens/s — норма, а не поломка: инференс упирается в пропускную способность памяти, лишние ядра его не ускоряют.

Первый запрос после паузы висит полминуты. Модель выгружается из памяти через 5 минут простоя, следующий запрос ждёт загрузки весов. Видно в ollama ps:

NAME       ID              SIZE     PROCESSOR    UNTIL
qwen3:8b   500a1f067a9f    6.6 GB   100% CPU     4 minutes from now

Лечится OLLAMA_KEEP_ALIVE=24h или -1. Плата честная: модель держит свои 6–7 ГБ RAM, даже простаивая.

server busy, please try again. Полностью — maximum pending requests exceeded: очередь переполнена, OLLAMA_MAX_QUEUE по умолчанию 512. Причина не в лимите, а в числе слотов OLLAMA_NUM_PARALLEL: поднимать его можно, только если памяти хватает на умноженный KV-кэш.

Ответ приходит целиком через минуту вместо потока. Nginx буферизует стриминг:

location / {
    proxy_pass http://127.0.0.1:11434;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_read_timeout 600s;
}

Без proxy_buffering off токены копятся в буфере, без proxy_read_timeout ответ обрывается 504 на 60-й секунде. И про Cloudflare: на бесплатном тарифе потолок ответа — 100 секунд, дальше 524, Nginx не поможет.

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

Больше половины разобранных ошибок — последствия неподходящей машины: на VPS с 4 ГБ памяти Ollama падает по OOM при любом drop-in. И первое требование даже не про объём: нужен KVM, а не контейнерная виртуализация. На OpenVZ и LXC она регулярно не стартует или падает при загрузке весов: нужен прямой доступ к памяти и mmap больших файлов. Нужен и AVX2: grep -o avx2 /proc/cpuinfo | head -1. Площадки MAATRIX — KVM на современных процессорах.

На диске не экономьте: 100 ГБ кажутся избыточными до момента, когда третья модель упрётся в no space left on device. А полноценная скорость чата — это GPU с 16–24 ГБ VRAM: 8B-модель выдаёт 40–80 токенов в секунду вместо семи.

Локация — Лондон. Причина практическая: registry.ollama.ai отдаётся с полной скоростью канала, без замираний на 0 B/s посреди пятигигабайтного слоя и без прокси в конфиге: скачивание модели — дело двух минут, а не вечера с перезапусками pull. До Европы пинг минимальный, сервер в GDPR-периметре — это важно, если через модель проходят рабочие документы. Из Москвы до Лондона 40–60 мс, для веб-интерфейса незаметно. Если персональные данные обязаны оставаться в российском поле, есть площадка в РФ: там 152-ФЗ важнее миллисекунд.

Оплата — картами российских банков, по СБП, криптой или токеном MAAT: зарубежная карта не нужна. Не уверены в конфигурации — напишите, какая модель и сколько пользователей. Путь от чистой системы до рабочего API — в статье про локальный запуск LLM через Ollama, связка с интерфейсом — в Open WebUI не видит Ollama, выбор площадки — в обзоре VPS в Великобритании для нейросетей.

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