Юнит-экономика LLM-функции: шаблон расчёта до релиза

Зачем считать до релиза

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

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

Самая частая ошибка - смотреть только на токены. Это удобно, потому что цифра понятная: вход, выход, тариф, сумма. Но бизнес платит не за токены, а за результат. Если модель с первого раза решает задачу только в 70% случаев, оставшиеся 30% тоже стоят денег, времени команды и доверия пользователей.

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

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

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

Что входит в один сценарий

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

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

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

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

Отдельно запишите, где у сценария деньги. В одном случае это прямой доход, если функция помогает довести пользователя до оплаты. В другом - экономия времени, например оператор тратит не 6 минут на тикет, а 4. В третьем - цена ошибки: неверная маршрутизация обращения, лишняя ручная обработка, скидка клиенту или возврат.

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

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

Какие числа взять на вход

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

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

Дальше измерьте токены, а не "размер запроса" на глаз. Считайте отдельно вход и выход: системный промпт, пользовательский текст, RAG-контекст, служебные инструкции, а потом средний ответ модели. Если ответ иногда в 5 раз длиннее обычного, фиксируйте не только среднее, но и верхний рабочий диапазон. Иначе бюджет на генерацию быстро уедет.

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

Если вы считаете сценарий через RU LLM, удобно сразу закладывать реальные тарифы провайдеров для основной и фолбэк-модели. Шлюз совместим с OpenAI API, поэтому для такого сравнения обычно достаточно поменять base_url на api.rullm.com и не трогать SDK, код и промпты.

Отдельной строкой внесите долю фолбэка. Это процент запросов, которые не проходят на основной модели и уходят на запасной маршрут: из-за лимитов, таймаутов, качества ответа или правил комплаенса. Даже 3-7% фолбэка заметно меняют экономику, если резервная модель дороже.

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

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

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

Шаблон расчета по шагам

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

Дальше удобно идти по простой формуле. Сначала найдите цену базового прохода на основной модели. Потом добавьте редкие, но дорогие ветки только по их доле.

Базовая формула

C_main = цена одного ответа на основной модели
C_fallback = цена одного ответа на резервной модели
C_review = цена одной ручной проверки
C_return = цена одного возврата или повторной обработки

p_fallback = доля запросов, ушедших в фолбэк
p_review = доля запросов, попавших на ручную проверку
p_return = доля запросов с возвратом или повтором

C_case = C_main + p_fallback * C_fallback + p_review * C_review + p_return * C_return
C_period = Traffic * C_case

Для C_main возьмите средний вход и средний выход в токенах по одному сценарию. Умножьте их на тариф модели в одной и той же единице, например за 1 млн токенов. Если у вас есть системный промпт, retrieval и длинная история, включите это сразу. Именно здесь часто теряют 20-40% бюджета.

Фолбэк не нужно считать на весь трафик. Если на резервную модель уходит 8% запросов, добавляйте только 0,08 * C_fallback. Это особенно важно, когда резервная модель заметно дороже основной.

Ручную проверку считайте так же. Если оператор тратит 3 минуты, а минута стоит 40 рублей, одна проверка стоит 120 рублей. При доле 4% в формулу попадет только 0,04 * 120.

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

После этого умножьте C_case на прогнозный трафик за день или месяц. А затем посмотрите на цену успешного кейса:

C_success = C_period / (Traffic * Success_rate)

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

Как посчитать фолбэк, ручные проверки и возвраты

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

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

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

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

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

Небольшой пример: из 10 000 запросов 8% уходят в фолбэк, 3% попадают к оператору, 1,2% заканчиваются полным возвратом, еще 2% требуют бесплатного перезапуска. После такого разложения сразу видно, где уходят деньги. Часто проблема не в цене модели, а в том, что второй проход слишком длинный, а ручная проверка занимает не 2 минуты, а все 7.

Пример для одного кейса

Возьмем автоответ на входящее обращение клиента в поддержке. За месяц приходит 10 000 обращений. LLM читает текст, готовит черновик ответа и, если уверенность низкая, отправляет запрос на фолбэк или человеку.

Чтобы не спорить о деталях, зададим условные ставки и средние объемы. Их легко заменить своими числами:

• основная модель: 700 входных токенов и 180 выходных, 0,5 руб. за 1000 input и 1,5 руб. за 1000 output
• фолбэк: 1800 входных и 350 выходных, 3 руб. и 9 руб. за 1000 токенов
• ручная проверка: 6% обращений, по 2 минуты на одно, ставка оператора 900 руб. в час
• возврат: 0,4% обращений, средняя компенсация 700 руб.

Сначала считаем основной поток. Одно обращение на основной модели стоит 700 / 1000 x 0,5 + 180 / 1000 x 1,5 = 0,62 руб. Если через нее проходит весь трафик, месячный расход равен 10 000 x 0,62 = 6 200 руб.

Теперь добавим фолбэк. Пусть он срабатывает у 8% обращений, то есть у 800 из 10 000. Один такой запрос стоит 1800 / 1000 x 3 + 350 / 1000 x 9 = 8,55 руб. Расход на фолбэк за месяц - 800 x 8,55 = 6 840 руб.

Дальше идет ручная проверка только спорных ответов. При доле 6% оператор смотрит 600 обращений. Это 1200 минут, или 20 часов. Стоимость проверки - 20 x 900 = 18 000 руб.

Самая неприятная строка - возвраты. Если ошибка модели приводит к компенсации в 0,4% случаев, это 40 обращений в месяц. При среднем возврате 700 руб. получаем еще 28 000 руб.

Итог по сценарию за месяц такой: 6 200 руб. основная модель + 6 840 руб. фолбэк + 18 000 руб. ручная проверка + 28 000 руб. возвраты = 59 040 руб. Делим на 10 000 обращений и получаем 5,90 руб. на одно обращение.

Такой расчет быстро отрезвляет. Токены в этом кейсе дают только 13 040 руб., а люди и ошибки - 46 000 руб. Если снизить возвраты с 0,4% до 0,2%, вы сэкономите 14 000 руб. в месяц. Если сократить ручные проверки с 6% до 3%, экономия составит еще 9 000 руб. Обычно это важнее, чем спор о цене основной модели на несколько копеек за запрос.

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

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

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

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

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

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

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

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

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

Короткий чек-лист перед запуском

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

• Зафиксируйте единицу расчета. Это не "месяц работы функции" и не "1000 запросов", а один понятный сценарий: например, одна классификация обращения или один готовый ответ клиенту.
• Разведите две цифры: цену основного ответа и цену успешного кейса. Между ними часто и прячется реальная маржа.
• Проверьте долю фолбэка на живых данных, а не на красивом тестовом наборе. Возьмите реальные длинные сообщения, шумный текст после OCR, смешанный русский и английский, пустые поля.
• Задайте порог, после которого ответ смотрит человек. Это должно быть правило или число, а не ощущение команды.
• Добавьте запас на пик трафика и длинные сообщения. Среднее значение почти всегда успокаивает зря.

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

Что сделать после первой версии расчета

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

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

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

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

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

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