Компании, активно внедряющие ИИ-инструменты, всё чаще сталкиваются с проблемой неконтролируемого роста расходов. Uber в 2026 году ввела лимит в $1 500 в месяц на сотрудника для каждого агентного инструмента кодинга: по данным Bloomberg, годовой бюджет на ИИ был израсходован за четыре месяца. Такая реакция понятна — чем больше команда пользуется ИИ, тем выше счёт провайдера. Но лимит на человека — это не единственный и не всегда лучший способ управлять затратами. Он не различает полезный сложный запрос и простой вызов, который случайно отправили в дорогую модель. А ещё может ограничить именно тех сотрудников, чья работа выигрывает от ИИ.
В «Первой Форме» подходят к этой задаче как к инженерной: не запрещают использование моделей и делают расход токенов наблюдаемым. Для этого нужно понимать, за какие токены платят, какие задачи решают модели и где теряется эффективность. Ключевая идея — токен не является стандартной единицей вроде грамма или киловатт-часа. В реальном запросе есть как минимум несколько разных величин: токены, которые физически прошли через токенизатор; токены, взятые провайдером из prompt cache; токены, которые фактически попали в биллинг с учётом ставок и скидок. Если смешать их в одну метрику, бюджетный контроль начинает работать неверно.
| Метрика | Описание |
|---|---|
| TokensIn | Оплачиваемый вход |
| EffectiveTokensIn | Физический объём входа, включая закэшированную часть |
| CacheReadTokens | Объём, который провайдер отдал из кэша |
| PaidTokensIn | Стоимость входа с учётом применимой ставки |
В контуре «Первой Формы» на каждый запрос записываются четыре метрики: TokensIn — оплачиваемый вход; EffectiveTokensIn — физический объём входа, включая закэшированную часть; CacheReadTokens — объём, который провайдер отдал из кэша; PaidTokensIn — стоимость входа с учётом применимой ставки. Бюджетный гейт считает оплачиваемый вход и фактический выход. Это важно: кэшированный контекст всё ещё участвует в работе модели, но может стоить существенно дешевле обычного входа. Например, часть OpenAI-моделей до корректировки учитывалась по полному объёму промпта, включая кэш. Из-за этого ограничение срабатывало в 1,5–3 раза раньше, чем возникала реальная потребность в бюджете. После разделения метрик гейт стал отражать именно оплату.
Цены на модели сравнивают в долларах за миллион токенов, будто токен — стандартная единица. Это не так. Thibault Sottiaux из OpenAI недавно привёл аналогию с пиццей: одну режут на 8 кусков по $2, другую — на 16 по $1,25. Кусок дешевле, а пицца дороже. В его замере одна модель уложила текст в 766 токенов там, где другой потребовалось 1 170 — на треть меньше при том же результате. Разная нарезка текста — только первый множитель, и единственный, который видно в прайсе. Остальные проявляются уже на сценарии: модель тратит токены на внутреннее рассуждение — у «Первой Формы» одна такая в среднем расходовала 76,6 КБ рассуждений ради ответа в 5,3 КБ, и оплачивается всё; агент решает задачу не одним вызовом, а число ходов у моделей разное; часть входа может приходить из кэша по сниженной ставке — а может не приходиться вовсе; «усиленные» режимы читают один и тот же запрос несколько раз при той же цене за токен. Поэтому сравнивать имеет смысл не цену токена, а стоимость успешного результата на конкретном сценарии.
Prompt cache — один из самых сильных инструментов оптимизации. У кэширующих провайдеров чтение из кэша может стоить примерно 0,10–0,25 от стандартной ставки входных токенов. Но сам по себе кэш не появляется: для него нужен повторяемый префикс запроса. Под стабильным префиксом понимается часть, которая повторяется от задачи к задаче: системный промпт, схема доступных инструментов, неизменяемые инструкции, общая статическая информация. Эта часть должна идти до переменных данных конкретной задачи. Если сначала передать новый пользовательский запрос, а затем длинную статическую инструкцию, кэш между запросами почти не поможет.
В одном из каналов deepseek-v4-flash в «Первой Форме» видели cache hit около 98%: при физическом размере контекста около 23 тысяч токенов оплачивалось 260–617 входных токенов. Это не означает, что такая эффективность будет у каждого провайдера или сценария. Например, часть моделей вообще не использует кэш, а у некоторых действует ограниченное время хранения контекста. Но измерение помогает отделить одну проблему от другой. Низкий cache hit не обязательно означает ошибку в учёте или некорректный счёт. Часто это признак того, что система собирает инструменты и инструкции динамически либо помещает статику после переменной части запроса. В замерах «Первой Формы» у одного из контуров общая статическая часть для ревьюеров составляла 1157 байт, но находилась после постановки задачи. Потенциально перенос этой информации в начало мог покрыть кэшем до 28–36% медианного промпта. Это гипотеза для A/B-проверки, а не автоматическая гарантия: изменение порядка контекста может повлиять на качество ответа.
Наконец, не каждой задаче нужна самая дорогая модель. Следующий источник лишних затрат — использование мощных моделей для простых операций. В «Первой Форме» подчёркивают: контролировать нужно не суррогатную метрику, а то, что является дефицитным ресурсом. Подход с раздельными метриками и измерением эффективности позволяет избежать жёстких лимитов, которые душат продуктивность, и вместо этого оптимизировать каждый сценарий.
