# Стоимость LLM API в рублях: как считать бюджет

Формулы и практические приёмы для расчёта стоимости LLM API: токены, повторные вызовы, инструменты, лимиты, резерв и стоимость успешной операции.

Канонический URL: https://llmtokenapi.ru/blog/stoimost-llm-api-v-rublyah
Опубликовано: 2026-08-31T14:14:54.276Z
Автор: Команда LLMTOKENAPI

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

## Из чего складывается стоимость вызова

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

Базовая оценка выглядит так:

`стоимость = входные токены × ставка входа + выходные токены × ставка выхода`

Ставки приводят к общей единице, например цене за миллион токенов. В биллинге LLMTOKENAPI денежные значения учитываются целыми копейками, поэтому итог округляется по правилам тарифа без float-ошибок. Актуальные значения и единицы всегда берите из [`GET /v1/prices`](https://api.llmtokenapi.ru/v1/prices), а доступные модели — из [каталога](/models). Не переносите цифры из статьи в production-конфигурацию: прайс меняется, а опубликованный endpoint остаётся источником истины.

## Считайте операцию целиком

Один пользовательский шаг может вызвать модель несколько раз. Агент сначала планирует, затем ищет информацию, вызывает инструмент и формирует итог. При невалидном JSON приложение повторяет генерацию. В RAG-сценарии добавляются embeddings, поиск и иногда rerank.

Полная формула полезнее:

`стоимость операции = сумма всех LLM-вызовов + web/embeddings/rerank + повторы`

Затем посчитайте стоимость принятого результата:

`стоимость успеха = общие расходы / число результатов, прошедших проверку`

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

## Оцените токены до запуска

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

Простой месячный прогноз:

`месячный бюджет = операции в день × 30 × стоимость одной операции`

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

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

## Ограничьте расходы на уровне запроса

Начните с `max_output_tokens`. Без предела модель может сформировать длинный ответ там, где продукту достаточно нескольких предложений или компактного JSON. Ограничение должно соответствовать интерфейсу: карточка, письмо и аналитический отчёт требуют разного бюджета.

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

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

## Маршрутизируйте задачи по сложности

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

Практичный маршрут включает три уровня:

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

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

## Следите за бюджетом в эксплуатации

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

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

## Как выбрать экономичное решение

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

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