Альтернативы Open WebUI для VPS: сравнение ресурсов

Какая альтернатива Open WebUI подходит для VPS

Альтернативы Open WebUI почти всегда сравнивают в контексте ноутбука, где оперативная память стоит недорого, а сервисы не слушают публичные адреса. VPS меняет оба этих фактора, что влияет на рейтинг. Open WebUI остается оптимальным решением по умолчанию, как только в системе появляется второй пользователь, так как проект предоставляет полноценные учетные записи и панель администратора. Более легкие проекты выигрывают, когда интерфейс конкурирует с моделью за последний гигабайт оперативной памяти. Цена этого выигрыша — отсутствие аутентификации.

Все приведенные ниже данные взяты из документации соответствующих проектов по состоянию на август 2026 года, повторно проверены 20 октября 2026 года, а также дополнительно уточнены для Open WebUI, LibreChat, Hollama и OrionChat 25 октября 2026 года. Документация Ollama и правила безопасности браузеров были повторно проверены 29 октября 2026 года. Четыре критерия оценки актуальны только тогда, когда сервер доступен из сети Интернет.

Четыре фактора, имеющие значение только при наличии публичного IP

• Память рядом с моделью. Сервер модели — самый ресурсоемкий процесс на сервере. Каждый мегабайт, занятый интерфейсом, — это мегабайт, который недоступен модели.
• Аутентификация. Некоторые из этих проектов поддерживают учетные записи пользователей и роли. Другие предполагают, что они являются единственным запущенным приложением на вашем ноутбуке, и не имеют никакой системы входа.
• Удаленный инференс. Интерфейс, который всегда обращается к 127.0.0.1:11434, ожидает, что модель находится на том же узле, что и сам интерфейс. Размещение модели в другом месте требует создания туннеля, который перенаправляет этот локальный порт на хост с моделью.
• Обслуживание. Один контейнер с файлом SQLite — это задача иного уровня сложности, чем шесть контейнеров с MongoDB и векторной базой данных в связке.

Сколько оперативной памяти модель оставляет для интерфейса

Интерфейс — не самый ресурсоемкий компонент системы. Модель потребляет значительно больше. Опубликованные размеры файлов для скачивания задают лишь нижнюю границу, так как веса должны находиться в оперативной памяти во время работы модели, а реальное потребление памяти превышает размер файла после выделения кэша контекста.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Это показатели, которые были указаны на страницах библиотеки Ollama 25 октября 2026 года. Это опубликованные размеры, а не результаты измерений. На VPS с 4 GB оперативной памяти модель qwen3:4b размером 2.5 GB оставляет менее 1.5 GB для операционной системы и всех остальных процессов, при этом кэш контекста сокращает этот объем по мере развития диалога. Именно поэтому значение num_ctx, которое вы задаете — это решение, касающееся не только качества, но и объема памяти. Модель qwen3:8b размером 5.2 GB на такой сервер не поместится вовсе. Это ситуация, которую никогда не рассматривают в обзорах ноутбуков, и именно здесь интерфейс чата, занимающий несколько сотен мегабайт, определяет, будет ли модель работать. Если вы подбираете сервер для задач, выходящих за рамки этих показателей, расчеты для модели 27B на VPS только с CPU показывают, как быстро интерфейс перестает быть решающим фактором.

Проводите измерения самостоятельно, а не доверяйте цифрам из обзоров, включая этот. Запустите docker stats --no-stream через час реальной работы, а не через минуту после запуска контейнера, так как важная часть памяти выделяется при первом использовании. Ollama также выгружает веса из памяти после пяти минут простоя, поэтому показатели, снятые в перерыве между диалогами, будут ниже пиковых, а при отправке следующего сообщения нагрузка возникнет снова, если вы не закрепите модель в памяти с помощью keep_alive.

Open WebUI: по-прежнему стандарт для нескольких пользователей

Open WebUI запускается из одного образа и хранит данные в одном томе.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Команда из README проекта публикует -p 3000:8080, который слушает все сетевые интерфейсы. Префикс 127.0.0.1: ограничивает его работу только локальным интерфейсом (loopback). На VPS этот префикс важнее всего остального в строке, поскольку Docker создает собственные правила iptables, и опубликованный порт игнорирует правила запрета ufw.

Получите доступ к странице через туннель или прокси (оба способа описаны ниже), затем создайте первую учетную запись. Эта учетная запись станет администратором. После этого регистрация новых пользователей автоматически отключается, пока администратор не включит параметр New Sign Ups. Все последующие учетные записи создаются с ролью pending, что является задокументированным значением по умолчанию DEFAULT_USER_ROLE. Таким образом, посторонний человек, попавший на страницу, не сможет использовать вашу модель, пока администратор не подтвердит его доступ.

Open WebUI потребляет больше оперативной памяти, чем проекты, описанные ниже, так как обладает более широким функционалом. Страница производительности в самом интерфейсе указывает на компоненты, потребляющие ресурсы. Стандартный движок эмбеддингов загружает модель sentence-transformers внутри контейнера, что требует около 500 МБ или более на каждый рабочий процесс. Установка RAG_EMBEDDING_ENGINE=ollama передает эту задачу серверу моделей, который у вас уже запущен. AUDIO_STT_ENGINE=webapi позволяет избежать загрузки локальной модели распознавания речи. При использовании SQLite с не установленным DATABASE_POOL_SIZE пул соединений расширяется до большого внутреннего размера, и каждое соединение увеличивает собственный кэш страниц и карту памяти. Поэтому на сервере с ограниченными ресурсами установите DATABASE_POOL_SIZE=8 и DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Функция автодополнения, которая запрашивает у модели продолжение текста во время ввода пользователем, теперь поставляется в выключенном состоянии (ENABLE_AUTOCOMPLETE_GENERATION по умолчанию имеет значение False), поэтому оставьте её выключенной на маломощных системах.

LibreChat: многопользовательская система со стеком сервисов

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

Интерфейс отвечает на порту 3080. LibreChat стоит рассмотреть, если вам нужна полноценная система управления учетными записями, а не просто форма входа: проект поддерживает авторизацию через LDAP и OAuth2, а стандартный файл compose также определяет панель администратора для управления пользователями, группами и ролями. Эта панель не работает сразу после установки. Она отказывается запускаться, пока в .env не будет задана переменная ADMIN_PANEL_SESSION_SECRET — обязательное значение длиной не менее 32 символов, у которого нет значения по умолчанию, поэтому сгенерируйте его с помощью openssl rand -hex 32, если оно вам нужно. Панель работает как отдельный сервис, а не внутри процесса LibreChat, требует версию LibreChat v0.8.5 или новее, и проект до сих пор помечает её как предварительную версию. Эта функциональность поставляется в составе стека.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Стандартный файл compose запускает 5 сервисов: api, MongoDB, Meilisearch, pgvector, RAG API. Шестой сервис, панель администратора, находится в том же файле и подключается после настройки секретного ключа. Ни один из них не является моделью. MongoDB и pgvector требуют выделения оперативной памяти, и на сервере с 4 GB это память, которая была нужна модели.

Два сервиса в файле публикуют порты, и ни одно из правил проброса не привязано к конкретному IP-адресу: API на порту 3080 и панель администратора на порту 3000 (значение по умолчанию для ADMIN_PANEL_PORT). Поэтому оба сервиса после запуска слушают все сетевые интерфейсы. Порт 3000 также использует Open WebUI, упомянутый выше, поэтому при включении панели на одном сервере возникнет конфликт. Переназначьте оба порта на 127.0.0.1 в docker-compose.override.yml, прежде чем открывать стек в интернет.

Обновления выполняются через git, и именно здесь часто допускают ошибки.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull завершается с ошибкой конфликта, если вы редактировали отслеживаемый файл docker-compose.yml, из-за чего обновление применяется частично. Вносите свои изменения в docker-compose.override.yml, который проект предоставляет специально для этого, а секретные данные храните в .env. Оба файла не отслеживаются git, поэтому git pull их не затрагивает.

Укажите LibreChat ваш собственный сервер моделей с помощью пользовательского endpoint в librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Замените model-host на адрес сервера, где запущен Ollama. Поле apiKey должно присутствовать, даже если Ollama игнорирует его значение, поэтому можно использовать любой заполнитель. Если LibreChat запущен в Docker, а Ollama работает на той же машине, localhost внутри контейнера будет указывать на сам контейнер, поэтому используйте там host.docker.internal.

Hollama и OrionChat: браузер выполняет всю работу

Hollama предоставляет браузерное приложение из одного небольшого контейнера. Чаты хранятся в локальном хранилище вашего браузера, а не на сервере.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

Версия этой команды из README использует --rm, что приводит к удалению контейнера при его остановке, поэтому интерфейс не восстанавливается после перезагрузки.

OrionChat идет дальше и вообще не имеет серверного компонента. Клонируйте репозиторий и раздавайте папку с помощью уже запущенного веб-сервера или откройте index.html с диска. API-ключи хранятся в localStorage браузера, история чатов остается в браузере, а приложение удаляет самые старые чаты, как только их количество превышает 512. Адрес Ollama в OrionChat жестко прописан в исходном коде (js/script.js) как http://localhost:11434, и в настройках нет поля для его изменения.

Ни в одном из проектов нет системы входа. На ноутбуке это приемлемо. На VPS это означает, что страницу нельзя публиковать в 0.0.0.0, а также влечет за собой важный нюанс: браузер обращается к модели напрямую, а не через сервер.

Этот факт определяет область применения данных решений. Ваш браузер должен иметь прямой доступ к Ollama. Для OrionChat это всегда означает localhost:11434 на машине, где запущен браузер, поэтому на VPS единственным маршрутом к модели является SSH-туннель, описанный ниже. Hollama принимает любой адрес, который вы вводите в качестве базового URL соединения, а руководство по self-hosting описывает работу с сервером Ollama на другом устройстве: добавьте источник Hollama в OLLAMA_ORIGINS на стороне Ollama. Таким образом, если вы не пробрасываете порт через SSH, Ollama должна слушать не только loopback, а API Ollama не требует логина или ключа. Из этого следуют два правила для браузера. Страница, обслуживаемая по HTTPS, не может вызывать обычный HTTP-эндпоинт на публичном IP-адресе, и консоль выводит Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. У loopback есть отдельное исключение: спецификация Mixed Content блокирует только те URL, которые не являются потенциально доверенными, а спецификация Secure Contexts считает localhost, 127.0.0.0/8 и ::1 потенциально доверенными, поэтому одна и та же HTTPS-страница может вызывать http://localhost:11434 или http://127.0.0.1:11434. Именно на этом исключении основывается работа SSH-туннеля ниже. Начиная с версии 142, Chrome добавляет один шаг, если страница загружается с публичного сайта, такого как https://chat.example.com: запрос от него к loopback или адресу локальной сети ожидает, пока пользователь не разрешит доступ к локальной сети в запросе разрешений. Chrome также исключает HTTP-запросы к эндпоинтам локальной сети, требующие разрешений, из проверок смешанного контента, когда имя хоста является литералом частного IP, таким как 192.168.0.1, именем .local или если в fetch указан targetAddressSpace: "local". Страница, которую вы открываете по адресу http://localhost через туннель, уже находится на loopback, поэтому этот запрос к ней не применяется. Вызов любого другого источника отклоняется с ошибкой has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource до тех пор, пока вы не разрешите этот источник.

Документированный способ изменить любую из этих настроек в Ollama — использование systemd override.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss теперь должен выводить 0.0.0.0:11434 там, где раньше выводил 127.0.0.1:11434. Вносите это изменение только в том случае, если брандмауэр или аутентифицирующий прокси уже контролируют доступ к порту, так как открытый 11434 — это открытый сервер моделей, а массовые сканеры быстро обнаруживают новые публичные порты. SSH-туннель ниже позволяет избежать этого вопроса: страница работает с источником localhost, который Ollama разрешает по умолчанию, а порт никогда не выходит за пределы сервера.

Может ли каждый из них использовать удаленный endpoint Ollama или vLLM

Open WebUI может, при этом соединение устанавливается на стороне сервера. OLLAMA_BASE_URL=http://model-host:11434 указывает его на Ollama. Для vLLM задайте OPENAI_API_BASE_URL=http://model-host:8000/v1, сохранив /v1, по которому vLLM предоставляет свой API. Установите OPENAI_API_KEY только в том случае, если сервер был запущен с ключом, так как в руководстве Open WebUI по vLLM аутентификация в противном случае не используется. Другие серверы, совместимые с OpenAI, принимают любой базовый путь, указанный в их собственной документации, который не всегда является /v1. OPENAI_API_BASE_URLS принимает несколько бэкендов, разделенных точкой с запятой.

LibreChat может делать это через baseURL пользовательского endpoint, показанного выше. Этот запрос также исходит от сервера, поэтому правила браузера здесь не применяются. Тот же базовый URL и тот же ключ-заполнитель работают и вне окна чата, что является всем необходимым, чтобы направить агент для написания кода на модель, которую вы уже разместили.

Hollama может указывать на любой endpoint, который вы введете в настройках. Ее соединение с Ollama имеет редактируемый базовый URL, который по умолчанию равен http://localhost:11434, кроме того, Hollama предлагает соединение, совместимое с OpenAI, по умолчанию http://localhost:8080/v1, что является путем к vLLM. Запрос исходит из вашего браузера, поэтому к нему применимо все, что описано в разделе выше. OrionChat нельзя направить куда-либо еще. Его endpoint жестко закодированы: Ollama зафиксирована на http://localhost:11434/v1/chat/completions, а в README указано, что запросы идут напрямую к официальному API каждого провайдера. Удаленная Ollama доступна только через SSH-туннель, который заставляет ее отвечать на этом локальном порту, а настроек для сервера vLLM нет вовсе.

Разделение интерфейса и модели — самое полезное преимущество удаленного endpoint. Разместите интерфейс на небольшом устройстве, а модель — там, где есть память. Это также подходящий момент, чтобы решить, должна ли Ollama или vLLM обслуживать запросы, поскольку эти два решения ведут себя совершенно по-разному, когда несколько человек одновременно общаются с моделью. Если сервер модели еще не существует, начните с запуска Ollama на VPS, а на устройстве только с CPU прочитайте как Ollama соотносится с llama.cpp, прежде чем выбирать исполнитель.

Никогда не публикуйте чат-интерфейс без авторизации на 0.0.0.0

На странице рекомендаций по безопасности Open WebUI указано, что проект «создан для частных доверенных сетей, подобно другой self-hosted инфраструктуре, такой как базы данных, реестры контейнеров и CI-серверы», и рекомендуется размещать его за VPN или обратным прокси-сервером с аутентификацией. Проект, в котором вообще нет системы входа, заслуживает как минимум такого же подхода.

Проверьте, что именно слушает порты, прежде чем доверять сервису.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Строка с 127.0.0.1:3000 — это то, что вам нужно. Строка с 0.0.0.0:3000 означает, что сервис слушает все адреса, а Docker по умолчанию разрешает любому внешнему IP-адресу обращаться к опубликованному порту. Если правило в цепочке DOCKER-USER Docker или брандмауэр вашего провайдера не блокирует это, ваш чат-интерфейс доступен из публичного интернета. С вашего собственного компьютера команда curl -sI http://YOUR.VPS.IP:3000, возвращающая HTTP/1.1 200 OK, отвечает на этот вопрос более однозначно.

Отключение авторизации в Open WebUI с помощью WEBUI_AUTH=False — это настройка для одного пользователя на машине, к которой никто другой не имеет доступа. В документации также сказано, что это работает только при установке без зарегистрированных пользователей, поэтому вы не сможете применить это к системе, где уже есть учетные записи.

Первый шаблон: привязка к loopback и доступ через SSH. Опубликуйте все порты на 127.0.0.1, затем пробросьте то, что нужно: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, и откройте http://localhost:3000 на своем ноутбуке. Ничего не опубликовано, поэтому ничего нельзя просканировать. Для OrionChat пробросьте порт модели той же командой с помощью -L 11434:127.0.0.1:11434, а Ollama оставьте на loopback. Hollama может обращаться к Ollama напрямую, но тот же проброс защищает Ollama от публичного интернета, поэтому для Hollama это более безопасный путь. Этот шаблон надежен ровно настолько, насколько надежна ваша настройка SSH, поэтому используйте его в связке с SSH только по ключам и защищенный sshd.

Второй шаблон: обратный прокси-сервер, выполняющий аутентификацию до того, как приложение получит запрос. Оставьте приложение на loopback, отдайте прокси-серверу 443 порт и настройте перед ним единый вход (SSO). Traefik, управляемый через метки Docker Compose с Authentik в качестве провайдера идентификации обеспечивает каждое приложение на сервере единым входом и сертификатом. При размещении Open WebUI за TLS (transport layer security) установите WEBUI_SESSION_COOKIE_SECURE=true и WEBUI_SESSION_COOKIE_SAME_SITE=strict. Также сократите JWT_EXPIRES_IN, значение которого по умолчанию составляет четыре недели, так как в документации Open WebUI указано: без Redis выход из системы не делает токен недействительным — он остается рабочим до истечения срока действия.

Второй шаблон не спасает проекты, работающие только в браузере. Прокси перед страницей не защищает эндпоинт модели, а запрос с этой страницы на другое имя хоста не передает ваш сессионный cookie, поэтому аутентифицирующий прокси перед Ollama ответит перенаправлением на форму входа, и чат не заработает. Либо направляйте эндпоинт модели через то же имя хоста, что и страницу, либо используйте первый шаблон.

Что выбрать

Если сервисом будет пользоваться кто-то, кроме вас, запускайте Open WebUI. В нем реализована полноценная система учетных записей, новые пользователи попадают в очередь на одобрение, а разработчики публикуют рекомендации по обеспечению безопасности, которым можно следовать. Если вам требуется LDAP или панель администратора, запускайте LibreChat, установите ADMIN_PANEL_SESSION_SECRET, если нужна панель, и убедитесь с помощью docker stats, что пять его сервисов (шесть с панелью) и ваша модель действительно помещаются в ресурсы, прежде чем переходить на него. Если это один пользователь на небольшом сервере, где модель уже заняла большую часть оперативной памяти, запускайте Hollama или OrionChat через SSH-туннель и позвольте браузеру хранить состояние. Неправильный выбор на VPS — это любой из них, опубликованный на 0.0.0.0 без предварительной авторизации.

FAQ

Безопасно ли открывать Open WebUI напрямую на публичном IP-адресе?

На собственной странице с рекомендациями по безопасности Open WebUI описывается как программное обеспечение для частных доверенных сетей, находящееся в той же категории, что и базы данных или CI-серверы. В нем реализована система учетных записей: первая созданная учетная запись становится администратором, а последующие остаются в статусе pending до момента их одобрения, поэтому оно значительно безопаснее интерфейсов без авторизации. Тем не менее, размещайте его за reverse proxy с TLS и, по возможности, используйте единый вход (SSO). Публикуйте порт контейнера как 127.0.0.1:3000:8080, чтобы собственные правила iptables в Docker не открыли его в Интернет без вашего ведома.

Какая альтернатива Open WebUI потребляет меньше всего оперативной памяти на VPS?

Варианты, работающие в браузере, такие как Hollama и OrionChat, поскольку приложение выполняется на стороне клиента. Сервер лишь отдает статические файлы, а для OrionChat вообще не требуется контейнер приложения. Open WebUI постоянно удерживает в памяти процесс Python, базу данных и, по умолчанию, локальную модель для эмбеддингов, что, согласно документации, требует около 500 МБ или более на одного воркера только для модели эмбеддингов. Проверьте показатели на своем сервере с помощью docker stats --no-stream, так как они меняются в зависимости от включенных функций.

Могут ли эти чат-интерфейсы использовать сервер Ollama на другом хосте?

Open WebUI и LibreChat могут, при этом соединение устанавливается самим сервером, поэтому правила браузера не применяются. Установите OLLAMA_BASE_URL для Open WebUI или baseURL в пользовательском endpoint для LibreChat. Для vLLM или другого сервера, совместимого с OpenAI, используйте OPENAI_API_BASE_URL с базовым путем, который указан в документации этого сервера (для vLLM это /v1), и добавьте API-ключ, только если сервер его требует. Hollama также может подключаться к любому адресу, но запрос исходит из вашего браузера, поэтому endpoint должен быть доступен из него напрямую. OrionChat не может: его адрес Ollama жестко задан как http://localhost:11434, поэтому удаленный Ollama будет работать только через SSH-туннель, пробрасывающий этот порт.

Почему мой браузерный чат-интерфейс не может связаться с Ollama?

Две причины охватывают почти все случаи. Ollama по умолчанию привязывается к 127.0.0.1:11434, поэтому браузер на другом компьютере не может связаться с ним напрямую, пока не будет изменен OLLAMA_HOST или не будет настроен SSH-туннель для проброса порта. Ollama по умолчанию принимает кросс-доменные запросы (CORS) с localhost, 127.0.0.1 и 0.0.0.0, поэтому страница, загруженная с вашего домена, получит отказ с ошибкой No 'Access-Control-Allow-Origin' header is present on the requested resource, пока этот источник не будет указан в OLLAMA_ORIGINS. Если страница работает по HTTPS, а endpoint — по обычному HTTP на публичном IP-адресе, браузер заблокирует вызов как смешанное содержимое (mixed content) еще до того, как его увидит Ollama. Адреса обратной петли (localhost, любой адрес в 127.0.0.0/8, например 127.0.0.2, или [::1]) являются исключением. Chrome также делает исключение для HTTP-запросов в локальной сети, использующих частные IP-адреса, такие как 192.168.0.1, имена хостов .local или targetAddressSpace: "local" после предоставления разрешения для локальной сети; требования CORS для Ollama при этом все равно сохраняются. Установите обе переменные в переопределении systemctl edit ollama.service, либо пробросьте порт через SSH, и проблема исчезнет.