Бюджет на LLM для нескольких команд: как посчитать

Почему пилот дает ложную картину

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

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

Поэтому бюджет, собранный по данным пилота, часто оказывается заниженным. На тесте люди просят короткий ответ, просто чтобы понять, работает ли идея. Через месяц после запуска им уже нужен подробный разбор, таблица, ссылки на фрагменты документа и объяснение выбора. Растут и входные токены, и выходные. Растет и число запросов на человека: если инструмент встроили в ежедневную работу, сотрудник использует его не 2-3 раза в день, а 15-20.

Финансы тоже часто видят слишком гладкую картину. В отчете может быть одна строка на LLM, хотя внутри нее скрываются очень разные типы затрат: дорогие reasoning-модели для сложных задач, массовые дешевые запросы, ретраи, логирование, маскирование PII, аудит и лимиты на уровне ключей. Если сложить все в одну сумму, пилот выглядит понятным, а потом бюджет начинает расползаться без явной причины.

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

Из чего складываются расходы

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

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

На стоимость одного запроса обычно влияют четыре вещи:

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

Именно повторы чаще всего дают неприятный сюрприз. Пользователь просит "перепиши короче", сервис делает retry, разработчик добавляет второй вызов на проверку формата, и один бизнес-запрос превращается в три или четыре обращения к модели. Если этого нет в расчете, пилот выглядит дешевым, а продакшен уже нет.

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

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

Нужен и резерв на смену модели или провайдера. Цены меняются, лимиты тоже, а иногда модель просто хуже справляется с конкретной задачей. Если у компании есть возможность быстро переключать маршрутизацию между провайдерами, риск простоя ниже, но финансовый запас все равно нужен. Практичный буфер - хотя бы 10-20% сверху.

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

Как разнести бюджет по командам и задачам

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

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

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

Учет удобно вести в простой схеме:

• поддержка: чат операторов и суммаризация диалогов
• юридическая команда: проверка договоров и вложений
• продуктовая команда: поиск, внутренний помощник и тесты

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

Если трафик идет через общий шлюз, полезно выдавать отдельный API-ключ на команду и ограничивать расход на уровне ключа. Так проще отделить траты одной группы от другой и не допустить ситуации, когда один отдел съедает весь пул.

Не смешивайте R&D и боевую нагрузку. Внутренние тесты, eval, red team, подбор модели и нагрузочные прогоны должны идти из отдельного бюджета. Иначе после запуска внезапно выяснится, что к пользовательским запросам добавились еще и инженерные эксперименты.

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

Какие лимиты задать заранее

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

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

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

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

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

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

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

Как посчитать квартальный бюджет

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

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

1. По каждой команде выпишите 3-5 частых сценариев и оцените, как часто люди или системы будут их запускать.
2. Для каждого сценария замерьте средний вход и выход в токенах, а также число вызовов в день. Если данных мало, возьмите неделю реальной работы, а не демо.
3. Посчитайте три режима месяца: базовый, высокий и пиковый. Базовый показывает обычную загрузку, высокий нужен для активного месяца, пиковый - для акции, отчетного периода или всплеска обращений.
4. Добавьте к расходам повторы запросов, ошибки интеграции, ручные перезапуски и запас на рост. Если у вас есть prompt caching или повторное использование ответов, вычтите ожидаемую экономию отдельно.
5. До запуска согласуйте лимиты с финансами: месячный потолок по команде, предупреждение при 70-80% и правила, что отключать первым при перерасходе.

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

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

Пример для трех команд

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

Возьмем условный месяц. Поддержка обрабатывает 18 000 диалогов. Контекст короткий: вопрос клиента, пара реплик, готовый ответ. В среднем один диалог тратит 1 500 токенов. Если команда работает на недорогой модели, расход получается умеренным и довольно ровным по дням.

Продажи делают меньше запросов, около 2 500 в месяц, но каждый запрос длиннее. Менеджер загружает заметки со встречи, просит сделать сводку, а потом пишет письмо клиенту. На один такой цикл легко уходит 4 000-6 000 токенов. По деньгам это уже заметная статья, хотя запросов меньше, чем в поддержке.

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

Для наглядности бюджет по функциям может выглядеть так:

• поддержка: 60 000 тг в месяц
• продажи: 110 000 тг в месяц
• юристы: 240 000 тг в месяц
• резерв на пики и повторные прогоны: 90 000 тг

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

Общий лимит в 500 000 тг от такой ситуации не спасает. Он просто останавливает перерасход уже после того, как одна функция забрала деньги у остальных. Поддержка в этот момент может остаться без ответа клиентам, хотя сама работала в рамках плана.

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

Где бюджет чаще всего трещит

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

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

Что обычно недооценивают

• Цена неравномерна: 80% запросов могут быть дешевыми, а остальные съедают половину месячного счета.
• Одна дорогая модель для всех команд почти всегда дает лишние траты.
• История чата и вложения растят расход незаметно, пока не приходит счет.
• Ночные батчи, ретраи и фоновые задачи часто не попадают в первый расчет.

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

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

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

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

Самый полезный вопрос перед запуском звучит просто: какие запросы будут редкими, но очень дорогими. Обычно именно они и рвут квартальный план.

Проверки перед запуском

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

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

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

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

Отдельно договоритесь о правилах эскалации. Кто получает сигнал на 80% лимита? Кто может временно поднять порог? Кто отключает второстепенные сценарии, если расход ушел вверх? Если ответы живут только в голове у техлида, это уже риск.

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

Эта проверка занимает несколько часов, но потом экономит недели споров после пилота.

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

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

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

Минимум, который реально работает, выглядит так:

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

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

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

Для компаний в Казахстане и Центральной Азии AI Router может упростить учет: один OpenAI-совместимый API для разных моделей и ежемесячный B2B-инвойсинг в тенге. Это не решает бюджет само по себе, но делает сверку расходов заметно проще, если продукт, аналитика и поддержка работают с разными моделями.

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