Прогноз расхода токенов: как заметить перерасход вовремя

Почему счёт растёт без предупреждения

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

Частая причина - рост трафика без такого же внимания к метрикам. Продукт запустил новый сценарий, команда открыла доступ ещё одному отделу, пользователи стали чаще нажимать "повторить". Число запросов выросло на 15-20%, а месячный бюджет на токены никто не пересчитал.

Вторая причина - более длинные запросы и ответы. Это происходит тихо. В промпт добавили новые инструкции, к сообщению начали прикладывать историю диалога, RAG стал подмешивать длинные куски документов. Если модель ещё и отвечает подробнее, расход растёт сразу с двух сторон: увеличиваются и входные, и выходные токены.

Есть и менее заметный источник перерасхода - повторные запросы. Таймауты, ретраи, дубли из очереди, повторная отправка с фронтенда после долгой загрузки. Пользователь видит один ответ, а система могла сходить к модели два или три раза. В отчёте за месяц это выглядит как "неожиданный" рост, хотя деньги ушли на реальные вызовы.

Отдельно стоит следить за смесью моделей. Даже если дорогая модель получает небольшую долю трафика, она может заметно сдвинуть весь месяц. Допустим, 90% запросов идут в недорогую модель, а 10% попадают в более дорогую из-за fallback, эксперимента или нового маршрута. Если эти 10% ещё и работают с длинным контекстом, средняя цена одного запроса растёт очень быстро.

Такое часто случается в командах, где все вызовы идут через один OpenAI-совместимый шлюз. Снаружи интеграция не меняется, но внутри могли измениться маршрут, fallback или лимиты. Для разработки это удобно. Для бюджета без ежедневного контроля это риск.

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

Какие цифры смотреть каждый день

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

Минимальный набор метрик лучше держать в одной таблице или на одном дашборде:

• input и output токены по отдельности
• число запросов за день
• ошибки и повторные запросы
• расход по моделям, командам и API-ключам
• фактическая стоимость по каждой модели

Input и output токены всегда стоит разделять. Рост input обычно означает, что в запросы попало больше контекста, истории чата или служебного текста. Рост output чаще говорит о другом: модель стала отвечать длиннее. Именно это особенно быстро раздувает счёт.

Число запросов нужно смотреть рядом с токенами. Если запросов стало на 10% больше, а токенов на 60%, проблема не в самом трафике. Значит, каждый вызов стал тяжелее. Часто причина простая: изменили системный промпт, добавили RAG-контекст или подняли лимит ответа.

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

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

Смотрите не только на токены, но и на цену выбранной модели. Один и тот же объём токенов может стоить по-разному. Если маршрутизация меняется между провайдерами и моделями, это особенно заметно.

Ещё один простой приём - помечать дни с релизами, акциями, массовой загрузкой документов и batch-задачами. Без таких отметок легко спутать нормальный всплеск с аномалией.

Как собрать прогноз шаг за шагом

Точный прогноз не требует сложной модели. Обычно хватает данных за последние 14-30 дней, если вы не меняли продукт, промпты и набор моделей. Меньший период часто шумит, больший тянет в расчёт старое поведение, которое уже не относится к текущему месяцу.

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

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

Удобный порядок расчёта выглядит так:

1. Для каждого сценария посчитайте среднее число запросов в будний день, в выходной и в день с пиком.
2. Для тех же групп посчитайте средний расход токенов на один запрос.
3. Умножьте ожидаемое число запросов до конца месяца на средний расход в каждом сценарии.
4. Сложите результаты и получите общий объём токенов и примерную сумму.

Формула простая: 12 000 запросов x 2 500 токенов на запрос = 30 млн токенов. Если таких сценариев три, считайте каждый отдельно, а потом суммируйте. Так сразу видно, какой поток съедает бюджет, а какой почти не влияет на счёт.

Дальше сравните итог не с текущим расходом, а с лимитом команды до конца месяца. Если прогноз показывает 85-90% лимита уже в середине месяца, не ждите счёт. Проверьте, что изменилось: выросла длина ответов, команда включила более дорогую модель, пользователи стали чаще повторять запросы, или один сервис ушёл в цикл ретраев.

Небольшой пример. Команда видит, что в будни сервис делает 8 000 запросов в день по 1 800 токенов, а по пятницам после выгрузки отчётов подскакивает до 14 000 запросов по 2 400 токенов. Такой всплеск нельзя размазать по месяцу. Его надо считать отдельно. Иначе расчёт покажет спокойную картину, а счёт придёт совсем другой.

Если вызовы идут через единый шлюз с аудит-логами по ключам и моделям, такой разбор собирать проще. Например, в AI Router можно смотреть расход по сервисам, ключам и маршрутам в одном месте, не меняя привычные SDK и код.

Как учитывать всплески до того, как они сломают бюджет

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

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

Для релизов и промо-кампаний считайте не только новых пользователей, но и частоту запросов на человека. После запуска люди часто пробуют функцию по несколько раз подряд, и токены растут быстрее, чем число сессий. Если в прошлом месяце промо дало рост трафика на 40%, проверьте, не выросла ли нагрузка на модели на 60-80% из-за повторных попыток и длинных диалогов.

Отдельно следите за правками в промптах. Команда меняет инструкцию, добавляет больше контекста, примеры или форматирование ответа, а потом смотрит только на качество. Счёт в этот момент растёт из-за двух вещей сразу: увеличивается вход, а модель начинает отвечать длиннее. Даже лишние 300-500 токенов в ответе быстро превращаются в заметную сумму на большом потоке.

Есть ещё один частый источник перерасхода - fallback на более дорогую модель. Такое бывает при сбоях, лимитах у провайдера или изменении маршрутизации. Иногда достаточно 5% таких запросов, чтобы месячный прогноз уже поехал вверх.

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

Достаточно держать запас по четырём линиям риска:

• релизы и промо
• удлинение промптов и ответов
• fallback на дорогую модель
• пакетные и ночные задачи

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

Какие аномалии ловить сразу

Счёт чаще ломает не один большой сбой, а тихий сдвиг в метриках, который никто не заметил в первый день. Самый частый пример - модель начала отвечать длиннее, и среднее число output токенов выросло на 20-40% без роста числа запросов.

Такое бывает после правки системного промпта, смены модели или запуска новой функции. Если вчера ответ в среднем занимал 900 токенов, а сегодня уже 1300, расход быстро пойдёт вверх даже при том же трафике.

Смотрите расход по каждому API-ключу. Один сервис, тестовый стенд или неудачный скрипт легко съедает заметную часть месячного бюджета. Порог тревоги можно сделать очень простым: если один ключ вдруг тратит в 2-3 раза больше своей обычной дневной нормы, команде стоит сразу проверить, что именно он отправляет и в какую модель.

Ошибки тоже стоят денег. Когда растут ретраи по часам, расход часто удваивается почти незаметно: первый запрос упал, второй ушёл повторно, потом клиент ещё раз отправил тот же текст. Если в 14:00 у вас обычно 1% ошибок, а сегодня 8%, это уже не шум.

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

Хорошо работают пять простых алертов:

• рост средних output токенов по модели и сценарию
• всплеск расходов по одному ключу
• скачок ошибок и ретраев по часам
• рост доли дорогих моделей в общем трафике
• дневной расход выше прогноза три дня подряд

Последний пункт часто недооценивают. Один плохой день ещё можно списать на случайность. Три дня подряд почти всегда означают, что текущий прогноз уже не годится и месяц закончится выше плана, если ничего не менять.

Пример: команда замечает риск на второй неделе

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

В первую неделю месяца всё выглядело спокойно. Чат-бот расходовал около 2,1 млн токенов в день, внутренний помощник - ещё примерно 900 тыс. В сумме выходило около 3 млн токенов в сутки. Если держать такой темп, прогноз на месяц был примерно 93 млн токенов. Команда укладывалась в бюджет без запаса, но и без тревоги.

На девятый день они выкатили релиз. В системный промпт добавили новые правила, а модели разрешили отвечать подробнее, чтобы снизить число повторных вопросов. Трафик почти не вырос, зато средний ответ стал заметно длиннее: был около 220 выходных токенов, стал около 540.

Через два дня дневной расход поднялся до 4,4 млн токенов. Счёт ещё не пришёл, но алерт уже сработал. Он смотрел не только на сам факт, но и на темп за последние дни. После пересчёта прогноз на конец месяца вырос с 93 млн до 129 млн токенов. У команды оставалось почти две недели, чтобы исправить ситуацию.

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

Через пару дней средний ответ снизился примерно до 300 токенов, а дневной расход вернулся к 3,3 млн. Новый прогноз показал около 101 млн токенов. Это всё ещё выше плана, но уже без провала по бюджету.

Разница в счёте получилась ощутимой. Без раннего алерта команда перелетела бы план примерно на 36 млн токенов. С алертом лишний объём составил около 8 млн. Такой скачок проще объяснить и финансам, и руководителю продукта. Вывод тут простой: аномалии часто начинаются не со всплеска запросов, а с одного релиза, который делает каждый ответ длиннее.

Где чаще всего ошибаются

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

Первая ошибка - смотреть только на среднее за месяц. Такая цифра сглаживает именно то, что и создаёт перерасход: релизы, рекламные кампании, ночные джобы, всплески в конце недели. Если 20 дней у вас тихо, а потом три дня сервис отвечает в три раза чаще, среднее почти скроет проблему.

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

Третья ошибка - не считать повторные запросы после ошибок. Таймаут, 429, сбой в сети, повтор из очереди, резервная модель после неудачного ответа - и один пользовательский запрос уже съел в два раза больше токенов. Такие вещи часто прячутся в логике приложения, а не в биллинге.

Четвёртая ошибка - ставить предупреждение слишком поздно. Алерт в день, когда бюджет уже почти сгорел, мало что даёт. Команда получает сигнал, но уже не успевает снизить лимиты, отключить дорогой маршрут или укоротить промпты. Порог лучше привязывать не только к сумме, но и к темпу. Если к 10 числу вы уже израсходовали 45% месячного бюджета, трафик нужно разбирать сразу.

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

Достаточно простого правила: считать не общий расход, а расход по владельцам, моделям и типам сбоев. Тогда аномалия всплывает раньше счёта, и у команды остаётся время что-то исправить.

Короткая проверка раз в неделю

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

Обычно хватает пяти шагов:

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

Ещё лучше коротко записывать причину роста. Заметка вроде "после релиза поиска средние output tokens выросли с 900 до 1400" помогает намного больше, чем длинный отчёт без вывода.

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

Что делать дальше, чтобы держать расход под контролем

Расход почти никогда не растёт "сам". Обычно цифры просто остаются без хозяина. Назначьте одного человека, который отвечает за прогноз, смотрит алерты и раз в неделю проверяет отклонение от плана. Это может быть техлид, FinOps-менеджер или владелец продукта, но имя должно быть одно.

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

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

Лимиты лучше держать на нескольких уровнях. Общий потолок на весь аккаунт редко спасает от сюрпризов. Намного понятнее ограничения по ключам, по командам и по отдельным сценариям, вроде чат-бота поддержки, внутреннего поиска или nightly jobs. Тогда один неудачный релиз не съест весь месячный бюджет.

Если вызовы идут через единый OpenAI-совместимый шлюз, удобно держать в одном месте расход, rate-limits и аудит-логи. Для команд в Казахстане и Центральной Азии эту задачу закрывает AI Router на airouter.kz: по нему проще понять не только итоговую сумму, но и то, какой ключ, модель или сервис дали перерасход.

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

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