Ollama и Open WebUI на VPS без GPU: рабочий вариант или боль?

Идея выглядит красиво: берём VPS, ставим Ollama, сверху поднимаем Open WebUI — и получаем личный ChatGPT на своём домене. Без лишних аккаунтов, с локальными моделями, историей диалогов и нормальным веб-интерфейсом.

На практике всё упирается не в саму установку. Поставить контейнеры обычно проще, чем потом честно ответить себе на вопрос: «А меня устраивает скорость?»

Без GPU модели работают на CPU. Значит, важны RAM, количество ядер, частота процессора, размер модели, квантизация, длина контекста и число одновременных пользователей. Open WebUI при этом не ускоряет модель. Он просто даёт удобный интерфейс к тому, что умеет Ollama или внешний API.

Если ожидание такое: «поставлю дешёвый VPS и получу быстрый аналог ChatGPT», скорее всего, будет боль. Если цель — пощупать self-hosted LLM, погонять лёгкие модели и понять ограничения, вариант вполне рабочий.

Что ставим и зачем

Минимальный стек обычно выглядит так:

  • Ollama — запускает локальные LLM и отдаёт API на порту 11434.

  • Open WebUI — веб-интерфейс: чаты, пользователи, настройки моделей, подключение к Ollama и внешним API.

  • Docker и Docker Compose — чтобы не размазывать установку по системе и проще обновляться.

  • nginx или другой reverse proxy — чтобы вывести интерфейс на домен, а не держать голый порт наружу.

  • SSL-сертификат — без HTTPS не стоит открывать панель в интернет.

  • Домен — удобнее для доступа и нормальной настройки TLS.

  • Базовая защита — firewall, закрытые порты, обновления, сильные пароли, аккуратное хранение токенов.

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

Минимальная конфигурация VPS

Ниже не «официальные требования», а практические ориентиры. Один и тот же сервер может вести себя по-разному на разных моделях и провайдерах. Особенно если CPU перепродан, диск медленный, а рядом на ноде шумные соседи.

Сценарий

CPU

RAM

SSD

Что ожидать

Минимальный тест

2–4 vCPU

8 GB RAM

60 GB SSD

Лёгкие модели, медленно, без комфорта

Нормальный старт

4 vCPU

16 GB RAM

80–120 GB SSD

Небольшие модели, личные тесты, один пользователь

Комфортнее

8 vCPU

32 GB RAM

120+ GB SSD

Лучше для экспериментов, больше запас под контекст и модели

Тяжёлые модели

Нужен GPU

32+ GB RAM

250+ GB SSD

Обычно не история про дешёвый VPS без GPU

На 8 GB RAM уже можно экспериментировать, но запас маленький. Сама система, Docker, Open WebUI, кэш, фоновые процессы и модель быстро съедают память. Если модель не влезает в RAM, начинается swap, и интерактивность превращается в ожидание.

16 GB RAM — более честный старт для небольших моделей. 32 GB дают больше свободы, но не делают CPU магическим ускорителем: память помогает загрузить модель и держать контекст, а скорость всё равно зависит от вычислений.

Почему без GPU всё не так весело

LLM-инференс — вычислительно тяжёлая задача. GPU хорошо подходит для параллельных операций, поэтому локальные модели на видеокартах ощущаются совсем иначе. На обычном VPS без GPU модель считает токены на CPU.

Главные ограничения такие.

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

RAM важнее, чем кажется. Модель должна поместиться в память с учётом квантизации и контекста. Чем крупнее модель и чем длиннее контекст, тем больше памяти нужно. Если памяти не хватает, сервер может начать активно использовать swap или просто упереться в OOM.

Большие модели могут не иметь смысла. Формально можно пытаться запускать модели крупнее, но «запустилось» и «можно пользоваться» — разные вещи. На CPU тяжёлая модель может отвечать так медленно, что практической пользы почти не остаётся.

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

Open WebUI не ускоряет инференс. Это важный момент. Open WebUI удобен: история, промпты, пользователи, подключение к разным backend. Но если Ollama медленно генерирует на CPU, интерфейс не сделает модель быстрее.

Пример docker-compose

Ниже минимальный пример для Ollama + Open WebUI в Docker Compose. Это не финальный production-шаблон, а отправная точка для тестового стенда.

services:  ollama:    image: ollama/ollama:latest    container_name: ollama    restart: unless-stopped    volumes:      - ollama:/root/.ollama    ports:      - "127.0.0.1:11434:11434"  open-webui:    image: ghcr.io/open-webui/open-webui:main    container_name: open-webui    restart: unless-stopped    depends_on:      - ollama    environment:      - OLLAMA_BASE_URL=http://ollama:11434    volumes:      - open-webui:/app/backend/data    ports:      - "127.0.0.1:3000:8080"
volumes:  ollama:  open-webui:

Что здесь важно:

  • Ollama слушает внутри Docker-сети и локально на 127.0.0.1, а не на всех интерфейсах.

  • Open WebUI ходит к Ollama по имени сервиса ollama.

  • Данные Ollama и Open WebUI лежат в named volumes, а не исчезают после пересоздания контейнера.

  • Наружу не открываются публичные порты 11434 и 3000 напрямую.

Для доступа с домена обычно ставят nginx или другой reverse proxy: HTTPS снаружи, проксирование на 127.0.0.1:3000 внутри сервера. Отдельно настраивают firewall и правила доступа.

После запуска можно зайти в контейнер Ollama и скачать модель:

docker compose up -d
docker exec -it ollama ollama pull qwen2.5:3b

Модель здесь приведена как пример лёгкого класса. Перед рабочим использованием лучше проверить актуальное имя в библиотеке Ollama и подобрать вариант под свою память и задачу.

[HUMAN_REVIEW] Проверить перед публикацией актуальность Docker-образов ollama/ollama:latest, ghcr.io/open-webui/open-webui:main, переменной OLLAMA_BASE_URL и выбранного имени модели в документации Ollama/Open WebUI.

Безопасность

Самая опасная ошибка — поднять Open WebUI, убедиться, что «оно открылось», и оставить панель торчать в интернет на дефолтных настройках.

Минимальный чек-лист:

  • не открывать Open WebUI без авторизации;

  • не публиковать Ollama API наружу без необходимости;

  • закрыть лишние порты через firewall;

  • использовать HTTPS, а не голый HTTP;

  • поставить сильный пароль и не переиспользовать его;

  • хранить API-токены и ключи не в случайных заметках и не в публичных compose-файлах;

  • регулярно обновлять контейнеры, но не делать это вслепую на рабочем стенде;

  • следить за диском: модели, логи и volume могут расти незаметно;

  • делать бэкапы данных Open WebUI, если там есть полезная история, настройки и пользователи.

Если Open WebUI нужен только вам, иногда проще закрыть его за VPN, Tailscale/WireGuard или хотя бы ограничить доступ по IP.

Когда VPS без GPU подходит

CPU-only VPS имеет смысл, если ожидания адекватные:

  • личные тесты;

  • изучение Ollama и Open WebUI;

  • лёгкие модели;

  • редкие запросы;

  • прототипы;

  • локальные эксперименты с промптами;

  • интерфейс Open WebUI для себя;

  • проверка идеи перед покупкой GPU-сервера;

  • связка с внешними API, где VPS держит интерфейс и автоматику, а не саму тяжёлую модель.

Когда лучше не мучиться

Есть сценарии, где VPS без GPU почти сразу превращается в компромисс ради компромисса:

  • нужна скорость ответа, похожая на коммерческие AI-сервисы;

  • пользователей больше одного-двух;

  • нужны тяжёлые модели;

  • нужен длинный контекст;

  • планируется клиентский или внутренний production-сервис;

  • важна стабильная задержка;

  • нужна генерация изображений;

  • параллельно крутятся n8n, боты, база, reverse proxy и ещё несколько сервисов;

  • нет времени администрировать сервер и разбираться, почему всё стало медленным после очередного обновления.

Отдельно про генерацию изображений: Stable Diffusion, ComfyUI и похожие задачи на CPU — это обычно не тот опыт, который хочется повторять. Там GPU нужен не для красоты, а для нормальной скорости работы.

API или свой сервер

Здесь нет универсального ответа. Свой сервер даёт контроль: данные, окружение, интерфейс, интеграции, возможность экспериментировать с локальными моделями. Но вместе с контролем приходят обновления, безопасность, бэкапы, мониторинг, подбор моделей и постоянные компромиссы по железу.

API проще стартует. Не нужно думать, влезет ли модель в RAM, сколько токенов в секунду выдаст VPS и почему контейнер съел диск. Минусы тоже есть: зависимость от провайдера, стоимость запросов, лимиты, вопросы приватности и доступности.

На практике часто выигрывает гибридная схема. VPS держит Open WebUI, n8n, бота, базу, reverse proxy и бизнес-логику. А модели подключаются через API или через отдельный GPU-хост, если локальный инференс действительно нужен.

Я отдельно собрал хаб с калькулятором и таблицами по VPS, GPU, API, Ollama, Open WebUI и AI-агентам.

Это не отменяет ручного подбора под задачу, но помогает прикинуть порядок ресурсов: где хватит VPS, где нужен GPU, а где дешевле и спокойнее уйти в API.

Вывод

Ollama + Open WebUI на VPS без GPU запускать можно. Это нормальный вариант для личной лаборатории, лёгких моделей, изучения self-hosted LLM и редких запросов.

Но это не замена полноценной GPU-инфраструктуре. Если нужна скорость, тяжёлые модели, длинный контекст, несколько пользователей или рабочий AI-сервис для клиентов, CPU-only VPS быстро покажет потолок.

Самый здоровый подход — начинать с цели. Если нужно понять стек и поэкспериментировать, берите VPS с запасом по RAM и не ждите чудес от CPU. Если нужен быстрый и стабильный результат, смотрите в сторону GPU или API. А Open WebUI в этой схеме можно использовать как удобную точку входа: к локальной Ollama, внешним моделям или гибридной инфраструктуре.