Как рассчитать стоимость использования LLM: формулы, скрытые расходы и примеры

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

Что входит в стоимость LLM

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

Если вы считаете только первый слой, вы считаете не стоимость решения, а стоимость сырья для него.

Входные, выходные и reasoning-токены

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

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

• Входные токены включают всё, что уходит в модель. Системная инструкция, история диалога, подтянутые из базы фрагменты документов, описания инструментов, примеры форматирования.
• Выходные токены это то, что модель сгенерировала. Они стоят в три-пять раз дороже входных, иногда больше.
• Reasoning-токены генерируются моделью во время размышления и в большинстве случаев не попадают в итоговый ответ. Платите вы за них по ставке выходных.
• Кэшированные входные токены стоят дешевле обычных входных, обычно в пределах десятой части их цены, но работают только при соблюдении технических условий.

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

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

Кэш контекста, батчи и контекстное окно

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

1. Кэширование контекста даёт скидку на повторно отправляемую часть промпта. Работает оно по принципу общего префикса, то есть неизменная часть должна стоять в начале запроса и совпадать побайтово. Если вы вставляете в системную инструкцию текущее время или идентификатор пользователя, кэш не сработает ни разу, а вы будете думать, что экономите.
2. Пакетная обработка снижает цену примерно вдвое в обмен на отложенный результат. Для ночного пересчёта базы знаний, разметки архива обращений или массовой генерации описаний товаров это почти бесплатная экономия. Для диалога с клиентом механизм непригоден.
3. Размер контекстного окна влияет на цену косвенно. Доступный миллион токенов не означает, что его нужно заполнять. Чем больше окно, тем сильнее соблазн отправлять в модель весь массив данных вместо отобранного релевантного фрагмента, и тем выше счёт при одинаковом качестве ответа.

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

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

Инфраструктура вокруг модели

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

• Эмбеддинги для поиска по документам. Считаются дешево, но считаются на каждый фрагмент базы и на каждый поисковый запрос пользователя.
• Переиндексация. При смене модели эмбеддингов или изменении способа нарезки документов базу нужно пересчитать целиком. За год таких пересчётов обычно случается два или три.
• Векторная база данных. Либо управляемый сервис с ежемесячной платой, либо свой контейнер, который кто-то обслуживает и за который кто-то платит памятью и диском.
• Логирование и мониторинг. Полные логи запросов и ответов растут быстро, особенно при длинном контексте, и хранение их за год превращается в заметную строку.
• Оценка качества. Автоматическая проверка ответов часто делается другой моделью, иногда более дорогой, чем рабочая. Это полноценный поток расходов.
• Модерация и фильтрация персональных данных. Дополнительный вызов перед основным, плюс иногда вызов после него.
• Шлюз и балансировка между поставщиками. Либо своя разработка, либо сторонний сервис с комиссией за объём.

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

Люди и остаточная ручная работа

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

• Разработка и интеграция. Обычно это от двухсот до шестисот часов работы команды на первую рабочую версию с поиском по документам и интеграцией в существующие системы.
• Сопровождение промптов. Инструкции устаревают вместе с процессами, регламентами и ассортиментом. Кто-то должен их обновлять каждый месяц.
• Подготовка и чистка данных. Если база знаний собрана из разрозненных файлов разного качества, половина проекта это работа с данными, а не с моделью.
• Проверка ответов на старте. В первые недели кто-то читает выборку ответов и фиксирует ошибки, иначе качество невозможно оценить.
• Остаточная ручная работа. Модель закрывает не сто процентов обращений, а например семьдесят. Оставшиеся тридцать по-прежнему стоят зарплату, и экономия считается только по закрытой части.

Последний пункт разрушает больше бизнес-кейсов, чем все скрытые технические расходы вместе. Проект, который снимает с оператора семьдесят процентов типовых обращений, не освобождает семьдесят процентов ставки. Оператор остаётся на месте, просто занимается более сложными случаями. Экономия возникает позже, при росте объёма без расширения штата, и в расчёте это нужно формулировать именно так.

Три ошибки, которые ломают смету

Эти ошибки системные, они повторяются почти в каждом первом расчёте, и каждая из них даёт промах в разы, а не в проценты.

Один запрос пользователя не равен одному вызову модели

Интуитивная модель расчёта выглядит так. Пользователь задал вопрос, модель ответила, мы заплатили за один вызов. В реальности один вопрос пользователя в зрелой системе разворачивается в цепочку обращений.

Возьмём типичный помощник по внутренней базе знаний компании.

1. Проверка запроса на корректность и наличие персональных данных. Один вызов недорогой модели.
2. Переформулировка вопроса для поиска, потому что пользователь пишет сокращённо и с опечатками. Второй вызов.
3. Расчёт эмбеддинга поискового запроса. Отдельная тарифицируемая операция.
4. Основной вызов с подтянутыми фрагментами документов. Самая дорогая часть.
5. Проверка ответа на соответствие источникам, чтобы отловить выдумку. Пятый вызов, иногда дорогой моделью.
6. Уточняющий вопрос пользователя, который тянет за собой всю историю диалога заново.

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

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

Расходы, которых нет в прайсе

Прайс поставщика описывает цену за токены основной модели. За его пределами остаётся всё перечисленное выше, плюс несколько вещей, которые проявляются только со временем.

• Повторные запросы при ошибках. Таймауты, лимиты скорости, сбои сети. Повторная попытка тарифицируется как новый вызов, даже если первая не дала результата.
• Неудачные ответы. Пользователь переформулировал вопрос, потому что первый ответ был бесполезен. Вы заплатили дважды, польза получена один раз.
• Тестирование и регрессионные прогоны. Каждое изменение промпта требует проверки на наборе эталонных случаев. Сто случаев на десять итераций это тысяча вызовов за один рабочий день разработчика.
• Разработческая среда. Эксперименты команды идут по тем же тарифам, что продакшен, и в первые месяцы могут превышать его по объёму.
• Изменение цен и устаревание моделей. Горизонт актуальности прайса сейчас составляет месяцы. Модель, под которую вы оптимизировали архитектуру, через полгода может быть снята с поддержки.

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

Парадокс активного пользователя

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

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

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

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

Что из этого складывается

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

Формулы расчёта

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

Стоимость одного запроса

Базовая формула выглядит так.

C_запрос = K × (T_вх × P_вх + T_кэш × P_кэш + T_вых × P_вых) + C_эмб

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

• K это среднее число вызовов модели на одно обращение пользователя. Измеряется по логам, а не оценивается. Для простого диалогового помощника получается от одного до двух, для системы с поиском по базе и проверкой ответа от четырёх до восьми, для агентных сценариев от десяти и выше.
• T_вх это средняя длина входа в токенах без учёта кэшируемой части. Сюда входят подтянутые фрагменты документов, история диалога, описания доступных инструментов.
• T_кэш это неизменная часть промпта, которая попадает под скидку за кэширование. Обычно это системная инструкция и постоянные примеры. Если кэш у вас не настроен, эту переменную нужно обнулить и перенести объём в T_вх, иначе расчёт получится оптимистичным на четверть.
• T_вых это сумма видимого ответа и reasoning-токенов. Для размышляющих моделей вторая часть может быть в пять-десять раз больше первой.
• P_вх, P_кэш, P_вых это тарифы за токен по соответствующим категориям.
• C_эмб это расходы на эмбеддинги поискового запроса. Величина небольшая, но она не нулевая, и при миллионах обращений она видна в счёте.

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

Стоимость активного пользователя

Метрика CPMAU показывает, сколько вам стоит один активный пользователь в месяц. Считается она не делением общего счёта на число зарегистрированных, а через фактическую активность.

CPMAU = C_запрос × N_обращений_на_пользователя_в_месяц

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

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

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

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

Стоимость одного полезного результата

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

C_результат = C_период / N_принятых_результатов

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

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

• Для задач с объективной проверкой доля принятых результатов измеряется автоматически через тесты или сверку с источником.
• Для задач без объективной проверки её приходится измерять выборочной оценкой, обычно на ста-двухстах случаях.
• Без этого знаменателя сравнение моделей по прайсу не имеет смысла, потому что вы сравниваете стоимость сырья, а не стоимость продукта.

Прогноз при росте трафика в десять раз

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

Факторы, которые делают рост быстрее линейного.

• Рост доли интенсивных пользователей. Зрелая аудитория ведёт более длинные диалоги, а длина диалога влияет на входные токены нелинейно.
• Усложнение сценариев. Продукт обрастает функциями, число вызовов на обращение растёт, коэффициент K увеличивается.
• Расширение базы знаний. Больше документов означает либо больше подтягиваемых фрагментов, либо более сложный поиск с дополнительной моделью переранжирования.
• Требования к надёжности. При серьёзном объёме появляются дублирующие проверки, резервный поставщик, более плотный мониторинг.

Факторы, которые делают рост медленнее линейного.

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

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

Пошаговый расчёт месячного бюджета

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

1. Соберите объём запросов по сценариям. Не общее число обращений, а разбивку по типам задач. Консультация по базе знаний, обработка входящего документа, генерация текста, классификация обращений. У каждого сценария своя длина контекста и своё число вызовов, и смешивать их в одну среднюю величину нельзя.
2. Замерьте среднюю длину входа и выхода. Берите не оценку на глаз, а реальный замер на пятидесяти-ста типичных запросах через токенизатор выбранной модели. Для русского текста ориентир такой, что одна страница примерно в тысячу восемьсот знаков превращается в семьсот-девятьсот токенов.
3. Определите коэффициент вызовов и долю reasoning. Пройдите по схеме обработки одного обращения и выпишите все обращения к модели, включая проверки и повторы. Отдельно зафиксируйте, включён ли режим размышления и с каким лимитом.
4. Умножьте на тарифы по категориям токенов. Отдельно для каждой модели в вашей схеме, отдельно для входа, кэша и выхода. Сложите в стоимость одного обращения по каждому сценарию, затем умножьте на месячный объём сценария.
5. Прибавьте инфраструктуру, тесты и модерацию. Эмбеддинги и переиндексация, векторная база, хранение логов, автоматическая оценка качества, разработческая среда. Если точных цифр нет, используйте коэффициент один и четыре к расходам на основную модель как первое приближение.
6. Заложите запас на рост и смену тарифов. Двадцать-тридцать процентов сверху на непредвиденные повторы, рост активности и изменение прайса. Это не перестраховка, это нормальная дисперсия первого квартала работы.

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

Что делать, если логов ещё нет

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

Пример расчёта на реальном проекте

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

Исходные данные после замера.

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

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

Теперь полная смета за месяц в установившемся режиме.

Статья расходов	Сумма в месяц, рубли	Доля
Вызовы основной модели	20 700	21%
Вспомогательные вызовы и эмбеддинги	1 950	2%
Переиндексация базы знаний, в среднем за месяц	1 500	2%
Векторная база и хостинг сервиса	12 000	12%
Хранение логов и мониторинг	4 500	5%
Автоматическая оценка качества и регрессионные прогоны	6 000	6%
Разработческая среда и эксперименты	5 000	5%
Сопровождение, промпты и обновление базы, 25 часов	45 000	47%

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

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

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

Облако или свой контур: точка окупаемости

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

Совокупная стоимость закрытого контура

Арендованный или купленный сервер с ускорителем это не единственная строка. Полная стоимость владения складывается из следующих частей.

• Сам ускоритель или его аренда. Для модели среднего размера в квантованном виде нужна видеопамять от двадцати четырёх до сорока восьми гигабайт, для моделей покрупнее от восьмидесяти и выше, и часто не одна карта.
• Оперативная память и диск. Память растёт не плавно, а ступенями под размер модели, и переход на следующую ступень иногда удваивает стоимость конфигурации.
• Электричество и охлаждение, если оборудование своё. Постоянно загруженный ускоритель это непрерывное потребление, а не пиковое.
• Администрирование. Обновление драйверов, движка вывода, мониторинг загрузки, перезапуски. Это от десяти до тридцати часов в месяц работы человека с нужной квалификацией.
• Резервирование. Один сервер означает отсутствие отказоустойчивости. Второй узел удваивает инфраструктурную часть.
• Простой. Облако вы платите по факту использования, своё железо платите круглосуточно, включая ночь и выходные.

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

Производительность за те же деньги

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

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

Практическая проверка выглядит так. Возьмите свою реальную нагрузку, посчитайте суммарный объём входных и выходных токенов за сутки, разделите на пропускную способность конфигурации и посмотрите, сколько часов в сутки оборудование будет занято. Если получается меньше двух-трёх часов, вы оплачиваете простой, и облако почти гарантированно дешевле.

При каком объёме своё железо дешевле

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

N_безубыточности = TCO_месяц / C_обращение_в_облаке

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

Отсюда ориентиры, которые я использую как предварительный фильтр.

1. До десяти тысяч обращений в месяц своё развёртывание не обсуждается по экономическим причинам. Только если есть требования к данным.
2. От десяти до пятидесяти тысяч обращений возникает серая зона, где результат зависит от длины контекста и выбранной модели. Считать нужно на конкретных цифрах.
3. Выше ста тысяч обращений в месяц при стабильном профиле нагрузки своё оборудование начинает давать ощутимую экономию, и она растёт с объёмом.
4. При неравномерной нагрузке с резкими пиками гибридная схема обычно выигрывает у любой чистой. Базовый поток идёт на своё оборудование, пики уходят в облако.

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

Порядки цен: флагманы, средний и бюджетный сегмент

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

Сегмент	Порядок цены за миллион токенов	Где уместен
Флагманы	единицы и десятки долларов за вход, кратно дороже за выход	сложные рассуждения, работа с кодом, юридические и аналитические задачи, агентные сценарии
Средний уровень	десятые доли и единицы долларов	ответы по базе знаний, обработка документов, диалог с клиентом, основная масса продуктовых задач
Бюджетный уровень и компактные модели	сотые и десятые доли доллара	классификация, маршрутизация, извлечение полей, проверки, переформулировка запросов

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

Зарубежные модели по API

Здесь важнее цены оказываются три организационных фактора, которые напрямую превращаются в деньги.

• Способ оплаты и доступа. Прямой договор с зарубежным поставщиком для российской компании затруднён, поэтому доступ обычно идёт через посредников, а они добавляют комиссию от десяти до тридцати процентов и свой курс конвертации. Это нужно закладывать в расчёт как отдельный коэффициент, а не игнорировать.
• Курсовой риск. Тариф номинирован в валюте, а бюджет чаще в рублях. На горизонте года колебание в двадцать процентов это нормальная рабочая гипотеза, и она должна быть в смете.
• Юридический контур. Передача персональных данных на зарубежную инфраструктуру требует отдельной правовой оценки, и для многих компаний вопрос закрывается на этом этапе независимо от цены.

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

Российские модели и требования 152-ФЗ

Если в обрабатываемых данных есть персональные данные, вопрос о площадке решается раньше вопроса о цене. Закон о персональных данных требует, чтобы обработка шла на территории России, а передача оператору за рубеж оформлялась отдельно и далеко не всегда возможна. Поэтому для большинства корпоративных сценариев выбор сужается до трёх вариантов.

1. Российские облачные модели через API. GigaChat от Сбера и YandexGPT в Яндекс Облаке закрывают эту задачу штатно, с договором на российское юридическое лицо, оплатой в рублях и обработкой внутри страны. Ценовые уровни сопоставимы с зарубежным средним сегментом, иногда ниже за счёт более дешёвого выхода.
2. Открытые модели на российской инфраструктуре. Qwen, DeepSeek, Llama и их производные разворачиваются на арендованных ускорителях у российских провайдеров. Юридически это ваша собственная обработка, что снимает вопрос о передаче данных третьей стороне.
3. Полностью закрытый контур на своём оборудовании. Максимальная степень контроля и максимальная совокупная стоимость, оправданная при высоких требованиях регулятора или при больших объёмах.

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

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

Как сократить расходы

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

Маршрутизация задач между моделями

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

Рабочая схема разделения выглядит так.

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

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

Кэширование, батчи и сжатие промптов

Технические приёмы, которые не меняют архитектуру, но требуют аккуратности в деталях.

1. Вынесите всё неизменное в начало промпта. Системная инструкция, правила формата, постоянные примеры. Динамические части, включая время, идентификатор пользователя и подтянутые документы, уходят в конец. Только при таком порядке кэш общего префикса работает.
2. Проверьте фактическое попадание в кэш по метаданным ответов. Поставщик возвращает число кэшированных токенов, и это единственный надёжный способ убедиться, что механизм включился. Расчётная экономия без проверки обычно оказывается нулевой.
3. Переведите всё, что не требует мгновенного ответа, в пакетную обработку. Ночная разметка обращений, пересчёт базы, генерация описаний, подготовка отчётов. Скидка около половины тарифа.
4. Сократите подтягиваемый контекст. Пять релевантных фрагментов вместо двадцати обычно не ухудшают ответ, потому что лишние фрагменты не помогают модели, а отвлекают её. Качество при этом иногда растёт.
5. Сжимайте историю диалога. После десятой реплики ранние сообщения заменяются краткой выжимкой. Это ломает парадокс активного пользователя, описанный выше, и ограничивает рост входных токенов.
6. Ограничьте длину ответа явно. Указание на объём в инструкции плюс технический лимит на выходные токены. Выход дороже входа в несколько раз, поэтому экономия здесь ощутимее.

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

Подписка на ассистента или прямой доступ к API

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

• Подписка выгодна при интенсивной индивидуальной работе. Один разработчик, активно использующий ассистента весь рабочий день, по тарификации токенов вышел бы за пределы подписки в несколько раз.
• Прямой доступ по API выгоден при нерегулярном использовании, при автоматизации и при необходимости встроить модель в собственный процесс.
• Гибридная схема обычно и выигрывает. Подписки для тех, кто работает с моделью ежедневно, доступ по API для продуктовых сценариев и для остальных сотрудников.
• Считать нужно по факту, а не по ощущениям. Месяц работы с API-доступом даёт точную цифру расхода на человека, и уже она сравнивается со стоимостью подписки.

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

Дообучение вместо длинных промптов

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

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

Когда это оправдано.

• Задача узкая и стабильная, формат ответа жёстко задан, объём запросов превышает сотни тысяч в месяц.
• У вас есть хотя бы несколько сотен качественных примеров правильных ответов, желательно тысячи.
• Требования к формату и стилю не меняются каждый месяц, иначе дообучение придётся повторять.

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

Калькуляторы и метрики контроля расходов

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

Что калькулятор не учитывает по своей природе.

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

Поэтому калькулятор это инструмент для одного шага расчёта, а не замена расчёту. Гораздо важнее настроить постоянное наблюдение за расходами, потому что смета живёт ровно до первого изменения в продукте.

Минимальный набор метрик, который имеет смысл выводить на единую панель.

1. Расход в деньгах за сутки с разбивкой по моделям и по сценариям. Без разбивки непонятно, что именно выросло.
2. Среднее число токенов на вход и на выход по каждому типу вызова. Рост этой величины почти всегда означает, что кто-то добавил данных в промпт.
3. Фактический коэффициент вызовов на одно обращение. Он незаметно растёт при каждом расширении функций.
4. Доля попаданий в кэш. Падение этого показателя означает, что кэш сломался, и обычно это следствие безобидной правки системной инструкции.
5. Доля повторов и ошибок, включая таймауты и превышения лимитов. Это оплаченные вызовы без результата.
6. Стоимость на пользователя по процентилям, не только средняя. Отдельно верхний процент.
7. Доля принятых результатов. Главная метрика для сравнения моделей и единственная, которая связывает расходы с пользой.

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

Когда расчёт не нужен

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

• Пилот на несколько десятков обращений в день. Расход составит сотни рублей в месяц, и любая цифра будет меньше погрешности. Считайте после того, как станет понятно, работает ли сценарий вообще.
• Задача очевидно дорогая по сравнению с результатом. Если один запрос обрабатывает документ на триста страниц, а результат экономит десять минут работы специалиста, арифметика видна без формул.
• Задача очевидно дешёвая. Классификация десяти тысяч обращений в месяц компактной моделью обойдётся в сумму меньше часа работы сотрудника. Решение принимается по применимости, а не по деньгам.
• Выбор продиктован регулятором. Если персональные данные обязаны обрабатываться внутри страны, сравнение с зарубежными тарифами не меняет решения.
• Архитектура ещё не стабилизировалась. Пока число вызовов на обращение меняется каждую неделю, любая смета устаревает быстрее, чем оформляется.

Во всех остальных случаях расчёт нужен, и особенно он нужен перед масштабированием. Переход от пилота к продакшену меняет не только объём, но и структуру расходов, и именно на этом переходе проекты обнаруживают, что экономика не сходится.

Чек-лист перед стартом

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

1. Зафиксирован объём запросов и сценарии. Разбивка по типам задач, а не общее число обращений. У каждого сценария свой профиль нагрузки.
2. Учтены все вызовы модели на один пользовательский запрос. Схема обработки нарисована, вызовы пронумерованы, включая проверки, повторы и уточнения.
3. Посчитаны инфраструктурные и скрытые статьи. Эмбеддинги, переиндексация, векторная база, логи, автоматическая оценка качества, разработческая среда, часы сопровождения.
4. Определена цена результата, а не только токена. Измерена доля принятых ответов на выборке хотя бы в сто случаев.
5. Сравнены минимум две модели на одной нагрузке. Одинаковые запросы, одинаковые промпты, сравнение по цене результата, а не по прайсу.
6. Есть лимиты и алерты по расходу токенов. Лимит на ключ, лимит на пользователя, дневной порог с уведомлением и аварийное отключение.

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

Частые вопросы о стоимости использования LLM

Сколько в среднем стоит один запрос к языковой модели

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

Почему фактический счёт оказался выше расчёта в несколько раз

В порядке частоты причины такие. Не учтены вспомогательные вызовы, то есть коэффициент K принят за единицу. Включён режим размышления, и выходных токенов оказалось на порядок больше ожидаемого. Кэш не сработал из-за динамических данных в начале промпта. Не учтена разработческая среда и регрессионные прогоны. Растёт длина диалогов, а значит входные токены на реплику. Каждая из этих причин даёт расхождение в разы, а вместе они дают порядок.

Как считать токены для русского текста

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

Что дороже на длинной дистанции, облако или свой сервер

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

Имеет ли смысл брать самую дешёвую модель, чтобы сэкономить

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

Как заложить в бюджет изменение цен

Горизонт стабильности прайсов сейчас составляет месяцы, причём движение идёт в обе стороны. Ставки за токен исторически снижаются, но одновременно растёт потребление токенов на задачу из-за размышления и агентных схем. Рабочая практика состоит в том, чтобы планировать бюджет на квартал с запасом в двадцать-тридцать процентов и пересматривать расчёт при каждой смене модели или заметном изменении архитектуры.

С чего начать, если расчёта нет совсем

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

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