Компании всё чаще пересматривают расходы на ИИ-инструменты. Например, Uber в 2026 году ввела лимит в $1 500 в месяц на сотрудника для каждого агентного инструмента кодинга: по данным Bloomberg, годовой бюджет на ИИ был израсходован за четыре месяца.
Такая реакция понятна — чем больше команда пользуется ИИ, тем выше счёт провайдера. Но лимит на человека — это не единственный и не всегда лучший способ управлять затратами. Он не различает полезный сложный запрос и простой вызов, который случайно отправили в дорогую модель. А ещё может ограничить именно тех сотрудников, чья работа действительно выигрывает от ИИ.
В «Первой Форме» мы подходим к этой задаче как к инженерной: не запрещаем использование моделей и делаем расход токенов наблюдаемым. Для этого нам нужно понимать, за какие токены платим, какие задачи решают модели и где теряется эффективность. Об этом сейчас и расскажем.
Физические токены не равны оплачиваемым
Токен — единица, в которой LLM принимает и генерирует текст. Но в реальном запросе есть как минимум несколько разных величин:
токены, которые физически прошли через токенизатор;
токены, взятые провайдером из prompt cache;
токены, которые фактически попали в биллинг с учётом ставок и скидок.
Если смешать их в одну метрику, бюджетный контроль начинает работать неверно. В нашем контуре на каждый запрос записываются:
TokensIn — оплачиваемый вход;
EffectiveTokensIn — физический объём входа, включая закэшированную часть;
CacheReadTokens — объём, который провайдер отдал из кэша;
PaidTokensIn — стоимость входа с учётом применимой ставки.
Бюджетный гейт считает оплачиваемый вход и фактический выход. Это важно: кэшированный контекст всё ещё участвует в работе модели, но может стоить существенно дешевле обычного входа. Например, часть OpenAI-моделей до корректировки учитывалась по полному объёму промпта, включая кэш. Из-за этого ограничение срабатывало в 1,5–3 раза раньше, чем возникала реальная потребность в бюджете. После разделения метрик гейт стал отражать именно оплату.
Это простое правило применимо не только к LLM: контролировать нужно не суррогатную метрику, а то, что действительно является дефицитным ресурсом.
Токен одной модели не равен токену другой
Цены на модели сравнивают в долларах за миллион токенов, будто токен — стандартная единица вроде грамма или киловатт-часа. Это не так. 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-проверки, а не автоматическая гарантия: изменение порядка контекста может повлиять на качество ответа.
Не каждой задаче нужна самая дорогая модель
Следующий источник лишних затрат — маршрутизация. Когда в системе много моделей, возникает соблазн направлять почти всё в «самую сильную». На практике модель может быть сильным автором текста, но слабым ревьюером; хорошо рассуждать на сложной задаче, но слишком долго отвечать на классификацию.
Поэтому в конвейере мы разделяем задачи по роли. Например:
bulk — оценка одного кейса, классификация, smoke-проверки;
review — ревью с машиночитаемым вердиктом;
write — подготовка изменения или текста;
analyze — исследовательские задачи;
scarce — модели вне регулярной ротации, которые запускаются только для явно названной потребности.
Пригодность оценивается по результату конкретной роли. Для авторов это может быть доля состоявшихся правок, для ревьюеров — доля корректных структурированных вердиктов.
Такой подход выявил перекос: в одном замере 61% запусков задачи «оценить один ответ» ушёл в тяжёлые каналы. Из 35,6 канало-часов на лёгких задачах 11,2 часа заняли модели, возможности которых для этой работы не были нужны.
Был и более наглядный пример. Одна из рассуждающих моделей в 39% прогонов упиралась в ограничение времени: она тратила в среднем 76,6 КБ на внутреннее рассуждение и выдавала ответ размером около 5,3 КБ. В этой роли дорогая модель оказалась ещё менее предсказуемой — её вывели из регулярной ротации.
Маршрутизация работает на нескольких уровнях:
Шлюз знает протоколы и маршруты конкретных провайдеров.
Приложение управляет пулами, весами моделей и настройками запроса: например, reasoning, top_p, seed или лимитом рассуждений.
Конвейер агентов выбирает пул под роль задачи, учитывает тарифные группы и таймауты.
Это позволяет менять состав пула и параметры без переработки всей логики приложения.
Экономия имеет смысл только вместе с проверкой качества
Заменить модель на более дешёвую недостаточно. Экономия, при которой незаметно ухудшается результат, просто переносит стоимость на следующий этап: повторные запуски, ручные доработки, ревью и исправления.
Поэтому мы проверяем изменения на живых кейсах до и после корректировки. Для задач ревью используются независимые судьи: модель не оценивает результат той же модели-провайдера. Дополнительно применяется adversarial-проверка другой моделью, а качество измеряется через машиночитаемые вердикты и долю состоявшихся правок.
Иногда счёт растёт там, где прайс не менялся. У модели бывает «усиленный» режим: цена за токен та же, но запрос читается несколько раз, и каждое чтение попадает в счёт. На одном и том же теле мы получили 74 365 оплаченных входных токенов против 20 296 у обычного режима — при одинаковой ставке.
Вывод здесь прост: тариф, модель и маршрут нужно проверять на конкретном сценарии, а не выбирать по названию или цене одного токена.
Наблюдаемость важнее красивого отчёта
В системах с агентами особенно легко обмануться хорошей формулировкой, что задачу выполнили и проверили. Поэтому важны артефакты, по которым можно перепроверить любой вывод:
логи токенов и кэша;
параметры маршрутизации;
результаты до и после изменения;
распределение запусков по ролям;
замеры latency;
сравнение качества;
история изменений в пулах моделей.
Этот подход иногда заставляет пересматривать собственные выводы. Например, одна из прежних метрик у нас показывала 96,5% задач, завершённых с первого круга. После проверки оказалось, что реальное значение ближе к 40%: метрика измеряла не то, что предполагалось. Здесь мы применяем простое правило из разработки: у каждой метрики, которую мы используем, должен быть понятный способ получить и проверить её.
Результат: управляемое потребление
Расходы на ИИ действительно становятся отдельной статьёй бюджета. Но из этого не следует, что единственный путь — выдать каждому сотруднику одинаковый лимит. Для себя мы выработали подход, который начинается с нескольких вопросов:
что именно попадает в биллинг;
какая часть контекста кэшируется;
какие задачи действительно требуют дорогих моделей;
где качество подтверждено замером, а не ожиданием;
какие ограничения у конкретного провайдера, тарифа и модели.
Когда на эти вопросы есть ответы, ИИ не нужно запрещать. Можно сделать так, чтобы полезный токен стоил дешевле, а сильная модель использовалась там, где её возможности действительно дают результат.
