Чтобы сэкономить на затратах на логические выводы, вы можете включить кэширование подсказок для поддерживаемых поставщиков и моделей. Большинство провайдеров автоматически включают кэширование подсказок, но учтите, что некоторые (см. Alibaba и Anthropic ниже) требуют, чтобы вы включали его для каждого сообщения. При использовании кэширования (автоматически в поддерживаемых моделях или через cache_control ), LLMSTORE использует фиксированную маршрутизацию поставщика для максимального увеличения количества попаданий в кэш — см. Привязка поставщика маршрутизации подробности ниже.

Привязка маршрутизации поставщика

Чтобы максимизировать вероятность попадания в кеш, LLMSTORE использует привязанную маршрутизацию поставщика для маршрутизации ваших последующих запросов к той же эндпоинту поставщика после кэшированного запроса. Это работает автоматически как с неявным кэшированием (например, OpenAI, DeepSeek, Gemini 2.5), так и с явным кэшированием (например, Anthropic). cache_control точки останова). Как это работает:
  • После запроса, использующего оперативное кэширование, LLMSTORE запоминает, какой поставщик обслужил ваш запрос.
  • Последующие запросы для одной и той же модели направляются к одному и тому же провайдеру, сохраняя при этом ваш кеш.
  • Прикрепленная маршрутизация активируется только в том случае, если цена чтения кэша поставщика ниже, чем обычная цена быстрого запроса, что гарантирует вам всегда выгоду от экономии средств.
  • Если прикрепленный поставщик становится недоступным, LLMSTORE автоматически переключается на следующего лучшего поставщика.
  • Привязка маршрутизации не используется при указании ручного заказа провайдера через provider.order — в этом случае ваш явный заказ имеет приоритет.
Жесткая детализация маршрутизации: Прикрепленная маршрутизация отслеживается на уровне учетной записи, для каждой модели и для каждого разговора. По умолчанию LLMSTORE идентифицирует диалоги, хешируя первое системное сообщение (или сообщение разработчика) и первое несистемное сообщение в каждом запросе, поэтому запросы, которые используют одни и те же открывающие сообщения, направляются одному и тому же поставщику. Это означает, что разные диалоги естественным образом привязаны к разным провайдерам, улучшая балансировку нагрузки и пропускную способность, сохраняя при этом кэши в каждом диалоге.

Использование session_id за липкие сеансы

Для более явного контроля над закрепленной маршрутизацией вы можете передать session_id в вашем запросе. Когда session_id присутствует, LLMSTORE использует его непосредственно в качестве закрепленного ключа маршрутизации, а не извлекает его из хеширования сообщений. Это особенно полезно для многооборотных агентских рабочих процессов, где открывающие сообщения могут меняться между запросами, но вы все равно хотите направить их к тому же поставщику. Вы можете предоставить session_id двумя способами:
  • Тело запроса: Включить session_id в качестве поля верхнего уровня в теле вашего запроса. Если указаны оба значения, значение body имеет приоритет.
  • Заголовок: установите x-session-id HTTP-заголовок.
Объект session_id должно содержать не более 256 символов. Если ни один из них не установлен, LLMSTORE возвращается к стилю OpenAI. Поле запроса prompt_cache_key в качестве закрепленного ключа маршрутизации. Клиенты, которые уже отправляют prompt_cache_key получить маршрутизацию, привязанную к сеансу, без каких-либо изменений.
Когда session_id установлен, липкая маршрутизация активируется при любом успешном запросе — даже до того, как будет замечено использование кэша — так что последующие запросы в том же сеансе получают выгоду от кэширования запросов с самого начала. Без session_id, липкая маршрутизация активируется только после обнаружения попадания в кэш.
При использовании списков фолбэков моделей липкая маршрутизация также закрепляет выбранную модель, а не только провайдера — модель не меняется на каждом шаге диалога.

Группировка запросов по модальностям

Помимо липкой маршрутизации, LLMSTORE использует session_id , чтобы сгруппировать ваши запросы в представлении «Сеансы» на странице «Журналы».. Один session_id связывает запросы в ходе разговора, повторных попытках и различных модальностях. Это позволяет отслеживать весь сеанс агента в одном месте. Эта группировка работает для синхронных эндпоинтов, а не только для завершения чата:
  • Чат и ответы: отправить session_id в теле запроса или x-session-id заголовок.
  • Встраивание, изменение ранжирования, преобразование речи в текст, преобразование текста в речь, создание изображений и видео: отправьте x-session-id заголовок. Эти эндпоинты не принимают тело session_id. Они используют это значение только для группировки, поэтому к ним не применяется липкая маршрутизация.
Ограничение в 256 символов применяется к обоим входам. Отправьте последовательное x-session-id в мультимодальном рабочем процессе, чтобы сгруппировать все эти поколения в одном сеансе. Например, агент расшифровывает аудио, вызывает модель чата, а затем генерирует изображение.
Пакетный API пока не группирует свои поколения по session_id.

Проверка использования кэша

Чтобы узнать, сколько кэша сэкономлено при каждом поколении, вы можете:
  1. Нажмите кнопку подробностей на вкладке Активность страница
  2. Используйте /v1/generation API, описано здесь
  3. Проверьте prompt_tokens_details объект в ответе usage включается в каждый ответ API Поле
Объект cache_discount в теле ответа сообщит вам, сколько ответ сэкономил на использовании кэша. Некоторые поставщики, такие как Anthropic, будут иметь отрицательную скидку на запись в кэш, но положительную скидку (которая снижает общую стоимость) на чтение кэша.
При использовании списков фолбэков моделей липкая маршрутизация также закрепляет выбранную модель, а не только провайдера — модель не меняется на каждом шаге диалога.

Поля объекта использования

Объект использования в ответах API включает подробные метрики кэша в prompt_tokens_details поле:
Ключевые поля:
  • cached_tokens: Количество токенов, прочитанных из кэша (попадание в кэш). Когда это значение больше нуля, вы получаете выгоду от кэшированного контента.
  • cache_write_tokens: Количество токенов, записанных в кэш. Это появляется при первом запросе при создании новой записи в кэше.

OpenAI

Кэширование изменений цен:
  • Кэш записывает: на моделях до семейства GPT-5.6 плата не взимается. GPT-5.6 и более поздние версии записывают в кеш расходов стоимость, в 1,25 раза превышающую первоначальную входную цену, даже при автоматическом кэшировании — согласие не требуется.
  • Чтение кэша: (в зависимости от модели) взимается 0,25- или 0,50-кратная стоимость исходной входной цены.
Нажмите здесь, чтобы просмотреть цены на кэш OpenAI для каждой модели. Оперативное кэширование с помощью OpenAI автоматизировано и не требует дополнительной настройки. Минимальный размер приглашения составляет 1024 токена. Нажмите здесь, чтобы узнать больше о кэшировании подсказок OpenAI и его ограничениях.

Явное кэширование подсказок

Кэширование изменений цен:
  • Запись в кэш: взимается в 1,25 раза больше исходной цены ввода (такая же ставка, как и при автоматической записи в кэш в GPT-5.6 и более поздних версиях).
  • Чтение кэша: взимается плата по сниженной скорости чтения кэша модели, так же, как и при автоматическом кэшировании.
Явное кэширование подсказок работает как для Chat Completions, так и для и Ответы API и дает вам прямой контроль над границами кэша вместо того, чтобы полагаться на автоматическое размещение точек останова OpenAI. Кэшированные префиксы имеют минимальный срок жизни 30 минут. См. Документацию OpenAI по явному кэшированию подсказок. для получения более подробной информации.
Явное кэширование подсказок OpenAI поддерживается только OpenAI GPT-5.6 и новее.
Есть два элемента управления:
  • prompt_cache_breakpoint: размещается в отдельном блоке текстового контента (input_text в ответах, text в завершениях чата), чтобы отметить конец многоразового префикса. Все, что проходит через этот блок, становится префиксом-кандидатом в кэше. Автоматическое кэширование остается включенным.
  • prompt_cache_options: размещается в корне запроса. Настройка mode чтобы "explicit" отключает точки останова, управляемые OpenAI, поэтому только блоки, отмеченные значком prompt_cache_breakpoint участвовать в кэшировании. Использование ttl для запроса продолжительности кэширования (например, "30m").
Responses API:
API завершения чата:
Токены уровня блока взаимозаменяемы: текстовый блок, отмеченный стиле Anthropic. cache_control получает prompt_cache_breakpoint при перенаправлении на поддерживающую модель OpenAI и блок, отмеченный значком prompt_cache_breakpoint получает значение по умолчанию (5 минут) cache_control при перенаправлении в Anthropic или Google. TTL не переводятся — cache_control ttl отброшен в сторону OpenAI, а уровень запроса prompt_cache_options остается только OpenAI.
Об активности кэша сообщается в usage.input_tokens_details (Ответы) и usage.prompt_tokens_details (Завершение чата): cache_write_tokens подсчитывает токены приглашений, записанные в кэш, и cached_tokens подсчитывает прочитанные из него токены подсказок.

Грок

Кэширование изменений цен:
  • Запись в кэш: бесплатно
  • Чтение кэша: взимается плата в размере x от исходной цены ввода.
Нажмите здесь, чтобы просмотреть цены на кэш Grok для каждой модели. Оперативное кэширование с помощью Grok автоматизировано и не требует дополнительной настройки.

Лунный ИИ

Кэширование изменений цен:
  • Запись в кэш: бесплатно
  • Чтение кэша: взимается плата в размере x от исходной цены ввода.
Оперативное кэширование с помощью Moonshot AI автоматизировано и не требует дополнительной настройки.

Грок

Кэширование изменений цен:
  • Запись в кэш: бесплатно
  • Чтение кэша: взимается плата в размере x от исходной цены ввода.
Оперативное кэширование с помощью Groq автоматизировано и не требует дополнительной настройки. В настоящее время доступно на моделях Kimi K2. Нажмите здесь, чтобы просмотреть документацию Groq.

Алибаба Квен

Кэширование изменений цен при явном кешировании:
  • Запись в кэш: взимается плата в размере x от стоимости первоначальная цена входных данных
  • Чтение кэша: взимается плата в размере x от стоимости первоначальная цена входных данных
Для кэширования подсказок Alibaba требуются явные точки останова в кэше. Добавить cache_control: { "type": "ephemeral" } к блокам контента, которые вы хотите кеш, использующий тот же синтаксис, что и явное кэширование Anthropic. Для записи в кэш используйте 5-минутный TTL. Явное кэширование Alibaba доступно на deepseek/deepseek-v3.2, qwen/qwen3-max, qwen/qwen-plus, qwen/qwen3.6-plus, qwen/qwen3-coder-plus, и qwen/qwen3-coder-flash. Эндпоинты моментальных снимков, в том числе qwen/qwen3.5-plus-02-15 и Параметры qwen/qwen3.5-flash-02-23, не надо поддерживает явное кэширование.

Пример

Anthropic Claude

Кэширование изменений цен:
  • Запись в кэш (5-минутный TTL): взимается плата в x от исходной цены ввода.
  • Запись в кэш (время жизни 1 час): плата взимается в 2 раза дороже исходной цены ввода.
  • Чтение кэша: взимается плата в размере x от исходной цены ввода.
Есть два способа включить кэширование запросов с помощью Anthropic:
  • Автоматическое кеширование: добавьте один Поле cache_control на верхнем уровне вашего запроса. Система автоматически применяет точку останова кеширования к последнему кэшируемому блоку и продвигает ее вперед по мере роста диалогов. Лучше всего подходит для многоходовых разговоров.
  • Явные точки останова в кэше: Разместить cache_control непосредственно на отдельных блоках контента для детального контроля над тем, что именно кэшируется. Существует ограничение на четыре явных точки останова. Рекомендуется зарезервировать точки останова кэша для больших объемов текста, таких как карточки персонажей, данные CSV, данные RAG, главы книг и т. д.
Автоматическое кэширование (верхний уровень) cache_control) поддерживается поставщиками Anthropic, Google Vertex AI, Azure и Amazon Bedrock, а также Claude Platform на AWS. В Amazon Bedrock LLMSTORE преобразует поле верхнего уровня в эндпоинт останова кэша (упрощенное управление кэшем Bedrock), поскольку API InvokeModel от Bedrock не принимает поля верхнего уровня напрямую. Явное значение для каждого блока Точки останова cache_control работают со всеми поставщиками, совместимыми с Anthropic, включая Bedrock и Vertex.
Поддержка Responses API: Responses API поддерживает автоматическое кэширование через верхний уровень. cache_control. В Anthropic стиле за блок Элементы cache_control внутри input не доступны через Responses API — вместо этого используйте поблочное OpenAIprompt_cache_breakpoint, который LLMSTORE преобразует в значение по умолчанию. Точка останова cache_control , когда запрос направляется в Anthropic или Google. Обратите внимание, что prompt_cache_breakpoint несет нет ttl; если вам нужно установить кеш ttl, используйте Chat Completions или Anthropic Messages API с cache_control.
По умолчанию срок действия кеша истекает через 5 минут, но вы можете продлить этот срок до 1 часа, указав "ttl": "1h" в cache_control объект. Нажмите здесь, чтобы узнать больше о кэшировании подсказок Anthropic и его ограничениях.

Минимальные требования к токенам

Каждая модель имеет минимальную длину кэшируемого запроса (см. Ограничения кэша Anthropic):
  • 4096 токенов: Клод Опус 4.8, Клод Опус 4.7, Клод Опус 4.6, Клод Опус 4.5, Клод Хайку 4.5
  • 2048 токенов: Клод Хайку 3.5
  • 1024 токена: Клод Сонет 4.6, Клод Сонет 4.5, Клод Опус 4.1, Клод Опус 4, Клод Сонет 4
Приглашения короче этого минимума не будут кэшироваться.

Параметры TTL кэша

LLMSTORE поддерживает два значения TTL кэша для Anthropic:
  • 5 минут (по умолчанию): "cache_control": { "type": "ephemeral" }
  • 1 час: "cache_control": { "type": "ephemeral", "ttl": "1h" }
Срок жизни в 1 час полезен для более длительных сеансов, когда вы хотите поддерживать кэшированный контент по нескольким запросам, не неся при этом повторные затраты на запись в кэш. 1-часовой TTL обходится дороже для записи в кэш (базовая цена ввода в 2 раза против 1,25x для 5-минутного TTL), но позволяет сэкономить деньги при длительных сеансах, избегая повторных записей в кэш. Срок жизни в 1 час для явных точек останова в кэше поддерживается всеми поставщиками моделей Claude (Anthropic, Amazon Bedrock и Google Vertex AI).

Кэширование в пакетном API

cache_control точки останова работают на Anthropic :batch эндпоинты так же, как и в API синхронизации, но запросы внутри одного пакета могут обрабатываться одновременно и в любом порядке — кеш, записанный одной строкой, не гарантированно будет виден другим строкам в том же пакете. Чтобы получить надежные попадания в кеш, используйте "ttl": "1h" устанавливает точки останова на общем префиксе и повторно использует этот префикс в последующих пакетах (или сначала нагревает кэш с помощью запроса на синхронизацию): первый пакет платит цену записи в кэш, а последующие пакеты считывают из кэша до тех пор, пока он остается теплым.

Примеры

Автоматическое кэширование (рекомендуется для многоходовых разговоров)

При автоматическом кэшировании добавьте cache_control на верхнем уровне запроса. Система автоматически кэширует весь контент до последнего кешируемого блока:
По мере расширения диалога точка останова кэша автоматически перемещается, чтобы охватить растущую историю сообщений. Автоматическое кэширование с TTL в течение 1 часа:

Явные точки останова в кэше (детальный контроль)

Пример кэширования системных сообщений (TTL по умолчанию — 5 минут):
Пример кэширования сообщений пользователя с TTL в 1 час:

DeepSeek

Кэширование изменений цен:
  • Запись в кэш: взимается та же цена, что и исходная цена ввода.
  • Чтение кэша: взимается плата в размере x от исходной цены ввода.
Оперативное кэширование с помощью DeepSeek автоматизировано и не требует дополнительной настройки.

З.АИ

Кэширование изменений цен:
  • Запись в кэш: бесплатно (в настоящее время Z.AI указывает кэшированное хранилище входных данных как бесплатное ограниченное время)
  • Чтение кэша: взимается плата по сниженной цене ввода в кэш, указанной на каждой странице модели (обычно примерно в 0,2 раза превышает первоначальную цену ввода).
Нажмите здесь, чтобы просмотреть цены кэша Z.AI на каждую модель. Оперативное кэширование с помощью Z.AI автоматизировано и не требует дополнительной настройки. О прочтении кэша сообщается в cached_tokens поле prompt_tokens_details в ответе об использовании. Нажмите здесь, чтобы узнать больше о кэшировании контекста Z.AI. Чтобы повысить частоту попаданий в кеш, LLMSTORE отправляет Z.AI ключ привязки сеанса с каждым запросом, полученный из вашей учетной записи и, если он предоставлен, ваш session_id. Прохождение session_id в многоходовых диалогах сохраняет запросы из одного и того же сеанса в одном и том же кэше.

Google Близнецы

Неявное кэширование

Модели Gemini 2.5 Pro и 2.5 Flash теперь поддерживают неявное кэширование, обеспечивая функции автоматического кэширования, аналогичные автоматическому кэшированию OpenAI. Неявное кэширование работает без проблем — без ручной настройки или дополнительных настроек. cache_control требуются точки останова. Изменения цен:
  • Никаких затрат на запись и хранение в кэше. – за кэшированные токены взимается плата в размере x от исходной стоимости входных токенов.
Обратите внимание, что TTL в среднем составляет 3–5 минут, но может варьироваться. Для запросов, подходящих для кэширования, существует минимум токенов ​​для Gemini 2.5 Flash и токенов для Gemini 2.5 Pro. Официальное объявление от Google
Чтобы максимизировать количество неявных попаданий в кэш, сохраняйте начальную часть сообщения. массивы согласованы между запросами. Push-варианты (например, вопросы пользователей или элементы динамического контекста) в конце вашего приглашения/запроса.

Изменения цен на кэшированные запросы:

  • Запись в кэш: взимается по стоимости входного токена плюс 5 минут хранения в кэше, рассчитывается следующим образом:
  • Чтение кэша: взимается плата в размере × исходной стоимости входного токена.

Поддерживаемые модели и ограничения:

Только некоторые модели Gemini поддерживают кэширование. Пожалуйста, ознакомьтесь с [Ценовой документацией Gemini API] Google.](https://ai.google.dev/gemini-api/docs/pricing) для получения самой последней информации. Срок жизни записей в кэше (TTL) составляет 5 минут, и он не обновляется. Через 5 минут срок действия кеша истекает и необходимо записать новый кеш. Модели Gemini обычно имеют минимум 4096 токенов для записи в кэш. Кэшированные токены учитываются при максимальном использовании токена модели. Gemini 2.5 Pro имеет минимум токенов , а Gemini 2.5 Flash содержит минимум токенов .

Как работает кэширование подсказок Gemini в LLMSTORE:

LLMSTORE упрощает управление кэшем Gemini, устраняя сложности:
  • Вам не нужно вручную создавать, обновлять или удалять кэши.
  • Вам не нужно явно управлять именами кэшей или TTL.

Как включить кэширование подсказок Gemini:

Для кэширования Gemini в LLMSTORE необходимо вставить cache_control точки останова явно указаны в содержимом сообщения, аналогично Anthropic. Мы рекомендуем использовать кэширование в первую очередь для больших фрагментов контента (таких как файлы CSV, длинные карточки символов, данные расширенной генерации (RAG) или обширные текстовые источники).
Количество не ограничено. cache_control точки останова, которые вы можете включите в свой запрос. LLMSTORE будет использовать только последнюю точку останова для Gemini кэширует обычное содержимое сообщений. Включая несколько точек останова безопасен и помогает поддерживать совместимость с Anthropic, но только последний будет использоваться для Близнецов.
У Близнецов есть сингл поле systemInstruction и кэшированное содержимое Gemini. относится к этому systemInstruction как неизменяемый. В LLMSTORE это означает cache_control внутри первого system или Сообщения developer можно кэшировать нормализованное системное приглашение, но оно не может сохранить некэшированный динамический хвост внутри того же сообщения. Если вам нужна часть приглашения, чтобы оставаться динамичной, перенесите этот динамический контент на более поздний срок. сообщение user вместо его добавления после кэшированного блока в первом system сообщение.

Примеры:

Пример кэширования системных сообщений

Этот шаблон работает, когда кэшированное системное содержимое стабильно во всех запросах. Если вам нужен динамический сегмент подсказок, поместите его позже user скорее сообщение , чем как некэшированный конечный контент в первом system сообщение.

Пример кэширования сообщений пользователя