Сколько RAM нужно для Open WebUI

MAATRIX

На вопрос «сколько RAM нужно для Open WebUI» отвечают цифрами от 512 МБ до 32 ГБ, и по-своему правы обе стороны: складывают две разные величины — аппетит самого веб-интерфейса и аппетит модели, которая считается рядом. Ниже — разбор по компонентам с реальными цифрами RSS, способ измерить расход на своём сервере и переменные, которыми Open WebUI ужимается примерно вдвое.

Короткий ответ: сколько памяти закладывать

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

Главное из таблицы: сам Open WebUI никогда не требует 16 ГБ. Веб-интерфейс живёт на 1–1,5 ГБ, а всё, что больше четырёх гигабайт, — память под модель, реранкер или PostgreSQL, а не под фронтенд с историей чатов.

Из чего складывается память Open WebUI

Open WebUI собран на python:3.11-slim-bookworm: FastAPI под uvicorn, SQLAlchemy, SQLite по умолчанию и — главный источник веса — PyTorch с sentence-transformers для локальных эмбеддингов. Именно торч, а не чат, делает контейнер тяжёлым.

Холодный старт с выключенной базой знаний — 450–600 МБ RSS; после первой индексации документа контейнер прогревается до 1,0–1,3 ГБ и там остаётся. Модель эмбеддингов из памяти не выгружается, так что «прогретое» состояние и есть рабочий уровень.

Отдельно про реранкер: BAAI/bge-reranker-v2-m3 — 568 млн параметров, на CPU он грузится в fp32, то есть 2,3 ГБ только под веса. Одна галочка «Hybrid Search» в админке превращает полуторагигабайтный сервис в четырёхгигабайтный — самая недооценённая строка расходов во всём Open WebUI. Погрешность цифр — процентов двадцать: версия и набор включённых функций двигают их в обе стороны.

Как измерить свой расход, а не гадать по чужим цифрам

Вот docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" на сервере с 4 ГБ, где Open WebUI работает фронтом к внешним API, а Ollama стоит без загруженной модели:

NAME         MEM USAGE / LIMIT     MEM %
open-webui   1.147GiB / 3.822GiB   30.01%
ollama       61.3MiB / 3.822GiB    1.57%

Здесь ловушка. На cgroup v2 docker stats показывает memory.current за вычетом неактивного файлового кеша — страничный кеш в цифру попадает: прочитали с диска модель на 5 ГБ, и «потребление» подскочило, хотя анонимных страниц столько же. Чистое значение и пик смотрите так:

CID=$(docker inspect -f '{{.Id}}' open-webui)
docker exec open-webui grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat
cat /sys/fs/cgroup/system.slice/docker-$CID.scope/memory.peak

anon — настоящая память процесса, file ядро отдаст обратно под давлением без всякого OOM. memory.peak появился в ядре 5.19, так что на Ubuntu 24.04 (ядро 6.8) и Debian 13 он есть; на cgroup v1 аналог — memory.max_usage_in_bytes. С ядра 6.8 счётчик сбрасывается записью echo reset > .../memory.peak — удобно замерить одну операцию, а не всё время с запуска.

Если контейнер уже падал, диагноз ставится двумя командами:

docker inspect -f '{{.State.OOMKilled}} {{.State.ExitCode}}' open-webui
journalctl -k --since "24 hours ago" | grep -i "out of memory"

true 137 означает, что процесс убил не баг, а ядро. В журнале это выглядит так:

Memory cgroup out of memory: Killed process 24817 (python3)
total-vm:6031244kB, anon-rss:1893224kB, file-rss:36864kB,
shmem-rss:0kB, UID:0 pgtables:4432kB oom_score_adj:0

anon-rss:1893224kB — это 1,8 ГБ в момент смерти: если на машине 2 ГБ и рядом крутится что-то ещё, картина сходится. Общий разбор — в материале про нехватку RAM.

Что даёт всплеск: RAG, реранкер, голос и воркеры

Ровное потребление никого не убивает — убивают пики. Источники по убыванию опасности:

• Индексация документов. Файл режется по CHUNK_SIZE (1000 символов) с перекрытием CHUNK_OVERLAP=100: PDF на 300 страниц — порядка 4000 кусков через эмбеддер. RAG_EMBEDDING_BATCH_SIZE по умолчанию равен 1 — медленно, зато экономно; подняли до 32, и индексация ускоряется втрое-вчетверо ценой лишних 300–600 МБ на пике.
• PDF_EXTRACT_IMAGES=true. Извлечение картинок и OCR — худший пик из штатных операций, на 4 ГБ уже рискованно.
• Гибридный поиск. ENABLE_RAG_HYBRID_SEARCH=true поднимает BM25 плюс реранкер — те самые 2,3 ГБ, и постоянно, а не на пике.
• Голос. Пустое AUDIO_STT_ENGINE означает локальный faster-whisper: WHISPER_MODEL=base — 250–400 МБ, small — около 700 МБ, medium — примерно 2 ГБ. Грузится при первом голосовом сообщении, то есть через недели после установки, когда про параметр уже забыли.
• UVICORN_WORKERS. Значение больше 1 множит всё: каждый воркер грузит свою копию torch и свой эмбеддер, четыре воркера на 4 ГБ — гарантированный OOM. Приложение асинхронное, одному воркеру нормально живётся с десятками пользователей.
• База. Переход с SQLite на DATABASE_URL=postgresql://... лечит database is locked, но добавляет сам PostgreSQL — 200–400 МБ при shared_buffers=128MB, плюсом к Open WebUI, а не вместо.

Как ужать Open WebUI до гигабайта

Самая большая экономия — вынести эмбеддинги наружу: PyTorch и sentence-transformers тогда не инициализируются вовсе, и с RSS уходит 500–600 МБ разом. Фрагмент docker-compose.yml:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    restart: unless-stopped
    ports: ["127.0.0.1:8080:8080"]
    volumes: ["/opt/open-webui:/app/backend/data"]
    environment:
      - RAG_EMBEDDING_ENGINE=openai
      - RAG_OPENAI_API_KEY=${OPENAI_API_KEY}
      - RAG_EMBEDDING_MODEL=text-embedding-3-small
      - AUDIO_STT_ENGINE=openai
      - ENABLE_RAG_HYBRID_SEARCH=false
      - UVICORN_WORKERS=1
      - MALLOC_ARENA_MAX=2
    mem_limit: 1500m
    memswap_limit: 2g

• RAG_EMBEDDING_ENGINE=openai — главная экономия. Честный минус: каждый документ уезжает на векторизацию в OpenAI, а это ровно то, от чего многие и ставят Open WebUI себе. Промежуточный вариант — RAG_EMBEDDING_ENGINE=ollama с nomic-embed-text (274M, около 300 МБ): данные остаются у вас, но память переезжает в контейнер Ollama.
• MALLOC_ARENA_MAX=2 ограничивает число арен glibc: многопоточный Python на 8 vCPU создаёт их до 64 и удерживает 300–500 МБ фрагментированной кучи. Эффект обычно 5–15 % RSS, иногда нулевой, но переменная бесплатна.
• mem_limit — не оптимизация, а предохранитель: без лимита ядро выбирает жертву по oom_score и может прибить Ollama или sshd вместо Open WebUI, а с лимитом умирает только контейнер и restart: unless-stopped поднимает его обратно.
• Тег :main плавающий: очередная версия может поднять базовое потребление на пару сотен мегабайт без предупреждения. Где памяти впритык — фиксируйте версию явно, вроде :v0.6.18.

Дополнительно — swap как страховка от пиков индексации: fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, строка /swapfile none swap sw 0 0 в /etc/fstab и sysctl -w vm.swappiness=10. Десятка вместо дефолтных 60 означает, что ядро полезет в swap только когда припёрло, и не выпихнет туда горячие страницы приложения. Но swap не превращает маленький сервер в большой: если туда уезжает модель Ollama, генерация падает с токенов в секунду до секунд на токен.

Когда память определяет не Open WebUI, а модель

Если Ollama живёт на той же машине, расчёты выше становятся фоновым шумом. Веса лежат в RAM целиком, а рядом — KV-кеш, о котором почти никто не думает заранее. У модели на 8 млрд параметров типично 32 слоя, 8 KV-голов и размерность головы 128: (8 × 128) × 2 (K и V) × 2 байта = 4 КиБ на токен на слой, или 128 КиБ на токен на все 32 слоя. Отсюда:

И это на один слот. OLLAMA_NUM_PARALLEL умножает кеш на число параллельных запросов: четыре слота при контексте 32k — 16 ГиБ сверх весов модели. Отсюда классическая история: человек выставляет в Open WebUI в «Advanced Params» параметр num_ctx в 32768, потому что «хочу длинные диалоги», и сервер на 16 ГБ уходит в OOM на ровном месте.

Квантование кеша режет расход примерно вдвое и включается через systemctl edit ollama:

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

q8_0 почти не влияет на качество, q4_0 режет память вчетверо, но на длинных контекстах ответы деградируют заметно. OLLAMA_MAX_LOADED_MODELS=1 важен, когда пользователи переключают модели в списке: без него в память въезжают обе. Сколько весит каждая модель — в таблице моделей для Ollama; здесь речь о том, что к ней прибавляется.

Какой сервер взять в MAATRIX под Open WebUI

Конфигурация определяется одним вопросом: где считаются модели.

Если модели считает внешний API — OpenAI, Anthropic, OpenRouter или ваш шлюз, — Open WebUI остаётся лёгким веб-приложением. Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. На 2 ГБ оно стартует и первую неделю выглядит нормально, но живёт до первого большого документа. Четыре гигабайта дают запас на прогретый эмбеддер (1,3 ГБ), пик индексации и систему с Docker. Комфорт для команды — 4 vCPU, 8 ГБ, 80 ГБ NVMe: влезают PostgreSQL, гибридный поиск с реранкером и десятки пользователей сразу.

Если Ollama стоит рядом, минимум определяется моделью: 8 vCPU, 16 ГБ RAM, 160 ГБ NVMe под 8B в Q4 с контекстом 8k. Честно о скорости: на CPU без видеокарты это 5–8 токенов в секунду — для личного помощника терпимо, для пяти человек одновременно нет, там нужен GPU, а не ещё оперативная память. Диск съедается быстро: образ 3,7 ГБ, старый образ до prune рядом, модель — ещё 4,7 ГБ, плюс растущий индекс.

Локация — Лондон. Причина практическая: с британского адреса Open WebUI ходит в OpenAI, Anthropic и Google напрямую, без прослоек и проверок, а пинг из Москвы держится в районе 45–60 мс — для чата это неотличимо от локального. Из России тот же запрос упирается в блокировки и требует прокси, то есть ещё одну точку отказа. Франция — равноценная альтернатива, США берут ради американского IP, Россию — когда пользователи только внутри страны и в чатах ходят персональные данные под 152-ФЗ. Подробнее — в разборе VPS в Великобритании для нейросетей, установка с нуля — в пошаговой инструкции.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки. Не уверены, какой сценарий ваш, — напишите, сколько будет пользователей и нужны ли локальные модели.

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