Настройка Cost Tracking для AI-запросов: мониторинг стоимости токенов

Cost tracking AI: почему расход токенов растёт незаметно

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

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

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

Что даёт сквозной учёт расхода запросов к моделям

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

Атрибуция расхода по продуктам и командам

Разбивка показывает, что основной объём тянет один-два сценария из десятка, остальные расходуют единицы процентов. Команда видит свой участок и правит его сама: переписывает шаблон запроса, сокращает пересказ истории диалога, переводит простые задачи на компактную модель. После такой правки доля лишних вызовов падает в 2-4 раза — причина видна в разрезе, а не в общем счёте.

Лимиты и предсказуемость потребления

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

Метки сокращают время разбора инцидента: всплеск прослеживается по журналу за минуты, а не за день переписки между командами. Заодно уходит класс отказов — молчаливое превышение квоты у поставщика, дублирующие повторы и вызовы из выведенного из эксплуатации сервиса.

Способы учёта AI-запросов: шлюз, инструментирование, логи

Учёт стоимости запросов — cost tracking — строят на трёх уровнях: общий шлюз перед провайдерами, инструментирование внутри приложения, постфактум-разбор логов провайдера. Отличаются они точностью атрибуции и ценой сопровождения, поэтому на практике чаще сходятся к гибридной схеме.

Точность атрибуции

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

Накладные расходы на прод

Шлюз добавляет задержку в каждый вызов и становится критичной точкой — его сбой останавливает обращения к моделям. Инструментирование не влияет на скорость ответа, но требует дисциплины в командах. Выгрузка логов не нагружает систему вовсе, зато запаздывает, и ограничить расход в моменте по ней нельзя.

Как мы внедряем мониторинг расхода токенов: этапы работ

Cost tracking AI-запросов начинается не с дашборда, а с инвентаризации: кто обращается к моделям и по каким ключам. Порядок работ ниже даёт разбивку стоимости по команде, продукту и сценарию, а не одну сумму в конце месяца.

1. Аудит вызовов и источников. Собираем реестр сервисов, ключей и моделей; отдельно помечаем фоновые задачи, повторные попытки и потоковые ответы — они чаще всего дают неучтённый расход.
2. Схема тегирования. Задаём обязательные метки: команда, продукт, окружение, сценарий. Вызов без метки не проходит валидацию шлюза, иначе растёт доля неопознанного расхода.
3. Настройка сбора метрик. Шлюз перед моделью фиксирует входные и выходные токены, тип модели, длительность и признак потока; агрегаты ложатся в хранилище с шагом по времени.
4. Проверка на потоковых и повторных вызовах. При потоковой выдаче счётчик приходит в конце ответа, при повторе — дублируется: здесь ловим двойной учёт и потери при обрыве соединения.
5. Сверка с отчётом провайдера. Сравниваем агрегаты за одинаковые периоды: расхождение в пределах пары процентов — округление, большее — разбираем по конкретным вызовам.
6. Передача регламентов. Отдаём описание меток, пороги оповещений, порядок разбора аномалий и правила добавления новых сценариев.

Проверка сходимости с данными провайдера

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

Что передаём на руки: конфигурации, политики, регламенты

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

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

Политики доступа и роли

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

Регламент реакции на аномалии

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

Кейс: как сократили расход токенов втрое без потери качества

Заказчик — платформа с несколькими командами продукта, каждая из которых обращалась к моделям напрямую из своих сервисов. Нагрузка росла умеренно, а расход токенов — быстрее неё: сводных цифр по всем вызывающим не было, часть трафика вообще не попадала в отчётность.

Что показали замеры до внедрения

Мы собрали разрозненные логи за месяц и свели их по единым атрибутам: модель, команда, окружение, назначение вызова, признак повторного запроса. Картина оказалась неприятной — 23% вызовов не учитывались нигде: фоновые задачи, автоматические повторы после ошибок, тестовые окружения и обходные пути мимо общего шлюза. Разброс расхода между командами при сопоставимой нагрузке отличался вчетверо: часть разницы объяснялась длиной промпта и отсутствием кэширования, часть — дублирующими вызовами одной и той же задачи.

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

Через два месяца после внедрения: доля неучтённых вызовов — 1%, разброс расхода между командами сократился с четырёхкратного до 1,3, время реакции на аномалию — с суток до 15 минут. Суммарный расход токенов упал втрое, при этом оценки качества на эталонном наборе задач остались на прежнем уровне.

Чем учёт в шлюзе отличается от инструментирования кода?

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

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

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

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

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

Частые вопросы про учёт вызовов моделей и лимиты

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

Как разделить расход, если несколько продуктов ходят через общий сервис вызовов?

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

Что происходит при потоковых ответах?

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

Учитываются ли повторные вызовы и таймауты?

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

Можно ли обойти учёт?

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

Обсудим задачу: вернёмся с оценкой и планом учёта

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

Что подготовить к разговору:

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

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