Цена модели в прайс-листе отвечает только на один вопрос: сколько стоит обработать заданное количество токенов по конкретному тарифу. Она не говорит, сколько будет стоить ваша функция — например, разбор одного обращения в поддержку или исправление ошибки в коде.
Чтобы сравнить провайдеров и модели, считайте стоимость LLM на завершённый сценарий: вместе с системной инструкцией, историей диалога, повторными вызовами инструментов и долей ответов, которые действительно решают задачу. Такой расчёт не требует сложной платформы наблюдаемости: достаточно зафиксировать расход токенов на реальных или воспроизводимых примерах и проверить его на небольшой выборке.
Стоимость LLM: что считать, кроме цены за токен
У API обычно есть отдельные тарифы для входных и выходных токенов. Вход — это не только вопрос пользователя: туда могут попасть системная инструкция, история переписки, найденные документы и описание доступных инструментов. Выход — ответ модели, а в агентном сценарии ещё и сгенерированные вызовы инструментов.
Базовая формула для одного запроса:
> Стоимость = входные токены × тариф на вход + выходные токены × тариф на выход.
Тарифы провайдеров меняются, могут различаться по модели, контексту, кэшированию и типу обработки. Поэтому подставляйте значения из актуальной страницы конкретного API, а не из обзора или старого скриншота. Например, OpenAI, Anthropic и Google публикуют тарифы в собственных документациях; условия для кэшированного ввода и отдельных режимов могут отличаться от стандартной цены.
Однако даже точная сумма за один вызов мало что говорит о расходе на функцию. Один пользовательский запрос может породить несколько обращений к модели, а часть ответов потребует исправления или ручной проверки.
Сначала разложите задачу на вызовы
Возьмите конкретный сценарий — например, подготовку краткого ответа на обращение из базы знаний. Опишите путь запроса, не объединяя все этапы в одну строку:
Модель получает инструкцию и формирует поисковый запрос.
Приложение извлекает документы.
3. Модель получает найденные фрагменты и составляет ответ.
4. Валидатор обнаруживает ошибку формата — приложение запрашивает исправление.
5. Если ответ не прошёл проверку, запрос передаётся человеку.
Не каждый сценарий включает все этапы. Важно измерить именно те, которые есть в вашей реализации. Для вызова инструмента учитывайте и запрос к модели, и возможное продолжение после получения результата инструмента. Сам инструмент может иметь собственную стоимость — например, плату за поиск или выполнение операции, — которую нужно учитывать отдельно от токенов.
Удобно вести запись на уровне одного пользовательского задания: идентификатор сценария, модель, число вызовов, входные и выходные токены каждого вызова, причина повтора и результат проверки. Тогда станет видно, что увеличивает расход: большой контекст, длинные ответы, повторные попытки или неудачно выбранный маршрут.
Рассчитайте цену на одном воспроизводимом примере
Предположим, система за один запрос использовала 2 000 входных и 500 выходных токенов, а затем сделала повторный вызов с 2 500 входными и 400 выходными токенами. Обозначим тарифы как Pвх и Pвых за миллион токенов. Тогда стоимость двух вызовов составит:
> (2 000 + 2 500) / 1 000 000 × Pвх
> + (500 + 400) / 1 000 000 × Pвых.
Если тарификация включает отдельную цену для части входа, например кэшированного контекста, вынесите её в отдельное слагаемое и используйте правила из документации провайдера. Не считайте, что повторный запрос автоматически дешевле: это зависит от того, что именно провайдер распознаёт как кэшируемый ввод и какие условия применяются.
Чтобы воспроизвести расчёт, сохраните фактическое использование токенов из ответа API или телеметрии приложения. Не заменяйте его оценкой «примерно столько-то слов»: токенизация зависит от модели и текста. Для предварительной прикидки оценки может хватить, но решение о бюджете лучше принимать по измеренному расходу.
Как сравнить модели, не выбрав самую дешёвую вслепую
Подготовьте небольшой набор репрезентативных заданий: обычные, сложные и пограничные случаи. Запустите каждую модель на одинаковых входных данных и с одинаковыми ограничениями, а затем проверьте результаты по критериям, которые важны для задачи.
Для извлечения полей такими критериями могут быть валидность JSON и точность значений. Для ответа по базе знаний — подтверждение выводов источниками и доля случаев, где ответ следует передать человеку. Для кодового агента — прохождение тестов и необходимость ручных исправлений. Один общий балл может скрыть существенные различия, поэтому сохраняйте как качество, так и стоимость каждого задания.
Сравнивайте не только среднее значение. Несколько длинных или проблемных запросов могут заметно увеличить счёт. Посмотрите на медиану и верхний квартиль стоимости, отдельно отметьте случаи с повторами и сбоями. При малой выборке эти оценки нестабильны: считайте их первоначальным замером, а не гарантией будущих затрат.
Главный показатель для выбора — не «цена за миллион токенов», а стоимость ответа, который прошёл проверку и пригоден для использования. Если дешёвая модель ошибается чаще и требует повторов, её фактическая стоимость полезного результата может оказаться выше.
Контекст и повторы: два расхода, которые легко пропустить
В чат-приложении к каждому новому запросу иногда добавляется история переписки. Чем длиннее диалог, тем больше входных данных модель может обработать. При retrieval-augmented generation дополнительный расход создают найденные фрагменты и метаданные. Измерьте размер именно того контекста, который действительно передаётся в API.
Повторы тоже неодинаковы. Один может быть автоматическим повтором после сетевой ошибки; другой — новым запросом, потому что модель выдала некорректный формат. Разделяйте их в метриках: первый влияет на надёжность доставки, второй может указывать на проблему инструкции, валидации или выбранной модели.
Практический разбор начинается с нескольких вопросов:
- Какие части контекста нужны для решения задачи, а какие добавляются «на всякий случай»?
- Можно ли ограничить объём истории или выбирать релевантные фрагменты вместо передачи всех документов?
- Почему срабатывают повторы: из-за временной ошибки API, неверного формата или неудовлетворительного ответа?
- Сохраняется ли качество после изменения контекста или числа попыток?
Документация провайдеров описывает настройки и способы оптимизации, но конкретный выигрыш зависит от вашего приложения. Сокращение контекста может снизить расход, но если удалить нужные данные, возрастёт число ошибочных ответов и повторов. Проверяйте изменения на том же наборе задач.
Когда полезны кэширование и маршрутизация
Кэширование может быть уместно, если запросы повторно содержат неизменный префикс — например, большую системную инструкцию. Но доступность, формат и тарификация функции зависят от API. Сверяйте требования к совпадению контекста и условия оплаты у выбранного провайдера; сам факт повторного использования текста ещё не доказывает, что он будет тарифицирован как кэшированный.
Маршрутизация отправляет разные задачи разным моделям. Простая классификация может обрабатываться одной моделью, а сложный запрос — более сильной. Это способ управлять расходом, но добавляет условия: нужен критерий маршрутизации и проверка его ошибок. Если сложное задание ошибочно направлено на слабую модель, последующие повторы могут съесть предполагаемую экономию.
Проверяйте оба изменения как эксперимент: сравните базовый вариант и оптимизированный на одном наборе запросов, учитывая полную стоимость вызовов и качество. Не переносите рекламное или внутреннее обещание экономии на собственный трафик без такого замера. Различия в распределении запросов, размере контекста и доле ошибок могут изменить результат.
Переведите расход запроса в бюджет продукта
После измерения стоимости отдельных заданий оцените ожидаемую нагрузку. Например, если функция обрабатывает несколько типов запросов, считайте каждый тип отдельно: у короткого FAQ и длинного разбора документа будут разные распределения токенов и повторов.
Для предварительного месячного бюджета умножьте число запросов каждого типа на его измеренную среднюю стоимость и сложите результаты. Затем отдельно посчитайте сценарий повышенной нагрузки — например, используя верхний квартиль расхода вместо среднего. Это не заменяет учёт фактического трафика, но помогает увидеть, чувствителен ли бюджет к небольшому числу дорогих запросов.
Не забудьте о расходах вне модели: поисковом API, хранении, исполнении кода и ручной проверке. Их нельзя корректно спрятать в «цену токена». В итоговом расчёте держите отдельные строки для генерации и сопутствующих операций — так будет проще понять, где именно появилась разница.
Минимальная проверка перед запуском
Перед тем как выбрать модель или объявить функцию дешёвой, проверьте четыре вещи:
- Тарифы: актуальны ли цены и правила для выбранной модели, региона, типа токенов и режима обработки?
- Репрезентативность: включает ли тестовый набор обычные запросы, длинный контекст и трудные случаи?
- Полная стоимость: учтены ли все вызовы, повторы, инструменты и обработка неудачных ответов?
- Пригодность результата: измеряете ли вы долю заданий, которые прошли проверку, а не только число успешных ответов API?
После запуска сравнивайте фактический расход с тестовой оценкой по типам задач. Если стоимость выросла, сначала проверьте изменения в среднем размере контекста, числе вызовов и доле повторов. Это конкретнее, чем менять модель по одному счёту и надеяться, что новая цена за токен решит проблему.
