Сколько RAM нужно Telegram-боту: замеры 13 ботов на VPS за 1 ГБ

Сколько оперативной памяти нужно Telegram-боту — вопрос, на который в интернете отвечают одинаково расплывчато: «немного», «хватит самого дешёвого VPS», «гигабайта за глаза». Конкретных цифр почти никто не публикует, поэтому одни покупают 4 ГБ под бота с шестью командами, а другие берут самый дешёвый тариф и всю неделю гадают, не упадёт ли он.

Мы разобрали свежий технический разбор, где автор измерил 13 своих Telegram-ботов на одном VPS: 1 vCPU, 1 ГБ RAM, 24 ГБ NVMe. Ниже — что из этого следует для выбора сервера, без оценок и «примерно», и сколько ботов реально потянет тот или иной тариф (актуальные конфигурации с ценами — в подборке VPS для Telegram-ботов).

Что реально было на машине

Хост — самый скромный из возможных: один виртуальный процессор, гигабайт памяти, NVMe-диск. Важная деталь: система показывает 961 МБ доступной памяти, а не 1024 — часть забирает прошивка и гипервизор. Планировать надо именно от этого числа, а не от того, что написано в тарифе.

На машине работали тринадцать отдельных сервисов: бот-загрузчик медиафайлов, семь демонстрационных и продающих ботов для SaaS-продукта, четыре клиентских бота и одна тестовая копия. Все — на Python, все на длинном опросе (long polling), каждый — отдельный systemd-сервис со своим токеном и своим процессом.

Сколько памяти съедает один бот

Замеры resident set size (RSS) для главного процесса каждого сервиса:

Тринадцать ботов вместе — 185 МБ, в среднем 14,2 МБ на каждого. Вся эта команда помещается в пятую часть гигабайтной машины.

Самое интересное — разброс. Самый лёгкий бот занимает 3,2 МБ, самый тяжёлый — 21 МБ, разница в 6,5 раза. И почти не зависит от количества пользователей: тестовая копия на 3,2 МБ и клиентский бот на 7,4 МБ работают на том же фреймворке, что и SaaS-боты на 17 МБ. Разница — в том, какие библиотеки бот подгружает.

Бот, который только разбирает текстовые команды, тянет библиотеку Telegram и почти ничего больше. Бот, которому нужны HTTP-клиент, драйвер базы, работа с изображениями и SDK платёжного сервиса, платит за каждую из этих зависимостей при старте — независимо от того, вызовет он этот код когда-нибудь или нет. Нижняя граница памяти определяется импортами, а не нагрузкой. Хотите более лёгкого бота — сокращайте список зависимостей, а не число пользователей.

Главная честная оговорка про эти цифры

RSS считает разделяемые страницы памяти один раз на процесс. Тринадцать Python-процессов на одной машине делят между собой многое: сам интерпретатор, libc, одинаковые версии библиотек. Поэтому простое суммирование RSS завышает реальный общий расход — на самом деле вся команда занимает заметно меньше 185 МБ.

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

Самый прожорливый процесс — не бот

Это наблюдение меняет взгляд на маленькие серверы. Если отсортировать ВСЕ процессы на машине по памяти, верхние строчки занимают вовсе не боты:

Один сетевой демон, установленный когда-то и забытый, занимает 162,8 МБ — это 88% от памяти всех тринадцати ботов и примерно одиннадцать «средних ботов». Добавьте сюда node и журнал — и накладные расходы, не связанные с ботами, спокойно превышают весь ботовый парк.

Поэтому ходовой мысленный шаблон перевёрнут. На вопрос «потянет ли мой гигабайтный VPS ещё одного бота?» честный ответ такой: ещё один бот стоит около 14 МБ и почти никогда не является проблемой. Проверять нужно всё, что на машине ботами не является: агент мониторинга, VPN-клиент, среда контейнеров, демон логов без ограничения на размер. Именно там на гигабайтной машине заканчивается память.

Настоящий предел — не память

Отдельно стоит сказать про лимиты. В том замере машина показывала 687 МБ занятой оперативной памяти и 1041 МБ использованного swap — то есть была перегружена по памяти, и давно.

При этом сервер работал 45 дней с load average 0,52 / 0,17 / 0,05, а медиа-бот не перезапускался ни разу. Ничего не падало. Это значит, что значительная часть памяти ушла в swap и больше никогда не читается — простаивающие боты держат аллокации, которые им не понадобятся. На NVMe это разумный компромисс, а не авария, и именно так Linux и должен себя вести.

Но реальный лимит это всё же задаёт. Когда ограничение начнёт проявляться, вы увидите это как задержку, а не как out-of-memory kill: бот, страницы которого выгружены в swap, ответит на первое сообщение после простоя чуть медленнее. На одном vCPU главный риск — несколько ботов, проснувшихся одновременно: общий всплеск упирается в процессор и в подкачку, но это никогда не «проблема нехватки RAM».

Две практические настройки, которые стоит применить на любом маленьком сервере:

• Ограничьте журнал. Неограниченный systemd-журнал растёт, пока не займёт реальную память и место на диске. Ограничение размера — правка в одну строку, а освобождает больше, чем весит бот.
• Поставьте лимиты памяти на каждый сервис. В systemd это делается директивой MemoryMax= в unit-файле: тогда один протекающий бот деградирует сам, а не утаскивает за собой двенадцать соседей.

Один процесс на бота — и почему это оправдано

Тринадцать отдельных сервисов — не самая эффективная схема из возможных. Можно запустить несколько ботов в одном процессе и сэкономить интерпретатор, выиграв, возможно, 100 МБ из 185.

Автор так не делает, и причина простая: 100 МБ — не дефицитный ресурс. Дефицитный ресурс — внимание. Когда клиентский бот падает на плохом обновлении, он падает один. systemd перезапускает только этот сервис, остальные двенадцать ничего не замечают, а журнал точно показывает, кто именно упал. Обменять память, которой хватает, на режим отказа, который придётся разбирать в два часа ночи, — плохая сделка.

Та же логика стоит за выбором длинного опроса вместо вебхуков. Вебхуки эффективнее на масштабе и требуют одного HTTPS-эндпоинта вместо тринадцати открытых соединений. Но им нужны публичный сертификат, обратный прокси и работающая DNS-запись — и каждое из этого может сломаться независимо. Длинный опрос не требует ничего: бот сам стучится наружу, работает за любым файрволом и не нуждается во входящем доступе. При небольших объёмах выбор очевиден; после нескольких сотен сообщений в секунду он меняется на обратный.

Как измерить свой сервер одной командой

Всё вышесказанное не требует специальных инструментов. Чтобы получить такую же таблицу по своему серверу:

systemctl list-units 'tg-*' --state=active --no-legend --plain

Эта команда покажет работающие сервисы. Дальше по каждому: systemctl show -p MainPID --value <unit> даёт PID, а grep VmRSS /proc/<pid>/status — память. И обязательно вторая команда:

ps -eo rss,comm --sort=-rss | head

Именно она показывает всё, что не является ботом, — включая тот самый демон на 162 МБ, о котором вы бы никогда не подумали.

Если вы только выбираете сервер, считайте так: примерно 15 МБ на бота, плюс всё остальное, что планируете установить, — и пусть решение определяет второе число. По этим замерам гигабайтного VPS хватает более чем на тридцать обычных ботов по памяти. Процессор, терпение или забытые фоновые демоны закончатся гораздо раньше, чем оперативная память. Сравнить тарифы с нужным объёмом памяти и диском можно в подборке VPS для Telegram-ботов — там фильтры по RAM, диску и цене.

Сколько ботов брать на один тариф

Практический вывод для аренды сервера простой:

• Один-два простых бота (команды, уведомления, формы) — хватит 512 МБ–1 ГБ RAM. Запас останется даже под системные службы.
• 5–15 ботов в одной инсталляции, включая ботов с базой данных и платежами, — реально укладываются в 1 ГБ RAM при условии, что зависимости не раздуты, а фоновые демоны под контролем.
• Диск важнее памяти: NVMe заметно ускоряет работу с базой и файлами, а при активном swap ещё и сглаживает просадки первого ответа.
• Изоляция важнее экономии: отдельный процесс и автоперезапуск (systemd или Docker с restart: always) стоят дороже ста мегабайт, которые они экономят.

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

А если свой сервер не нужен?

Если считать память, обновлять зависимости и следить за перезапусками не хочется, есть специализированные платформы для ботов. Например, Bothost — российский PaaS для Telegram, Discord и VK-ботов. Тариф Starter (1 бот, 1 vCPU, 256 МБ RAM, 0,5 ГБ SSD) бесплатный, Basic за 99 ₽ в месяц даёт 5 ботов, 1 ГБ RAM и env-переменные, а Pro за 250 ₽ — 20 ботов и 2 ГБ.

По замерам выше 256 МБ с запасом покрывают несколько простых ботов, а 1 ГБ — больше тридцати; на платформе деплой занимает минуты, а сервер администрировать не нужно. Одно честное уточнение: на бесплатном Starter диск обнуляется при перезапуске и env-переменных нет — боту с базой данных или токенами нужен Basic.

Читайте также

• VPS для Telegram-бота: какая конфигурация нужна — минимальные и комфортные требования по CPU и RAM.
• Лучший VPS для Telegram-бота 2026 — подборка тарифов с ценами и дисками.
• Как задеплоить Telegram-бота на VPS — systemd, Docker и вебхуки пошагово.
• VPS или хостинг ботов: что выбрать — когда сервер избыточен.

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

Сколько RAM нужно Telegram-боту?

На разобранном сервере длиннополлинговый Python-бот занимает от 3 до 21 МБ resident-памяти, в среднем 14,2 МБ по тринадцати ботам. Разброс объясняется тем, какие библиотеки бот импортирует, а не числом пользователей: HTTP-клиент, драйвер базы и медиабиблиотека стоят на старте дороже, чем любая нагрузка в рантайме. Подобрать тариф под нужный объём — подборка VPS для Telegram-ботов.

Можно ли запустить несколько ботов на одном VPS с 1 ГБ?

Да. Тринадцать ботов в разобранном примере занимают 185 МБ в сумме — меньше пятой части машины. Память редко становится узким местом: первыми сдаются один vCPU при одновременных всплесках и демоны, не связанные с ботами.

Нужен ли отдельный сервер для каждого бота?

Нет. Каждому боту нужен свой процесс и свой токен, но один хост спокойно держит много ботов. Отдельный systemd-сервис на каждого даёт изоляцию сбоев, не требуя покупать отдельные серверы.

Что выбрать — длинный опрос или вебхуки?

Длинный опрос дешевле и гораздо проще: не нужно публичного эндпоинта, сертификата, обратного прокси, и он работает за любым файрволом, потому что бот стучится наружу сам. Вебхуки выигрывают при высокой нагрузке и готовой инфраструктуре с публичным доменом.

Почему бот может отвечать с задержкой на маленьком VPS?

Чаще всего из-за вытеснения памяти в swap: бот, чьи страницы давно не использовались, при первом сообщении после простоя подтягивает их обратно. На NVMe это доли секунды, но на медленном диске задержка заметна. Лечится лимитами памяти на сервисы и ограничением размера журнала.

_Статья подготовлена по материалам технического разбора «13 Telegram Bots on a $4.17 VPS: The Real RAM Numbers» (charliemorrison.dev). Цифры замеров приведены по источнику; цены и тарифы сверяйте в каталоге на дату чтения. Редакция ServerScan._