Сокращение затрат на токены агентов: кэширование, маршрутизация и поддержание чистоты контекста.

Обычно новый агент начинает работу с системным промптом длиной 500 токенов и двумя инструментами, причем оба этих показателя быстро растут. Согласно сообщениям, утекший системный промпт Claude имел длину около 24 000 токенов. Пользователи OpenClaw сообщают, что уже в первом ходе на Gemini 3.1 Pro поступало более 150 000 токенов входных данных, в результате чего ответ составлял всего 29 токенов. Если не оптимизировать работу агента, то обработка 100 сообщений в день при объеме входных данных 166 тыс. токенов каждое обойдется примерно в 996 долларов в месяц на Gemini 3.1 Pro и около 2 490 долларов на Claude Opus 4.6. Однако некоторые правила проектирования позволяют снизить эти затраты до примерно 50–100 долларов в месяц.

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

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

Перестаньте платить дважды за одни и те же токены

Затраты на работу модели возникают не только из-за чрезмерно частого вызова модели. Они также проистекают из необходимости постоянной оплаты обработки одинакового текста. Для решения этой проблемы существуют два совершенно разных механизма. Кэширование K/V является основой кэширования запросов, тогда как семантическое кэширование — это отдельная концепция. Для длинных системных запросов кэширование запросов обеспечивает простое решение проблемы; семантическое кэширование требует больше усилий и сопряжено с более высоким риском.

Как работает кэш K/V

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

Когда большая языковая модель получает запрос, текст токенизируется, токены преобразуются в векторы, а внутри каждого слоя внимания эти векторы проецируются в тензоры K/V.

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

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

Экономическая выгода легко понять, используя округленные цифры. Предположим, обработка 2 000 токенов занимает одну секунду, а объем вводного текста составляет 10 000 токенов. Пропуск повторных вычислений экономит 5 секунд на каждый запрос, хотя реальная скорость предварительной обработки сильно варьируется в зависимости от настроек.

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

Таким образом, сохранённый кэш ускоряет запросы и тем самым снижает их стоимость. Однако хранение кэша не бесплатно. Кэшированные данные в формате K/V занимают память на стороне сервера, поэтому многие провайдеры истекают срок действия записей примерно через 5–10 минут.

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

Кэширование префиксов в vLLM

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

Важны три флага:

• --enable-prefix-caching включает эту функцию.
• --block-size задаёт количество токенов в каждом блоке. При размере блока 16 движок прекращает обработку после 16 токенов и начинает новый блок.
• --kv-cache-memory-bytes явно указывает размер кэша K/V для каждой GPU. Больше памяти позволяет кэшируемым блокам сохраняться дольше, но одновременное выполнение множества длинных запросов быстрее заполняет кэш, из-за чего старые блоки удаляются раньше.

Существуют и другие варианты, включая SGLang с RadixAttention для кэширования префиксов, а также LMCache, предназначенный для интеграции в движки обслуживания. Механизмы работы схожи с описанными выше.

Кэширование через поставщиков API

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

Отправка prompt-cache-key позволяет объединять похожие запросы и повышать коэффициент попадания в кэш. Кэширование автоматически включается для запросов длиной 1 024 токена и более, но первые 256 токенов используются для направления запросов обратно в тот же кэш, поэтому статическая часть должна быть длиннее 256 токенов.

Anthropic работает иначе: кэширование необходимо включить с помощью параметра cache-control. Удаление данных обычно происходит через 5–10 минут бездействия у обоих поставщиков, но этот срок можно увеличить. Anthropic позволяет продлить его до часа за вдвое большую цену.

При самостоятельном хостинге сэкономленное время означает также сэкономленные деньги. С поставщиками API преимущество заключается в более дешевых токенах входных данных из кэша. OpenAI снижает стоимость токенов из кэша на 90% от обычной цены. Anthropic также предоставляет такую скидку, но взимает плату за хранение кэша, поэтому неправильное использование может обойтись дороже, чем отсутствие кэширования.

Когда 90% запроса является статическим и кэш используется правильно, как показано на графике, стоимость резко снижается.

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

Семантическое кэширование

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

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

Предложение заключается в сопоставлении похожих запросов с уже существующими ответами. Вопрос вроде «Какая столица Франции?» и спешное требование «Быстро, скажите столицу Франции» должны оба направляться к одному сохраненному ответу, без необходимости повторного запуска ИИ для его генерации. Это хорошо работает, когда множество людей задают практически идентичные универсальные вопросы, а основные данные медленно устаревают.

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

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

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

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

Многие базы данных могут выполнять эту работу, а библиотеки занимаются реализацией необходимых механизмов, среди них semanticcache, prompt-cache, GPTCache, vCache, Upstash semantic-cache и Redis с LangCache.

Экономия может быть значительной. Redis утверждает, что количество вызовов API сокращается на 68,8%, а задержка уменьшается на 40–50%, хотя эти цифры отчасти являются маркетинговыми, поскольку они получены в условиях простого сценария вопрос-ответ. Результаты полностью зависят от настройки: бот для вопросов-ответов с большим количеством дублирующихся запросов экономит больше, тогда как агент для программирования, чьи запросы уникальны, — меньше.

Кэширование подсказок эффективно, когда меняющийся вопрос находится внутри большой статической подсказки, а семантическое кэширование — когда люди постоянно перефразируют один и тот же вопрос. Уровень семантического совпадения 15% приносит лишь незначительную экономию, но при уровне выше 45–50% это уже становится значимым преимуществом.

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

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

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

Не загружайте замороженные токены заранее

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

Сохраняйте размер слоя, загружаемого постоянно, минимальным

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

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

Сообщается, что Claude Code использует подобную схему управления памятью. Всегда загружается индексный файл, длина которого не должна превышать 200 строк, в то время как подробные файлы по темам хранятся в другом месте. Как агент будет вести себя на практике по сравнению с тем, что предусмотрено системой, — это отдельный вопрос. Похожий подход применяется при настройке продвинутых инструментов Claude, в слоистой архитектуре Claude Skills, а также при попытках загружать инструменты MCP по мере необходимости вместо того, чтобы указывать все определения серверов сразу в промпте.

Работает ли это?

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

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

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

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Определён один инструмент с именем tool_search, при этом используется готовый вариант — BM25 или Regex, либо пользовательский вариант. Для иллюстрации один инструмент отмечен как отложенный. Это имеет смысл только при наличии 10 и более инструментов. Поиск выполняется сервисом Anthropic, поэтому способ вставки схемы инструмента в системный промпт и сам процесс поиска остаются скрытыми. Как только находится подходящий инструмент, его определение добавляется непосредственно в разговор в виде блока tool_reference.

Идея хороша, поскольку она позволяет использовать меньший объём начального контекста за счёт дополнительного шага поиска. Однако тестирование с 4 000 инструментами принесло довольно неудовлетворительные результаты, поэтому требуется дальнейшее тестирование. Инструменты также должны быть достаточно хорошо описаны, чтобы их можно было найти, а отладка усложняется, когда промежуточный шаг остаётся невидимым.

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

Экономия здесь зависит от количества токенов, которые отправляются изначально. Второй калькулятор сравнивает поиск инструментов с кэшированием промптов.

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

Используйте дешевые модели для простых задач

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

Коммерческие продукты уже используют часть этих методов. Сообщается, что ChatGPT направляет запросы в зависимости от таких факторов, как тип разговора, сложность вопроса, необходимость использования инструментов и явное указание на необходимость глубокого анализа, например фраза «think hard», в то время как Claude опирается на делегирование задач на основе описания плюс встроенных подагентов, таких как Explore. Сама концепция понятна; сложность заключается в том, чтобы реализовать её без снижения качества ответов. Далее рассматриваются методы прогнозируемого направления запросов и подходы с проверкой результата, такие как каскадные процессы и использование подагентов, а третий раздел посвящен расчету экономии средств.

Направление запросов в зависимости от сложности

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

Сигналы маршрутизации от OpenAI не являются публичными, и пользователи часто ощущают, что в неподходящий момент их перенаправили на менее совершенную модель. В мире открытого кода есть больше вариантов для изучения. RouteLLM от LMSYS, группы из Беркли, создавшей Chatbot Arena, обучается на реальных данных о предпочтениях пользователей, собранных в этом проекте. Он сочетает стандартные эмбеддинги с небольшой частью для маршрутизации, что должно снижать затраты на хостинг; авторы сообщают о значительном снижении расходов при сохранении большей части производительности GPT-4. Это утверждение ещё не проверялось независимо.

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

Современные маршрутизаторы вряд ли обеспечивают значительное преимущество по сравнению с простыми решениями. Люди не отказались от маршрутизации и продолжают её тестировать, но экономия не гарантирована, если качество ответов остается низким. Существуют также сервисы с хостингом, такие как OpenRouter Auto и Switchpoint, однако ни один из публичных решений не раскрывает деталей своей маршрутизационной логики или точности. Калькулятор сравнивает LLMRouter, эвристические методы, самостоятельно размещаемый классификатор, подход с использованием LLM в качестве маршрутизатора, RouteLLM и OpenRouter Auto. Для оценки качества в реальных условиях необходимы тщательные тестирования с четкими цифрами, что крайне важно для этой области.

Начните с дешевых решений, переходите на более сложные при низкой уверенности

Не пытаясь предсказывать уровень сложности запроса на основе его триггера, дешевая модель может сначала дать ответ, а затем проверочный механизм решит, сохранить ли его или перевести задачу на более мощную модель. В статье Google «Speculative Cascades» описывается этот компромисс: сначала используются небольшие модели ради экономии средств и ускорения работы, а более крупные — только тогда, когда это необходимо.

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

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

Реализация с открытым исходным кодом под названием CascadeFlow утверждает, что позволяет достичь экономии в 69% при сохранении качества на уровне 96% по сравнению с GPT-5. Однако тесты проводились с использованием заданий, имеющих проверяемые правильные ответы, таких как математические задачи и вопросы с множественным выбором. Основная проблема заключается в том, что небольшие модели часто ошибаются уверенно, поэтому целесообразно начинать с консервативных порогов и чаще повышать их, что увеличивает затраты. Использование дешевых каскадных решений в калькуляторе позволяет достичь экономии около 50%, при условии, что для некоторых запросов всё же требуются более крупные модели.

Делегирование субагентам

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

Claude Code поставляется с встроенными подагентами. Подагент Explore является специализированным работником типа Haiku, предназначенным для исследования и поиска в кодовой базе; он использует принцип применения более дешевых моделей к менее сложным задачам. Основная сессия также делегирует задачи путем сопоставления описаний незаметно для пользователя, в результате чего тот видит сниженную общую стоимость. Поскольку оркестратор обычно участвует в планировании, синтезе и повторных попытках, экономия оказывается меньше, чем при использовании механизма маршрутизации.

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

Сохраняйте чистоту контекста

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

Это происходит повсюду. Пользователи OpenClaw жалуются на накопление контекста, как и пользователи Claude Code, ведь добавлять данные проще, чем их удалять.

Самая сложная часть — это обработка состояния

Это двухуровневая проблема. Речь идёт не только о сжатии чата; новые данные также должны оставаться в аккуратном состоянии при поступлении в рабочее состояние, а это требует тщательной работы. Плохой подход выглядит так: агент постоянно добавляет необработанные результаты в контекст:

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

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

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

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

В записках Anthropic по задачам долгосрочного характера говорится, что сжатие должно сохранять архитектурные решения, нерешенные ошибки и детали реализации. Автономное сжатие LangChain позволяет агенту самостоятельно решать, когда его применять, не дожидаясь того момента, когда контекст уже станет слишком объемным — это, по-видимому, и является подходом Anthropic. Команды начинают рассматривать сжатие как проблему системного уровня, используя соответствующие критерии оценки и правила, специфичные для каждого агента, а не просто как обычный трюк суммаризации.

В недавней статье Цзя и соавторов утверждается, что при 6-кратном сжатии было достигнуто сокращение объема токенов на 51,8–71,3%, а также улучшение эффективности решения задач на 5,0–9,2% в рамках тестов SWE-bench Verified. Следовательно, речь идет не только о снижении затрат — это также способствует улучшению общей производительности.

Удаление ненужных данных может эффективно освободить от 30 до 70% объема контекста, что эквивалентно существенной экономии средств. Для окна контекста в 10 тыс. элементов очистка 30–50% данных при 100 тыс. операциях может сэкономить до 1 500 долларов, а при объеме в 40 тыс. — до 6 000 долларов. Инструменты сжатия, уже использующие очень маленькие дешевые модели, могут стоить дороже, чем они экономят. Тем не менее чистый контекст не снижает качество в той степени, в какой это могут сделать семантическое кэширование или маршрутизация, поэтому при правильном применении это является явной выгодой. Недостаток заключается в необходимости приложения усилий для этого.

Выбор среди них

Существует четыре способа снизить затраты на токены, и оптимальное сочетание зависит от конкретного случая использования:

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

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