Стоимость LLM в тенге: как собрать годовой бюджет

Почему годовой бюджет часто расходится с фактом

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

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

Есть и вторая ловушка: один и тот же сценарий тратит разный объем токенов. Запрос клиента может быть коротким, а может потянуть длинную переписку, системный промпт, историю диалога, куски базы знаний и большой ответ на выходе. Даже простой кейс поддержки в понедельник и в конце квартала обходится по-разному. Добавьте повторные запросы, retries и A/B-тесты промптов, и разброс быстро станет заметным.

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

Для Казахстана и Центральной Азии есть еще один источник расхождения - курс валют. Многие модели тарифицируются в долларах, а бюджет защищают в тенге. Курс меняется быстрее, чем финансовый план. Поэтому расходы в тенге нельзя считать фиксированной суммой на весь год. Они плавают, даже если объем токенов не вырос.

Пример показывает это наглядно. Команда заложила 10 млн токенов в месяц по средней ставке и получила понятную смету. Потом добавила RAG, стала хранить больше контекста, увеличила ответы для сложных обращений и параллельно протестировала две новые модели. Объем вырос не на 10-15%, а почти вдвое. Если к этому добавить скачок курса, разница между планом и фактом уже не выглядит странной.

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

Что включить в расчет

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

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

Разница на практике бывает большой. Короткий вопрос клиента может занимать 600-900 входных токенов и давать 150-300 выходных. Разбор длинной претензии или договора легко уходит в несколько тысяч токенов на входе и в заметно более длинный ответ.

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

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

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

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

Для компаний в Казахстане полезно сразу разделять две корзины: расходы на внешние модели и расходы на локальный хостинг. Например, через AI Router можно отдельно считать API-вызовы и задачи, где нужны data residency, аудит-логи или свои open-weight модели на местной инфраструктуре. Так финансовая модель выходит чище, и спорных мест в ней меньше.

Как собрать расчет по шагам

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

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

1. Выпишите сценарии с самым большим потоком запросов. Обычно это чат поддержки, поиск по базе знаний, разбор документов, внутренний copilot для сотрудников. Не начинайте с редких кейсов. Бюджет чаще всего съедают 2-3 массовых сценария.

2. Снимите фактический размер входа и выхода по логам. Смотрите не на ощущения команды, а на среднее число токенов в промпте и в ответе. Полезно взять и 90-й перцентиль, если ответы иногда сильно раздуваются. Иначе среднее значение даст слишком красивую картину.

3. Для каждого сценария посчитайте месячную стоимость отдельно. Формула простая: число запросов в месяц x средние входные токены x цена input плюс число запросов в месяц x средние выходные токены x цена output. Если в одном сценарии вы используете две модели, считайте их раздельно.

4. Разложите объем по месяцам. Рост пользователей редко идет ровно. У поддержки бывают всплески в конце квартала, у ритейла - перед акциями, у банка - в отчетные периоды. Если ждете рост на 30% за год, не размазывайте его тонким слоем. Покажите, в каком месяце нагрузка реально поднимется.

5. Переведите все в тенге по одному правилу курса. Не меняйте курс от таблицы к таблице. Выберите внутреннее правило компании: плановый курс на год или консервативный курс с запасом. Тогда финансовый отдел увидит логику, а не набор случайных цифр.

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

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

Как заложить курс валют без гадания

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

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

Один ритм обновления лучше "точности"

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

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

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

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

Когда риск можно сократить

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

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

Как посчитать пиковую нагрузку

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

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

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

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

Длина ответа в пик часто растет. Пользователи пишут длиннее, операторы просят больше деталей, бот чаще вызывает дополнительные инструменты. Если в обычное время ответ занимает 400 токенов, в пиковый час он может вырасти до 650-800. Это заметно меняет расчет.

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

После этого сверьте не только бюджет, но и технические потолки. У модели и провайдера есть лимиты по запросам и токенам в минуту. У вашего приложения есть свои очереди, таймауты и ограничения на уровне API-ключа. Если команда работает через шлюз вроде AI Router, проверьте оба слоя: лимиты выбранной модели и rate limits на уровне ключа.

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

Пример расчета для службы поддержки

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

Чат дает 24 000 обращений в месяц, из них 75% простые и 25% сложные. Почта дает еще 8 000 обращений: 60% простые и 40% сложные. Простые обращения идут на быструю недорогую модель с ценой 1 200 ₸ за 1 млн входных токенов и 4 800 ₸ за 1 млн выходных. Сложные обращения идут на более сильную модель: 12 000 ₸ за 1 млн входных и 36 000 ₸ за 1 млн выходных.

Для чата возьмем такой расход: простое обращение - 1 000 входных и 250 выходных токенов, сложное - 2 500 и 900. Для почты цифры выше: простое письмо - 1 800 и 600, сложное - 4 500 и 1 400.

Тогда простые обращения за месяц дадут 26,64 млн входных токенов и 7,38 млн выходных. Это 67 392 ₸. Сложные обращения дадут 29,4 млн входных и 9,88 млн выходных. Это 708 480 ₸. Базовая сумма на месяц - 775 872 ₸.

Теперь добавим вечерний пик. Допустим, с 18:00 до 22:00 приходит 35% всех чатов, и команда не хочет держать людей в очереди. Поэтому 30% простых чат-обращений в этот слот уходят не на дешевую, а на сильную модель. Это 1 890 диалогов в месяц. Разница по цене для одного такого диалога - 18,6 ₸. Только пик добавит еще 35 154 ₸, и месячная сумма вырастет до 811 026 ₸.

Пилоты новых промптов лучше не прятать внутри основной строки расходов. Допустим, команда раз в квартал прогоняет 700 сложных писем на новой цепочке промптов. При расходе 6 000 входных и 1 500 выходных токенов на письмо это еще 88 200 ₸ за один пилот. В годовом плане такую сумму удобнее держать отдельным резервом: 352 800 ₸ в год.

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

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

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

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

Вторая ошибка появляется, когда команда берет цену одной модели и делает вид, что так будет весь год. На практике маршрут запросов меняется. Часть трафика уходит на более дешевую модель, часть - на более сильную, а часть - на локально размещенные open-weight модели, если важны задержка, data residency или свои дообученные версии.

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

Еще один частый промах - не считать служебные вызовы. Команда закладывает только основной запрос к модели и забывает про ретраи, модерацию, маскирование PII, классификацию, проверку ответа и другие вспомогательные шаги. Каждый такой вызов стоит денег. Иногда они добавляют 10-25% к объему, а при нестабильной интеграции и больше.

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

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

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

Быстрая проверка перед защитой бюджета

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

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

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

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

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

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

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

Когда черновой бюджет готов, не несите его сразу на год вперед. Сначала проверьте его на реальных данных за 2-4 недели. Логи быстро покажут, где вы занизили объем, а где заложили лишнее.

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

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

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

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

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

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