cache_control ), LLMSTORE использует фиксированную маршрутизацию поставщика для максимального увеличения количества попаданий в кэш — см. Привязка поставщика маршрутизации подробности ниже.
Привязка маршрутизации поставщика
Чтобы максимизировать вероятность попадания в кеш, LLMSTORE использует привязанную маршрутизацию поставщика для маршрутизации ваших последующих запросов к той же эндпоинту поставщика после кэшированного запроса. Это работает автоматически как с неявным кэшированием (например, OpenAI, DeepSeek, Gemini 2.5), так и с явным кэшированием (например, Anthropic).cache_control точки останова).
Как это работает:
- После запроса, использующего оперативное кэширование, LLMSTORE запоминает, какой поставщик обслужил ваш запрос.
- Последующие запросы для одной и той же модели направляются к одному и тому же провайдеру, сохраняя при этом ваш кеш.
- Прикрепленная маршрутизация активируется только в том случае, если цена чтения кэша поставщика ниже, чем обычная цена быстрого запроса, что гарантирует вам всегда выгоду от экономии средств.
- Если прикрепленный поставщик становится недоступным, LLMSTORE автоматически переключается на следующего лучшего поставщика.
- Привязка маршрутизации не используется при указании ручного заказа провайдера через
provider.order— в этом случае ваш явный заказ имеет приоритет.
Использование session_id за липкие сеансы
Для более явного контроля над закрепленной маршрутизацией вы можете передать session_id в вашем запросе. Когда session_id присутствует, LLMSTORE использует его непосредственно в качестве закрепленного ключа маршрутизации, а не извлекает его из хеширования сообщений. Это особенно полезно для многооборотных агентских рабочих процессов, где открывающие сообщения могут меняться между запросами, но вы все равно хотите направить их к тому же поставщику.
Вы можете предоставить session_id двумя способами:
- Тело запроса: Включить
session_idв качестве поля верхнего уровня в теле вашего запроса. Если указаны оба значения, значение body имеет приоритет. - Заголовок: установите
x-session-idHTTP-заголовок.
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. Они используют это значение только для группировки, поэтому к ним не применяется липкая маршрутизация.
x-session-id в мультимодальном рабочем процессе, чтобы сгруппировать все эти поколения в одном сеансе. Например, агент расшифровывает аудио, вызывает модель чата, а затем генерирует изображение.
Пакетный API пока не группирует свои поколения по
session_id.Проверка использования кэша
Чтобы узнать, сколько кэша сэкономлено при каждом поколении, вы можете:- Нажмите кнопку подробностей на вкладке Активность страница
- Используйте
/v1/generationAPI, описано здесь - Проверьте
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-кратная стоимость исходной входной цены.
Явное кэширование подсказок
Кэширование изменений цен:- Запись в кэш: взимается в 1,25 раза больше исходной цены ввода (такая же ставка, как и при автоматической записи в кэш в GPT-5.6 и более поздних версиях).
- Чтение кэша: взимается плата по сниженной скорости чтения кэша модели, так же, как и при автоматическом кэшировании.
Явное кэширование подсказок OpenAI поддерживается только OpenAI GPT-5.6 и новее.
prompt_cache_breakpoint: размещается в отдельном блоке текстового контента (input_textв ответах,textв завершениях чата), чтобы отметить конец многоразового префикса. Все, что проходит через этот блок, становится префиксом-кандидатом в кэше. Автоматическое кэширование остается включенным.prompt_cache_options: размещается в корне запроса. Настройкаmodeчтобы"explicit"отключает точки останова, управляемые OpenAI, поэтому только блоки, отмеченные значкомprompt_cache_breakpointучаствовать в кэшировании. Использованиеttlдля запроса продолжительности кэширования (например,"30m").
Токены уровня блока взаимозаменяемы: текстовый блок, отмеченный стиле 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 от исходной цены ввода.
Лунный ИИ
Кэширование изменений цен:- Запись в кэш: бесплатно
- Чтение кэша: взимается плата в размере x от исходной цены ввода.
Грок
Кэширование изменений цен:- Запись в кэш: бесплатно
- Чтение кэша: взимается плата в размере x от исходной цены ввода.
Алибаба Квен
Кэширование изменений цен при явном кешировании:- Запись в кэш: взимается плата в размере x от стоимости первоначальная цена входных данных
- Чтение кэша: взимается плата в размере x от стоимости первоначальная цена входных данных
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 от исходной цены ввода.
- Автоматическое кеширование: добавьте один Поле
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."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" }
Кэширование в пакетном API
cache_control точки останова работают на Anthropic :batch эндпоинты так же, как и в API синхронизации, но запросы внутри одного пакета могут обрабатываться одновременно и в любом порядке — кеш, записанный одной строкой, не гарантированно будет виден другим строкам в том же пакете. Чтобы получить надежные попадания в кеш, используйте "ttl": "1h" устанавливает точки останова на общем префиксе и повторно использует этот префикс в последующих пакетах (или сначала нагревает кэш с помощью запроса на синхронизацию): первый пакет платит цену записи в кэш, а последующие пакеты считывают из кэша до тех пор, пока он остается теплым.
Примеры
Автоматическое кэширование (рекомендуется для многоходовых разговоров)
При автоматическом кэшировании добавьтеcache_control на верхнем уровне запроса. Система автоматически кэширует весь контент до последнего кешируемого блока:
Явные точки останова в кэше (детальный контроль)
Пример кэширования системных сообщений (TTL по умолчанию — 5 минут):DeepSeek
Кэширование изменений цен:- Запись в кэш: взимается та же цена, что и исходная цена ввода.
- Чтение кэша: взимается плата в размере x от исходной цены ввода.
З.АИ
Кэширование изменений цен:- Запись в кэш: бесплатно (в настоящее время Z.AI указывает кэшированное хранилище входных данных как бесплатное ограниченное время)
- Чтение кэша: взимается плата по сниженной цене ввода в кэш, указанной на каждой странице модели (обычно примерно в 0,2 раза превышает первоначальную цену ввода).
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 от исходной стоимости входных токенов.
Изменения цен на кэшированные запросы:
- Запись в кэш: взимается по стоимости входного токена плюс 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) или обширные текстовые источники).
У Близнецов есть сингл поле
systemInstruction и кэшированное содержимое Gemini.
относится к этому systemInstruction как неизменяемый. В LLMSTORE это означает
cache_control внутри первого system или Сообщения developer можно кэшировать
нормализованное системное приглашение, но оно не может сохранить некэшированный динамический хвост
внутри того же сообщения. Если вам нужна часть приглашения, чтобы оставаться динамичной,
перенесите этот динамический контент на более поздний срок. сообщение user вместо его добавления
после кэшированного блока в первом system сообщение.Примеры:
Пример кэширования системных сообщений
user скорее сообщение
, чем как некэшированный конечный контент в первом system сообщение.