Как снизить расходы на LLM: кэширование, маршрутизация моделей и сокращение промптов

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

Из чего складывается счёт

На стоимость LLM влияют несколько факторов:

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

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

Сначала измерьте, потом меняйте

Оптимизация вслепую — это гадание. Для начала отслеживайте:

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

Реальные данные часто удивляют. Может выясниться, что 20% пользователей дают 70% расходов или что один RAG-процесс запихивает в каждый вызов гору бесполезного контекста. Пока кто-то не посмотрит, ни того ни другого не видно.

Кэшируйте повторяющуюся работу

Кэширование — один из самых простых способов вообще обойтись без инференса. Представьте ассистента поддержки. Тысячи клиентов спрашивают в том или ином виде: «Какие у вас условия возврата?» Если ответ почти не меняется, генерировать его каждый раз заново бессмысленно.

Схема короткая. Приходит запрос, проверяется кэш. При попадании пользователю возвращается сохранённый ответ. При промахе вызывается модель, результат сохраняется, ответ уходит пользователю. Повторных вызовов модели становится намного меньше.

Семантический кэш

Обычному кэшу нужно точное совпадение строк, а «Какие у вас условия возврата?» и «Можно вернуть деньги?» — разные строки. Семантический кэш сравнивает смысл. Каждый запрос представляется эмбеддингом, и когда сходство превышает заданный порог, система берёт уже готовый ответ. Это хорошо работает для:

• FAQ
• поддержки клиентов
• внутренних ассистентов по базе знаний
• документации к продукту
• однотипных корпоративных процессов

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

Маршрутизируйте по сложности

Частая архитектурная ошибка — отправлять каждый запрос самой мощной доступной модели. Сравните три запроса: «Какие у вас часы работы поддержки?», «Кратко перескажи эту жалобу клиента» и «Проанализируй эти финансовые документы и найди потенциальные риски». Премиальная модель с рассуждениями справится со всеми тремя, но платить за неё в первом случае — пустая трата.

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

Сокращайте промпт

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

Проверьте промпты на:

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

Короткий промпт с чёткой постановкой задачи часто работает не хуже длинного. Цель — не самый короткий промпт из возможных, а самый компактный, который всё ещё надёжно даёт нужный результат.

В RAG отправляйте меньше фрагментов, но точнее

RAG-конвейеры дорожают, когда модели передают слишком много найденных документов. Скажем, поиск возвращает 20 фрагментов по 1000 токенов. Это 20 000 токенов контекста на один запрос, и большая их часть модели, скорее всего, не нужна.

Лучше так: запрос, поиск, реранкинг и только самые релевантные фрагменты в LLM. Снижаются расход токенов, задержка и шум, а ответы могут даже стать лучше.

Сожмите то, что осталось

Даже в релевантных документах полно лишнего текста. Сжатие контекста вытаскивает полезные части до того, как их увидит модель. Документ на 10 000 токенов может ужаться до 1500 токенов по делу. Это окупается на:

• юридических документах
• финансовых отчётах
• технической документации
• корпоративных базах знаний
• длинной истории общения с клиентом

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

Модели способны написать гораздо больше, чем хочет пользователь. На вопрос вроде «Какой статус у моего заказа?» ответ на 1000 токенов не нужен. Задайте разумные лимиты на вывод и формат ответа. Для структурированных задач компактный формат работает лучше прозы:

Status: Shipped
Expected Delivery: Friday
Tracking Available: Yes

Меньше выходных токенов — меньше счёт, а обычно ещё и быстрее ответ.

Используйте обычный код там, где его достаточно

Возможно, это самое важное правило в AI-инженерии: некоторым задачам LLM не нужна вовсе. Проверка, превышает ли заказ $1000, — это одна строка: if order_value > 1000. Обычный софт и так справляется с вычислениями, сортировкой, фильтрацией, валидацией, работой с датами, запросами к базе и детерминированными бизнес-правилами. Оставьте модель для тех мест, где понимание языка или рассуждение действительно что-то добавляют.

Держите агентов на коротком поводке

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

Продуманная архитектура может:

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

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

Несрочное — пакетами

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

Выбирайте модель как инженер

Выбор модели — инженерное решение, и оценивать его стоит по нескольким вопросам:

• Качество: насколько точным должен быть результат?
• Стоимость: какая цена за запрос приемлема?
• Задержка: как быстро нужен ответ?
• Контекст: сколько информации модель должна принять?
• Рассуждение: насколько сложна задача?
• Надёжность: насколько стабильными должны быть результаты?

Замените вопрос «Какая модель лучшая?» на «Какой модели достаточно для этой задачи?». Такая небольшая перемена может изменить всю экономику продакшена.

Докажите, что ничего не сломалось

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

Условный пример: исходная версия даёт 92% при $0.020 за запрос, оптимизированная — 91% при $0.009. Если бизнес готов принять падение качества на один пункт, второй вариант обходится в разы дешевле.

Как сложить слои вместе

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

Какой экономии ждать

Не воспринимайте «минус 60%» как обещание. Результат сильно зависит от нагрузки. И всё же сочетание нескольких оптимизаций может дать серьёзное снижение. Возьмём гипотетический ежемесячный счёт в $10 000 и посмотрим, где его можно урезать:

• сократить повторные запросы на 20%
• перевести подходящие нагрузки на более дешёвые модели
• убрать лишние входные токены
• искать и отправлять только релевантный контекст
• устранить ненужные вызовы инструментов и моделей
• пресечь чрезмерно длинные ответы

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

Чек-лист перед запуском

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

• Необходимость: каждому ли шагу нужна LLM? Может ли детерминированный код взять часть работы на себя? Ограничены ли циклы агентов?
• Промпты: не раздуты ли системные инструкции? Нужны ли примеры? Не просачивается ли нерелевантный контекст?
• Поиск: не слишком ли много фрагментов извлекается? Есть ли реранкинг? Можно ли сжать контекст?
• Модели: не используется ли самая дорогая модель там, где она не нужна? Можно ли маршрутизировать запросы по сложности?
• Кэширование: кэшируются ли повторные запросы? Подойдёт ли семантический кэш?
• Вывод: контролируется ли длина ответов? Есть ли смысл в структурированном выводе?
• Мониторинг: отслеживается ли расход токенов? Известна ли стоимость каждой функции? Следят ли за метриками качества наравне со стоимостью?

Цель — устойчивость, а не минимальная цена

«Сделать AI как можно дешевле» — неправильная цель. Правильнее — достичь нужного для бизнеса качества при минимальных устойчивых затратах. Приложение поддержки может отвечать на простые FAQ маленькой моделью, а запутанные жалобы отдавать более сильной. Ассистенту для программирования на сложных задачах могут понадобиться серьёзные рассуждения. Конвейер обработки документов может ставить во главу угла пропускную способность и стабильность. Универсального рецепта нет, правильная архитектура зависит от нагрузки.

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