Как прогнозировать расходы на LLM: считаем стоимость на активного пользователя

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

Цепочка факторов

Расходы на инференс раскладываются на пять множителей. Каждый из них кто-то в компании может оценить или измерить.

monthly_spend = U × a × s × r × c

Число, за которым стоит следить — cost per engaged user = s × r × c. Оно не зависит от того, сколько у вас пользователей. Именно его вы сравниваете с ценой и проверяете на дашборде.

Пример расчёта

Возьмём правдоподобные допущения. Не факты, а просто для иллюстрации.

Подставляем:

Вовлечённые пользователи = 20 000 × 0,35 = 7 000
Запросов в месяц = 7 000 × 6 × 4 = 168 000
Месячный spend = 168 000 × 0,0055 = $924
Cost per engaged user = 6 × 4 × 0,0055 = $0,132

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

Четыре причины, почему линейная модель ломается

1. Диалоги удлиняются, а история пересылается

Если каждый ход пересылает весь диалог, ход n оплачивает n−1 предыдущих. Стоимость сессии из k ходов пропорциональна k(k+1)/2, а не k. Для k=4 это 10 единиц, для k=8 уже 36: вдвое больше ходов — в 3,6 раза выше стоимость. Улучшение удержания в диалоге увеличивает этот член квадратично. Скользящее окно с саммари возвращает линейность — это стандартное исправление.

2. Растёт корпус для ретрива

Больше документов обычно означает больше чанков, длиннее чанки или и то и другое. Каждый из них — входные токены в каждом запросе. Следите за T_in на запрос. Если оно плывёт вверх, стоимость c растёт под прогнозом, который считал её постоянной.

3. Агентские циклы умножают r

Фича, становясь агентской, не увеличивает r на процент — она умножает его на число шагов. Переход с одного вызова на шесть шагов — это 6× на весь прогноз, и это приходит в одном релизе. Любой пункт роадмапа со словом «агент» заслуживает отдельной строки в прогнозе.

4. У использования тяжёлый хвост

Пользователи не потребляют среднее. Если верхняя доля q пользователей даёт долю s токенов, то средний пользователь в этой группе стоит s/q от общего среднего. Например, топ-5% пользователей генерируют 40% токенов — это 8× к средней стоимости. При средних $0,132 пользователь из топ-5% обходится примерно в $1,06 в месяц. Измеряйте q и s по своим данным: это группировка за месяц. Форма хвоста важна, потому что прогноз работает, пока микс пользователей стабилен, и ломается, когда канал роста приносит другой тип — корпоративный пилот, партнёр по интеграции, вирусный тред — и хвост утолщается.

Сценарии, а не одна цифра

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

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

Как держать прогноз честным

• Пересчитывайте ежемесячно по логам. Каждый член измерим. Прогноз, не сверенный с фактом, — это пожелание.
• Алертите на cost per engaged user, а не на total spend. Рост total spend при росте пользователей ожидаем; рост cost per пользователя — регрессия, требующая объяснения.
• Пересматривайте прогноз при любом изменении r. Правки промптов меняют c постепенно; архитектурные изменения меняют r скачками. Именно скачки ломают бюджеты.
• Держите модель в репозитории. Таблица на чьём-то гугл-диске не перезапускается. Двадцать строк кода против таблицы использования — перезапускаются.
• Прогнозируйте и косвенные затраты. Хранилище векторов, логи и eval-прогоны масштабируются теми же членами и регулярно забываются.

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