Что значит, что модель экономнее расходует токены: как считать реальную стоимость API

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

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

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

Что значит, что модель экономнее расходует токены?

Фраза «модель экономнее расходует токены» может описывать несколько разных изменений. Это не единый показатель, а сокращение одного или нескольких компонентов запроса.

В простом сценарии есть четыре базовые величины:

• входные токены — системные инструкции, история диалога, вопрос пользователя и приложенные данные;
• видимые выходные токены — текст, код, JSON или другой результат, который получает приложение;
• скрытые токены рассуждений — внутренние шаги reasoning-модели, если провайдер учитывает их отдельно;
• число запросов — сколько обращений потребовалось до успешного завершения задачи.

Базовая формула выглядит так:

Стоимость задачи =
Σ(входные токены × тариф входа)
+ Σ(выходные токены × тариф выхода)
+ стоимость кэширования
+ стоимость дополнительных инструментов

Если модель создает ответ на 20 % короче, это означает только сокращение видимого вывода. Входной контекст может остаться прежним, а внутреннее рассуждение — стать длиннее. Если же новая модель чаще вызывает поиск, интерпретатор кода или функцию базы данных, число обращений увеличивается.

В официальной структуре статистики API уже встречаются отдельные поля для входных токенов, кэшированных входных токенов, выходных токенов, общего количества токенов и reasoning-токенов. Поэтому при проверке нельзя ограничиваться только полем total_tokens: сохраняйте детализацию каждого запроса. (platform.openai.com)

Четыре разных вида «экономии»

1. Более короткий ответ.
Модель перестает повторять условие, уменьшает пояснения или выдает компактный JSON. Это полезно, если ответ передается дальше по цепочке или сохраняется в базе. Однако для задачи «написать рабочий модуль» слишком короткий ответ может повысить число исправлений.

2. Меньше рассуждений.
Модель быстрее решает простые задачи при низком уровне reasoning. Здесь экономия может быть реальной, но только если качество не падает. Для сложной логики сокращение внутренних шагов часто превращается в дополнительные проверки, повторные запросы и ручную доработку.

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

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

Почему токенов меньше, а счет API не снизился?

Вход и выход имеют разную цену

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

Для Token Cost Calculator используйте не одну строку «токены на запрос», а минимум четыре столбца:

1. вход без кэша;
2. вход из кэша;
3. видимый вывод;
4. скрытые или промежуточные токены.

Некоторые API также отдельно отражают промежуточные данные, которые возникают при выполнении кода или использовании инструментов. В документации для выполнения кода указано, что сгенерированный код, результат выполнения и промежуточные этапы могут участвовать в расчетах как входные или выходные токены. (ai.google.dev)

Успешность задачи меняет цену сильнее, чем длина ответа

Предположим, старая модель выполняет задачу с первой попытки за 100 условных единиц стоимости, а новая тратит 70 единиц, но успешно завершает только 80 % запусков. Для оставшихся 20 % приложение повторяет запрос:

Средняя стоимость =
70 / 0,80 = 87,5 условной единицы

На первый взгляд новая модель дешевле, но экономия уже не 30 %, а 12,5 %. Если повторная попытка включает длинный контекст, инструменты и дополнительную валидацию, разница исчезает полностью.

На практике расходы увеличивают:

• автоматические повторы после тайм-аута;
• повторная генерация JSON после ошибки схемы;
• запросы «исправь предыдущий ответ»;
• ручное редактирование результата;
• повторная передача всего контекста вместо конкретного фрагмента.

Более дешевый ответ может вызвать больше обращений

Короткий ответ не равен завершенной работе. Если модель выдала неполный SQL-запрос, некорректный вызов функции или код без обработки исключений, оркестратор запускает следующий цикл. В итоге один короткий ответ становится частью длинной цепочки.

Важное наблюдение: сравнивайте не «стоимость одного ответа», а стоимость результата, который прошел автоматическую проверку и был принят системой без дополнительной генерации.

Кэш может не сработать

Кэширование снижает повторную передачу одинакового префикса, но только при соблюдении условий конкретного API. Часто меняющийся системный промпт, динамическая дата в начале сообщения, случайно переставленные инструкции или добавленный идентификатор пользователя могут разрушить совпадение префикса.

Документация по контекстному кэшированию указывает, что повторно используемый контент передается модели один раз, а последующие обращения могут использовать сохраненные входные токены по сниженной ставке. При этом учитываются размер кэша и срок его хранения; для некоторых режимов срок по умолчанию составляет 1 час. (ai.google.dev)

Почему многошаговый агент нельзя оценивать по одному запросу?

В чате человек видит один ответ. В AI Agent за ним могут скрываться десятки операций:

1. распознавание намерения;
2. планирование;
3. поиск в базе знаний;
4. вызов внешнего инструмента;
5. проверка результата;
6. исправление ошибки;
7. финальная формулировка.

Каждый следующий шаг часто получает историю предыдущих сообщений. Если агент отправляет полный журнал действий, объем входных токенов растет даже тогда, когда каждый отдельный ответ остается коротким.

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

Практический пример увеличения стоимости

Рассмотрим задачу «найти заказ и подготовить ответ клиенту»:

• первый запрос классифицирует обращение;
• второй ищет заказ;
• третий проверяет статус оплаты;
• четвертый формирует ответ;
• пятый повторяется из-за неверного формата JSON.

Даже если новая модель экономнее на каждом видимом ответе, пять обращений могут оказаться дороже трех обращений старой модели. Поэтому стоимость вызова большой языковой модели должна измеряться на уровне цепочки trace_id, а не только на уровне API-ответа.

Нужно ли считать рассуждения отдельно?

Да, если API предоставляет такую детализацию. У thinking-моделей внутренние рассуждения могут тарифицироваться вместе с выходом, хотя пользователю показывается только итог или краткое резюме. В официальной документации указано, что при включенном thinking стоимость ответа складывается из выходных и thinking-токенов; их количество можно получить из поля статистики использования. (ai.google.dev)

Как провести честный тест новой модели?

Ниже — последовательность, которую можно использовать перед сменой модели в рабочем сервисе.

Шаг 1. Зафиксируйте набор реальных задач

Возьмите не абстрактные вопросы, а обезличенные примеры из production:

• типовые обращения клиентов;
• реальные фрагменты кода;
• документы, которые пользователи действительно загружают;
• задачи с инструментальными вызовами;
• сложные случаи, где раньше требовалась ручная проверка.

Для первого сравнения достаточно 30–50 задач на один сценарий. Это не универсальная статистическая норма, а практический стартовый диапазон для внутреннего пилота. Если стоимость ошибки высока, увеличьте выборку и разделите ее по сложности.

Шаг 2. Заморозьте условия

Нельзя сравнивать новую модель с коротким промптом, а старую — с историей из production. Зафиксируйте:

• одинаковый системный промпт;
• одинаковый контекст;
• одинаковые инструменты;
• одинаковые ограничения на длину ответа;
• одинаковое число параллельных запусков;
• одинаковый критерий успешности.

Если меняется промпт, это уже не чистая миграция модели, а совместная оптимизация модели и приложения.

Шаг 3. Определите критерий «готово»

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

Без критерия успеха команда начнет объявлять дешевым любой короткий ответ.

Шаг 4. Сохраняйте детализацию каждого вызова

Минимальная запись должна включать:

task_id
trace_id
model
attempt
input_tokens
cached_input_tokens
output_tokens
reasoning_tokens
tool_calls
latency_ms
status
retry_reason
human_correction
estimated_cost

Если конкретный API не возвращает reasoning-токены, помечайте поле как неизвестное, а не подставляйте ноль. Иначе сравнение будет систематически занижать расходы модели с внутренним рассуждением.

Шаг 5. Повторите тест в несколько прогонов

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

Шаг 6. Посчитайте стоимость выполненной задачи

Используйте формулу:

Итоговая стоимость задачи =
стоимость всех входов
+ стоимость всех выходов
+ стоимость reasoning
+ стоимость кэширования
+ стоимость повторов

Затем добавьте бизнес-показатель:

Стоимость принятого результата =
итоговая стоимость задачи / доля успешных задач

Эта метрика лучше отвечает на вопрос, даст ли миграция экономию в production.

Какие показатели важны для разных сценариев?

В середине оценки полезно разделить задачи: одинаковый показатель не подходит для кода, документов и поддержки.

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

Вопрос: стоит ли всегда выбирать модель с самой низкой ценой за миллион токенов?

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

Вопрос: можно ли считать экономию по общему числу токенов?

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

Как сократить счет за счет кэша и контекста?

Начните не с уменьшения промпта, а с его разметки. Разделите сообщения на стабильную и динамическую части.

Стабильный префикс:

• правила поведения;
• формат ответа;
• описание инструментов;
• справочная документация;
• общие ограничения продукта.

Динамическая часть:

• текущий вопрос;
• идентификатор пользователя;
• свежие записи базы;
• дата и временные параметры;
• результаты предыдущего шага.

Стабильный префикс должен идти в начале, если механизм кэша использует совпадение начала запроса. Не добавляйте в него случайные значения и не меняйте порядок инструкций без необходимости. Проверяйте фактическое количество cached_input_tokens или аналогичного поля, а не предполагайте, что кэш работает автоматически. Официальное руководство по кэшированию описывает именно такой контроль через данные об использовании. (ai.google.dev)

Историю диалога также не нужно передавать целиком всегда. Практическая схема:

1. последние несколько сообщений оставлять без изменений;
2. старые сообщения сжимать в структурированное резюме;
3. удалять дублирующие системные пояснения;
4. передавать инструменту только необходимые поля;
5. ограничивать размер результата поиска;
6. хранить большие документы отдельно и извлекать релевантные фрагменты.

Важно учитывать стоимость хранения кэша. Если данные используются редко, длительный TTL может съесть часть экономии. Кэш полезен там, где один и тот же большой контекст действительно повторяется много раз.

Как настроить бюджет и найти аномалии после миграции?

После запуска не ограничивайтесь месячным счетом. Разделите стоимость API для большой языковой модели по нескольким измерениям:

• модель;
• продуктовая функция;
• пользователь или команда;
• тип задачи;
• trace_id;
• успешный и неуспешный запуск;
• интерактивный и пакетный режим.

Установите три уровня контроля:

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

Блокирующий лимит.
Останавливает бесконечный цикл агента, например после заданного числа шагов или превышения max_total_tokens.

Аномалия качества.
Показывает рост повторов, ручных исправлений, эскалаций или ошибок схемы. Это важно: счет может увеличиться не из-за тарифа, а из-за ухудшения поведения модели.

Еженедельный отчет должен отвечать на пять вопросов:

1. изменилась ли стоимость принятого результата;
2. выросло ли число запросов на одну задачу;
3. сколько входа приходится на кэш;
4. какие функции чаще всего запускают повтор;
5. не увеличилась ли длина истории в агентских цепочках.

Для команды, которая тестирует несколько моделей параллельно, полезна изолированная среда с фиксированными версиями SDK, логированием и контролируемыми ключами. В этом случае временная аренда Mac для тестирования разработческих сценариев может быть практичнее, чем смешивание экспериментов с рабочими машинами. Технические руководители также могут заранее сверить доступные условия через страницу тарифов ZilCloud.

Какие ошибки чаще всего искажают оценку?

Ошибка 1. Тестировать только короткие запросы

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

Ошибка 2. Сравнивать ответы без проверки результата

Короткий ответ может быть неполным. Для кода и структурированных данных это особенно опасно: визуально компактный JSON не означает валидный JSON.

Ошибка 3. Не учитывать повторы

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

Ошибка 4. Смешивать изменения

Если одновременно поменять модель, промпт, лимит вывода, схему инструментов и стратегию кэширования, вы не поймете, что именно дало эффект.

Ошибка 5. Принимать оценку провайдера за производственный счет

Официальная демонстрация обычно описывает типовой сценарий. В production меняются длина контекста, распределение задач, доля повторов, частота кэш-попаданий и количество пользователей.

Как принять решение о миграции без самообмана?

Соберите итоговую таблицу не по цене токена, а по четырем уровням:

1. техническая эффективность — токены, запросы, задержка;
2. качество — успешность, ошибки, ручные исправления;
3. полная стоимость задачи — все вызовы, инструменты, повторы и кэш;
4. операционная нагрузка — сложность мониторинга, стабильность SDK, лимиты и управление доступом.

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

Для тестов с новыми моделями можно вынести окружение отдельно: это упрощает воспроизводимость, не затрагивает рабочие настройки и позволяет сохранять одинаковые версии инструментов. По опыту команд, которые сравнивают цепочки вызовов, обычная схема на локальных ноутбуках быстро упирается в нехватку параллельных окружений, ручное переключение конфигураций и слабую изоляцию секретов. Облачный Mac через ZilCloud дает более удобную основу для краткосрочного пилота: можно отделить экспериментальный контур, воспроизвести сценарий агента и после завершения проверки не держать отдельное физическое устройство. Для запроса временной конфигурации подойдет форма заказа ZilCloud.

Главный вывод прост: экономия токенов — это сигнал для проверки, а не готовое доказательство экономии. Сначала измерьте полную стоимость успешной задачи, затем проверьте повторы, кэш, рассуждения и инструментальные вызовы. Только после этого обещание «модель расходует меньше токенов» превращается в финансово подтвержденное решение о миграции.

Читайте также

• Как выбрать модель для разных задач и требований к стоимости
• Сравнение моделей для вывода и практическая оценка производительности
• Инфраструктура ИИ-агентов: руководство по запуску и оптимизации