Сколько RAM нужно для SearXNG и Perplexica

MAATRIX

«Сколько RAM нужно для SearXNG?» — вопрос без единого ответа: обычно за ним стоит связка из двух-трёх процессов, а не один. SearXNG в одиночку укладывается в 1–2 ГБ, рядом с ним Perplexica — с 9 марта 2026 года переименованная в Vane — добавляет свой Node-процесс, а с локальной моделью через Ollama — ещё несколько гигабайт под веса. Считаем: сколько стоит каждый компонент отдельно, что при неудачной схеме считается дважды, и какой тариф закрывает три рабочих сценария.

Из чего складывается память: три независимых слагаемых

Итоговое требование к RAM для связки SearXNG и Vane — это не одна цифра, а сумма трёх слагаемых, и большинство материалов про эту связку считает только одно из них. Первое — сам SearXNG: метапоисковая прокси на Granian, которая рассылает запрос по десяткам движков и сама ничего не вычисляет. Второе — Vane: Node-процесс, который забирает результаты SearXNG, при необходимости разбирает страницы (иногда через встроенный Chromium) и отправляет всё языковой модели. Третье, необязательное, — сама модель, если вы не хотите платить провайдеру за токены и гоняете инференс через Ollama на этом же сервере.

Про переименование — коротко, раз название всё ещё путает читателей и поисковики. С 9 марта 2026 года Perplexica называется Vane: сменился Docker-образ (itzcrazykns1337/perplexica → itzcrazykns1337/vane), путь данных и способ настройки. Подробности — в статье Perplexica на сервере: частые ошибки и решения, здесь не повторяем. Эта статья и статья про частые ошибки SearXNG считают каждая свою часть — как они складываются вместе, разберём ниже.

SearXNG и Vane по отдельности — и почему их нельзя просто сложить

По каждому компоненту цифры уже есть, и здесь их стоит свести, а не выводить заново. SearXNG сам по себе, с Valkey под лимитер и полутора десятками движков, укладывается в 4 ГБ на 2 vCPU — комфортный тариф, а не минимум впритык: ядро на Granian с несколькими воркерами и Valkey поверх, по данным обсуждения о памяти в репозитории searxng/searxng, держатся в диапазоне от 150 МБ (один воркер) до 600 МБ (воркер на каждое ядро). Комфортные 4 ГБ по большей части идут в запас на рост числа движков, а не съедаются самим процессом.

Vane — отдельная история, и здесь легко посчитать дважды. Толстый образ vane:latest несёт свой собственный SearXNG внутри того же контейнера — не production-инстанс на Granian, а сервер разработки на Flask, для внешних задач непригодный, но занимающий память наравне с остальным. Для такой связки честный минимум — 4 ГБ на одно активное исследование одновременно, и это уже с учётом встроенного поиска. Если рядом на том же сервере вы ещё и закажете SearXNG из каталога, вы либо получите конфликт порта 8080 при попытке поднять оба сразу, либо будете платить памятью за два независимых экземпляра SearXNG, используя из них только один.

Правильная схема — тонкий образ vane:slim-latest с переменной SEARXNG_API_URL, указывающей на единственный внешний SearXNG — тот самый, из каталога apps.maatrix.io. Итоговая цифра для этой связки — 8 ГБ на 4 vCPU, и раскладывается она примерно пополам: 4 ГБ — комфортный SearXNG, о котором говорилось выше, и ещё около 4 ГБ — сам Vane с разбором страниц и редкими запусками Chromium под Deep Research. Не 4+4 ради круглого счёта, а именно так, потому что второй SearXNG в этой схеме вы просто не запускаете.

Что добавляет Ollama к требованиям по RAM

Если хотите, чтобы Vane отвечал вообще без внешних провайдеров, третье слагаемое — вес модели плюс её KV-кэш. Разбирать это заново нет смысла: в статье сколько RAM нужно для Ollama есть и формула, и таблица по моделям — берём оттуда готовые цифры и складываем со связкой из прошлого раздела. Если Ollama на сервере ещё нет, порядок установки — в отдельном пошаговом гайде.

Модель для чата уровня llama3.1:8b в Q4_K_M весит 4,9 ГБ, буферы вычислительного графа добавляют ещё 10% (×1,1), а KV-кэш на контекст 8k — это около 1 ГБ. Итого чуть больше 6 ГБ чистой добавки под саму модель. Но Vane использует Ollama не только для ответа: похожесть найденных фрагментов с запросом (SIMILARITY_MEASURE, косинусное сходство) считает отдельная embedding-модель, и без неё смысловой поиск по загруженным документам не работает вовсе. nomic-embed-text весит всего 274 МБ, но занимает отдельный слот загрузки — при OLLAMA_MAX_LOADED_MODELS=1, который стоит по умолчанию, каждый запрос к embedding-у выгружает из памяти чат-модель и грузит её обратно на следующий вопрос. Памяти это не добавляет, а вот к задержке на каждом сообщении — добавляет ощутимо. Держать обе модели прогретыми одновременно — OLLAMA_MAX_LOADED_MODELS=2.

Складываем: 8 ГБ на связку SearXNG и Vane, плюс 6 ГБ на llama3.1:8b, плюс 0,3 ГБ на embedding-слот — около 14,5 ГБ. На практике берут 16 ГБ: круглая цифра с запасом на системные процессы (в формуле из статьи про Ollama под них отдельно заложено 1,5 ГБ) и на то, чтобы не жить впритык при всплеске параллельных запросов.

Параллельные сессии: что размножается с числом пользователей, а что нет

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

Самый прямой множитель — параллельные слоты Ollama. По умолчанию OLLAMA_NUM_PARALLEL разрешает до четырёх одновременных генераций и резервирует под каждую свой KV-кэш: для llama3.1:8b это уже не 1 ГБ, а до 4 ГБ, зарезервированных на параллелизм, который при одном пользователе просто не нужен. Для связки, где Ollama обслуживает вас или небольшую команду, разумно срезать это явно — тем же способом, каким на этом сервере уже правится адрес Ollama для самого Vane:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=1"

Экономия — реальные 3 ГБ на том же контексте, без единой правки в Vane или SearXNG.

Второй множитель — Chromium в Vane, и здесь честно нет точной цифры на клетку таблицы: каждое активное Deep Research исследование со скрапингом — отдельный процесс браузера, и сколько именно он ест, зависит от веса открытых страниц, а не от контекста модели. Смотреть за этим стоит через docker stats vane --no-stream в момент нагрузки, а не по чужим замерам — так же честно предупреждает и статья про ошибки Vane, где механизм разобран подробнее.

Третий — воркеры Granian у SearXNG. От числа пользователей Vane они напрямую не размножаются, но каждый одновременный поисковый запрос — одно исходящее соединение на воркер, а документация SearXNG прямо не советует увеличивать их число вручную: растёт потребление ресурсов и риск проблем с бот-детектом источников. Упираетесь именно в это — решение не в подкрутке воркеров, а в тарифе с запасом по памяти, где дефолтная схема не голодает.

Без Ollama: связка на облачных ключах — легче, но не бесплатно

Более лёгкий путь для большинства — не поднимать Ollama вообще, а подключить Vane к OpenAI, Anthropic, Gemini, Groq или своему OpenAI-совместимому серверу через мастер настроек на первом запуске. Тогда третье слагаемое из первого раздела попросту не появляется: вся генерация и все эмбеддинги считаются на стороне провайдера, и бюджет памяти сервера — это ровно 8 ГБ связки SearXNG и Vane из второго раздела, без гигабайтов под веса.

Честный компромисс не в памяти, а в двух других вещах. Первая — деньги переходят из разовых в постоянные: каждый токен ответа и каждый вызов embedding-а — это счёт от провайдера, а не разовая стоимость сервера. Вторая — контент, который вы нашли и который Vane передаёт модели как контекст, покидает вашу инфраструктуру и попадает к третьей стороне; для личного поиска это обычно не проблема, для корпоративного контекста с чужими документами — уже вопрос, который стоит решить осознанно, а не по умолчанию. Локация здесь по-прежнему важна, но по другой причине: с российского адреса часть провайдеров отвечает не результатом, а 403 unsupported_country_region_territory, что к памяти прямого отношения не имеет, но делает даже мощный сервер бесполезным, если он не в той стране.

Три сценария целиком

Сведём всё в одну таблицу — не замер производительности, а сумма из предыдущих разделов, где каждая цифра уже объяснена и посчитана, а не взята с потолка.

vCPU в третьей строке взят не из формулы, а по числу процессов, которым одновременно нужен процессор без GPU: воркеры SearXNG, Node-процесс Vane, изредка Chromium и сама Ollama, считающая инференс на CPU, — шести ядер достаточно, чтобы они не выстраивались в очередь друг за другом. Диск в 100 ГБ — не под ваши данные, а под сумму: образ с Chromium и Python-окружением, слои Docker, веса модели и место на вторую модель, если решите попробовать другую.

Какой сервер брать в MAATRIX

SearXNG есть в каталоге apps.maatrix.io и разворачивается автоматически при заказе сервера — команды из предыдущих разделов вставлять не нужно, это работает и на Ubuntu, и на Debian. Адрес панели и доступы к инстансу появляются в личном кабинете, в разделе «Доступ», сразу после сборки сервера. Vane в каталог пока не входит — он ставится рядом одной командой, где SEARXNG_API_URL указывает на уже поднятый из каталога инстанс на этом же сервере:

docker run -d -p 3000:3000 \
  -e SEARXNG_API_URL=http://127.0.0.1:8080 \
  -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:slim-latest

Честный минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Это вторая строка таблицы из прошлого раздела — SearXNG из каталога плюс Vane на облачных ключах, без Ollama. Для одного-двух человек и обычного темпа запросов этого хватает с запасом; ограничение прямое — держать здесь ещё и локальную модель нельзя: при первой же попытке ollama pull llama3.1:8b и загрузке модели в память вы либо получите отказ Ollama выделить память, либо OOM-killer снимет самый тяжёлый процесс в системе.

Комфортный вариант: 6 vCPU, 16 ГБ RAM, 100 ГБ NVMe. Третья строка таблицы — та же связка плюс одна локальная модель для чата и отдельный слот под эмбеддер, без обращения к внешним API вообще. Если позже захочется модель крупнее 8B, считайте отдельно по формуле из третьего раздела и берите следующий тариф — это уже не апгрейд текущего сервера, а другая весовая категория, точно так же, как и для голой Ollama без SearXNG и Vane рядом.

Локация — Лондон (UK). Причина не одна и та же для обоих вариантов из этого раздела. Для честного минимума на облачных ключах это прежде всего провайдеры моделей: с британского адреса OpenAI, Anthropic и Gemini отвечают штатно, тогда как российский IP на части из них упирается в региональный отказ независимо от того, насколько верно указан ключ. Для комфортного варианта с локальной моделью эта причина отпадает — Ollama никуда наружу не ходит, — но остаётся вторая, уже про сам SearXNG: чистый западноевропейский дата-центровый адрес без истории спама реже получает капчу от Google и Bing, чем случайный IP, — источники смотрят на репутацию адреса, а не на модель у вас внутри.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна, хотя сервер физически стоит в Лондоне.

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