Сколько RAM нужно для LiteLLM Gateway

MAATRIX

LiteLLM Proxy выглядит лёгким: это же просто прослойка между вашим кодом и чужими API. Потом контейнер уходит в Exited (137) на сервере с гигабайтом памяти, и вопрос «сколько RAM нужно» становится срочным. Ниже — разбор потребления по компонентам, замеры RSS, формула под свою нагрузку и честные пороги: где хватит 2 ГБ, а где придётся брать 4.

Короткий ответ и почему требования LiteLLM к RAM путают с Ollama

Половина вопросов про требования LiteLLM к RAM приходит от людей, которые перепутали шлюз с локальным инференсом. LiteLLM Gateway не запускает модели. Он принимает запрос в формате OpenAI, переписывает его под нужного провайдера, отправляет наружу и стримит ответ обратно. Ни весов, ни VRAM, ни GPU. Сервер под модель, которая крутится у вас, — другая задача и другие цифры: там речь про десятки гигабайт.

Память шлюза уходит на другое: Python-процесс с десятками импортированных SDK, воркеры uvicorn, базу под виртуальные ключи и учёт расходов, кэш и буферы активных запросов. Отсюда рабочие пороги:

Дальше — откуда эти числа берутся, а не «на глаз».

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

Разложим потребление по слагаемым. Цифры — с установки на Ubuntu 24.04, Python 3.12, Docker, образ ghcr.io/berriai/litellm:main-stable, 12 моделей в config.yaml.

• Импорт самого пакета — 250–270 МБ. LiteLLM тянет за собой openai, anthropic, httpx, tiktoken, pydantic, tokenizers, а в ряде сборок ещё и boto3. Это цена входа, до единого обработанного запроса.
• FastAPI + uvicorn + роуты прокси — плюс 40–60 МБ. Сюда же схемы pydantic, которых в проекте несколько сотен.
• Карта цен и контекстов — 20–40 МБ. Файл model_prices_and_context_window.json весит несколько мегабайт на диске, но в виде словарей Python разрастается в разы.
• Каждый дополнительный воркер — плюс 330–380 МБ. Воркеры uvicorn — отдельные процессы, а не потоки. Copy-on-write делит часть страниц, но интерпретатор и словари расходятся по копиям.
• Prisma на старте — пик 400–500 МБ на 30–60 секунд. Образ litellm-database и запуск с DATABASE_URL дёргают Node, чтобы сгенерировать клиент и накатить схему. Разовый всплеск, но именно он убивает гигабайтные машины.
• PostgreSQL 16 с настройками по умолчанию — 150–250 МБ. shared_buffers = 128MB плюс по 5–10 МБ на бэкенд-соединение.
• Redis 7.2 под кэш ответов — 25–40 МБ на 10 тысяч ключей.
• Буферы активных запросов. Стрим с промптом на 8k токенов держит около 1,5 МБ: тело запроса, список сообщений, нагрузка провайдера, копия для логирующего callback. Контекст на 200k токенов даёт пик 30–40 МБ на время обработки.

Отдельная строка — встроенный кэш. Если в конфиге стоит cache: true без указания типа, LiteLLM держит его в памяти процесса и растит ровно до тех пор, пока хватает RAM.

Замеры: сколько ест LiteLLM на самом деле

Не верьте оценкам, включая эти: померьте у себя, это три команды.

Стоимость импорта отдельно от всего остального:

/usr/bin/time -v python3 -c "import litellm" 2>&1 | grep "Maximum resident"
	Maximum resident set size (kbytes): 268412

262 МБ — только чтобы загрузить библиотеку. Дальше смотрим живой контейнер:

docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"
NAME          MEM USAGE / LIMIT     MEM %
litellm       598.4MiB / 3.844GiB   15.20%
litellm-db    186.1MiB / 3.844GiB   4.73%
litellm-redis 28.7MiB / 3.844GiB    0.73%

598 МБ у шлюза в покое после сотни запросов, суммарно со стеком — около 815 МБ. Это один воркер. При запуске с --num_workers 4 в docker stats увидите примерно 1,9 ГБ, но реальная нагрузка на систему ниже: часть страниц общая. Честную цифру даёт PSS:

apt install -y smem
smem -k -P litellm -t | tail -1
                                     1.1G     1.4G     1.9G

Разница между RSS (1,9 ГБ) и PSS (1,4 ГБ) — те самые общие страницы: планировать лучше по RSS с запасом, а при подсчёте «влезет ли» смотреть на PSS.

Проверить, что процесс жив и отвечает: curl -s http://127.0.0.1:4000/health/readiness | python3 -m json.tool.

Главный вывод замеров: число моделей в конфиге на память почти не влияет. Разница между 5 и 60 записями в model_list — меньше 15 МБ. Память едят воркеры и одновременные запросы, а не каталог моделей.

Почему гигабайтный сервер падает при старте

Самый частый сценарий: сервер с 1 ГБ, всё поднимается, а через минуту контейнер мёртв. Проверяем причину:

docker inspect litellm --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
true 137

Код 137 — это 128 + 9, то есть SIGKILL. Кто именно убил, видно в ядре:

dmesg -T | grep -i "killed process"
[Tue Aug 18 04:12:57 2026] Out of memory: Killed process 2231 (litellm) total-vm:2984512kB,
anon-rss:1391204kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:3204kB oom_score_adj:0

anon-rss 1,39 ГБ на машине с гигабайтом — это пик, а не стабильное потребление. В логах контейнера последняя строка обычно Running Prisma migrate deploy..., и дальше тишина. Шлюз убивают не запросы пользователей, а разовая генерация клиента Prisma на старте.

Что с этим делать, по порядку предпочтения:

1. Накатить схему один раз и запретить трогать её при каждом старте. После первой успешной миграции добавьте DISABLE_SCHEMA_UPDATE=True в окружение контейнера. Старт перестаёт дёргать Node — пик уходит.
2. Вынести Postgres на отдельную машину. На гигабайтном VPS локальная БД съедает пятую часть памяти и конкурирует со шлюзом за страничный кэш.
3. Добавить swap как страховку, а не как решение. fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, затем sysctl -w vm.swappiness=10. Стартовый пик переживёт, но если в свап уедут рабочие страницы, задержка первого токена вырастет на сотни миллисекунд. Это временный костыль — подробнее в разборе про нехватку RAM.
4. Отказаться от БД совсем, если виртуальные ключи и учёт расходов не нужны. Без DATABASE_URL LiteLLM работает как чистый прокси на статическом master_key, и 1 ГБ хватает с запасом.

Если симптомы другие — не OOM, а таймауты и отвалы провайдеров, — смотрите разбор частых ошибок LiteLLM.

Формула расчёта под свою нагрузку

Считать надо не «по опыту», а по слагаемым:

RAM ≈ 300 МБ (общая база) + N × 350 МБ (воркеры) + C × S (одновременные запросы) + БД и кэш

Где N — число воркеров, C — пик одновременных запросов, S — средний размер запроса в памяти (1,5 МБ при промптах до 8k токенов, 10–15 МБ при 32k, 30–40 МБ при 200k).

Три сценария:

• Один разработчик, 3–5 клиентов, промпты до 8k. N=1, C=10. Получаем 300 + 350 + 15 = 665 МБ плюс Postgres 200 МБ. 2 ГБ — с запасом, 1 ГБ — впритык и без БД.
• Команда 20 человек, IDE-плагины и пара ботов, есть длинные контексты. N=2, C=40, среди них 5 запросов по 32k. Получаем 300 + 700 + 60 + 65 = 1,1 ГБ плюс БД и Redis 240 МБ. 4 ГБ: 2 ГБ формально проходят, но на всплеске упрётесь.
• Прод, 150–300 rps, агенты с большими контекстами. N=4–8, C=200+. Здесь уже 3–5 ГБ только на шлюз, плюс отдельная БД. 8–16 ГБ, а лучше два инстанса за балансировщиком с общим Redis.

Про CPU важная поправка: упираются в него чаще, чем в память. Шлюз в основном ждёт сеть, но подсчёт токенов через tiktoken и сериализация JSON — работа процессора. На 1 vCPU один воркер выдаёт порядка 60–80 нетяжёлых запросов в секунду, дальше растёт задержка на самом прокси. Правило: воркеров не больше, чем vCPU. Четыре воркера на двух ядрах съедят 1,4 ГБ и не добавят пропускной способности. И помните, что часть отказов под нагрузкой приходит от провайдера, а не от вас — про это разбор ошибки 429.

Как ужать потребление без потери функций

От самого эффективного к косметике.

Уберите отладочные логи. Переменная LITELLM_LOG=ERROR вместо DEBUG — это не только про диск. В режиме отладки каждый запрос и ответ сериализуются целиком ещё раз, на длинных контекстах это ощутимый прирост пикового RSS.

Вынесите кэш в Redis. Локальный кэш в памяти процесса не имеет верхней границы и не делится между воркерами:

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: 127.0.0.1
    port: 6379
    ttl: 3600
  drop_params: true

И ограничьте сам Redis, чтобы он не съел машину: maxmemory 256mb и maxmemory-policy allkeys-lru в /etc/redis/redis.conf.

Отключите загрузку карты цен из сети. LITELLM_LOCAL_MODEL_COST_MAP=True заставляет брать её из установленного пакета: минус несколько десятков мегабайт на старте и защита от зависания инициализации при недоступном raw.githubusercontent.com.

Подрежьте Postgres, если он на той же машине. В postgresql.conf: shared_buffers = 64MB, max_connections = 50, work_mem = 4MB. Для учёта расходов достаточно, а по умолчанию база резервирует больше.

Поставьте жёсткий потолок. В systemd-юните — MemoryMax=1500M и MemoryHigh=1200M, в docker-compose — mem_limit: 1500m. Тогда при утечке умрёт шлюз, а не SSH-сессия и не база. Текущее потребление — systemctl show litellm -p MemoryCurrent.

Одна строка, о которой почти не пишут: MALLOC_ARENA_MAX=2 в окружении. glibc заводит отдельные арены под потоки, и на многоядерной машине это раздувает виртуальную память и фрагментирует кучу. На восьмиядерном сервере ограничение арен снимало у нас 120–180 МБ RSS без каких-либо последствий для скорости.

И про безопасность заодно: порт 4000 наружу открывать не нужно. Забиндьте шлюз на 127.0.0.1:4000, поставьте перед ним Caddy или Nginx с TLS, откройте только ufw allow 443/tcp и ufw allow 22/tcp. Открытый в интернет LiteLLM без master_key находят сканерами за часы — и проблемой станет не RAM, а счёт от провайдера.

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

Начнём с локации, потому что для шлюза она важнее конфигурации. LiteLLM ходит к OpenAI, Anthropic и Google, а все трое отсекают запросы с российских адресов. Базовый выбор — US, Нью-Йорк: чистый IP и короткий маршрут до их эндпоинтов. Если потребители в Европе, разумны Франция или Лондон: пинг до пользователей ЕС ниже, а прибавка до американских API теряется на фоне времени генерации. Локация RU для шлюза к зарубежным моделям не подходит — придётся городить вторую прослойку, лишнее звено, которое ломается.

Теперь честно про конфигурации.

Минимум — 2 vCPU / 2 ГБ / 20 ГБ NVMe. Рабочий вариант для одного разработчика или небольшой команды: шлюз в один воркер, Postgres рядом, Redis под кэш. В покое — около 900 МБ, гигабайт остаётся на всплески. Диска хватает надолго, но следите за таблицей LiteLLM_SpendLogs: на активном использовании она растёт на сотни мегабайт в месяц, старые записи стоит чистить по расписанию.

Комфорт — 4 vCPU / 4 ГБ / 40 ГБ NVMe. Здесь можно держать 2–4 воркера, длинные контексты, callbacks в Langfuse и не думать о памяти вообще. Советуем её по умолчанию: разница в цене с 2 ГБ невелика, а запас снимает целый класс проблем.

Брать 1 ГБ ради экономии не советуем прямо: формально шлюз там запускается, но миграция схемы или всплеск запросов кладёт его в OOM, и на диагностику уйдёт больше, чем сэкономлено. 8 ГБ и выше нужны при сотнях запросов в секунду — до этого деньги полезнее вложить в резервный инстанс во второй локации.

Если начинаете с нуля, поможет пошаговая установка LiteLLM на VPS. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT: зарубежная карта для американской площадки не нужна. Не уверены в конфигурации — напишите профиль нагрузки (сколько человек, какие контексты, нужен ли учёт расходов), подберём без переплаты.

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