Все статьи
Экономика10 минутОбновлено 27 сентября 2026 г.

Сколько стоит Telegram-бот на нейросети

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

Из чего складывается счёт: три множителя и формула

Счёт бота определяют три множителя: модель с её ставками входа и выхода, объём контекста каждого запроса и длина ответов. Формула одного диалога такая: входные токены по ставке входа плюс выходные токены по ставке выхода, всё делённое на миллион; месячный итог — сумма по всем диалогам. Выходные токены обычно дороже входных в разы, поэтому болтливый бот с короткими вопросами и длинными ответами стоит заметно дороже сдержанного при том же числе диалогов. Считать надо весь workflow месяца, а не одно «среднее сообщение»: медиана скрывает дорогие хвосты.

Числовой пример — сначала в токенах, потому что токены ваши, а ставки общие. Возьмём диалог: системный промпт 800 токенов, история переписки 2 000, новый вопрос пользователя 200 — итого 3 000 входных; ответ бота 400 выходных. Проверка арифметики с условными ставками, которые не являются тарифами: допустим, вход — 2 условные единицы за миллион, выход — 8. Тогда диалог стоит 3 000 × 2 / 1 000 000 плюс 400 × 8 / 1 000 000 — это 0,006 плюс 0,0032, итого 0,0092 условной единицы. Подставьте вместо них ставки своей модели из каталога — масштаб и пропорции не изменятся: вход тянет объёмом, выход — ценой.

История диалога — скрытый множитель, который новички не закладывают. Каждый запрос бота несёт хвост переписки: десятый запрос диалога дороже первого в разы при том же размере нового вопроса, потому что оплачивается весь переданный контекст целиком. Быстрый тест на своих данных: сравните стоимость первого и пятнадцатого сообщения типового диалога из истории — разница и есть цена «памяти», которую платит каждое обращение. Отсюда правило замера: считайте медиану и верхний перцентиль полного входа по реальным диалогам из истории кабинета, а не размер одного вопроса в вакууме. Бот с «бесконечной памятью» без окна истории — это счёт, растущий с каждым сообщением пользователя.

Параметр max_tokens — одновременно качество и аварийный тормоз. Он ограничивает длину ответа и тем самым верхний перцентиль счёта: даже сорвавшаяся в многословие модель не уйдёт за предел. Слишком низкий предел срезает ответы на полуслове и плодит уточняющие запросы, которые стоят дороже сэкономленного, — баланс подбирается под задачу: короткие справки — низкий, разборы и код — выше. Отдельно задайте timeout клиента и промежуточное сообщение «Думаю…» с последующим редактированием: долгие запросы упираются в таймауты Telegram, а повтор по таймауту оплачивается дважды.

Системный промпт — налог на каждый запрос: каждые его символы оплачиваются в каждом обращении бота. Инструкция на тысячу токенов при тысяче диалогов — это миллион оплаченных входных токенов за месяц только за «характер» бота. Держите промпт коротким и по делу, а тяжёлое — регламенты, прайсы, документы — подавайте по требованию, а не в каждом запросе. Разница между «бот знает всё всегда» и «бот подтягивает нужное» видна в счёте уже в первый месяц.

Что ещё попадает в счёт помимо диалогов. Повторы после ошибок и зацикленные агентские вызовы накручивают токены молча — retry положен только временным ошибкам, а не неверному ключу или пустому балансу. Streaming ответов на цену не влияет: те же токены, та же формула, другой способ доставки. Голосовые транскрипция и синтез, генерация картинок считаются по своим тарифам, а не по token-ставкам текстовой модели, — закладывайте их отдельными строками. И помните: ноль активности — ноль расходов, pay-as-you-go не знает абонентской платы, поэтому считать надо факт из истории, а не прогноз из головы.

  • формула: вход по ставке входа плюс выход по ставке выхода, делённые на миллион
  • история диалога делает поздние запросы дороже ранних в разы
  • max_tokens ограничивает верхний перцентиль счёта
  • системный промпт оплачивается в каждом запросе
  • retry, голос и картинки — отдельные строки счёта

Три сметы: личный бот, поддержка, ассистент команды

Метод смет одинаковый, подставляйте свои цифры. Для каждого сценария считаем месячный объём токенов — диалоги, умноженные на вход и выход, — затем применяем формулу со ставками модели из каталога и сверяем с калькулятором на странице моделей. Итоги ниже — порядки с пометкой «пример», а не тарифы: точные ставки живут недели, объёмы токенов ваши и проверяются историей кабинета. Сценарии идут от дешёвого к дорогому, и главный вывод спойлером: выбор модели двигает итог сильнее всех оптимизаций вместе взятых.

Сценарий первый — личный бот для себя: 30 диалогов в месяц, короткие вопросы, окно истории в пять сообщений, младшая модель. Объём: 30 × 1 500 входных — 45 тысяч, плюс 30 × 250 выходных — 7,5 тысячи токенов за месяц. Порядок итога на младшей модели — доли доллара в месяц, пример: меньше, чем комиссия за одно пополнение. Вывод: личный бот — самая дешёвая строка любого бюджета, оптимизировать здесь нечего; единственный риск — забыть окно истории, и тогда «бот для себя» начнёт есть как поддержка.

Сценарий второй — поддержка на 1 000 диалогов в месяц: типовой вопрос с контекстом заказа, средний диалог — 3 000 входных и 400 выходных токенов. Объём: 3 миллиона входных плюс 400 тысяч выходных за месяц. Порядок итога на младшей модели — единицы долларов в месяц, пример; тот же объём на флагмане — на порядок выше, десятки, пример. Разница в порядок — только выбором модели, без смены архитектуры, промптов и истории. Отдельно закладывайте пиковые дни: средняя тысяча диалогов обычно распределена неравномерно, и лимиты должны держать пик, а не среднее, — иначе бот ляжет в день акции. Вывод: для поддержки сначала выбирается класс модели под допустимое качество, и только потом оптимизируется всё остальное.

Сценарий третий — админ-ассистент команды: 300 диалогов в месяц, но с документами в контексте — регламенты, переписка, таблицы; средний диалог — 6 000 входных и 800 выходных токенов. Объём: 1,8 миллиона входных плюс 240 тысяч выходных. Порядок итога — от единиц до десятков в месяц в зависимости от класса модели, пример. Разумная схема — разделение: рутинные справки отвечает младшая модель, разборы конфликтов и сводки — средняя или старшая, итог тогда ближе к нижней границе. Вывод: длинные контексты любят разделение моделей, а не единую «самую умную на всё».

Что сильнее всего двигает итог — по убыванию. Класс модели: разы и порядки, главный рычаг. Окно истории: двух-трёхкратная разница между «вся переписка» и «последние пять сообщений с суммаризацией». Число диалогов: линейно, без сюрпризов. Длина ответов через max_tokens: до двукратной разницы между болтливым и сдержанным ботом. Что почти не двигает: длина системного промпта после разумного минимума и retry при корректных настройках. Оптимизируйте сверху вниз по этому списку — не наоборот.

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

  • личный бот: десятки тысяч токенов — доли доллара, пример
  • поддержка 1 000 диалогов: миллионы токенов — единицы на младшей, десятки на флагмане, пример
  • ассистент с документами: разделение моделей держит итог у нижней границы
  • рычаги по силе: модель, окно истории, число диалогов, длина ответов
  • свой кейс — медиана и p95 из истории через калькулятор

Как удержать бюджет: лимиты, окно, разделение

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

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

Третий рубеж — разделение моделей по сложности. Дефолтный маршрут — младшая модель: приветствия, FAQ, классификация обращений, короткие справки. Сложные разборы, жалобы и генерация документов — средней или старшей. Простейший роутер — правила по длине и теме; продвинутый — классификатор первым проходом на младшей модели. Ошибка новичка — единая флагманская модель «на всё, чтобы точно хорошо»: качество FAQ от неё не растёт, а счёт — в разы.

Четвёртый рубеж — наблюдаемость. История списаний в кабинете должна показывать, сколько стоит бот по дням и направлениям: прод, тесты, эксперименты — на разных ключах, иначе разбор счёта превращается в гадание. Триггер для разбора — рост более чем на треть без роста аудитории: обычно это забытый цикл, разъехавшееся окно истории или чужой ключ в логах. Разбор занимает вечер: история по ключам, медианы входа и выхода, один вопрос себе — что изменилось.

Пятый рубеж — дисциплина запросов. Разумный max_tokens под задачу, timeout клиента, промежуточное «Думаю…» с редактированием сообщения против таймаутов Telegram, повтор только временных ошибок с backoff — не 401, не 403 и не пустого баланса. Ключ — только на backend в переменных окружения, никогда в клиенте, мини-приложении или репозитории: извлечённый ключ Telegram-бота тратят за часы, потому что боты легко находятся поиском. При подозрении на утечку — отозвать и перевыпустить сразу.

Короткие ответы на частые вопросы. Хватит ли бесплатного доступа навсегда? Нет: триал-кредиты покрывают знакомство, постоянной бесплатной нагрузки не бывает. Где считать точнее всего? Калькулятор на странице моделей по своим медиане и перцентилю из истории — точнее любых чужих смет, включая эту статью. Когда пересматривать схему? Раз в квартал или по триггерам: рост счёта, смена тарифов, новое поколение моделей, требования к документам. Итог: бот стоит столько, сколько насчитала формула, — измеряйте свои токены, держите четыре рубежа, и счёт останется строкой, а не сюрпризом.

  • отдельный ключ с лимитом трат и rate limit на пользователя
  • окно истории или суммаризация вместо полной переписки
  • простое — младшей модели, сложное — старшей
  • история списаний по ключам и разбор при росте более чем на треть
  • ключ только на backend, повтор только временных ошибок

Источники и связанные страницы

Следующий шаг

Открыть эту статью в Markdown

Следующий материалКак безопасно хранить API-ключи для AI-сервисов