Контроль затрат на LLM в продакшне: токенные бюджеты и дизайн запросов

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

Стоимость токенов - это проблема дизайна до того, как она станет проблемой выбора модели.

Куда уходят токены

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

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

Раздувание системного промпта

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

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

Хорошо выверенный системный промпт на 500 токенов часто работает так же хорошо, как на 2000 токенов - и стоит на 75% дешевле в фиксированной части каждого запроса.

Структура запросов и кеширование

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

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

Маршрутизация по моделям

Не каждый запрос нуждается в вашей лучшей и самой дорогой модели. Типичный паттерн:

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

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

Контроль длины вывода

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

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

Требование к мониторингу

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

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