Как разработать подсказки LLM с поддержкой кэша для OpenAI, Anthropic и Gemini

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

Практическое решение — сделать кэширование запросов частью компилятора запросов шлюза. Шлюз должен отделять стабильный материал запроса от нестабильного материала запроса, компилировать инструкции кэширования для конкретного поставщика и измерять стоимость и задержку с помощью кэшируемого префикса. Это особенно важно в среде с несколькими моделями, где OpenAI, Anthropic и Gemini предоставляют различное поведение кэширования, поля учета, TTL и затраты на установку.

Начинайте с кэшируемой единицы, а не поставщика

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

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

Факт: реализации поставщиков различаются. OpenAI документов требуют кэширования при повторном использовании общего префикса с учетом кэшированных токенов. В его общедоступной статье о кэшировании подсказок говорится, что автоматическое кэширование начинается с префикса в 1024 токена и увеличивается с шагом в 128 токенов, и что записи кэша обычно очищаются после 5–10 минут бездействия и в течение одного часа после последнего использования. Anthropic документирует явные точки останова в кэше и рекомендует размещать cache_control в последнем общем блоке, например, в системных подсказках или определениях инструментов. Gemini документирует кэширование контекста как платную функцию, при этом количество кэшированных токенов возвращается в метаданных об использовании для операций кэширования и вызовов генерации, использующих кэш.

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

Компилируйте запросы от наиболее стабильных к наиболее Volatile

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

1. Политика безопасности и соответствия требованиям платформы.
2. Политика организации или клиента.
3. Роль приложения и инструкции по задачам.
4. Схемы инструментов и правила использования инструментов.
5. Статические знания или долгосрочные ссылки материал.
6. История разговоров, которая повторно используется в разных ходах.
7. Извлеченные отрывки или другой контекст, специфичный для запроса.
8. Текущая задача пользователя.
9. Эфемерные метаданные, необходимые только для этого вызова.

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

Пример внутренних блоков подсказок

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

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

Использовать адаптеры поставщика вместо одного предположения о кэше

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

OpenAI Адаптер

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

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

Anthropic Адаптер

Для Anthropic скомпилируйте явные точки останова в кэше. Разместите cache_control в последнем блоке, который должен быть доступен для последующих запросов. Хорошими кандидатами являются большие системные инструкции, определения инструментов или стабильный ссылочный контекст. Плохими кандидатами являются разовые сообщения пользователей, полезные данные текущих задач или фрагменты RAG для конкретных запросов.

Факт: Anthropic документирует продолжительность кэширования по умолчанию 5 минут и продолжительность кэширования 1 час, доступную за дополнительную плату. Это делает выбор TTL экономическим решением. Длинный кэш может иметь смысл для агентов интерактивного кодирования, многоэтапного просмотра документов или поддержки вторых пилотов с паузами между ходами. Это может быть расточительно для одноразовой задачи с небольшим повторением.

Gemini Адаптер

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

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

Измеряйте экономичность кэша, а не просто попадание Скорость

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

Сохраняйте эти поля для каждого запроса, когда поставщик предоставляет их или шлюз может их оценить:

• Поставщик и модель.
• Кенант, приложение, среда и идентификатор ключа API.
• Запрос версии шаблона и кэшируемого префикса hash.
• Политика TTL или продолжительность кэширования.
• Некэшированные входные токены.
• Кэшированные входные токены.
• Токены записи или создания кэша, если они доступны.
• Выходные токены.
• Время получения первого токена и общее количество latency.
• Версия цены по списку поставщиков, используемая для расчета затрат.
• Независимо от того, был ли запрос частью интерактивного сеанса, пакетного задания, цикла агента или однократного вызова.

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

Для начала достаточно простой модели рентабельности инвестиций:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

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

Добавьте правила Lint для взломщиков кэша

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

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

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

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

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

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

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

Осторожно обращайтесь с рабочими нагрузками RAG

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

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

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

Проверка поведения перед оптимизацией затрат

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

Используйте регрессионные тесты перед развертыванием макетов с поддержкой кэша. Как минимум проверьте:

• Приоритет инструкций для политики безопасности и соответствия требованиям.
• Выбор инструментов для известных задач.
• Достоверность структурированных выходных данных при использовании схем.
• Качество ответа на репрезентативных примерах RAG.
• Задержка и стоимость при повторении Turns.
• Учет использования для конкретного поставщика.

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

Выбирайте рабочие нагрузки выборочно

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

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

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

Контрольный список реализации

• Создайте внутреннюю модель блока подсказок с метками стабильности: глобальный, арендатор, приложение, рабочий процесс, сеанс и запрос.
• Рендеринг блоков детерминированно, включая порядок инструментов и свойства схемы. order.
• Переместить изменчивые поля из стабильного префикса.
• Вычислить хеш кэшируемого префикса после рендеринга.
• Добавьте адаптеры поставщика для повторного использования префикса OpenAI, точек останова кэша Anthropic и ресурсов кэша контекста Gemini.
• Запишите некэшированные входные токены, кэшированные входные токены, токены записи в кэш, если они доступны, выходные токены, задержка, модель, арендатор, приложение, хеш-префикс и срок жизни.
• Создавайте информационные панели для экономии чистых долларов, затрат на запись/настройку, частоты попаданий и задержки в зависимости от рабочей нагрузки.
• Добавьте правила проверки для временных меток, случайных идентификаторов, нестабильного размещения RAG, динамического порядка инструментов и персонализации в общих файлах. блоков.
• Выполняйте регрессионные тесты поведения подсказок перед изменением рабочей схемы.
• Сначала включите кеширование для часто повторяющихся рабочих нагрузок, а затем расширяйте его на основе измеренной рентабельности инвестиций.

Вывод

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

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

Чтение по теме

• Независимая от поставщика наблюдаемость LLM