Как настроить распределение затрат на ИИ

Поймите, чего счёт вам не расскажет

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

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

Записывайте поля в момент вызова

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

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

Переводите токены в деньги в одном месте

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

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

Сводите к единицам, которыми принимают решения

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

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

Показывайте это там, где идёт работа

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

Настраивайте оповещения на отношение, а не на сумму

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

Пользуйтесь этим для настоящих вопросов

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

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