Экономика ИИ: почему счёт за токены растёт незаметно

Команда показывает прототип: ассистент отвечает на вопросы по базе знаний, всем нравится, запускают в прод. Через два месяца приходит счёт от провайдера моделей, и он в 6–8 раз выше прогноза. Дальше — паника, попытки «оптимизировать промпт» и спор, не выключить ли всё до выяснения. Это типичная история, и проблема в ней не финансовая, а инженерная: стоимость не была частью архитектуры.

Почему прогноз всегда занижен

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

Первое — контекст. В прототипе в модель кладут два-три релевантных фрагмента. В проде, чтобы «не терять качество», в контекст начинают подкладывать историю диалога, системные инструкции, примеры, весь найденный retrieval’ом материал. Реальная длина запроса оказывается не 1–2 тысячи токенов, а 8–15 тысяч. Цена растёт линейно по длине — счёт растёт в разы.

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

Третье — ретраи и «тихие» циклы. Таймаут, неудачный парсинг ответа, агент, который зациклился на инструменте. Каждый такой случай — это оплаченные токены без результата. В системе без наблюдаемости они невидимы до счёта.

Стоимость — это метрика шага, а не системы

Главная ошибка — рассуждать о стоимости на уровне «системы в среднем». Среднее ничего не говорит: 5% запросов могут давать 60% расхода. Считать нужно по шагам процесса.

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

Что реально снижает расход

Гибридная маршрутизация. Не каждый шаг требует сильной модели. Классификация, извлечение полей, короткие переформулировки прекрасно решаются дешёвой быстрой моделью. Сильная и дорогая нужна там, где цена ошибки высока. Решение о модели — функция шага (риск, требуемое качество, задержка), а не глобальная константа «везде GPT уровня X». На реальных процессах перенос рутинных шагов на дешёвую модель снимает 40–70% расхода без заметной потери качества — потому что качество там и не требовалось.

Бюджет контекста. Для каждого шага задаётся потолок: сколько токенов контекста он имеет право использовать. Это заставляет retrieval возвращать не «всё, что нашли», а переранжированный минимум. Контекст-бюджет — это не ограничение качества, а защита от тихого роста длины запроса.

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

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

Что считать нормой

Несколько ориентиров из практики, не как гарантия, а как точка отсчёта:

• Если стоимость ответа на порядок выше, чем у конкурирующего шага в том же процессе, — это не «дорогая модель», это ошибка в контексте. Сначала смотрите, что туда кладётся.
• Если 10% запросов дают больше половины расхода — это не повод оптимизировать всё, это повод разобрать эти 10%.
• Если расход растёт быстрее числа запросов — где-то незаметно растёт длина контекста. Это всегда можно найти по трассировке.

Вывод

Token-экономика — это слой платформы, такой же, как задержка и надёжность. Её проектируют до запуска: маршрутизация по стоимости шага, бюджеты контекста, кэширование, обрыв циклов и трассировка расхода по шагам. Сделанная заранее, она стоит несколько дней работы. Сделанная по факту счёта — недели разбирательств и обычно временное отключение части функциональности. Разница не в технологиях, а в том, считали ли стоимость инженерной величиной с самого начала.