Почему цены за миллион токенов недостаточно
Сравнение прайс-листов — удобный первый шаг, но оно не отвечает на главный практический вопрос: сколько будет стоить выполнить вашу задачу с приемлемым качеством?
В простом запросе учитываются входные и выходные токены. В агентном сценарии к ним добавляются вызовы инструментов и модели, повторные попытки, вспомогательные запросы и обработка ошибок. Один пользовательский запрос может привести к нескольким обращениям к API. А если дешёвая модель чаще ошибается и требует повторного запуска, стоимость успешного результата окажется выше ожидаемой.
Полезнее считать не цену отдельного вызова, а стоимость завершённой задачи. Такой подход позволяет сравнивать модели на одинаковых данных и с одинаковыми критериями качества. Он также показывает, где именно растут расходы: из-за длинного контекста, ответов, повторов или сложного маршрута агента.
Как оценить стоимость LLM для одного сценария
Начните с конкретной задачи, а не с усреднённого «запроса к модели». Например: разобрать обращение в поддержку, определить категорию, извлечь номер заказа и сформировать ответ по базе инструкций.
Для каждого запуска фиксируйте:
- входные токены, включая системную инструкцию и переданный контекст;
- выходные токены;
- число запросов к каждой модели;
- число вызовов инструментов, если они тарифицируются отдельно;
- повторы и причину каждого повтора;
- результат проверки: задача выполнена или нет.
Базовая формула для одного вызова выглядит так:
`стоимость = входные токены × цена входных токенов + выходные токены × цена выходных токенов`
Перед подстановкой проверьте единицы в прайс-листе: тарифы часто указаны за миллион токенов. Тогда расчёт для обычного запроса будет таким:
`стоимость запроса = (входные токены / 1 000 000 × ставка входа) + (выходные токены / 1 000 000 × ставка выхода)`
Если ставка зависит от типа токенов — например, для кэшированного входа, аудио или изображений — соответствующие части нужно считать отдельно. Актуальные тарифы следует брать из официальной страницы поставщика: цены и доступность функций меняются.
Считайте весь маршрут, а не только финальный ответ
Предположим, агент сначала классифицирует обращение, затем ищет сведения в базе и после этого пишет ответ. Даже если пользователь отправил один запрос, внутри могут произойти несколько модельных вызовов.
Для маршрута из трёх обращений стоимость одной попытки равна сумме стоимости каждого обращения. Если одно из них отправляется повторно после ошибки, повтор тоже включается в расчёт. При этом вызов инструмента сам по себе не всегда тарифицируется поставщиком LLM, но может создавать расходы на поиск, выполнение кода или сторонний API.
Сведите журнал в таблицу или CSV со столбцами `task_id`, `model`, `input_tokens`, `output_tokens`, `cached_tokens`, `tool_calls`, `retry`, `success`. Для агента добавьте `step` и `retry_reason`, чтобы отличать повтор после таймаута от повтора из-за неудовлетворительного ответа. Не смешивайте эти случаи: технический сбой и ошибка модели требуют разных решений.
Посчитайте сумму расходов по одному `task_id`, а затем сравните её с фактом успешного выполнения. Если задача провалилась, стоимость не исчезает: ресурсы уже потрачены. Разделение успешных и неуспешных запусков помогает увидеть, не субсидируют ли удачные попытки длинную цепочку безрезультатных запросов.
Сравнивайте стоимость успешного результата
Низкая стоимость вызова не означает низкую стоимость работы. Если одна модель справляется с задачей в 85% случаев, а другая — в 95%, сравнивать только средний чек вызова недостаточно.
Для грубой оценки можно использовать:
`стоимость успешной задачи ≈ средняя стоимость попытки / доля успешных попыток`
Например, при средней стоимости попытки 0,01 условной денежной единицы и доле успеха 80% оценка составит 0,0125 за успешную задачу. Это приближение: оно предполагает, что попытки сопоставимы, а повторные запуски не меняют вероятность успеха. Если система повторяет запросы до успеха или останавливается после заданного лимита, лучше считать фактические расходы по полным цепочкам.
Создайте небольшой проверочный набор из реальных, обезличенных задач. Для каждого примера заранее определите, что считается успехом: правильная категория, валидный JSON, верные извлечённые поля или ответ, подтверждённый источником. Запустите каждую модель на тех же примерах и сохраните как стоимость, так и результат проверки.
Не заменяйте критерий качества впечатлением «ответ выглядит хорошо». Проверка должна быть воспроизводимой: схема для структурированного вывода, эталонные поля для извлечения данных или оценка человеком по заранее заданной шкале. Если автоматическая оценка тоже использует LLM, отдельно учитывайте её стоимость и проверяйте, насколько она согласуется с ручной оценкой.
Учтите повторы, лимиты и кэш
Повторные запросы влияют на итог по-разному. Повтор после временной ошибки API может быть необходим для надёжности; повтор после плохого ответа — признак того, что нужно проверить модель, инструкцию или критерий остановки. В обоих случаях токены повторного обращения входят в расход.
Измеряйте долю повторов и среднее число вызовов на завершённую задачу. Если у сервиса есть лимит повторов, включите его в тест. Без ограничения цепочка иногда продолжает расходовать ресурсы на задачу, которую не может решить. Для безопасного сравнения зафиксируйте число попыток и одинаковые условия остановки для всех кандидатов.
Кэширование способно уменьшить стоимость повторно используемого контекста, но эффект зависит от условий конкретного API: какие части запроса подходят для кэша, как долго они сохраняются и как тарифицируются. Документация OpenAI, например, описывает prompt caching как отдельный механизм; перед расчётом проверьте действующие требования и тарифы провайдера.
В тесте не предполагайте, что любой повтор идентичного текста обязательно будет кэширован. Записывайте фактические показатели использования кэша, если API их возвращает. Иначе расчёт покажет оптимистичный сценарий, который может не повториться в production.
Проведите тест на своих данных
Практический протокол можно выполнить локально, даже если сам вызов модели остаётся платным:
Возьмите несколько десятков типичных задач и, если возможно, добавьте сложные и редкие случаи.
2. Удалите персональные и конфиденциальные данные либо замените их безопасными фиктивными значениями.
3. Зафиксируйте системную инструкцию, параметры генерации, инструменты и правила повторов.
4. Запустите каждую модель на одинаковом наборе и сохраните сырые ответы, метаданные использования и ошибки.
5. Проверьте качество по заранее определённым правилам.
6. Рассчитайте общую стоимость, долю успешных задач и стоимость одного успешного результата.
Для повторяемости сохраняйте дату теста, идентификатор модели, версию промпта и настройки. Если модель доступна под изменяемым псевдонимом, одного названия может быть недостаточно для воспроизведения: запишите точный идентификатор, который возвращает API, если он доступен. Проверяйте, что сравнение не смешивает разные лимиты контекста, режимы рассуждения или дополнительные функции, оплачиваемые отдельно.
Такой тест не доказывает, что модель будет вести себя так же на всём потоке. Он показывает результат на конкретном наборе и помогает отсеять неподходящие варианты до масштабирования.
Рассчитайте месячный бюджет без ложной точности
Когда стоимость задачи измерена, умножьте её на ожидаемый объём. Но вместо одного среднего значения полезно построить три сценария: обычный, высокий и пиковый. Для каждого задайте число задач, долю длинных запросов и ожидаемую частоту повторов.
Например, если обращения различаются по сложности, разделите их на простые и сложные типы. Посчитайте стоимость каждого типа отдельно, а затем примените прогнозируемую долю в общем трафике. Такой расчёт лучше отражает ситуацию, когда небольшое число сложных запросов поглощает значительную часть бюджета.
Не выдавайте прогноз за точный счёт: реальные расходы зависят от распределения длины запросов, поведения пользователей и ошибок. После запуска сверяйте расчёт с биллингом провайдера. Если объёмы по журналу API и счёту расходятся, проверьте, одинаково ли учитываются отменённые запросы, кэшированные токены, мультимодальные данные и вызовы дополнительных сервисов.
Для управляемого бюджета установите лимиты на размер контекста, длину ответа, число шагов агента и количество повторов. Это не гарантирует заданную стоимость каждой задачи, но ограничивает сценарии, в которых один запрос превращается в длинную цепочку обращений.
Что проверить перед выбором модели
Перед переходом на более дешёвую модель сравните не рекламную цену, а полный тестовый маршрут. Убедитесь, что:
- все кандидаты решали одни и те же задачи;
- качество оценивалось по одинаковым правилам;
- в расходы вошли повторы и дополнительные вызовы;
- тарифы проверены по официальной документации на дату расчёта;
- кэш учитывался только при подтверждённом использовании;
- бюджетный прогноз основан на фактическом составе запросов;
- выводы ограничены проверенным набором данных.
Начните с небольшого теста и сохраните журнал запусков. Если более дешёвая модель проходит критерии качества с сопоставимой стоимостью успешной задачи, её можно проверить на ограниченной доле реального трафика. Если нет — данные покажут, какая часть сценария создаёт разницу: качество, длина ответа, число шагов или частота повторов.
