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

MAATRIX

«4 ГБ хватит с запасом» и «меньше 32 ГБ даже не начинайте» — оба ответа встречаются в обсуждениях про Langfuse, и оба по-своему верны. За self-hosted Langfuse стоит не одна программа, а стек из шести контейнеров с очень разным аппетитом к памяти, и вопрос «сколько RAM нужно для Langfuse» без уточнений — какой способ развёртывания, сколько трейсов в день — не имеет одного числа. Разберём минимумы по компонентам, разницу Docker Compose и Kubernetes, реальный OOM у воркера и то, как трафик сам поднимает планку со временем.

Из чего состоит Langfuse и почему сумма компонентов — не ответ

Собственный docker-compose.yml из репозитория Langfuse поднимает шесть сервисов: langfuse-web (интерфейс и приём событий, порт 3000), langfuse-worker (обработка очереди, порт 3030, только на 127.0.0.1), clickhouse (сами трейсы и метрики, порты 8123 и 9000), postgres (метаданные — пользователи, проекты, ключи, промпты), redis (очередь BullMQ и кэш) и minio (S3-совместимое хранилище сырых событий и медиа). На момент публикации ветка репозитория тянет образы langfuse:4 и langfuse-worker:4 из реестра docker.langfuse.com вместе с clickhouse/clickhouse-server:25.12 — проект ведёт одновременно ветки v4 (последний релиз — 4.21.0) и v3 (последний релиз — 3.225.5), и минимальная версия ClickHouse у них разная: v3 — от 24.3, v4 — от 25.12.

Документация по Docker Compose на одной машине называет ориентир прямо: не меньше 4 ядер, 16 ГБ памяти (пример — AWS t3.xlarge), 100 ГБ диска. Оговорка честная: Compose не даёт отказоустойчивости и горизонтального масштабирования без отдельного балансировщика — конфигурация для одной команды, не продакшн с резервированием.

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

Кто из шести контейнеров сколько просит и почему

Гайд Langfuse по масштабированию даёт минимальные требования по каждому компоненту отдельно — цифры для Kubernetes, где каждый сервис живёт в своём поде:

Сумма — 11 vCPU и 25,5 ГБ; ниже — почему именно так.

ClickHouse прожорливее всех не случайно: колоночная OLAP-база, и для развёртываний крупнее тестового документация советует уже от 16 ГБ — выборки по датам и агрегации тем быстрее, чем больше данных лежит в памяти, а не читается с диска заново.

PostgreSQL при том же минимуме в 4 ГБ на практике — самый лёгкий из тяжёлых: только метаданные, без трейсов — проекты, пользователи, ключи, промпты. Для соло-проекта реальный расход обычно ниже официального потолка.

Redis/Valkey формально просит меньше всех — 1,5 ГБ, но здесь интуиция подводит: это очередь заданий на BullMQ, а не просто кэш, и в docker-compose.yml для него задана политика noeviction. При упоре в maxmemory Redis не вытесняет ключи, а отклоняет запись ошибкой OOM command not allowed when used memory > 'maxmemory'. Для кэша это не страшно, но здесь в той же памяти — очередь приёма трейсов: переполнение останавливает приём событий.

Web и Worker на Node.js делят одну ловушку: по умолчанию Node.js ограничивает кучу примерно 1,7 ГБ независимо от памяти контейнера — контейнеру досталось 4 ГБ, а Node ограничен 1,7 ГБ, и вы получите проблемы с памятью. Лечится настройкой на обоих контейнерах:

NODE_OPTIONS=--max-old-space-size=3500

— пример для 4 ГБ выделения. Без переменной купленная память просто не используется процессом.

MinIO/S3 спокойнее всех: раздаёт и принимает файлы, а не считает по ним — узкое место диск и сеть, не RAM.

Docker Compose на одной машине против Kubernetes: откуда разные цифры

Сумма из раздела выше — 25,5 ГБ, официальная рекомендация для одной машины — 16 ГБ: дело не в ошибке источника, а в том, что это ответы на разные вопросы.

Минимумы для Kubernetes — гарантированный резерв на под, а не средний расход: планировщик резервирует память заранее, чтобы под не столкнулся с соседями за ресурсы узла. Плюс документация советует держать не меньше двух реплик langfuse-web для отказоустойчивости — ещё около 4 ГБ на дублирование, не нужное на одной машине.

На одной машине через Compose иначе: шесть процессов делят один кэш страниц ядра, диск кэшируется один раз, а не по разу на контейнер, и нет резерва под чужих соседей по узлу. Отсюда цифра скромнее — 4 ядра и 16 ГБ на весь стек.

Вывод простой: если вы не разворачиваете Langfuse в кластере Kubernetes — а большинство self-hosted инсталляций живут на одном сервере — ориентируйтесь на цифру для одной машины, а не на сумму выше.

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

Показательный случай — разбор из открытого обсуждения на GitHub. Пользователь развернул langfuse-worker в Kubernetes со щедрым лимитом памяти — limit: 20Gi — но request: 512Mi, а на CPU и того меньше — request: 100m, десятая часть ядра. Контейнер регулярно уходил в Exited (137).

Разгадка в разнице между request и limit. Limit — потолок, выше которого cgroup убьёт процесс, а request — то, что резервирует планировщик и на что смотрит узел при нехватке памяти: под, использующий намного больше своего request, — первый кандидат на убийство, даже если до limit ещё далеко. Щедрый лимит в 20 ГБ не спас: с резервом в 512 МБ воркер выглядел «маленьким», и его убивали первым.

Ответ разработчиков там же — цифра из их эксплуатации: в облаке Langfuse воркер в продакшне стабильно потребляет около 2,5 ГБ, отсюда рекомендация закладывать под него не меньше 4 ГБ request. Это уже не теоретический минимум из таблицы, а наблюдение с реальной нагрузкой.

После починки памяти всплыла вторая проблема — задания подвисали с ошибкой job stalled more than allowable limit. Причина была не в памяти, а в тех же 100m CPU: воркеру не хватало времени продлевать «замок» на задание в очереди BullMQ. Урок: нехватка памяти на вид иногда на деле нехватка CPU — поднимать стоит оба ресурса вместе.

Если уже сейчас docker inspect langfuse-worker --format='{{.State.OOMKilled}}' отвечает true — это диагностика по факту, ей посвящён отдельный разбор частых ошибок Langfuse; здесь — как подобрать память заранее.

Как нагрузка сама поднимает планку: трейсы без ретеншена и рост ClickHouse

Таблица минимумов описывает старт, а не то, что будет через два месяца. В открытой версии Langfuse нет встроенной автоматической чистки: трейсы, обсервации, оценки и медиафайлы копятся бессрочно, пока не удалите их сами — через API (DELETE /api/public/traces/:traceId или DELETE /api/public/traces списком ID, оба требуют Basic Auth) или cron-скриптом поверх ClickHouse.

В Enterprise-редакции self-hosted есть функция Data Retention, но платная: включается переменной LANGFUSE_EE_LICENSE_KEY на langfuse-web и langfuse-worker, минимальный срок хранения — 3 дня; без лицензии этой настройки в интерфейсе просто нет.

Почему это вопрос про память, а не только про диск: ClickHouse держит недавние данные в кэше, чтобы дашборд отвечал быстро, а не читал диск на каждый клик. Чем больше неочищенных данных, тем больше «рабочего набора» претендует на кэш — и та же ClickHouse, которой хватало 8 ГБ в первый месяц, через полгода без чистки чаще упирается в память.

Нагрузка влияет на память и через настройки воркера: LANGFUSE_INGESTION_QUEUE_PROCESSING_CONCURRENCY управляет числом параллельных заданий — ориентир около 20 на воркер. Поднять значение, чтобы быстрее разгрести очередь после всплеска, соблазнительно, но каждое параллельное задание — память в той же куче Node.js: подняли конкурентность, не подняв NODE_OPTIONS, — получите тот же OOM, что разобран выше.

Практическое правило: память для старта считайте достаточной на определённый объём трафика, а не навсегда. docker stats --no-stream langfuse-worker clickhouse postgres redis раз в неделю дешевле, чем внезапный Exited (137), когда до Langfuse дошёл трафик, который вы и хотели логировать.

Практическая формула: сколько закладывать под свою нагрузку

Сведём сказанное в шкалу для одной машины через Docker Compose — так self-hosted Langfuse запускают чаще всего:

К любому уровню стоит добавить не гигабайты, а три настройки из разделов выше:

• NODE_OPTIONS=--max-old-space-size=<70–85% от памяти контейнера> на langfuse-web и langfuse-worker — иначе часть купленной RAM останется недоступной для Node.js;
• не срезайте maxmemory у Redis ниже 1,5 ГБ — это очередь приёма, а не только кэш, и noeviction при переполнении не деградирует плавно, а останавливает приём новых трейсов;
• не полагайтесь на swap вместо RAM для ClickHouse и Postgres — производительность СУБД на свопе проседает настолько, что проще сразу добавить памяти.

Оговорка по таблице: цифры — стартовая точка. У проекта с редкими тестами и у продакшн-бота с тысячами обращений в день — оба формально «Langfuse для одной команды» — реальный расход разойдётся в разы, как описано в разделе про рост ClickHouse.

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

Сведём цифры статьи в решение: официальный минимум для одной машины — 4 ядра и 16 ГБ — ориентир вендора на разумный запас, а не голая граница выживания.

Честный минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Ниже официальных 16 ГБ — осознанный компромисс: подходит для соло-разработки, тестового контура или маленькой команды с редким потоком трейсов, при условии что вы чистите ClickHouse вручную или не копите данные месяцами. Ниже этой отметки на шесть контейнеров реалистично не заходить: один воркер под нагрузкой просит около 2,5 ГБ, без учёта ClickHouse и Postgres рядом.

Комфортный вариант: 8 vCPU, 16–24 ГБ RAM, 120–150 ГБ NVMe. Ближе к рекомендации Langfuse для single-VM, с запасом: все шесть контейнеров с адекватным NODE_OPTIONS, воркер держит конкурентность без риска OOM при всплесках, ClickHouse не деградирует через пару месяцев накопления трейсов без ретеншена. Продукт логирует каждый вызов LLM в проде — начинать стоит именно с этого варианта, а не приходить к нему после первого падения воркера.

В каталоге приложений MAATRIX Langfuse ставится автоматически при заказе сервера — весь стек из шести контейнеров поднимается сразу настроенным, вручную docker compose up поднимать не нужно. Работает на Ubuntu и Debian; адрес панели и ключи доступа — в личном кабинете, в разделе «Доступ», дальше остаётся прикрутить домен и HTTPS.

Локация — Великобритания (Лондон). В трейсах Langfuse оседают промпты и ответы пользователей — слепок переписки с вашим ИИ-продуктом вместе с персональными данными в ней. Соседство с юрисдикцией GDPR — разумный выбор для команды на европейскую аудиторию, а короткий пинг от серверов приложения в ЕС до сервера с Langfuse заметен на отзывчивости дашборда при частых батчах с трейсами.

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

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