Как оценить затраты функции на ИИ до того, как ценообразование станет хаотичным

Почему цены быстро становятся запутанными

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

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

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

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

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

Возьмём функцию составления ответа в службе поддержки. В пилоте с 500 тикетами цифры могут выглядеть нормально. Перенесите ту же функцию на 20 000 тикетов в месяц, добавьте повторные подсказки, проверки модерации и шаг проверки рискованных ответов — и маржа быстро меняется. К моменту, когда финансы просят цифры, дорогой частью редко бывает первый демонстрационный вызов. Дорого обходится повторная работа вокруг него.

Что считать до того, как открывать таблицу

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

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

Соотнесите каждое действие с реальной работой

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

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

Обычная таблица обычно имеет четыре столбца:

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

Не откладывайте учёт человеческих расходов. Если сотрудники проверяют ответы с низкой уверенностью, обрабатывают эскалации, отвечают на жалобы пользователей или тестируют изменения подсказок — это должно быть в прогнозе. Даже 2–5 минут проверки на небольшой доле запросов может быстро съесть маржу.

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

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

Превратите поведение продукта в объём запросов

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

Затем определите точное действие, которое создаёт расход. Это может быть чат-запрос, резюме, переписка или запуск агента. Считайте эту единицу, а не просмотры страницы или логины. Продукт с 2 000 активных пользователей может оставаться дешёвым, если каждый отправляет по запросу в неделю. Продукт с 200 активными пользователями может быстро стать дорогим, если каждый запускает 20 запросов в день.

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

• Лёгкие пользователи пробуют функцию время от времени.
• Обычные пользователи полагаются на неё в обычной работе.
• Активные пользователи встроили её в повторяющуюся задачу и отправляют намного больше запросов.

Дайте каждой группе долю от активных пользователей и примерную частоту действий. Даже простые числа помогают. Если 60% — лёгкие, 30% — обычные и 10% — тяжёлые, умножьте размер группы на число действий на человека и сложите итоги. Это даст куда более полезный прогноз, чем одно среднее.

После этого составьте три сценария спроса. Финансы всё равно будут их просить.

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

Вот простой пример. Допустим, у вас 500 еженедельных активных пользователей. Если 300 лёгких пользователей делают по 2 запроса в неделю, 150 обычных — по 10, а 50 тяжёлых — по 40, вы получаете 4 100 запросов в неделю до учёта повторов, резервных вызовов и проверки людьми. Это число не идеально, но достаточно, чтобы тестировать цену.

Добавьте повторы, резервные вызовы и повторную работу

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

Начните с провальных вызовов, которые пользователи повторяют сами. Если ответ тайм-аутится, выглядит неверно или слишком медленно, многие нажмут отправить снова. Даже умеренный процент повторов меняет арифметику. Функция с 50 000 ежемесячных подсказок и 12% ставкой повторных запусков создаёт не 50 000 генераций, а 56 000, ещё до учёта всего остального.

Приложение также может повторять запрос само. Сетевые ошибки, лимиты по скорости и краткие сбои провайдера могут запускать повторный вызов. Команды часто добавляют эту логику на раннем этапе, а потом забывают включить её в прогноз. Если 4% запросов повторяются один раз, это 2 000 дополнительных вызовов поверх базовых 50 000.

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

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

Простая таблица помогает:

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

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

Планируйте пиковую нагрузку, а не средний трафик

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

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

Этот час важнее, чем суточный итог. Если вы обрабатываете 12 000 запросов в день, финансы могут поделить это на 24 и предположить ровный поток. Реальные продукты редко ведут себя так. Многие пользователи действуют группами — после кампании, в начале смены или сразу после пакетного импорта.

Параллельные запросы влияют и на счёт, и на стресс системы. Десять тысяч запросов, распределённых по дню, управляемы. Пятьсот запросов, которые пересекаются в одну минуту — это совсем другая проблема. Чтобы оценить конкуренцию, посмотрите, сколько времени занимает один запрос, и сколько может пересекаться во время всплеска. Если один вызов ИИ занимает 8 секунд, а пользователи вызывают 60 запросов в минуту, несколько запросов будут идти одновременно.

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

Цените дополнительную ёмкость для этих загруженных периодов, даже если нужна она всего несколько часов в неделю. Если средняя нагрузка требует 4 воркера, а в понедельник утром нужно 10 — включите в прогноз эти 10 воркеров, большую пропускную способность моделей и потерянные вызовы из‑за таймаутов или дублирования.

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

Считайте время людей и поддержку

Большинство команд недооценивают эту часть. Расходы модели заметны. Часы, которые люди тратят на проверку, исправление и объяснение плохих ответов — нет.

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

Обычная карта включает такие шаги:

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

Проставьте минуты рядом с каждым шагом. Будьте честны. «Быстрая проверка» часто превращается в 3–5 минут, когда вы учитываете переключение контекста, чтение подсказки, проверку ответа и оставление заметки.

Время поддержки должно быть в том же прогнозе. Неверные ответы создают тикеты. Смешивающие ответы тоже, даже если по факту ответ технически верен. Если 1 из 150 ответов ИИ приводит к тикету, и каждый тикет занимает 8 минут, это небольшое число быстро складывается в масштабе.

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

Используйте почасовую ставку для каждой роли:

• проверяющий
• модератор
• агент поддержки
• инженер или специалист

Затем умножьте время на частоту. Например, 5% выводов могут требовать проверки, 0.7% могут создать работу поддержки, а 0.1% потребуют специалиста. Это даёт финансам чистый слой трудовых затрат поверх расходов на токены и инфраструктуру.

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

Постройте прогноз пошагово

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

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

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

Обычная прогнозная таблица имеет по строке на каждую часть потока:

• что делает вызов
• сколько токенов или запросов он использует
• цена за единицу
• стоимость за действие

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

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

Завершите одним сравнением: общая цена за действие против вашей плановой цены. Если одно AI‑помощью действие стоит $0.18, а ваша цена даёт только $0.12, разрыв очевиден. Вы можете сокращать контекст, менять модели, ограничивать использование или брать доплату за интенсивное применение до того, как экономика станет хуже.

Простой пример из SaaS-инструмента поддержки

Агент поддержки кликает «Draft reply» после того, как клиент просит возврат денег. Приложение отправляет текст тикета, детали заказа и политику компании в одну модель, которая пишет первый черновик. Затем этот черновик отправляют во вторую модель, которая проверяет рискованные утверждения, неверные условия возврата или грубый тон.

Предположим, продукт обрабатывает 20 000 тикетов в месяц, и 35% из них используют AI‑черновики. Это даёт 7 000 попыток составить черновик до повторов и времени на проверку.

Добавим реальное поведение. Если средний тикет вместе с политикой компании — 1 200 входных токенов, а черновик ответа — 250 выходных токенов, первая модель обрабатывает примерно 1 450 токенов на запрос. Проверка безопасности может занимать 400 входных и 80 выходных токенов, то есть ещё 480. Один чистый проход — около 1 930 токенов всего.

Пользователи редко принимают первый черновик каждый раз. Если 18% агентов нажимают regenerate, чтобы сделать ответ короче или более формальным, эти дополнительные запуски быстро увеличивают объём. 7 000 попыток превращаются в 8 260 циклов черновиков с учётом рернов.

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

Людские расходы тоже обычно считают поздно. Если тимлид проверяет 6% AI‑ответов перед отправкой, это примерно 496 проверок в месяц. По 90 секунд каждая — примерно 12.4 часа проверки. При ставке $35 в час это даёт около $434 в месяц до того, как агенты поддержки начнут редактировать черновики.

Простой прогноз для этой функции требует четырёх чисел:

• месячные тикеты
• доля тикетов с использованием AI
• процент рернов на черновик
• доля проверок и минут на проверку

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

Ошибки, которые ломают цифры

Многие команды строят прогноз на чистом среднем поведении, которое никогда не появляется в реальности. Средний трафик скрывает часы, когда использование скачет в 3–5×, очереди растут, и медленные ответы вызывают ещё больше повторов. Если функция работает нормально в полдень, но падает каждое утро понедельника, дешёвый прогноз — выдумка.

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

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

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

Более безопасный прогноз делает четыре вещи:

• использует p50 и p95, а не одно среднее
• добавляет ставки повторов, таймаутов и повторных отправок
• включает время сотрудников на 100 или 1 000 запросов
• делит пользователей на сегменты вместо одного усреднённого числа

Небольшой инструмент поддержки это ясно показывает. Если 1 000 агентов по 20 запросов в день в среднем — красиво, но если 150 агентов отправляют по 120 запросов в пики, 8% рернов и 5% проверок человек, цена за клиента меняется быстро. Именно в этой разнице рождается недоценка.

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

Быстрые проверки и следующие шаги

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

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

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

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

Сделайте короткую финальную проверку:

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

Эта быстрая проверка часто помогает командам поймать самые большие ошибки. Если хотите внешний обзор перед финальной фиксацией цен, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями по архитектуре AI‑продуктов, инфраструктуре и поддержке в роли Fractional CTO. Внешняя проверка допущений использования, пиков и человеческих накладных может сэкономить много доработок позже.