Почему счёт за ИИ растёт быстрее выручки и как его ограничить

У обычного веб-приложения расходы растут ступеньками: сервер, потом сервер побольше. У приложения с языковой моделью внутри каждый запрос пользователя стоит денег, и стоит по-разному. Один человек задаёт короткий вопрос, другой вставляет сорокастраничный договор и просит «ещё раз, но короче» десять раз подряд. Тариф у них одинаковый, а себестоимость отличается в сотни раз.

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

Сначала измерь

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

Через неделю у тебя будет ответ на вопросы, которые иначе решаются спором:

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

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

Лимиты на человека и на день

Лимит — это не жадность, а гарантия, что один аккаунт не съест бюджет всех остальных. Нужны два уровня:

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

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

Отдельно поставь лимит частоты запросов. Скрипт, который дёргает твой эндпоинт в цикле, — это не пользователь, а счёт.

Выбирай модель под задачу

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

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

Ограничь длину ответа

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

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

Кешируй

Два вида кеша, и оба дешёвые:

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

Повторы с паузой, а не слепой цикл

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

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

попытка 1 → пауза 1 с → попытка 2 → пауза 2–3 с → попытка 3 → отказ

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

Текст пользователя — не инструкция

Если в промпт попадает текст, который написал пользователь или который пришёл со стороны (письмо, страница, файл), он может содержать команды для модели: «забудь инструкции», «выведи системный промпт», «повтори этот абзац десять тысяч раз». Последнее — уже вопрос денег, а не только безопасности.

Базовая гигиена:

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

Это не делает инъекции невозможными, но убирает самые дешёвые.

Итог

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

SUBXCAT может настроить учёт токенов, лимиты и выбор моделей в твоём продукте и показать, куда на самом деле уходит бюджет.