Внутренний биллинг AI-расходов без споров между командами

Почему счёт за AI вызывает споры

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

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

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

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

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

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

Что считать, кроме токенов

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

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

У каждого запроса должен быть понятный набор меток. Минимум, который реально работает, такой: продукт или сервис, команда или владелец бюджета, среда prod/stage/dev, сценарий вроде чата, поиска, суммаризации или классификации, и тип расхода - обычный вызов, retry, cache hit или cache miss.

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

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

Цену тоже не стоит держать в памяти. Её лучше фиксировать на дату запроса. Это особенно важно, если вы маршрутизируете трафик между провайдерами или меняете модель без переписывания кода через OpenAI-совместимый шлюз. Через месяц никто не вспомнит, почему один и тот же сценарий внезапно подорожал.

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

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

Как разнести расходы по продуктам

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

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

Одного ключа мало, если внутри продукта несколько сценариев с разной стоимостью. Поэтому полезно передавать в каждый запрос короткий тег функции, например checkout_assistant, support_chat или catalog_search. Даже если запросы идут через единый шлюз, такой тег потом помогает объяснить счёт обычными словами: поиск занял 18% бюджета, потому что делал много embedding-запросов, а не потому, что у кого-то просто выросли токены.

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

Часто хватает простой схемы: 70% общих затрат делятся по фактическому числу запросов, 30% - поровну между продуктами, которые пользовались сервисом в этом месяце, пилоты считаются отдельно, а продакшен не субсидирует тесты. Формула не обязана быть идеальной. Она должна быть понятной и повторяемой.

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

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

Как объяснять счёт без слов про токены

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

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

Удобнее считать стоимость понятного результата: одного ответа в чате поддержки, одной проверки документа, одной краткой сводки звонка или одной обработанной заявки. После этого расход лучше показывать крупными единицами. Не 2,4 млн токенов, а 1000 диалогов по 3200 тенге. Не вырос input, а одна заявка стала дороже на 18%.

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

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

Удобный формат отчёта простой: сценарий, объём, цена за единицу, общая сумма и причина отклонения. Одного взгляда достаточно, чтобы понять, что произошло. Например: чат поддержки, 48 000 диалогов, 2,9 тенге за диалог, рост из-за более длинных ответов.

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

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

Пошаговая схема внутреннего биллинга

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

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

Дальше введите единый формат тегов для всех запросов. Обычно хватает трёх полей: продукт, среда и сценарий. Например, product=support-bot, env=prod, feature=summary. Такие теги помогают понять не только сумму, но и причину расхода. Без них все запросы выглядят одинаково, даже если один сервис отвечает клиентам, а другой гоняет внутренние тесты.

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

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

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

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

Пример: чат-бот, поиск и поддержка в одном счёте

Один общий счёт за LLM легко превращается в спор. Продуктовая команда говорит, что трафик создал чат-бот. Команда поиска отвечает, что у них вызовов мало. Поддержка уверяет, что тесты почти не повлияли.

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

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

Допустим, за месяц вышло 1 200 000 тенге.

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

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

Где команды ошибаются

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

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

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

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

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

Когда отчёт перестаёт быть понятным

Отчёт почти бесполезен, если он объясняет перерасход названиями моделей вместо сценариев. Фраза вроде "мы больше тратили из-за модели X" мало кому помогает. Гораздо понятнее звучит так: доля длинных ответов в поддержке выросла на 28%, поиск начал делать второй запрос при низкой уверенности, ретраи после таймаута добавили 11% к счёту.

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

Когда в отчёте есть сценарий, дата изменения и цена одного действия, спор быстро сходит на нет. Люди не думают токенами. Они понимают язык вроде: один поиск стоит 0,8 тенге, одно резюме диалога - 2,4 тенге, тесты за неделю съели 17% счёта.

Быстрая проверка перед запуском

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

1. Назначьте владельца бюджета для каждого продукта. Нужен конкретный человек, который подтверждает правила учёта, смотрит отчёт и отвечает на вопросы по своему направлению.
2. Привяжите каждый ключ, сервис и batch-задачу к тегу продукта. Если мобильный чат, поиск по базе знаний и внутренний помощник идут через один шлюз, теги сразу покажут, кто и сколько использовал.
3. Отделите тесты от боевой нагрузки. Запросы из песочницы, QA и ручных проверок должны идти в отдельный контур, иначе запуск новой функции случайно раздует боевой счёт.
4. Запишите формулу общих расходов до старта. Если несколько продуктов используют один шлюз, общие логи, маскирование PII или хостинг модели, заранее решите, как делить эту часть.
5. Проверьте, что отчёт читает человек, который не думает токенами. Сумма в тенге, число запросов, цена одного сценария и короткая причина роста почти всегда понятнее, чем столбцы с входными и выходными токенами.

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

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

Что делать дальше

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

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

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

Хорошо работает и разбор на одном примере. Допустим, у продукта поддержки вышел счёт на 1 200 000 тенге. В черновике видно, что 800 000 ушло на ответы клиентам, 250 000 - на внутренний поиск по базе знаний и ещё 150 000 - на повторные вызовы после таймаутов. После такого разговора спор обычно становится предметным: команда уже обсуждает не почему так дорого, а какую часть она берёт на себя и что исправит в следующем месяце.

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

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