Стоимость API

Цена LLM API для стартапа: считать по успешной задаче

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

Опубликовано 13 августа 2026 · 12 минут чтения · Ключевой запрос: цена llm api для стартапа

Короткий ответ

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

Почему ставка за токены не равна расходам

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

Поэтому разделите метрики на технические и продуктовые. Технические — входные токены, выходные токены, длительность, код ответа, повторы и модель. Продуктовые — начатая задача, валидный ответ, принятый результат, ручная доработка и отмена. Не логируйте полный prompt, Authorization, документы или персональные данные ради аналитики: для расчёта достаточно агрегатов и обезличенных счётчиков.

Формула для первой финансовой модели

Для одного запуска обозначьте входные токены как in, выходные как out, а актуальные ставки как pin и pout. Базовая стоимость запуска равна in × pin + out × pout. Если в среднем на одну попытку приходится r попыток, а доля успешных пользовательских задач равна s, приблизительная цена успешной задачи равна (in × pin + out × pout) × r / s. Ставки подставляйте только из актуального каталога или договора, а не из этой статьи.

def cost_per_success(input_tokens, output_tokens, input_rate, output_rate,
                     attempts_per_run, success_rate):
    if not 0 < success_rate <= 1:
        raise ValueError("success_rate must be between 0 and 1")
    one_attempt = input_tokens * input_rate + output_tokens * output_rate
    return one_attempt * attempts_per_run / success_rate

# Enter current rates from the RussiaAPI catalog or contract; do not copy a rate from this article.
input_rate = float(input("Current input-token rate: "))
output_rate = float(input("Current output-token rate: "))
estimate = cost_per_success(
    input_tokens=850,
    output_tokens=260,
    input_rate=input_rate,
    output_rate=output_rate,
    attempts_per_run=1.05,
    success_rate=0.92,
)
print(estimate)

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

Соберите измерения до выбора модели

Выберите 20–50 обезличенных примеров из ключевого пользовательского потока. Для чат-ассистента это могут быть вопросы разной длины, русский текст, структурированный ответ и невалидный вход. Для извлечения — документы разрешённого тестового набора с заранее известной схемой. На каждом кейсе измеряйте токены, время, долю валидных ответов, число повторов и оценку качества. Дата, модель и версия prompt должны храниться рядом с агрегированной метрикой.

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

Держите контекст под контролем

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

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

Повторы и ошибки — отдельная статья расхода

Различайте повтор выполнения и повтор доставки ответа. При 429 или некоторых временных 5xx допустим ограниченный backoff с jitter. Ошибки 401, 403, неверный JSON и неизвестная модель не исправляются ожиданием и не должны тратить новый запрос. При сетевом тайм-ауте сначала проверьте состояние своей операции: иначе можно создать дубль и двойной расход.

Установите максимум попыток, общий дедлайн и бюджет на один пользовательский сценарий. Храните idempotency key или внутренний ID операции, чтобы второй клик не запускал новую работу. Технические детали есть в материалах про 429 и controlled retry и защиту от дублей. Это не способы обойти лимиты, а защита вашего приложения от лишней нагрузки и непредсказуемого счёта.

Бюджеты, лимиты и оповещения

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

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

Типичные ошибки в расчёте

• Копировать тариф из старой статьи или другого провайдера.
• Учитывать только запросы, но не долю валидных результатов.
• Игнорировать повторные попытки, отмены и двойные клики.
• Сравнивать модели на разных prompt и разных наборах кейсов.
• Отправлять в аналитику ключи, Authorization или лишние данные пользователя.

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

FAQ

Читайте также

• Как снизить стоимость LLM API
• Как выбрать модель для API
• 429 API: backoff и повтор
• Документы RussiaAPI