Счёт за инференс приходит с задержкой в месяц, и это его главное неприятное свойство. К моменту, когда цифра становится видна, архитектура уже выбрана, а трафик уже идёт.
Хорошая новость в том, что счёт считается заранее и на салфетке. Плохая — что почти никто не считает, потому что расчёт выглядит слишком простым, чтобы быть правдой.
Формула
месяц = запросы × шаги × (1 + повторы) × токены_на_шаг × цена_за_токенПять множителей, и только один из них — про модель. Остальные четыре — про то, как вы её вызываете. Это и есть главный вывод: выбор поставщика влияет на счёт меньше, чем устройство вашего цикла.
Разбор по множителям
Запросы. Единственный множитель, который вы обычно знаете точно: он есть в аналитике продукта. Берите пик, а не среднее — счёт выставят по факту, а не по вашим ожиданиям. Если у продукта выраженная сезонность или рабочие часы, разница между средним и пиком легко достигает трёх-четырёх раз.
Шаги. Сколько раз модель вызывается на один пользовательский запрос. В чат-сценарии это единица. В агентном — столько, сколько решит оркестратор, и это принципиально другой разговор: множитель перестаёт быть константой и становится распределением. Для расчёта берите не типичное число шагов, а разрешённый максимум, потому что именно он определяет верхнюю границу счёта.
Повторы. Тот самый множитель, который ломает расчёты.
Если агент, не справившийся с первого раза, пробует ещё, доля повторов складывается не с единицей, а умножается на всю остальную цепочку. При двадцати процентах повторов вы платите на двадцать процентов больше — при условии, что повтор один и он на уровне всей задачи.
Если же ограничитель стоит внутри вызова инструмента, а не в оркестраторе, повторы перемножаются между шагами. Двадцать процентов на каждом из пяти шагов — это уже не плюс двадцать процентов, а совсем другая цифра. И в логах это выглядит как обычная работа.
Токены на шаг. Здесь чаще всего сидит скрытый рост. Контекст имеет свойство накапливаться: история диалога, результаты предыдущих шагов, системная инструкция, описания доступных инструментов. Запрос, который в тесте занимал две тысячи токенов, в проде на десятом сообщении занимает пятнадцать.
Причём растёт он не линейно по времени, а линейно по глубине диалога — то есть у самых вовлечённых пользователей, которых вы больше всего цените.
Цена за токен. Публикуется поставщиком, меняется, и это единственная строка, где смена модели действительно что-то меняет. Отдельно проверьте, различается ли у вашего поставщика цена входа и выхода: в агентных сценариях вход обычно на порядок больше выхода, и считать их по одной ставке — значит ошибиться в разы.
Что делать с этим за час
Возьмите три сценария: обычный день, пик и худший случай. Для каждого подставьте свои значения.
Разница между обычным днём и худшим случаем в агентных сценариях легко достигает порядка — и именно она определяет, нужен ли вам жёсткий потолок расходов. Если разница укладывается в два раза, потолок можно не ставить. Если в десять — без него вы не управляете бюджетом, а наблюдаете за ним.
Отдельно посчитайте, во что обходится один пользователь в месяц. Если эта цифра сопоставима с тем, что он вам платит, дальше можно не считать: проблема не в оптимизации, а в модели монетизации. Это неприятный разговор, но он дешевле, когда происходит до масштабирования.
Где обычно ошибаются
Самая частая ошибка — линейная экстраполяция с пилота. На пилоте десять пользователей, счёт небольшой, умножаем на тысячу и получаем оценку. Она систематически занижена, потому что на пилоте короткие диалоги, мало повторов и нет длинного хвоста сложных запросов.
Вторая — считать по средней длине запроса. Средняя длина не отражает распределения, а платите вы за сумму, в которую длинный хвост вносит непропорциональный вклад.
Третья — забыть про системную инструкцию и описания инструментов. Они отправляются на каждом шаге, они одинаковые, и поэтому про них не думают. При пяти шагах вы платите за них пять раз.
Мнение
Оптимизировать стоит четвёртый множитель, а не пятый.
Смена модели на более дешёвую даёт разовый выигрыш и обычно стоит недель работы над качеством: меняется поведение, ломаются подобранные формулировки, нужен новый прогон проверок. Сокращение контекста и ограничение повторов дают тот же порядок экономии, не трогают качество ответов и делаются за дни.
Когда это неверно: если у вас один шаг, короткий контекст и нет повторов, оптимизировать нечего, кроме цены за токен. Тогда действительно вся экономия в выборе поставщика, и заниматься надо именно им.
Что стоит поставить до запуска
Жёсткий потолок расходов на месяц и алерт на превышение доли, а не абсолютной суммы: доля срабатывает раньше и без ложных тревог в дни пиков. Разбор счёта постфактум — это всегда разговор о том, что уже потрачено.
И отдельная строка в трассировке: номер повтора. Без неё вопрос «почему счёт вырос» не имеет ответа в данных, только в предположениях.
Три рычага, которые дают экономию без потери качества
Обрезка истории. Не весь диалог нужен на каждом шаге. Обычно достаточно последних нескольких ходов плюс краткая выжимка более раннего. Это самая дешёвая правка из всех: она не трогает ни модель, ни логику, а срезает множитель, который растёт быстрее остальных.
Разделение системной инструкции и описаний инструментов. Если агенту на конкретном шаге доступны три инструмента из пятнадцати, отправлять описания всех пятнадцати незачем. Отбор по шагу убирает постоянную составляющую, которую вы иначе платите на каждом обращении.
Ранняя остановка. Отдельная проверка «достаточно ли уже собрано, чтобы ответить» между шагами. Она стоит одного дешёвого обращения и регулярно экономит два дорогих. Работает не всегда, но там, где работает, эффект больше, чем от смены поставщика.
Что не считается экономией
Уменьшение максимального числа шагов «чтобы не разгонялось» экономит счёт и одновременно роняет долю успешных ответов. Формально расходы падают, фактически вы просто перестали решать часть задач — и это надо называть своим именем, а не оптимизацией.
То же с агрессивным кешированием ответов: оно даёт эффект ровно в той мере, в какой запросы повторяются. Прежде чем закладывать его в расчёт, посмотрите долю точных повторов в реальном трафике; она обычно ниже, чем ожидается.
Редакции: формула проверяется на собственном трафике. Публиковать её с примерными числами нельзя — цены поставщиков меняются, и устаревшая таблица хуже её отсутствия. Здесь намеренно нет ни одной подставленной цифры.