Стоимость токенов API: как считать расход продукта, а не демо
Расчёт стоимости LLM API на полном сценарии: вход, выход, история, повторы, резервы, оценка до вызова и сверка подтверждённого списания по каждой задаче.
Стоимость LLM-функции считают по полному рабочему сценарию: все входные и выходные токены, число шагов, повторные обращения и ручная проверка. Оценка до вызова помогает ограничить риск, но окончательный расход берите из подтверждённого результата.
Что попадает в расчёт
Клиент видит короткий вопрос, но API получает ещё системную инструкцию, историю диалога, найденные фрагменты документов и параметры. Модель создаёт ответ, иногда длиннее ожидаемого. У разных маршрутов стоимость входа и выхода может различаться; медиа и специальные режимы требуют отдельной проверки. Поэтому расчёт по числу букв пользовательского вопроса почти всегда занижает реальную нагрузку.
Возьмите несколько фактических или синтетических запросов одного сценария и сохраните для каждого размер входа, размер выхода, число вызовов и подтверждённую стоимость. Считайте не среднее по удачным демонстрациям, а распределение: обычный запрос, длинный документ и крайний случай. Для планирования бюджета важны хвосты, вместе со средним значением.
Сценарий может состоять из нескольких вызовов
Пример: приложение извлекает поля из заявки, затем пишет черновик ответа и, при сомнении, просит человека проверить. Пусть у каждого этапа есть собственный вход и выход. Сложите стоимость обоих вызовов для успешно закрытой заявки; добавьте долю заявок, где первый результат пришлось переделать. Если человек тратит время на исправление, это тоже часть экономики функции, хотя не строка API-счёта.
Не смешивайте попытки с полезными результатами. Десять дешёвых генераций могут дать пять пригодных ответов. Тогда цена одного пригодного результата вдвое выше цены одного вызова ещё до ручной проверки. Привяжите расходы к конкретным операциям и классам ошибок. Это поможет увидеть, где стоит улучшать подсказку, а где дешевле изменить процесс.
Оценка до отправки и её пределы
В Kvantora POST /v1/chat/quote оценивает подготовленный текстовый запрос без вызова модели и без денежного резерва. В ответе можно увидеть estimated_cost_microrub и срок действия оценки. Документация предупреждает: входные токены оцениваются приблизительно, цена и доступность снова проверяются при отправке. Это инструмент для решения о запуске, не чек об оплате.
Добавьте max_cost_microrub в тело и дневной бюджет ключа. Первый ограничивает отдельный запрос, второй: поток обращений. В продукте можно предупредить пользователя, что документ слишком велик для установленного предела, и предложить сузить вход. Не повышайте лимит автоматически только ради того, чтобы ошибка исчезла.
Бюджет связывают с полезным объёмом работы
Планируя месячный лимит, оцените число задач, ожидаемую долю длинных входов и допустимую долю повторов. Затем добавьте запас для пикового дня и установите технические ограничения на отдельный запрос. Это не предсказание точной суммы: структура входных данных меняется. Зато команда заранее знает, после какого объёма должна остановить автоматический поток и проверить причины роста.
Когда бюджет подходит к пределу, снижать качество без уведомления пользователя опасно. Лучше явно сообщить, что автоматическая обработка временно недоступна или требует подтверждения. Смена модели на более дешёвую должна проходить тот же набор тестов. Если она чаще ошибается, финансовый выигрыш может исчезнуть в ручной правке и повторной отправке.
Резерв, расход и неизвестный исход
Платный запрос может пройти через резервирование средств до исполнения. Завершённое списание и открытый резерв учитываются отдельно. При таймауте клиенту неизвестно, принял ли сервер запрос; такой случай нельзя записывать как нулевой расход или сразу отпускать резерв на основании своей догадки. Нужно восстановление по исходной идентичности и фактическому состоянию.
Для отчёта заведите отдельные колонки: оценка, подтверждённый расход, открытое ожидание и отклонение до исполнения. Это чуть сложнее одной цифры, зато финансовая картина перестанет зависеть от качества сети. Сумма открытых ожиданий также влияет на доступный бюджет для новых задач.
Оптимизируйте после измерения ошибок
Самый простой способ сократить расход: не отправлять ненужный контекст. Уберите дубли документов, старую историю и поля, которые не нужны для задачи. Затем проверьте качество: иногда короткий вход заставляет модель чаще ошибаться и повторные вызовы съедают экономию. Сравнивайте стоимость пригодного результата, а не длину подсказки саму по себе.
Другой рычаг: маршрутизация по задаче. Простое извлечение может проходить на одном варианте, а сложный разбор на другом, но такое решение должно следовать из собственного теста. Не стройте автоматический fallback при неизвестном исходе: это может удвоить платную работу. Сначала разберитесь с восстановлением, потом с экономией.
Полезно сравнивать два вида нагрузки: одиночный запрос нового пользователя и продолжение длинного диалога. Во втором случае история часто растёт незаметно, даже если каждое новое сообщение короткое. Установите правило сокращения истории и проверьте, что оно не выбрасывает важные условия. Экономия токенов имеет смысл только вместе с сохранением качества.
Какие числа нужны владельцу продукта
Показывайте число завершённых задач, расход на них, долю повторов и число открытых случаев. По моделям храните публичный ID и дату, иначе после изменения каталога цифры потеряют смысл. Отдельно измеряйте ручную проверку, если функция обещает экономить время команды. Без этого дорогая ошибка может выглядеть как хорошая оптимизация.
Не копируйте в долгоживущий план цены из поста о релизе. Возьмите актуальные данные фактического маршрута и пересчитайте свой набор после изменения модели или условий. Бюджет становится управляемым тогда, когда команда знает, что именно оплачено и какой полезный результат получен.