Как LLMStart построила свой биллинг для ИИ-агента: микрокредиты, ОГРН и пять LLM за один запрос — VogueTech

Что произошло

LLMStart.ru вместе с интегратором Айтон запустили в продакшн собственного ИИ-консультанта по 1С:УНФ на базе LangChain. Агент работает в Telegram и обслуживает два типа пользователей:

консультантов Айтона во внутренних чатах — как «умная шпаргалка» по 1С;
клиентов Айтона в групповых чатах — там, где раньше отвечали живые консультанты.

Каждый ответ нейросети стоит денег: провайдер LLM (через OpenRouter) тарифицирует запросы по токенам. Чтобы не сжечь бюджет и честно выставлять счета по каждой компании-клиенту, команда спроектировала собственную биллинговую систему.

Ключевые решения:

вся архитектура крутится вокруг сущности «Организация»;
идентификатор организации — ОГРН, а не абстрактный UUID;
единый баланс на организацию, а не отдельные кошельки на каждый чат;
собственная единица учёта — «микрокредит» (0,000001 доллара);
расчёт расходов по usage_metadata моделей и сверка с биллингом OpenRouter «копейка в копейку»;
отказ от стандартных callback handler’ов LangChain в пользу связки ContextVar + Mixin, чтобы протащить ID организации через до пяти LLM-вызовов в одном запросе, включая те, что идут мимо LangChain.

Зачем это нужно

Почему всё завязали на «Организацию»

ИИ-консультант — multi-tenant система: на одной инфраструктуре живут десятки клиентов Айтона. Для каждого нужно обеспечить:

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

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

ОГРН вместо внутренних идентификаторов

Вместо того чтобы придумывать собственные ID, LLMStart использует ОГРН компании как ключ организации. Это даёт несколько прямых выгод:

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

Роли завязаны на организацию, а не на пользователя вообще

Роли всего три:

администратор;
консультант;
клиент.

При этом роль зависит от того, в какой организации находится пользователь:

попал в головную организацию Айтон — работаешь как консультант и видишь все клиентские организации;
попал в клиентскую организацию — работаешь как клиент и видишь только свою «песочницу».

Логика прав живёт в одном месте, а не размазана по чатам и пользователям. Это снижает количество ошибок и упрощает поддержку.

Почему отказались от кошельков на каждый чат

Заказчик изначально хотел считать деньги по чатам: раз токены тратит чат, значит, у каждого чата должен быть свой «кошелёк».

На практике это быстро приводит к проблемам:

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

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

Сам баланс не хранится как один столбец в базе. Это результат простой формулы:

суммируем все пополнения из журнала поступлений;
вычитаем все расходы из журнала списаний.

Так проще отлаживать и аудировать систему: любой баланс можно разложить по операциям.

Что меняет для рынка

Микрокредиты вместо «абстрактных токенов»

Главный вызов — выбрать, в чём считать расходы. У команды было три варианта.

Наивные токены. Считать все токены по одной цене.
- Проблема: разные модели стоят по-разному. Например, Gemini Pro — $2.00 за миллион токенов, а Gemini Flash — $0.50 за миллион.
- Если считать «просто токены», запросы к более дорогим моделям незаметно сжигают бюджет в 4 раза быстрее.
Взвешенные токены. Вводим коэффициенты: 1 токен Gemini Pro = 4 токена Gemini Flash.
- Проблема: как только провайдер меняет цены, все коэффициенты устаревают.
- Придётся пересчитывать старые балансы клиентов задним числом — это больно и рискованно.
Микрокредиты. Выбор LLMStart.
- Вводится собственная единица учёта — микрокредит, равный 0.000001 доллара.
- Все операции хранятся в базе как целые числа. Это убирает проблемы с округлением и накоплением ошибок.

Как это работает:

из ответа нейросети берут usage_metadata с количеством токенов на вход и выход;
умножают на актуальные цены модели из конфигурации (например, pricing.yaml);
переводят сумму в микрокредиты и записывают в журнал расходов.

Команда прогнала 18 вызовов к разным моделям и сверила свои расчёты с биллингом OpenRouter. Разница — в пределах одной копейки, фактически точное совпадение.

Фиксация цен на момент запроса

Чтобы сохранить прозрачность и историю, в журнале расходов хранят не только сумму списания, но и тарифы модели в момент запроса:

название модели;
цена за миллион входных токенов;
цена за миллион выходных токенов.

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

Для бизнеса это критично: можно обосновать любой счёт клиенту и провести аудит за любой период.

Зачем отказались от стандартных callback handler’ов LangChain

В архитектуре агента один пользовательский запрос может запустить до пяти LLM-вызовов:

главный агент, который ведёт диалог;
классификатор, который определяет тип вопроса;
проверка на prompt-инъекции и нежелательный контент;
суммаризатор, если диалог стал слишком длинным;
эксперт-агент, если вопрос сложный и требует отдельной проработки.

Часть этих вызовов идёт через LangChain, часть — напрямую к OpenRouter или другим обвязкам. Задача биллинга — при любом сценарии знать, к какой организации относится запрос, и корректно списать деньги.

Стандартные callback handler’ы LangChain хорошо работают, пока все запросы проходят через него. Но как только появляются обходные пути, привязка к одному фреймворку становится ограничением.

LLMStart ушла в сторону связки ContextVar + Mixin:

ContextVar хранит ID организации в контексте выполнения запроса;
Mixin добавляют к классам общий функционал работы с этим контекстом и биллингом.

В итоге ID организации «протаскивается» через все вызовы, даже если часть из них не знает о LangChain. Это делает биллинг независимым от конкретной библиотеки и устойчивым к изменениям архитектуры агента.

Multi-tenant LLM как продукт, а не прототип

Для рынка это важный сдвиг: многие ИИ-агенты остаются на стадии прототипа — один бот, одна компания, ручной контроль расходов. Здесь же:

полноценная multi-tenant архитектура с изоляцией по организациям;
связка прав доступа и финансового контура на уровне ОГРН;
точный биллинг с собственной валютой и логированием тарифов.

Такой подход ближе к SaaS-продукту, чем к эксперименту с нейросетью внутри одного чата.

Что это значит для вас

Для интеграторов и разработчиков ИИ-ботов

Если вы строите ИИ-агентов для бизнеса, особенно в формате «одна платформа — много клиентов», из этого кейса можно забрать несколько практических идей:

Думать с уровня организации. Привязывайте всё — пользователей, чаты, балансы, роли — к юридическому лицу или эквиваленту.
Использовать естественные ключи, когда это возможно. ОГРН, ИНН или другой внешний идентификатор упрощают интеграции и отчётность.
Считать в деньгах, а не в токенах. Разные модели стоят по-разному, а цены меняются. Микрокредиты или другая дискретная валюта снимают много проблем.
Хранить историю тарифов. Не только сумму, но и цену модели в момент запроса. Это спасёт при спорах с клиентами.
Не завязываться жёстко на один фреймворк. Связка ContextVar + Mixin позволяет протащить контекст (ID организации, лимиты, трейсинг) через любые вызовы, а не только через LangChain.

Для владельцев продуктов и руководителей

Если вы планируете запускать ИИ-ассистента для клиентов:

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

Этот подход особенно полезен для компаний, которые продают ИИ-агентов по подписке или по usage-модели и хотят масштабировать сервис на десятки организаций.

Кому это не подойдёт

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

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