Цена токена в прайс-листе — не стоимость пользовательской задачи. Чтобы оценить стоимость LLM, нужно посчитать все обращения, которые возникают при одном завершённом сценарии: от первого запроса до финального ответа, включая повторные попытки, вызовы инструментов и обработку ошибок.
Такой расчёт помогает выбрать модель и понять, окупится ли кэширование или сокращение контекста. Ниже — практический способ собрать оценку на собственных запросах, не подменяя её рекламной ценой за миллион токенов.
Почему стоимость LLM нельзя вывести из одного запроса
У многих API отдельные тарифы для входных и выходных токенов. Некоторые поставщики также выделяют кэшированные входные токены, длинный контекст или обработку пакетами. Поэтому формула зависит от конкретного тарифа.
Для простого запроса без кэширования расчёт выглядит так:
Стоимость = входные токены × цена входа + выходные токены × цена выхода.
Если тариф указан за миллион токенов, количество токенов делят на 1 000 000. Но в продукте задача редко ограничивается одним запросом. Например, агент может сначала классифицировать обращение, затем вызвать поиск, передать результаты модели и сформировать ответ. Каждый шаг способен создать отдельную платную операцию.
Кроме того, длина запроса меняется. К истории диалога добавляются инструкции, результаты поиска и предыдущие ответы. Усреднять стоимость по одному короткому тесту рискованно: такой тест не отражает ни длинный контекст, ни повторные вызовы.
Как посчитать стоимость LLM для одного сценария
Начните не с выбора модели, а с описания задачи. Зафиксируйте, что считается одним завершённым действием пользователя, и перечислите все запросы к модели внутри него.
Например, сценарий «ответить на вопрос по базе знаний» может включать:
запрос для определения намерения пользователя;
обращение к поиску или RAG-системе;
3. передачу найденных фрагментов модели;
4. повторный запрос, если ответ не прошёл проверку формата.
Инструментальный вызов сам по себе не обязательно является запросом к LLM, но результат инструмента может стать частью следующего входного контекста. Включайте в расчёт только те операции, которые действительно тарифицируются выбранным поставщиком.
Для каждого вызова записывайте отдельно:
- число входных токенов;
- число выходных токенов;
- тип модели и тариф;
- кэшированные токены, если они тарифицируются иначе;
- вероятность повтора или дополнительного шага.
Дальше вычислите цену каждого вызова и сложите её. Для ожидаемой стоимости сценария учитывайте частоту дополнительных шагов. Если 10% запросов требуют ещё одного вызова стоимостью 0,004 доллара, ожидаемая добавка составляет 0,0004 доллара на пользовательскую задачу. Это оценка среднего, а не гарантия для каждого запроса.
Возьмите данные использования, а не длину текста
Количество слов не позволяет надёжно определить число токенов: результат зависит от языка, разбиения токенизатором и содержимого запроса. Код, JSON, таблицы и кириллица могут давать другую токенизацию, чем обычный английский текст.
Надёжнее собирать usage-метрики из ответов API. Проверьте документацию конкретного поставщика: названия полей и учёт кэша отличаются. Например, в API могут отдельно отражаться входные и выходные токены, а сведения о кэшированных токенах — передаваться в дополнительном поле.
Для воспроизводимой оценки возьмите выборку реальных задач, скрыв персональные данные и секреты. Включите обычные, короткие и длинные случаи, а также запросы, которые приводят к повторам. Для каждого сохраните:
- тип сценария и число вызовов;
- usage каждого вызова;
- результат выполнения: успех, ошибка, повтор;
- длительность, если задержка важна для продукта.
Рассчитайте не только среднее, но и медиану и верхний перцентиль. Среднее показывает общий расход на длинной дистанции, а высокий перцентиль помогает увидеть дорогие случаи, которые могут быть редкими, но заметными для бюджета.
Пример расчёта с несколькими вызовами
Предположим, задача состоит из двух запросов: первый получает 1 200 входных и 100 выходных токенов, второй — 3 000 входных и 500 выходных. Для примера используем условные тарифы: 2 доллара за миллион входных и 8 долларов за миллион выходных токенов. Это не актуальная цена конкретного поставщика.
Первый вызов стоит:
- вход: 1 200 × 2 / 1 000 000 = 0,0024 доллара;
- выход: 100 × 8 / 1 000 000 = 0,0008 доллара;
- всего: 0,0032 доллара.
Второй:
- вход: 3 000 × 2 / 1 000 000 = 0,006 доллара;
- выход: 500 × 8 / 1 000 000 = 0,004 доллара;
- всего: 0,01 доллара.
Итоговая цена задачи — 0,0132 доллара. Если считать только первый запрос, оценка окажется ниже почти в четыре раза. Если второй вызов возникает лишь в половине случаев, ожидаемая стоимость равна 0,0032 + 0,5 × 0,01 = 0,0082 доллара.
В реальном расчёте подставьте тарифы из актуальной документации поставщика и реальные показатели API. Учитывайте валюту, округление и возможные отдельные условия тарификации.
Повторы и отказы: считайте вероятность, а не максимум
Автоматические повторы способны заметно изменить расход. При таймауте клиент может повторить запрос, хотя сервер уже обработал исходный вызов. Если повтор создаёт новое тарифицируемое обращение, стоимость растёт; поведение зависит от API и конкретной ошибки.
Разделите повторы по причинам: временная ошибка сети, ограничение частоты, невалидный ответ модели или бизнес-логика приложения. Для каждой категории измерьте долю повторов и число дополнительных вызовов.
Простая оценка ожидаемых затрат:
Ожидаемая стоимость = базовая стоимость + сумма (вероятность дополнительного шага × его стоимость).
Не закладывайте один универсальный процент на все запросы. Например, повтор после сетевого сбоя может зависеть от инфраструктуры, а повтор из-за несоответствия JSON-схеме — от качества инструкции и модели. Сведите показатели по типу сценария, иначе редкий дорогой маршрут исказит оценку обычного запроса.
Кэширование и длинный контекст меняют расчёт
Кэширование префикса может снизить цену повторяющейся части контекста, но условия зависят от поставщика: какие токены подходят, сколько длится кэш и как тарифицируются запись и чтение. Не считайте весь повторный запрос кэшированным автоматически. Проверьте документацию и фактические usage-поля.
Для оценки сравните два варианта на одной выборке:
- обычный запрос с полной инструкцией;
- запрос с включённым поддерживаемым механизмом кэширования.
Сравнивайте общую стоимость сценария и качество результата, а не только цену входных токенов. Сокращение контекста тоже может сэкономить деньги, но способно убрать важные данные и ухудшить ответы. Проверьте это на тестовом наборе с заранее заданными критериями.
Длинный контекст учитывайте отдельно: некоторые тарифы меняются при превышении порога длины, а у разных моделей могут отличаться правила подсчёта. Перед расчётом проверьте текущую страницу цен и ограничения API, а затем подтвердите результат по журналу использования.
Сравнивайте модели по цене успешной задачи
Модель с более дешёвыми токенами может чаще требовать повторов или дополнительной проверки. Поэтому полезная метрика — стоимость корректно завершённой задачи, а не стоимость одного вызова.
Проведите сравнение на одних и тех же входных данных. Для каждой модели измерьте:
- долю задач, прошедших критерии качества;
- число вызовов на успешный результат;
- токены на весь сценарий;
- частоту ошибок и повторов;
- задержку, если она влияет на продукт.
Сначала определите, что означает «успешный результат». Для извлечения данных это может быть совпадение с эталонной структурой и корректность ключевых полей; для ответа по документам — наличие подтверждения в источнике. Без фиксированных критериев сравнение моделей превращается в оценку впечатлений.
Затем сопоставьте стоимость успешной задачи:
Расходы на тестовую выборку / число задач, прошедших проверку.
Метрика не заменяет анализ ошибок: две модели с похожей средней ценой могут проваливаться на разных типах запросов. Смотрите результаты по сегментам и оставляйте для сравнения одинаковые условия — промпт, лимиты, инструменты и правила повторов.
Как проверить расчёт после запуска
До запуска оценка остаётся прогнозом. После интеграции сверяйте собственную телеметрию с биллингом поставщика. Расхождения могут появиться из-за неучтённых вызовов, отличий в подсчёте токенов, кэширования, пакетной обработки или обработки ошибок.
Полезно сохранять идентификатор сценария, модель, число вызовов, usage и статус результата. Не записывайте в аналитические логи секреты и персональные данные; при необходимости сохраняйте только агрегированные показатели.
Для регулярного контроля пересчитывайте стоимость на скользящем периоде и отдельно отслеживайте:
- расходы на одну завершённую задачу;
- долю повторных вызовов;
- среднее и высокие перцентили токенов;
- изменение доли кэшированных входов;
- стоимость задач, не прошедших проверку качества.
Перед пересмотром бюджета обновите тарифы по официальным страницам поставщика: цены и правила тарификации меняются. Затем повторите расчёт на свежей выборке и проверьте, не изменились ли модель, промпт, длина контекста или логика маршрутизации.
