Как рассчитать стоимость LLM: расходы ИИ-помощника за месяц

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

Рабочая формула начинается так:

месячный расход = стоимость всех вызовов модели + вспомогательные сервисы + инфраструктура + сопровождение.

До запуска в формуле будут допущения. После пилота их нужно заменить фактическими значениями из журнала задач, usage провайдера и счетов. Так можно получить стоимость задачи, увидеть источник перерасхода и оценить рост нагрузки, не выдавая условный бюджет за фиксированную цену.

Из чего складывается стоимость работы ИИ-помощника

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

В месячный эксплуатационный бюджет могут входить:

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

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

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

Как измерить нагрузку и расход токенов

Единицей планирования должна быть выполненная бизнес-задача: например, подготовленный для проверки ответ по документам. Сообщение пользователя — только одно событие внутри такой задачи.

Для начала запишите:

1. сколько задач поступает за период;
2. сколько обращений к модели приходится на одну задачу;
3. сколько входных и выходных токенов содержит типичный вызов;
4. сколько возникает повторов и незавершённых попыток;
5. какие внешние сервисы вызываются в ходе задачи.

Предварительный расчёт числа вызовов выглядит так:

задачи × вызовы на задачу × коэффициент повторов.

Если дополнительных повторов 10%, коэффициент равен 1,10. Затем число вызовов умножают отдельно на средний вход и средний выход. Среднее нужно получать на выборке, где есть короткие, обычные и сложные задачи, а не на одном удачном диалоге.

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

Предварительный подсчёт токенов полезен до отправки запроса. Согласно документации Claude Platform, отдельный механизм token counting оценивает входные токены для структурированного запроса до его отправки. Но такая оценка не подменяет фактический usage: к моменту выполнения могут добавиться выход, серверные инструменты, новые вызовы и повторы. Для запросов с серверными инструментами документация предписывает смотреть usage фактического ответа.

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

Как читать тариф модели

Смотрите не на одно число рядом с названием модели, а на все категории, которые использует ваш сценарий. На официальной странице Claude Platform, проверенной 6 октября 2026 года, цены указаны в USD за миллион токенов и разделены как минимум на вход, выход, запись кэша и чтение кэша.

Например, на эту дату для Claude Sonnet 5.5 страница указывала следующие ставки:

Эти числа показывают, как читать тариф, но не являются обещанием будущей цены или рекомендацией конкретной модели. Перед сметой и публикацией предложения нужно снова проверить страницу провайдера, выбранную модель, платформу размещения, режим обработки и договорные условия. Пересчитывать USD в другую валюту без актуального источника курса не следует.

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

Как учитывать повторы и вспомогательные сервисы

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

Считайте каждую статью в её собственной единице:

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

Неизвестные значения оставляйте параметрами. После контрольного периода замените их сведениями из usage, журналов и счетов. Так видно, относится рост к модели, распознаванию, поиску или инфраструктуре.

Что считать при собственном размещении

У собственного сервера нет единственной «цены запроса». В бюджет входят:

• оплаченные часы сервера либо амортизация оборудования;
• электричество и охлаждение, если оборудование принадлежит компании;
• хранение, сеть, резервирование и наблюдение;
• фактическая загрузка и простой;
• доступная пропускная способность при нужной задержке;
• объединение запросов в пакеты, если batching допустим для процесса;
• обновления модели, библиотек и окружения;
• время на восстановление после сбоя.

Разделите общий расход сервера на число пригодно выполненных задач при измеренной нагрузке. Пустующий сервер всё равно создаёт затраты, а расчёт только по пиковой мощности способен завысить ожидаемую производительность или скрыть простой.

Квантование может снизить требования к памяти и вычислениям, но одновременно изменить качество результата. Сравнивайте варианты на одном наборе задач и считайте только результаты, которые прошли одинаковые критерии пригодности. Более дешёвый запуск не экономит бюджет, если сотрудник вынужден переделывать ответы или система чаще повторяет запросы.

Учебный пример месячного бюджета

Ниже — синтетический учебный пример. Это не клиентский кейс, не файл с измерениями и не результат внедрения Switch On AI.

Допустим, помощник получает 1 000 задач в месяц. Для каждой задачи он делает два обращения к модели. Одно обращение содержит в среднем 1 500 входных и 300 выходных токенов. Дополнительные повторы составляют 10% от базового числа вызовов.

Сначала считаем вызовы:

• базовые вызовы: 1 000 × 2 = 2 000;
• дополнительные вызовы: 2 000 × 10% = 200;
• всего: 2 000 + 200 = 2 200 вызовов.

Затем считаем токены:

• вход: 2 200 × 1 500 = 3 300 000, то есть 3,3 млн токенов;
• выход: 2 200 × 300 = 660 000, то есть 0,66 млн токенов.

Обозначим цену миллиона входных токенов как p_in, а цену миллиона выходных — как p_out. Стоимость модели составит:

3,3 × p_in + 0,66 × p_out.

Повторы уже включены в 2 200 вызовов, 3,3 млн входных и 0,66 млн выходных токенов. Умножать эти объёмы ещё раз на 1,10 нельзя: это двойной учёт.

Полный месячный бюджет в этом примере равен стоимости модели плюс фактические расходы на поиск, распознавание, хранение, инфраструктуру и сопровождение. Если часть операций покрывает подписка, прибавляется только непокрытая часть.

Сценарий роста нагрузки

Предположим, число задач удвоилось до 2 000, а остальные условия не изменились. Это отдельный условный сценарий:

• 2 000 × 2 × 1,10 = 4 400 вызовов;
• 4 400 × 1 500 = 6,6 млн входных токенов;
• 4 400 × 300 = 1,32 млн выходных токенов;
• стоимость модели: 6,6 × p_in + 1,32 × p_out.

Линейный рост здесь задан условиями примера. В рабочей системе средний контекст, число повторов, доля кэша и состав задач могут измениться. Поэтому сценарий роста нужно подтвердить замером, а инфраструктуру дополнительно проверить на нужную задержку и пропускную способность.

Как поставить лимиты и проверять счета

Лимит должен описывать не только сумму, но и действие системы. Заранее задайте три элемента:

1. Порог предупреждения. Например, согласованная доля месячного бюджета, после которой ответственный получает уведомление и проверяет источник роста.
2. Жёсткий предел. Сумма, число токенов, вызовов или задач, после которой система не продолжает обычную работу без отдельного решения.
3. Действие при достижении предела. Остановить необязательные задачи, перевести запрос человеку, использовать заранее разрешённый упрощённый режим или приостановить процесс. Конкретное действие зависит от риска операции.

Один общий лимит на аккаунт плохо объясняет перерасход. Разбивайте usage по процессам, подразделениям, типам запросов, моделям и средам. Отдельно показывайте обычные задачи, длинные документы, повторы, ошибки и тестовые вызовы.

В конце расчётного периода сверяйте три набора данных:

• журнал поступивших и завершённых бизнес-задач;
• журнал вызовов со статусами и расходом;
• usage и счёт провайдера.

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

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

Облако и собственный сервер также сравнивают при одинаковом числе задач, составе запросов, качестве и допустимой задержке. Для сервера учитывают загрузку, batching и простой, для облака — фактический usage и сопутствующие сервисы. Универсальной точки окупаемости нет: она зависит от нагрузки, оборудования, тарифа, требований к данным и работы по сопровождению.

Как обсудить эксплуатацию перед внедрением

Для первой оценки подготовьте данные об одной операции:

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

Switch On AI может разобрать эту операцию, проверить доступные данные и API, определить, подходит ли ИИ-помощник, бот или обычная интеграция, и согласовать прототип ключевого сценария. Совместимость конкретных систем, права доступа, тарифы и состав сопровождения проверяются отдельно. Фиксированную эксплуатационную стоимость нельзя обещать без контрольной нагрузки и замера.

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