Введение
Структурированный вывод стал одним из самых безопасных способов интеграции больших языковых моделей (LLM) в производственные системы. Вы передаете JSON-схему в вызов API своей LLM, и гарантируется, что ответ будет соответствовать этой структуре. Никаких сбоев синтаксического анализа, некорректных ответов или логики повторных попыток.
JSON-схемы увеличивают использование входных токенов, поскольку схема включается в каждый запрос, отправляемый модели. В зависимости от провайдера эти накладные расходы составляют от почти пренебрежимо малых до более чем десяти раз превышающих размер исходного промпта.
В этой статье вы увидите измерения по нескольким моделям и узнаете, как сократить эти накладные расходы.
Краткая памятка для тех, кто менее знаком с выставлением счетов в LLM: языковые модели обрабатывают текст как токены — фрагменты слов, примерно по 3–4 символа каждый. Вы платите за токен как за то, что отправляете (входные токены), так и за то, что получаете обратно (выходные токены). Когда что-то незаметно добавляет токены к вашему вызову API, это напрямую увеличивает ваш счет.
Центр экспертизы искусственного интеллекта (CoE) в компании Vonage внедрил структурированный вывод во все наши пайплайны: анализ тональности, извлечение сущностей и оценку взаимодействия с клиентами. Улучшение опыта разработчиков было мгновенным.
Однако во время тестирования мы заметили неожиданную закономерность. Использование токенов стабильно превышало то, что должны были давать одни лишь наши промпты — недостаточно, чтобы вызвать тревогу, но достаточно, чтобы это заметить. Мы запускали короткие аналитические промпты, возможно, по 100 токенов каждый, через модели с привязанными JSON-схемами. Размер промпта был ничтожно мал, так откуда же брались лишние токены? Мы провели эксперимент, чтобы выяснить это.
Количественная оценка накладных расходов схемы
Документация по структурированному выводу рассказывает, как им пользоваться, но не говорит о том, во сколько он обходится. У каждого провайдера есть страница «Структурированный вывод», объясняющая параметры API. Ни один из них не объясняет, что происходит с количеством токенов при прикреплении схемы.
Мы хотели ответить на один простой вопрос: когда вы передаете JSON-схему в LLM, сколько дополнительных входных токенов это на самом деле добавляет?
Настройка была намеренно минималистичной. Тот же промпт, та же системная инструкция, та же температура. Единственной переменной было то, прикреплена ли схема и насколько она сложна.
Мы протестировали пять схем, от тривиально простых до производственного уровня. Минимальная схема состояла всего из одного поля (88 символов JSON):
Исходя из этого, мы увеличивали сложность:
- Простая — три поля с ограничением перечисления (enum) (237 символов)
Простая — три поля с ограничением перечисления (enum) (237 символов)
- Средняя — вложенный объект с массивами (358 символов)
Средняя — вложенный объект с массивами (358 символов)
- Сложная — массивы объектов с перечислениями (555 символов)
Сложная — массивы объектов с перечислениями (555 символов)
- Очень сложная — глубокая вложенность, несколько массивов, булевы значения, перечисления (1730 символов)
Очень сложная — глубокая вложенность, несколько массивов, булевы значения, перечисления (1730 символов)
Сам промпт представлял собой короткое взаимодействие со службой поддержки, занимающее около 99 токенов в токенизаторе Gemini и 121 в Claude. Разные токенизаторы разбивают один и тот же текст по-разному, что объясняет исходный разрыв между провайдерами. Мы сделали промпт намеренно маленьким, так как хотели увидеть накладные расходы изолированно, а не скрытыми под длинным контекстом.
Мы запустили его на трех моделях: Gemini 2.5 Flash, Gemini 3.5 Flash и Claude Haiku 4.5.
Сколько накладных расходов добавляет JSON-схема?
На графике ниже показано общее количество входных токенов, зарегистрированных каждой моделью для всех пяти уровней сложности схем. Серые базовые полосы представляют тот же промпт, отправленный без какой-либо прикрепленной схемы.
Результаты показывают четкую закономерность. Как и ожидалось, увеличение сложности приводит к росту потребления токенов во всех трех моделях. Но есть один явный лидер: Gemini 2.5 Flash остается близкой к базовому уровню на протяжении всего времени. Для глубоко вложенной схемы Gemini 2.5 Flash использует 186 токенов по сравнению с 1189 у Claude Haiku 4.5.
Учет токенов у разных провайдеров немного отличается, поэтому эти измерения отражают учитываемые в счетах токены, а не детали внутренней реализации.
Почему короткие промпты обходятся дороже
По отдельности токены стоят дешево. Но картина затрат меняется в зависимости от вашего сценария использования.
Если вы используете структурированный вывод для длинных документов — скажем, с входными данными от 5000+ токенов, — накладные расходы ничтожно малы. Несколько сотен лишних токенов поверх 5000 — это погрешность округления.
Но большинство производственных вызовов структурированного вывода не имеют длинного контекста. Это короткие аналитические задачи:
- Классифицировать это сообщение клиента (тональность, намерение, срочность)
Классифицировать это сообщение клиента (тональность, намерение, срочность)
- Извлечь сущности из этого предложения
Извлечь сущности из этого предложения
- Оценить это взаимодействие по пяти параметрам
Оценить это взаимодействие по пяти параметрам
- Направить этот тикет в нужный отдел
Направить этот тикет в нужный отдел
Эти промпты обычно составляют 50–500 токенов. При таком масштабе накладные расходы становятся основным фактором в вашем счете за входные токены.
Рассмотрим схему средней сложности на Claude Haiku 4.5 с промптом на 100 токенов:
- Без схемы: 121 входной токен
Без схемы: 121 входной токен
- Со схемой: 415 входных токенов
Со схемой: 415 входных токенов
- Накладные расходы: 71% от вашего общего счета за входные данные
Накладные расходы: 71% от вашего общего счета за входные данные
Вы платите за входные токены почти в 3,5 раза больше, чем требует ваш фактический контент. Умножьте это на миллионы вызовов API в месяц, и это станет существенным фактором затрат.
Выбор правильной модели для структурированного вывода
Вот где становится интересно для всех, кто оценивает модели для производственных рабочих нагрузок.
При полезной нагрузке в 100 токенов со схемой средней сложности:
Модель
Эффективные входные данные
Цена за млн токенов
Стоимость за 1 млн вызовов
Gemini 2.5 Flash
124 токена
$0,30
$37,20
Gemini 3.5 Flash
264 токена
$1,50
$396,00
Claude Haiku 4.5
415 токенов
$0,80
$332,00
- Цены по состоянию на июль 2026 года
Цены по состоянию на июль 2026 года
Gemini 2.5 Flash примерно в девять раз дешевле Claude Haiku и в одиннадцать раз дешевле Gemini 3.5 Flash для этого конкретного сценария использования. Не только из-за базовых цен, но и из-за того, как каждая модель обрабатывает схему изнутри.
Коэффициенты базовых цен (Haiku в 2,7 раза дороже 2.5 Flash за токен) усиливаются накладными расходами до гораздо больших различий в эффективной стоимости.
Когда накладные расходы перестают иметь значение
Накладные расходы представляют собой фиксированную стоимость за вызов. По мере роста вашей входной полезной нагрузки они растворяются:
- При 500 токенах (короткое сообщение клиента с контекстом) — средняя схема добавляет 37% у Haiku
При 500 токенах (короткое сообщение клиента с контекстом) — средняя схема добавляет 37% у Haiku
- При 2000 токенах (полная стенограмма разговора) — снижается до 13%
При 2000 токенах (полная стенограмма разговора) — снижается до 13%
- При 5000 токенах (сводка документа или фрагмент контекста RAG) — менее 6%
При 5000 токенах (сводка документа или фрагмент контекста RAG) — менее 6%
- При 10 000 токенах (длинный документ или история из нескольких реплик) — примерно 3%
При 10 000 токенах (длинный документ или история из нескольких реплик) — примерно 3%
Если ваша рабочая нагрузка связана с суммированием документов, запуском RAG по извлеченным фрагментам или анализом полных стенограмм разговоров, накладные расходы практически ничтожны. В основном это вызывает беспокойство при больших объемах работы с короткими промптами, таких как классификация, маршрутизация и извлечение сущностей.
Почему схемы JSON увеличивают использование токенов
Когда вы передаете схему JSON через API, модели обрабатывают ее в целом двумя способами:
Компактное кодирование — схема обрабатывается эффективно, возможно, в виде специальных токенов или сжатой инструкции. Gemini 2.5 Flash, судя по всему, кодирует схемы именно так. Накладные расходы минимальны и медленно растут по мере увеличения размера схемы.
Подробное развертывание — схема преобразуется в инструкции на естественном языке, в которых явно прописано каждое ограничение. Судя по количеству токенов, именно так поступают Gemini 3.5 Flash и Claude Haiku, что объясняет, почему их накладные расходы растут примерно линейно в зависимости от количества символов в схеме.
Подробный подход, вероятно, обеспечивает более надежное соблюдение схем для сложных структур, но это влечет за собой затраты токенов, о которых не заявляет ни один провайдер.
Снижение накладных расходов
Вот как их сократить:
- Сделайте схемы минимальными. Удалите поля, которые вы не используете в своем последующем коде. Упростите вложенные структуры, где иерархия не является семантически необходимой. Помещайте описания и примеры в свой промпт, а не в само определение схемы. Схема, уменьшенная с 1730 до 555 символов, экономит вам примерно 650 токенов за вызов на Claude. У Claude накладные расходы на схему составляют от 0.6 до 1.6 дополнительных токенов на один символ JSON схемы, причем более мелкие схемы несут пропорционально большие накладные расходы. У Gemini 3.5 Flash этот показатель ниже — примерно от 0.3 до 0.5 токенов на символ, — но при больших объемах он все равно накапливается.
Сделайте схемы минимальными. Удалите поля, которые вы не используете в своем последующем коде. Упростите вложенные структуры, где иерархия не является семантически необходимой. Помещайте описания и примеры в свой промпт, а не в само определение схемы. Схема, уменьшенная с 1730 до 555 символов, экономит вам примерно 650 токенов за вызов на Claude. У Claude накладные расходы на схему составляют от 0.6 до 1.6 дополнительных токенов на один символ JSON схемы, причем более мелкие схемы несут пропорционально большие накладные расходы. У Gemini 3.5 Flash этот показатель ниже — примерно от 0.3 до 0.5 токенов на символ, — но при больших объемах он все равно накапливается.
- Согласовывайте модель с характером рабочей нагрузки. Если ваша производственная нагрузка представляет собой в основном структурированный вывод с короткими промптами (менее 500 токенов фактического содержимого), накладные расходы должны стать частью критериев выбора модели. Если ваши входные данные велики (более 2000 токенов), накладные расходы ничтожно малы. В таком случае выбирайте, основываясь на качестве и задержке.
Согласовывайте модель с характером рабочей нагрузки. Если ваша производственная нагрузка представляет собой в основном структурированный вывод с короткими промптами (менее 500 токенов фактического содержимого), накладные расходы должны стать частью критериев выбора модели. Если ваши входные данные велики (более 2000 токенов), накладные расходы ничтожно малы. В таком случае выбирайте, основываясь на качестве и задержке.
- Подумайте об отказе от схемы для простых случаев. Для одной метки классификации или логического флага хорошо составленный промпт, запрашивающий JSON напрямую, не имеет никаких накладных расходов. Вы жертвуете некоторой надежностью ради экономии средств — это того стоит, когда структура тривиальна.
Подумайте об отказе от схемы для простых случаев. Для одной метки классификации или логического флага хорошо составленный промпт, запрашивающий JSON напрямую, не имеет никаких накладных расходов. Вы жертвуете некоторой надежностью ради экономии средств — это того стоит, когда структура тривиальна.
- Используйте пакетную обработку, где это возможно. Накладные расходы представляют собой фиксированную стоимость за один вызов. Обработка 10 элементов за один вызов оплачивает их один раз вместо десяти.
Используйте пакетную обработку, где это возможно. Накладные расходы представляют собой фиксированную стоимость за один вызов. Обработка 10 элементов за один вызов оплачивает их один раз вместо десяти.
- Измеряйте это. Запустите один и тот же вызов со схемой и без нее. Разница в токенах ввода — это ваши скрытые расходы. Умножьте на объем вызовов и цену за токен. Это число должно быть учтено в вашей модели затрат.
Измеряйте это. Запустите один и тот же вызов со схемой и без нее. Разница в токенах ввода — это ваши скрытые расходы. Умножьте на объем вызовов и цену за токен. Это число должно быть учтено в вашей модели затрат.
Заключение
Накладные расходы на схемы — это затраты, которые не отображаются отдельной строкой в вашем счете. Для команд, выполняющих миллионы вызовов структурированного вывода с короткими промптами, они могут составлять большую часть ваших расходов на входные токены. Измерение накладных расходов на схемы и их учет при выборе модели — это первый шаг к сокращению ненужных затрат на ИИ.
Примечание по методологии
В экспериментах, описанных в этой статье, использовались идентичные промпты для всех моделей и условий:
- Модели Gemini тестировались через Vertex AI REST API (us-central1 для 2.5 Flash, global для 3.5 Flash)
Модели Gemini тестировались через Vertex AI REST API (us-central1 для 2.5 Flash, global для 3.5 Flash)
- Claude Haiku 4.5 тестировался через AWS Bedrock
Claude Haiku 4.5 тестировался через AWS Bedrock
- Температура была установлена на уровне 0.0 для всех запусков
Температура была установлена на уровне 0.0 для всех запусков
- Было протестировано пять уровней сложности схем, каждый запуск выполнялся как в контрольном режиме (без схемы), так и в режиме со схемой
Было протестировано пять уровней сложности схем, каждый запуск выполнялся как в контрольном режиме (без схемы), так и в режиме со схемой
- Количество токенов указано в соответствии с API использования каждого провайдера
Количество токенов указано в соответствии с API использования каждого провайдера
