Стоимость LLM-приложения: считайте за решённую задачу

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

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

Учебный расчёт для двух конфигураций

Представим 100 одинаковых по составу задач. Конфигурация A тратит 100 условных денежных единиц на первые обращения и ещё 40 на повторы. Конфигурация B — 150 и 10 соответственно. Это вымышленные суммы, не тарифы провайдеров и не результаты измерения конкретных моделей.

Показатель	A	B
Всего задач	100	100
Первичные обращения	100	150
Повторы	40	10
Общий расход	140	160
Успешно решено	70	90
Расход на успех	2,00	1,78

A дешевле по общему счёту, но B дешевле по одному успешному результату: 160/90 ≈ 1,78. Это ещё не окончательный выбор. Если B слишком медленная или нарушает требования к данным, выигрыша по одной метрике недостаточно.

Сначала определите, что значит успех

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

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

Что включить в стоимость

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

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

Как организовать измерение

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

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

Что оптимизировать первым

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

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

Как перейти от разбора к практике

LLMOps & Evaluation подходит разработчикам, которым нужны оценка качества, наблюдаемость и контроль работы LLM-приложения. Перед выбором проверьте требования к Python, API и окружению. Материал подготовлен Latorn; ссылка ведёт на наш платный курс. Перед покупкой сравните программу и требования со своей задачей.

Посмотреть программу курса. Для самостоятельной диагностики доступна подборка упражнений.

Источники и проверка

Примеры в статье авторские и учебные. Технические справочники: OpenTelemetry: GenAI.