Как снизить затраты на LLM: кеш, маршрутизация и лимиты

Где бюджет утекает каждый день

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

Самая частая проблема - длинный system prompt, который приложение отправляет снова и снова. Если инструкция весит 1200 токенов, а сама задача занимает 80, вы платите в основном за повтор. На большом объеме это быстро бьет по бюджету. Бот поддержки, который отвечает на тысячи коротких вопросов в день, может тратить заметную часть денег только на одинаковый префикс.

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

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

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

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

Что измерить до первых правок

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

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

Для каждого сценария соберите пять чисел:

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

Последний пункт лучше считать строго. Не по одному удачному запросу, а по формуле: все затраты на сценарий / число ответов, которые дошли до нужного результата. Если из 100 запросов 15 ушли в повторы, а 10 ответов оператор потом правил руками, это тоже часть стоимости LLM в продакшене.

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

Смотрите не только на среднее, но и на распределение. Средний контекст может быть 6 тысяч токенов, а p95 - уже 18 тысяч. Обычно бюджет съедают именно такие хвосты.

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

Разделите сценарии по цене ошибки

Одна и та же дорогая модель для всех запросов почти всегда сжигает деньги зря. Смотрите не на престиж модели, а на цену промаха. Если ошибка не ломает процесс и не бьет по деньгам, переплачивать незачем.

Обычно хватает трех классов:

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

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

Простое правило перехода

Если задача укладывается в 1-2 коротких абзаца и цена ошибки мала, берите дешевую модель. Если нужно точно вынуть поля, собрать JSON или сжать документ без потери смысла, ставьте средний класс. Если первая модель сомневается, противоречит правилам или запрос связан с деньгами и правовыми рисками, сразу поднимайте его выше.

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

Если у вас единый OpenAI-совместимый эндпоинт, такие правила удобнее держать в маршрутизации, а не размазывать по коду каждого сервиса.

Где кеширование промптов реально экономит

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

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

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

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

Hit rate лучше считать отдельно по каждому сценарию. Один и тот же подход может давать 70% попаданий в поддержке и 5% в разборе договоров. Среднее число по всей системе здесь только запутает.

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

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

Как сократить контекст без лишнего риска

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

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

С документами правило то же. Модели редко нужен весь договор, весь JSON или вся карточка клиента. Передавайте только те поля, которые участвуют в задаче. Для проверки реквизитов не нужен блок с историей правок. Для ответа по доставке не нужен весь профиль пользователя.

В поисковых сценариях лишний контекст тоже быстро раздувает счет. Если поиск вернул 10 чанков, это не значит, что все 10 надо отправлять в модель. Сначала отберите 3-4 самых близких по смыслу фрагмента, а остальное оставьте как запасной вариант. Нередко одно хорошее совпадение работает лучше, чем длинная простыня текста.

Проверять такие изменения лучше на небольшой, но живой выборке. Возьмите 30-50 реальных запросов, прогоните их с полным и коротким контекстом, сравните точность, длину ответа и число ошибок. Отдельно отметьте сценарии, где короткий контекст ломает результат.

Простой пример: в поддержке интернет-магазина полный лог диалога занимал 6-8 тысяч токенов, а после резюме и двух последних ходов - около 1,5 тысячи. Если качество ответа не просело, экономия становится заметной уже в первый день.

Если вы используете единый LLM-шлюз, такие тесты проще проводить по сценариям. В RU LLM, например, удобно сравнивать маршруты и быстро видеть, где короткий контекст снижает стоимость без потери качества.

Поставьте предел на ретраи

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

Для большинства сценариев хватает одного ретрая на сетевой сбой или таймаут. Второй повтор иногда оправдан для коротких запросов, но пять попыток подряд почти никогда не окупаются. Если модель не ответила с первой или второй попытки, проблема обычно не в удаче, а в размере контекста, лимитах провайдера или в самом запросе.

Ошибки 4xx лучше разбирать, а не повторять. Если вы получили ошибку валидации, превышение лимита токенов или отказ по правам доступа, повтор ничего не исправит. Он только сожжет еще деньги и добавит шум в логи.

На повторе запрос стоит менять. Самый полезный шаг - урезать контекст: убрать дубли, старые сообщения и длинные вложения, которые не влияют на ответ. Рядом поставьте жесткий предел на выходные токены. Часто модели хватает 300-500 токенов, а без лимита она уходит в длинный ответ и умножает стоимость.

Рабочая схема короткая:

• 1 ретрай только на таймаут и сетевой сбой
• 0 ретраев на 4xx ошибки
• перед повтором сократить контекст
• на каждом запросе ограничить max tokens
• записывать точную причину повтора

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

Как внедрить это по шагам

Не пытайтесь чинить все сразу. Сначала возьмите 2-3 сценария, которые съедают больше всего денег. Обычно это поддержка, разбор длинных документов и генерация типовых отчетов.

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

Порядок внедрения

1. Выберите дорогие сценарии и посчитайте для каждого цену на 1000 запросов.
2. Включите кеширование для длинных и повторяющихся префиксов: system prompt, правила, шаблоны, большие инструкции.
3. Перенесите простые задачи на более дешевые модели. Классификация, извлечение полей и короткие переписывания редко требуют самой сильной модели.
4. Ограничьте ретраи. В большинстве команд хватает 1-2 автоматических повторов, если второй запрос уже короче и точнее первого.
5. Сравните результат до и после по цене, задержке и качеству, а не только по общему счету.

Качество лучше проверять на одном и том же наборе задач. Если раньше модель решала 92 из 100 кейсов, а после изменений решает 91, но счет упал на 35%, это часто нормальный обмен. Если точность просела заметно, откатите один шаг и проверьте, что именно сломалось.

Если у вас уже есть единый OpenAI-совместимый шлюз, этот этап идет быстрее: можно менять маршрутизацию и класс модели без переписывания SDK и бизнес-логики. В случае с RU LLM обычно достаточно поменять base_url и дальше тестировать правила на части трафика, не ломая текущую интеграцию.

Как считать экономию по каждому сценарию

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

Удобно считать так:

Стоимость 1000 запросов = 1000 × доля сценария ×
((эффективный вход / 1000) × цена входа + (выход / 1000) × цена выхода) × (1 + доля ретраев)

Эффективный вход = динамический вход + повторяемая часть × (1 - hit rate кеша)

Повторяемая часть - это системный промпт, шаблон, инструкции, куски политики ответа. Если кеш попадает в 70% запросов, вы платите за эту часть только в оставшихся 30%. Это особенно заметно там, где длинный системный промпт и короткий ответ.

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

Теперь разница видна в рублях. Допустим, 60% запросов идут в дешевый класс, 30% в средний и 10% в дорогой. После обрезки контекста вход упал с 6000 до 4200 токенов, кеш дает 50% hit rate на повторяемую часть, а лимит на ретраи снизил их долю с 0,18 до 0,05. Даже без смены модели месячная сумма часто падает на десятки процентов.

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

Пример для поддержки, документов и отчетов

У команды поддержки в банке, ритейле или SaaS обычно смешиваются очень разные запросы. Одни пользователи спрашивают одно и то же по десять раз в день, другие присылают договоры и счета, третьи пишут длинные претензии. Если отправлять все это в одну дорогую модель, стоимость LLM в продакшене быстро выходит из-под контроля.

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

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

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

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

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

Ошибки, которые быстро съедают эффект

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

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

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

Еще одна тихая утечка - забытый лимит на выход. Если не ограничить длину ответа, модель начнет писать больше, чем нужно. Это особенно заметно в отчетах, суммаризациях и переписке, где разница между 200 и 1200 выходных токенов быстро бьет по счету.

Обычно эффект съедают пять вещей:

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

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

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

Быстрая проверка перед запуском

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

Перед запуском проверьте пять вещей:

• У каждого сценария есть владелец. Не абстрактная "команда AI", а конкретный человек, который отвечает за бюджет и держит цель, например: не дороже 2 рублей за успешный ответ в поддержке.
• Код режет контекст по правилу. Не оператор решает вручную, что оставить в запросе. Правило должно быть в коде: сколько последних сообщений брать, какие поля выкидывать, когда звать суммаризацию.
• Сервис ограничивает ретраи. Если модель не ответила два раза, третий и четвертый запрос часто просто жгут деньги. Там же задайте предел длины ответа, чтобы модель не писала 1200 токенов там, где хватает 150.
• Отчет считает цену одного успешного ответа. Средняя цена всех вызовов почти бесполезна. Нужна цена результата, который дошел до пользователя без ручной переделки.
• Команда видит расходы по сценариям и классам моделей. Иначе дорогой генератор отчетов незаметно смешается с дешевым классификатором для роутинга.

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

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

Что делать дальше

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

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

Рабочий порядок такой:

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

Если у вас есть требования 152-ФЗ, проверьте это сразу. Нужно точно знать, где лежат логи, где хранятся бэкапы, кто видит сырые промпты и маскируются ли персональные данные. Эти вопросы лучше закрыть до расширения пилота, а не после первого инцидента.

Когда нужен единый OpenAI-совместимый эндпоинт, маршрутизация моделей и биллинг в РФ, не обязательно собирать отдельный слой самим. Это можно закрыть через RU LLM: команда меняет base_url на api.rullm.com, сохраняет текущие SDK, код и промпты без изменений, а дальше уже наводит порядок в лимитах, кеше и выборе моделей.

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