Экономика телеграм-бота: от 100 до 100 000 пользователей

MAATRIX

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

Почему нельзя просто умножить пользователей на стоимость одного

Первая ошибка при прикидке бюджета — считать линейно: «один пользователь стоит X рублей инфраструктуры, значит 10 000 пользователей стоят 10 000×X». Так не работает по двум причинам.

Во-первых, инфраструктура телеграм-бота не масштабируется гладко — она масштабируется ступенями. На 100 пользователей всё живёт в одном процессе на одном сервере: код бота, SQLite-файл или локальный Postgres, редкие обращения к внешнему API. На 10 000 в один процесс уже не помещается — нужно выносить БД отдельно, добавлять очередь задач, следить за лимитами Telegram API. На 100 000 меняется сам подход: один обработчик апдейтов заменяется несколькими, появляется кеш перед базой, база переезжает на отдельный сервер с более серьёзными дисками. Каждая такая ступень — это не постепенное подорожание, а разовый скачок в архитектуре и в счёте.

Во-вторых, стоимость сильнее зависит не от числа пользователей, а от того, что бот с ними делает. Бот-справочник, который отвечает готовыми текстами из базы, и бот, который на каждое сообщение дёргает LLM или обрабатывает фото — это два совершенно разных профиля нагрузки при одинаковом числе подписчиков. Дальше в статье будем разбирать оба сценария отдельно, потому что усреднять их бессмысленно.

Методика: как оценить реальную нагрузку по числу пользователей

Прежде чем считать сервер, нужно превратить «число пользователей» в понятную инженеру величину — запросы в секунду и объём данных. Делается это через три параметра.

DAU (Daily Active Users) — процент от общей базы, который реально пишет боту в течение дня. Для телеграм-ботов типичная доля активных — от 10% до 40% от общего числа подписчиков, но это сильно зависит от типа бота: у бота с ежедневной рассылкой или игровым циклом DAU выше, у бота «спросил один раз и забыл» — ниже. Точную цифру для вашего бота даст только реальная статистика, но для прикидки на старте разумно ориентироваться на 15-25% как консервативную оценку.

Среднее число сообщений на активного пользователя в день. Простой бот-справочник — это обычно 2-5 сообщений на активного пользователя (спросил — получил ответ). Бот с диалогом, играми или многошаговыми сценариями — может быть 15-30 и больше.

Пиковая концентрация нагрузки. Пользователи не пишут боту равномерно 24 часа в сутки — есть часы пик (обычно вечер по местному времени аудитории), на которые может приходиться 20-30% всей суточной нагрузки. Считать нужно не среднюю нагрузку в секунду, а пиковую, иначе сервер, который в среднем справляется, будет захлёбываться каждый вечер.

Формула для прикидки:

DAU = Всего_пользователей × Доля_DAU
Сообщений_в_сутки = DAU × Сообщений_на_пользователя
RPS_средний = Сообщений_в_сутки / 86400
RPS_пиковый ≈ RPS_средний × 6..10   (эмпирический коэффициент пиковой концентрации)

Оговорка сразу: коэффициент 6-10 — это ориентир, а не измеренная константа. У бота с аудиторией в одном часовом поясе пик будет острее, у бота с международной аудиторией — более размазанным по времени. Первую неделю после запуска стоит логировать реальное распределение сообщений по часам и подставлять в формулу свои цифры, а не чужие ориентиры.

Дальше разбираем три масштаба: ~100, ~10 000 и ~100 000 пользователей — и для каждого считаем, что меняется в архитектуре и в расходах.

Масштаб 1: ~100 пользователей — всё в одном месте

При 100 пользователях даже с оптимистичным DAU в 25% и активным профилем в 15 сообщений в день на человека получаем:

DAU = 100 × 0.25 = 25
Сообщений в сутки = 25 × 15 = 375
RPS средний = 375 / 86400 ≈ 0.004
RPS пиковый ≈ 0.03

Это исчезающе малая нагрузка — меньше одного запроса в 20-30 секунд даже в пике. На таком масштабе любой самый дешёвый VPS с 1 vCPU и 1-2 ГБ RAM справляется без всякого напряжения, и узкое место — не сервер, а то, что бот вообще делает при обработке сообщения.

Архитектура на этом масштабе:

• Сервер: один самый младший VPS. Достаточно 1 vCPU, 1-2 ГБ RAM, 20-25 ГБ диска (в основном под систему, логи и Python-окружение с зависимостями). Раздел про то, сколько ресурсов реально нужно VPS для телеграм-бота, разбирает это подробнее.
• База данных: SQLite-файл рядом с кодом бота или локальный Postgres/MySQL на том же сервере — отдельный сервер БД не нужен, накладные расходы на сетевые запросы к своей же базе на этом объёме только замедлят дело.
• Очередь задач: не нужна. Если бот не генерирует ничего тяжёлого (видео, документы, LLM-ответы), обработка каждого сообщения занимает миллисекунды-десятки миллисекунд, и синхронной обработки в одном процессе достаточно.
• Внешние API: если бот дёргает платный API (например, LLM) — на этом объёме сообщений расход по API обычно меньше стоимости самого сервера, но его всё равно стоит считать отдельно от инфраструктуры (см. ниже методику расчёта стоимости LLM-запросов).

Единственная реальная статья расходов здесь — сам VPS, и она минимальна. Дальше на этом масштабе можно спокойно жить месяцами, если аудитория растёт медленно — архитектуру не нужно менять, пока нагрузка не приблизится на порядок к следующей ступени.

Масштаб 2: ~10 000 пользователей — база отдельно, возможна очередь

Пересчитаем по той же формуле, но с более активным профилем — 10 000 пользователей уже подразумевает, что бот делает что-то содержательное, а не просто отвечает заготовками:

DAU = 10 000 × 0.2 = 2000
Сообщений в сутки = 2000 × 10 = 20 000
RPS средний = 20 000 / 86400 ≈ 0.23
RPS пиковый ≈ 1.5-2

Полтора-два запроса в секунду в пике — это уже нагрузка, которую один процесс на слабом сервере может держать с задержками, особенно если каждый запрос сопровождается обращением к базе или внешнему API. Здесь начинают проявляться первые архитектурные швы.

Сервер. Нужен VPS помощнее: 2-4 vCPU, 4-8 ГБ RAM. Логика бота (webhook-обработчик или long polling) и веб-сервер (если используется webhook через FastAPI/aiohttp) занимают заметную часть ресурсов сами по себе, не считая обработки запросов. Стоит заранее определиться с webhook или polling — от этого зависит и профиль нагрузки, и то, как бот ведёт себя при рестарте.

База данных. На этом объёме локальная SQLite или Postgres «рядом с кодом» начинают мешать друг другу — миграции, бэкапы и высокая частота записи (история диалогов, статистика) конкурируют за диск с самим ботом. Разумный шаг — вынести базу на отдельный процесс с собственным диском, даже если физически это ещё тот же сервер, а лучше — на отдельный небольшой VPS (1-2 vCPU, 2-4 ГБ RAM для Postgres с 10 000 активных записей вполне достаточно). Архитектурный разбор такого разделения — в статье бот с базой данных PostgreSQL: архитектура.

Очередь задач. Если у бота есть операции дороже простого текстового ответа — генерация изображений, вызов LLM с ожиданием в несколько секунд, обработка загруженных файлов — на 10 000 пользователей такие операции уже могут накладываться друг на друга и блокировать обработчик. Здесь оправдана очередь (Celery + Redis, RQ или аналог): бот принимает сообщение, кладёт тяжёлую задачу в очередь и сразу отвечает пользователю «обрабатываю», а результат приходит отдельным сообщением, когда воркер закончит. Без очереди при параллельных тяжёлых запросах бот либо тормозит для всех, либо падает по таймауту у части пользователей — типичный сценарий разобран в статье очередь задач росла, пока не встало всё.

Внешние API. Если это LLM-бот, посчитайте отдельно стоимость по токенам: 20 000 сообщений в сутки при среднем диалоге в несколько сотен токенов на входе и выходе может складываться в заметную ежемесячную сумму, которая на этом масштабе часто превышает стоимость самого сервера. Точную методику расчёта см. в статье как считать стоимость LLM-запросов на своём сервере — там же честно оговорено, что цифры сильно зависят от модели и длины диалога, и усреднённые оценки без учёта вашего конкретного промпта не работают.

Итоговая структура расходов на этом масштабе — уже не один VPS, а связка: сервер под бота, сервер (или отдельный ресурс) под базу, опционально Redis для очереди, плюс переменная статья на внешние API, если они есть. Стоимость инфраструктуры без учёта API обычно кратна стоимости первого масштаба в 3-5 раз, а не в 100 раз — рост нагрузки не линеен по отношению к росту пользователей, потому что первая ступень была сильно недогружена.

Масштаб 3: ~100 000 пользователей — горизонтальное масштабирование и кеш

На третьей ступени формула даёт уже серьёзные цифры:

DAU = 100 000 × 0.2 = 20 000
Сообщений в сутки = 20 000 × 8 = 160 000
RPS средний = 160 000 / 86400 ≈ 1.85
RPS пиковый ≈ 12-18

12-18 запросов в секунду в пике — цифра, которую один процесс на одном сервере уже физически не тянет стабильно, особенно если каждый запрос требует обращения к базе и внешнему API с задержкой в сотни миллисекунд. На этом масштабе меняется сам подход к архитектуре.

Обработчики бота. Вместо одного процесса — несколько воркеров, каждый из которых обрабатывает свою долю входящего потока апдейтов. Для webhook-схемы это несколько процессов за балансировщиком (nginx или встроенный балансировщик хостинга), для long polling — придётся переходить на webhook, потому что long polling принципиально плохо горизонтально масштабируется (все воркеры конкурируют за один и тот же поток обновлений от Telegram).

Кеширование. На этом объёме запросов часть данных — профиль пользователя, его настройки, состояние диалога — стоит держать в Redis, а не дёргать основную базу на каждое сообщение. Это снимает существенную долю нагрузки с БД и снижает задержку ответа.

База данных. На 100 000 пользователей база почти всегда переезжает на отдельный сервер с более серьёзными дисками (SSD/NVMe обязательны, не сетевой медленный диск) и большим объёмом RAM под кеш страниц самой СУБД. Здесь же встаёт вопрос реплик для чтения, если аналитика и отчёты начинают конкурировать с основной нагрузкой бота за ресурсы базы.

Сервер(ы): ориентировочно 2-3 инстанса под сами обработчики (4-8 vCPU, 8-16 ГБ RAM каждый, конкретное число зависит от того, сколько CPU-времени тратит одна обработка сообщения) плюс отдельный сервер под базу (4-8 vCPU, 16-32 ГБ RAM, приоритет — быстрый диск) плюс Redis (может жить на небольшом VPS отдельно или даже на том же сервере, что балансировщик, если ресурсов хватает).

Внешние API. Если это LLM-бот, на 160 000 сообщений в сутки расходы на токены почти наверняка станут основной статьёй бюджета, превышающей всю инфраструктуру вместе взятую. На этом масштабе имеет смысл считать unit-экономику по каждому активному пользователю в месяц и сравнивать её с монетизацией бота — иначе рост аудитории превращается в рост убытков, а не выручки.

Как считать разные типы ботов по-разному

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

Лёгкий бот (справочник, FAQ, простые команды, ответы из готовой базы без обращения к внешним сервисам). Время обработки одного сообщения — единицы-десятки миллисекунд. Такой бот может держать 100 000 пользователей почти на той же конфигурации, что и 10 000, потому что узкое место — не CPU, а пропускная способность сети и число одновременных соединений, а это дёшево масштабируется.

Средний бот (диалог с состоянием, обращение к базе на каждое сообщение, возможно один вызов внешнего API без генерации). Время обработки — десятки-сотни миллисекунд. Это профиль, для которого и написаны расчёты выше — он неплохо описывается формулой RPS и стандартными ступенями масштабирования.

Тяжёлый бот (генерация текста через LLM, обработка изображений, распознавание речи, любая операция с ожиданием в секунды). Здесь сообщения в секунду — не главная метрика, важнее количество одновременных долгих операций, которое сервер может держать параллельно. Даже 1000 активных пользователей с тяжёлым профилем могут упереться в лимиты раньше, чем 50 000 пользователей лёгкого бота. Для таких ботов очередь задач нужна практически с первого дня, а не с 10 000 пользователей, и расчёт стоимости должен строиться не от числа пользователей, а от числа параллельных генераций, которое реально нужно поддерживать.

Из этого следует главный практический вывод: прежде чем считать сервер под конкретное число пользователей, определите профиль своего бота и замерьте (не оцените, а именно замерьте на реальном трафике или нагрузочном тесте) среднее время обработки одного сообщения. Разница между 20 мс и 2000 мс на обработку — это разница на два порядка в требуемых ресурсах при одинаковом числе пользователей.

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