Open WebUI и Ollama на тарифе Heka: установка по шагам

MAATRIX

Хочется свой ChatGPT: веб-интерфейс с историей диалогов, переключением моделей и доступом с телефона, но чтобы всё считалось локально и никуда не утекало. На бумаге это две команды — поставить Ollama и накинуть сверху Open WebUI. На практике первый запуск упирается в вопросы без чётких ответов в мануалах: сколько памяти реально нужно, как контейнер находит Ollama на хосте, что делать, когда браузер открывает пустую страницу вместо чата. Ниже — установка с нуля на тарифе Heka: почему нужен именно этот уровень железа, команды по шагам и разбор поломок первого дня.

Что такое Open WebUI и зачем он нужен поверх Ollama

Сама по себе Ollama — движок инференса и ничего больше. Она тянет веса моделей из своего реестра, держит их в памяти и отдаёт ответы через HTTP API на порту 11434. Есть терминальный клиент ollama run llama3.1, но это диалог в одну строку без истории, без параллельных чатов и без разграничения пользователей. Для рабочего инструмента этого мало.

Open WebUI закрывает разрыв. Это отдельное веб-приложение, которое подключается к API Ollama и превращает его в интерфейс, неотличимый по ощущениям от ChatGPT: диалоговые окна с историей, переключатель моделей прямо в чате, системные промпты, загрузка файлов для RAG-поиска по документам, голосовой ввод. Самая практичная часть — многопользовательский режим: первый зарегистрированный аккаунт автоматически становится администратором, дальше можно открыть или закрыть регистрацию и выдавать роли admin/user/pending, не раздавая всем ssh-доступ к серверу.

Технически Open WebUI не заменяет Ollama, а работает как клиент поверх её API — так же он умеет ходить и к OpenAI-совместимым эндпоинтам, что разобрано в материале про подключение Open WebUI к OpenAI API. Здесь речь только о связке с локальной Ollama: без внешних ключей и чужих логов запросов, но и без чужой видеокарты — вся нагрузка ложится на своё железо.

Почему для этого стека нужен тариф уровня Heka

Ошибка новичков — судить по весу модели на диске. Файл qwen2.5:7b в Q4_K_M весит около 4,7 ГБ, и кажется, что 8 ГБ RAM с запасом хватит. На практике в бюджет попадает не только модель:

• Веса в RAM. Для CPU-инференса (без видеокарты) Ollama держит все веса целиком, плюс контекстное окно добавляет 0,5–1,5 ГБ сверху для 7B.
• Модель посерьёзнее про запас. 13B в том же квантовании — уже около 8 ГБ; для сложных задач память нужно закладывать под неё, а не под меньшую.
• Сам Open WebUI. Python-приложение с базой SQLite и websocket-соединениями на каждого пользователя — в простое несколько сотен мегабайт, под нагрузкой больше; разбор по компонентам — в статье сколько RAM нужно для Open WebUI.
• Docker и система. Демон Docker, systemd, файловый кэш — ещё 1,5–2 ГБ.

Сложите это, и нижняя граница комфорта выходит на 16 ГБ RAM — притом что 8 ГБ формально хватает только для одной 7B-модели без запаса и без параллельных пользователей.

Здесь и появляется тариф Heka ($23/мес) — старший в линейке MAATRIX без видеокарты: около 8 vCPU, 16 ГБ RAM и NVMe с запасом под несколько моделей и кэш Docker-образов. Многоядерность важна не меньше памяти: CPU-инференс параллелит вычисления по ядрам, и на 8 vCPU генерация живее, чем на 2–4 — точных цифр токенов в секунду не даём, они зависят от модели и кванта, замерить их стоит на своём железе. Младшие тарифы формально тоже подойдут, но модель будет соседствовать с системой впритык, и любой второй процесс станет поводом для OOM-киллера.

Ставить вручную не обязательно — в каталоге apps.maatrix.io есть готовый пакет «Ollama + Open WebUI» под тариф Heka, разворачивается автоматически при заказе. Но если хочется понимать, что происходит внутри, — вот всё по порядку.

Устанавливаем Ollama

Все команды — на чистом Ubuntu 24.04. Официальный установочный скрипт сам определяет архитектуру, ставит бинарник и поднимает systemd-сервис:

curl -fsSL https://ollama.com/install.sh | sh

После установки сервис должен быть активен:

systemctl status ollama
ollama --version

По умолчанию Ollama слушает 127.0.0.1:11434 — только локальные подключения, наружу порт не торчит, и менять это не нужно. Единственное, что стоит проверить сразу, — фаервол не должен пропускать 11434 наружу вообще:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 11434/tcp
sudo ufw enable

Модель качать необязательно — удобнее сделать это позже из интерфейса Open WebUI, с прогрессом загрузки. Но проверить, что движок отвечает, стоит:

curl http://127.0.0.1:11434/api/version

Ответ вида {"version":"0.9.6"} — Ollama жива и готова принимать запросы.

Устанавливаем Open WebUI через Docker

Docker — самый предсказуемый способ развернуть Open WebUI: зависимости и версия Python зашиты в образ, обновление — замена образа, а не борьба с pip. Если Docker ещё не стоит:

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker

Дальше — запуск. Ключевых моментов два: контейнер должен достучаться до Ollama на хосте, а данные должны пережить перезапуск и обновление контейнера.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:3000:8080 \
  -v open-webui:/app/backend/data \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  ghcr.io/open-webui/open-webui:v0.7.2

Разберём флаги по одному:

• -p 127.0.0.1:3000:8080. Порт биндится только на localhost — трафик наружу пустим позже через Nginx с HTTPS.
• -v open-webui:/app/backend/data. Именованный том хранит базу пользователей, историю чатов и файлы для RAG. Без него docker rm стирает всё до нуля.
• --add-host=host.docker.internal:host-gateway. На Linux, в отличие от Docker Desktop, алиас host.docker.internal по умолчанию не резолвится — флаг добавляет его вручную.
• -e OLLAMA_BASE_URL=.... Говорит Open WebUI, где искать Ollama. Эту переменную чаще всего указывают с портом контейнера вместо порта хоста — интерфейс поднимается, но список моделей остаётся пустым.
• Тег v0.7.2 вместо latest. Между релизами Open WebUI меняет структуру базы и требует миграций; незамеченное автообновление однажды оставит вас с чатом, который не открывается.

Проверка, что контейнер поднялся и не падает в перезапуск:

docker ps --filter name=open-webui
docker logs -f open-webui

В логах должна появиться строка о старте Uvicorn на 0.0.0.0:8080 — внутренний порт контейнера, наружу он не торчит благодаря биндингу на localhost.

Первая настройка: админ-аккаунт и первая модель

Пока порт биндится только на localhost, до интерфейса можно достучаться через SSH-туннель, не открывая ничего наружу раньше времени:

ssh -L 3000:127.0.0.1:3000 user@ваш-сервер

http://localhost:3000 открывает страницу регистрации. Первый аккаунт автоматически получает роль администратора — дальше стоит зайти в Admin Panel → Settings → General и переключить Enable New Sign Ups: выключить совсем, оставить с подтверждением или разрешить свободно для команды за VPN.

Дальше — проверить связь с Ollama: Admin Panel → Settings → Connections, там должен стоять URL http://host.docker.internal:11434 с зелёным индикатором. Красный в девяти случаях из десяти — неверно указанная переменная OLLAMA_BASE_URL; подробный разбор — в статье Open WebUI не видит Ollama: причины и решение.

Первую модель удобнее загрузить прямо из интерфейса: вкладка Workspace → Models, название модели из библиотеки Ollama, кнопка загрузки. Для старта на 16 ГБ RAM разумный выбор — 7–8B в Q4, например qwen2.5:7b или llama3.1:8b. После загрузки модель появляется в списке — выбираете, пишете первое сообщение и проверяете, что ответ приходит, а не висит на «thinking».

Полезная настройка здесь же — keep_alive: по умолчанию Ollama выгружает модель из памяти через пять минут простоя, экономя RAM. Нужен мгновенный ответ после паузы — значение можно увеличить, но тогда модель постоянно занимает свою долю памяти.

Домен, HTTPS и типичные проблемы запуска

Отдавать чат наружу голым HTTP на нестандартном порту не стоит даже для личного пользования — пароль администратора и содержимое диалогов пойдут открытым текстом. Nginx как reverse proxy плюс сертификат Let's Encrypt решают это без изменений в контейнере.

Базовый серверный блок, если домен уже указывает на IP сервера:

server {
    listen 80;
    server_name webui.вашдомен.ru;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

Две строки здесь обязательны. proxy_set_header Upgrade/Connection "upgrade" — Open WebUI держит с браузером websocket для потокового вывода токен за токеном; без них ответ приходит одним куском после паузы вместо плавной печати. proxy_read_timeout 300s нужен, чтобы длинная генерация не обрывалась на стандартной минуте простоя.

Сертификат — стандартный certbot, сам допишет listen 443 ssl и редирект с 80-го порта:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d webui.вашдомен.ru

После этого порт 3000 на хосте можно держать забинденным только на localhost — снаружи сервис виден исключительно через 443-й с сертификатом.

Дальше — проблемы, с которыми сталкивается почти каждый на первом запуске.

Порт 3000 уже занят. Частая ситуация, если на сервере уже что-то слушает порт или старый контейнер завис в перезапуске:

sudo lsof -i :3000
docker ps -a --filter name=open-webui

Старый контейнер — docker rm -f open-webui и запускайте заново; порт занят другим сервисом — перенесите Open WebUI на -p 127.0.0.1:3001:8080 и поправьте proxy_pass в Nginx.

Недостаточно памяти для загруженной модели. Симптом — модель не загружается, либо контейнер Ollama падает и рестартует:

dmesg -T | grep -i "out of memory"
journalctl -u ollama -n 50

Строка Out of memory: Killed process ... (ollama) — модель не влезла со всем остальным. Решение не в тюнинге, а в арифметике: более лёгкое квантование или тариф с большим запасом RAM. Другие ошибки Ollama на сервере — в статье Ollama на сервере: частые ошибки и решения.

Docker не видит GPU. Если на сервере есть видеокарта, а Ollama всё равно считает на CPU, дело почти всегда в отсутствующем nvidia-container-toolkit — без него контейнер не получает доступ к устройству, даже если драйвер на хосте стоит:

nvidia-smi
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Ollama внутри контейнера подтягивает GPU автоматически, а сам Open WebUI в GPU не нуждается — он только рисует интерфейс, вся тяжёлая работа остаётся на стороне Ollama.

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