Сколько RAM нужно для Flowise

MAATRIX

Flowise выглядит лёгким: один Node-процесс, один порт 3000, никакого инференса на сервере. А потом контейнер уходит в перезапуск с кодом 137, и в логах пусто. Ниже — куда уходит память, расчёт векторного индекса по формуле и две противоположные ловушки: одна убивает Flowise на 2 ГБ, вторая — на 16.

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

Официальная документация Flowise не называет ни одной цифры по памяти: в разделе Get Started есть только требование к рантайму, «Node v18.15.0 or v20 and above is supported». Всё остальное — чужой опыт, а не спецификация. Ниже расчёт, который вы проверите на своей машине командами из следующих двух секций.

Главное строкой: сам Flowise — Node-процесс на несколько сотен мегабайт, и от числа потоков он почти не растёт. Растут векторы, документы, браузер загрузчика и воркеры очереди.

Почему пустой Flowise занимает сотни мегабайт

Свежий инстанс без единого потока держит 400–600 МБ резидента. Причина в том, как собирается каталог узлов: класс NodesPool при старте обходит dist/nodes, делает require каждого файла и сразу создаёт экземпляр класса.

const nodeModule = await require(file)
if (nodeModule.nodeClass) {
    const newNodeInstance = new nodeModule.nodeClass()
    ...
    const isDisabled = disabled_nodes.includes(newNodeInstance.name)

В версии 3.1.4 в packages/components/nodes лежит около четырёхсот файлов узлов в 25 категориях: 70 инструментов, 54 чат-модели, 49 загрузчиков документов, 36 векторных хранилищ, 20 моделей эмбеддингов. Каждый тянет свои зависимости, а в package.json пакета flowise-components их 156: весь @langchain/*, llamaindex, chromadb, faiss-node, pdfjs-dist, puppeteer, playwright.

Отсюда неочевидный вывод: переменная DISABLED_NODES память не экономит. В коде выше require(file) и new nodeModule.nodeClass() выполняются до проверки isDisabled — модуль уже в кэше, класс уже создан, отключение лишь убирает узел из списка для интерфейса. То же с SHOW_COMMUNITY_NODES=false.

Свой базовый расход замерьте сразу после старта:

docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}'
ps -o pid,rss,etime,cmd -C node --sort=-rss | head -3
curl -fs http://127.0.0.1:3000/api/v1/ping && echo " — сервер поднялся"

Запишите число. Всё, что вырастет сверх него, — уже ваши данные.

Ловушка образа: NODE_OPTIONS=--max-old-space-size=8192

Самая дорогая мина лежит прямо в Dockerfile проекта:

FROM node:24-alpine
...
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser
ENV NODE_OPTIONS=--max-old-space-size=8192
WORKDIR /usr/src/flowise
COPY . .
RUN pnpm install && pnpm build:docker

Строка стоит до RUN pnpm install, потому что turbo-сборка UI на дефолтной куче падает. Но ENV со сборкой не заканчивается: переменная остаётся в образе, и контейнер на VPS с 2 ГБ памяти честно считает, что имеет право вырасти до восьми гигабайт.

Почему это плохо, видно из того, как V8 выбирает лимит кучи сам: примерно четверть физической памяти, но не больше 2 ГБ (4 ГБ на машинах свыше 16 ГБ).

Своё значение смотрите изнутри контейнера, а не с хоста:

docker exec flowise sh -c 'echo "$NODE_OPTIONS"'
docker exec flowise node -e "console.log(require('v8').getHeapStatistics().heap_size_limit/1048576)"

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

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb85bc0 node::Abort() [node]

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

docker inspect -f '{{.State.OOMKilled}} {{.State.ExitCode}}' flowise   # true 137
journalctl -k --since "1 hour ago" | grep -i "out of memory"

В журнале ядра строка выглядит как Out of memory: Killed process 8123 (node) total-vm:9834512kB, anon-rss:1893224kB ... oom_score_adj:0: девять гигабайт total-vm при anon-rss меньше двух — тот самый случай.

Третий вариант, самый обидный: контейнер с mem_limit: 2g на 16-гигабайтном хосте. V8 читает физическую память из /proc/meminfo и лимит cgroup не видит — решит, что у него 16 ГБ, возьмёт 2 ГБ кучи и упрётся в cgroup раньше собственного потолка. Лечение одно:

services:
  flowise:
    image: flowiseai/flowise:latest
    restart: always
    ports: ['3000:3000']
    environment:
      - PORT=3000
      - NODE_OPTIONS=--max-old-space-size=1536
      - FLOWISE_FILE_SIZE_LIMIT=20mb
    mem_limit: 2g
    volumes:
      - ~/.flowise:/home/node/.flowise

--max-old-space-size ставьте примерно в 75 % от лимита контейнера: куча — не весь процесс. И проверьте путь тома: контейнер перешёл на пользователя node, домашний каталог теперь /home/node/.flowise, а не /root/.flowise из старых руководств.

Векторы в памяти: расчёт In-Memory Vector Store

Узел In-Memory Vector Store (внутреннее имя memoryVectorStore) — самый частый способ незаметно съесть гигабайты. Он оборачивает MemoryVectorStore из LangChain и в описании честно называет себя «exact, linear search»: индекс лежит в куче Node обычными JS-массивами, поиск идёт перебором.

Число в JavaScript — double, восемь байт, и однородный массив чисел V8 хранит упакованными double. Вектор занимает размерность × 8 байт плюс текст фрагмента (кириллица в UTF-16 — два байта на символ) плюс метаданные.

Это только векторы: при разбиении по 1000 символов сто тысяч фрагментов добавят ещё около 200 МБ строк. И удвойте пик на время апсерта — пока строится хранилище, в памяти живут и массив Document, и готовые векторы.

• Индекс не переживает перезапуск — он собирается заново при каждом запуске потока, и за эмбеддинги вы платите повторно: деньгами провайдеру или временем локальной модели.
• Поиск линейный. Сто тысяч векторов по 1536 измерений — порядка 150 миллионов умножений на запрос, в один поток, с блокировкой event loop.
• Индекс ограничен кучей V8, поэтому вы получите Reached heap limit, а не плавную деградацию.

Альтернативы снимают проблему целиком: pgvector в Postgres держит индекс на диске, Qdrant или Chroma добавляют HNSW вместо перебора. Особый случай — faiss-node: его индекс тоже в памяти, но в нативной, не в куче V8, и во float32 — вдвое дешевле по байтам, зато --max-old-space-size его не сдерживает вообще.

Пики, а не средние: документы, Chromium и очередь

Сервер убивают не средние значения, а всплески. Их три.

Загрузка файлов. FLOWISE_FILE_SIZE_LIMIT по умолчанию равна 50mb. Пятидесятимегабайтный PDF — это не 50 МБ в памяти: файл приезжает в теле запроса, часто в base64 (плюс треть объёма), затем pdf-parse или pdfjs-dist разбирает его в объектную модель, затем текст режется на фрагменты — и стадии сосуществуют. Практический множитель — от пяти до десяти к размеру исходника.

Chromium внутри образа. В Dockerfile есть apk add --no-cache ... chromium и ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser — официальный образ несёт в себе настоящий браузер. Узлы Puppeteer Web Scraper и Playwright Web Scraper запускают его по-настоящему, и каждый экземпляр — 300–700 МБ сверх Node, отдельным процессом. Если веб-скрейпинг не нужен, вот здесь DISABLED_NODES как раз помогает: экономит не загрузку модуля, а запуск браузера.

Queue-режим. При MODE=queue главный сервер только кладёт задачи в BullMQ, а выполняют их воркеры (flowise worker). Документация описывает, что делает воркер при получении задачи: «Reconstruct full execution context (DB, components, abort controllers)». Слово components ключевое — воркер поднимает весь тот же каталог из четырёхсот узлов. Связка «сервер + два воркера + Redis» — не 600 МБ, а около двух гигабайт в покое.

Отдельно про WORKER_CONCURRENCY: документация называет по умолчанию 10000, .env.example показывает 100000. В обоих случаях это «сколько угодно параллельно» — ограничения по памяти нет, его ставите вы:

MODE=queue
QUEUE_NAME=flowise-queue
WORKER_CONCURRENCY=5
REMOVE_ON_AGE=86400
REMOVE_ON_COUNT=1000
REDIS_HOST=127.0.0.1

Пятёрка — отправная точка для 8 ГБ. Если потоки только ходят в облачный API и ждут ответа, поднимайте до 20–30: память там тратится на промисы.

И про рантайм, от которого зависят дефолты кучи: с версии flowise@3.1.3 (июнь 2026) в пакете стоит "engines": { "node": "^24" } вместо прежнего >=18.15.0 <19.0.0 || ^20, а документация про это ещё не знает. npm на Node 20 установку не остановит — отделается предупреждением npm warn EBADENGINE Unsupported engine.

Локальные модели рядом: когда 4 ГБ превращаются в 16

Частый способ промахнуться с тарифом — посчитать память под Flowise и забыть про модель на том же сервере. Flowise к моделям только ходит, вес держит Ollama; подробности — в таблице памяти для Ollama, здесь цифры с нашего стенда: AMD EPYC 9554, 16 vCPU (8 физических ядер плюс HT), без GPU, Ollama 0.33.1.

Прибавьте Flowise с полугигабайтом, Postgres и систему — и «сервер под no-code AI» с локальной семёркой начинается от 16 ГБ, а не от восьми. Полезная при выборе тарифа деталь того же замера: на qwen2.5:7b генерация даёт 5,7 / 7,6 / 7,6 / 7,4 токена в секунду при num_thread 2 / 4 / 8 / 16. То есть на CPU скорость выходит на полку уже на четырёх потоках — упор в пропускную способность памяти, а не в ядра, и переплачивать за 16 vCPU ради генерации бессмысленно. А 32 потока на 16 vCPU дают обвал до 0,35 ток/с.

Вывод: под локальные модели берите отдельный сервер и подключайте его узлом Ollama по адресу вида http://10.0.0.5:11434. И помните про эмбеддинги — nomic-embed-text занимает около 300 МБ, bge-m3 порядка гигабайта, и они висят в памяти постоянно.

Что заказать в MAATRIX под Flowise

Сразу честно: Flowise нет в каталоге готовых приложений apps.maatrix.io. Сервер приезжает чистым — Ubuntu или Debian, — и Flowise вы ставите сами по инструкции выше: docker compose up -d с приведённым файлом либо npm install -g flowise на Node 24. В каталоге есть готовые сборки родственных сервисов, которые разворачиваются автоматически при заказе и появляются с доступами в кабинете: Ollama под локальные модели рядом, LiteLLM как шлюз к провайдерам, Dify, AnythingLLM, n8n.

• Честный минимум — 2 vCPU / 2 ГБ / 40 ГБ NVMe. Прототип на облачных моделях, векторы во внешней базе, NODE_OPTIONS=--max-old-space-size=1536, swap на 2 ГБ от пиков апсерта. Ограничение назову прямо: In-Memory Vector Store здесь живёт до нескольких тысяч фрагментов.
• Рабочая база — 2 vCPU / 4 ГБ / 60 ГБ NVMe. Десяток потоков, Postgres с pgvector на том же сервере, спокойная загрузка документов. Конфигурация, на которой Flowise перестаёт о себе напоминать.
• Комфорт — 4 vCPU / 8 ГБ / 80 ГБ NVMe. Queue-режим с воркером, Redis, база знаний в сотни тысяч фрагментов, несколько человек на холсте.
• С локальной моделью — 8 vCPU / 16–32 ГБ, а правильнее два сервера: лёгкий под Flowise и отдельный под Ollama.

Диск считайте отдельно: каталог ~/.flowise хранит database.sqlite, загруженные файлы и логи, а образ с Chromium внутри сам занимает пару гигабайт. Берите от 40 ГБ NVMe.

Локация — Великобритания, Лондон. Логика та же, что в любой задаче с внешними LLM-провайдерами: с российского адреса OpenAI отвечает 403 unsupported_country_region_territory, Google для Gemini — User location is not supported for the API use, и переустановкой Flowise это не лечится. Лондон даёт рабочий доступ к API и низкий RTT до Европы — обычно 30–45 мс против сотни с лишним до Нью-Йорка. США берите, если аудитория американская.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Если упрётесь в память, посмотрите что делать при нехватке RAM; по продукту пригодятся пошаговая установка Flowise и сравнение Dify против Flowise — у Dify профиль потребления другой, десяток контейнеров вместо одного процесса.

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