Отчёт по расходам на LLM для бухгалтерии и CTO без ручных сверок

Почему цифры по LLM не сходятся

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

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

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

Снаружи это выглядит как мелкая операционная проблема. На деле она регулярно съедает часы. В конце месяца кто-то выгружает CSV, кто-то сверяет его с логами приложения, кто-то вручную раскладывает расходы по отделам. На одну такую сверку легко уходит полдня.

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

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

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

Что должно быть в одном формате

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

Начните с периода. В каждой выгрузке укажите месяц отчёта и дату, когда вы сняли данные. Это сразу снимает часть споров, когда usage у провайдера догружается позже или часть запросов уехала в следующий день по UTC. Простая пометка вроде "май 2026, выгрузка 3 июня 2026" экономит много времени.

Дальше нужен бизнес-контекст. У каждой строки или группы строк должны быть команда, продукт и владелец бюджета. Иначе расходы быстро превращаются в общий счёт "за AI", который никто не считает своим. Если один сервис используют support, mobile и data team, разделите затраты сразу, а не в конце месяца вручную.

Техническая часть тоже должна быть простой. Фиксируйте не только модель, но и провайдера, а также тип запроса. Одна и та же модель у разных провайдеров может стоить по-разному и биллиться по разным правилам. Тип запроса тоже влияет на итог: chat, embeddings, rerank, batch и fine-tuned inference лучше не смешивать в одной колонке.

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

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

Хороший формат обычно помещается в 8-10 колонок и читается без устных пояснений. Если бухгалтер видит итог по деньгам, а CTO сразу понимает, какая команда, какая модель и какой тип запросов дали этот итог, вы собрали отчёт правильно.

Как выбрать единицу учёта

Когда в одной таблице рядом стоят токены, запросы, доллары и тенге, споры почти неизбежны. Нужна одна база, к которой можно привести все модели и все команды. Для LLM удобнее всего считать стоимость за 1 млн токенов с разбиением по типам токенов.

Одинаковый объём запросов может стоить по-разному даже внутри одной модели. Причина простая: input и output тарифицируются отдельно, а cache часто идёт по своей ставке. Если сложить всё в одну строку "токены всего", отчёт станет короче, но потеряет смысл. Команда может снизить input на 20%, а счёт не изменится, если вырос дорогой output.

Поэтому для каждой модели и каждой команды лучше держать четыре поля: input tokens, output tokens, cached tokens, если провайдер считает их отдельно, и ставку в пересчёте на 1 млн токенов по каждому типу. Тогда видно, где вырос расход на диалоги, где сработал кэш, а где модель просто отвечает слишком длинно.

Не смешивайте разные типы задач

Чат, embeddings и batch-задачи нельзя складывать в одну кучу без отдельной пометки. У них разная логика цены и разная польза для бизнеса. У чата обычно важны input и output. У embeddings расход часто связан с массовой индексацией. У batch-задач цена может быть ниже, но объём выше.

Простой пример: команда поддержки отправила 8 млн токенов в чат-модель, а поиск по каталогу прогнал 40 млн токенов через embeddings. Если записать это одной суммой, покажется, что поиск дороже по потреблению, хотя деньги могла съесть именно чат-модель.

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

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

Как собрать отчёт шаг за шагом

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

Начинайте не с денег, а с сырых usage-данных. Деньги вы посчитаете позже, когда приведёте строки к одному виду.

Сначала выберите период, например календарный месяц, и часовую зону. После этого выгрузите usage по всем провайдерам за тот же интервал. В каждой выгрузке оставьте одинаковый набор полей: дата, модель, API-ключ или project ID, число входных и выходных токенов, cached tokens, количество запросов и исходную стоимость, если провайдер её отдаёт.

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

После этого пересчитайте токены в деньги по одной таблице ставок. В ней должны быть цена за input, output и cached tokens, валюта и дата действия тарифа, если он менялся в течение месяца.

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

Что проверить перед финалом

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

Если трафик идёт через единый шлюз, часть работы упрощается. Например, у AI Router запросы можно вести через один OpenAI-совместимый эндпоинт, а затем сверять месячные расходы в тенге по одному B2B-инвойсу. Это не отменяет внутреннюю разбивку по командам, но заметно сокращает число ручных склеек между разными кабинетами.

Как разложить расходы по командам

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

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

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

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

Для каждой команды полезно показывать лимит на месяц, фактический расход, отклонение в деньгах и процентах, а также короткий комментарий, если сумма заметно изменилась. Не нужен длинный разбор. Одной ясной фразы обычно достаточно: "запустили поиск по базе знаний для 12 тысяч пользователей" или "две недели тестировали long-context модель в QA". Без такого комментария скачок выглядит как ошибка.

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

Пример отчёта за месяц

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

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

У аналитиков это особенно заметно. Они загружают отчёты, таблицы и заметки встреч, а в ответ получают длинные summary. Запросов у них меньше, чем у поддержки, но ответы длиннее, поэтому строка по output растёт быстрее. В этом примере output даёт больше 80% месячного счёта.

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

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

Где чаще всего ошибаются

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

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

Вторая ошибка - работать только с алиасами моделей. В коде команда видит что-то вроде "support-main" или "gpt-4.1", но тарификация зависит от фактической модели, провайдера и версии на момент запроса. Если один и тот же алиас в разные дни вёл на разные модели, средняя цена по алиасу даёт ложную картину. Для отчёта нужна связка: алиас, фактическая модель, провайдер и ставка.

Третья ошибка - складывать внутренние эксперименты вместе с клиентским трафиком. Тогда тесты новой функции, оценка промптов и нагрузочные прогоны выглядят как расходы продукта. CTO видит рост затрат, а бухгалтерия не понимает, что относится к R&D, а что можно отнести на конкретный сервис.

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

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

Перед отправкой проверьте пять вещей:

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

Если хотя бы один пункт пустой, отчёт почти наверняка придётся пересобирать.

Короткая проверка перед отправкой

Перед отправкой нужен ещё один быстрый проход. Он занимает 10-15 минут, но потом экономит часы на письмах и созвонах.

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

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

Дальше сверьте общий итог с данными провайдера или шлюза. Сумма должна сходиться до понятной разницы, например из-за округления или отдельной строки с НДС. Любое заметное отклонение лучше пояснить сразу одной фразой: "рост на 42% из-за запуска пилота в поддержке, 18 млн токенов за 6 дней".

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

Что изменить в следующем месяце

Если в этом месяце вы собирали отчёт вручную, не пытайтесь сразу переделать всё. Начните с базовых правил. Зафиксируйте словарь полей: одно имя модели, одно имя команды, одна валюта и один способ считать usage. Пока в одном файле стоит "gpt-4.1-mini", в другом "GPT 4.1 mini", а в третьем просто "mini", сверка будет съедать часы.

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

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

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

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

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