В этой статье разберём, во сколько обходится LLM-сервис при нагрузке в 100 000 диалогов в день и где проходит граница окупаемости разных вариантов. Посмотрим на стоимость облачных API, аренды GPU и собственного железа, а заодно прикинем, какая инфраструктура нужна, чтобы всё это выдержало боевой трафик.

Исходные допущения

Представим продукт, в котором пользователи активно общаются с моделью:

• 100 000 диалогов в день.

• Каждый диалог — это 100–300 токенов от пользователя.

• На один диалог модель отвечает примерно тремя сообщениями.

• В среднем получаем: ~900 токенов на вход (input) и ~1 200 токенов на выход (output) на один диалог.

Дальше считаем стоимость и нагрузку исходя из этих допущений.

Стоимость на GPT-4O Mini (без кеша)

Для начала посмотрим на сценарий с облачной моделью GPT-4O Mini.

Какой получается RPS (запросов в секунду)  при идеальных условиях

Берём 100 000 диалогов в день: 100 000 ÷ 86 400 секунд ≈ 1.16 RPS

Это средняя нагрузка за сутки, если бы диалоги равномерно распределялись по времени. В реальной жизни так не бывает: всегда есть часы пик.

Предположим, что 70% всего трафика приходится на 6 самых загруженных часов в день. Тогда: 70 000 диалогов / (6 × 3 600 секунд) ≈ 5.63 RPS в пиковые часы.

Если хотим свой уровень качества, как у GPT-4O Mini

Теперь перенесёмся в сценарий, где мы хотим свою модель, которая по качеству не повторяет GPT-4O Mini, но хотя бы не сильно ему уступает. В моём бенчмарке буду использовать условную Qwen2.5-32B-Instruct.

Что по инфраструктуре: A100 и пропускная способность

Одна видеокарта A100 на RunPod стоит примерно $1.89 в час
Её «пропускная способность» — 2–3 запроса в секунду со стримингом ответов. Если нам нужно иметь запас по производительности, горизонтальное масштабирование, то берём 6 серверов.

Если прикинуть бюджет локального развёртывания на RunPod, картина получается такой. 

Одна A100 обходится примерно в $1.89 в час. Для обслуживания нашей пиковой нагрузки с запасом мы закладываем 6 таких серверов, то есть стоимость инфраструктуры составляет 6 × $1.89 = $11.34 в час. 

Если считать работу кластера в режиме 24/7, месячные расходы выглядят так: $11.34 × 24 × 30 ≈ $8 164.80 в месяц.

Для сравнения: при тех же параметрах трафика использование облачной GPT-4O Mini стоит порядка $2 535 в месяц. Локальное решение на базе Qwen2.5-32B-Instruct, развёрнутое на шести A100, выходит примерно в $8 165 в месяц.

Сценарий_simple_text_chat_system: 100 000 текстовых диалогов в сутки

Ежедневно обрабатывается около 100 тысяч диалогов, в каждом из которых в среднем по 3 сообщения от пользователя. 

В пересчёте на токены это даёт примерно 900 токенов на вход и 1 200 токенов на выход на один диалог. 

При таком трафике средняя нагрузка на систему составляет около 1.16 запросов в секунду, а в пиковые часы, когда 70% всего трафика приходится на шесть наиболее загруженных часов, нагрузка вырастает до 5.63 RPS.

Стоимость Cloud API (GPT-4o-mini)

Аренда RunPod

Стоимость своего оборудования

Сравнение решений

Когда переходить на собственные модели?

Переход на собственные модели — это всегда баланс между экономикой и требованиями к контролю над данными. С точки зрения денег есть 3 ключевых сигнала. 

Во-первых, объём трафика: при высоком количестве запросов локальное решение начинает выигрывать у GPT-4o-mini — ориентировочно после отметки в 140 000 диалогов в день. 

Во-вторых, важна длина контекста: если вы регулярно обрабатываете большие массивы информации — свыше 100 000 токенов на один запрос, — счёт быстро растёт, и собственная инфраструктура становится логичнее. 

В-третьих, если вы планируете работать с моделью долгосрочно, то покупка и эксплуатация своего «железа» начинают отбиваться относительно аренды GPU (RunPod в нашем примере) примерно за 24 месяца.

Но есть и неэкономические факторы, которые часто оказываются даже важнее.

Для многих компаний критична конфиденциальность данных: любые сценарии, где запрещено передавать информацию внешним сервисам, автоматически подталкивают к on-prem или self-hosted-подходу. 

Свою роль играют и регуляторные требования: соответствие GDPR, 152-ФЗ, ограничения на трансграничную передачу данных — всё это проще и прозрачнее обеспечить, когда модели и данные работают внутри контролируемого контура.

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

Альтернативные сценарии использования agentic-систем

Показательный кейс SAST-агент-«патчер» на базе Qwen2.5-Coder, который автоматически анализирует репозитории, находит уязвимости и готовит правки. Экономику такого сценария можно прикинуть довольно просто. 

Допустим, у нас есть около 50 репозиториев с ежедневными сканированиями — это вполне типичный объём для средней корпорации уровня Tier-1–2.

Ежедневно возникает порядка 20 уязвимостей, которые требуют анализа с последующим оперативным исправлением. 

В сумме это даёт примерно 1000 запусков агента в день с объёмом 160 000 токенов на вход и 25 000 токенов на выход на каждый запуск.

Если перенести этот сценарий целиком на GPT-4o-mini, даже на старте мы получаем весьма ощутимый ежемесячный счёт. 

При этом важно помнить, что речь идёт о multi-agent system (MAS): под каждый агент в пайплайне у нас набирается 40+ промптов, связанных между собой. Только представьте, что после PoC вы решаете переехать, например, с облака на Qwen — все эти промпты придётся адаптировать и переписывать, что сильно увеличивает стоимость экспериментов и миграции.

И чтобы не быть голословным, приведу цифры. 

Для стартапов и проектов с небольшим объёмом запросов (и не самыми жёсткими требованиями к безопасности после PoC) оптимальным выбором по-прежнему остаются облачные API. У них низкий порог входа: не нужно сразу вкладываться в инфраструктуру, покупать «железо» и настраивать сложный контур — достаточно завести аккаунт и начать работу.

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