Что такое prompt caching у провайдеров (Anthropic, Google) и как его использовать?

Краткий тезис

Prompt caching — это техника, при которой API провайдера сохраняет KV-кэш (Key-Value cache) для повторяющихся частей промпта (например, системного сообщения или длинного контекста). При повторном запросе с тем же префиксом кэш переиспользуется, что резко снижает latency (задержку) и cost (стоимость). Anthropic обещает до 90% экономии для shared префиксов, Google предлагает аналогичный механизм через Context Caching. Использование требует структурирования промпта: статическая часть (системный промпт, few-shot примеры) отделяется от динамической (вопрос пользователя), и для статической части явно запрашивается кэширование.

1. Термин: Prompt Caching

Prompt caching — это механизм, при котором провайдер LLM (Large Language Model) сохраняет промежуточные вычисления (KV-кэш) для части входного промпта, которая повторяется между запросами. Когда приходит новый запрос с таким же префиксом, сервер не пересчитывает attention для этой части, а использует сохранённый кэш.

Аналогия: как кэш процессора (CPU cache) ускоряет доступ к часто используемым данным, так и prompt caching ускоряет обработку повторяющихся фрагментов промпта.

2. Как работает KV-кэш в LLM (основы)

В трансформерах (Transformer) на этапе генерации каждый токен вычисляется через self-attention. Для каждого предыдущего токена модель хранит пары Key и Value — это и есть KV-кэш. Без кэширования при генерации каждого нового токена пришлось бы заново вычислять attention по всей последовательности, что даёт квадратичную сложность O(n²). С кэшем сложность снижается до O(n) на токен.

Prompt caching расширяет эту идею: если несколько запросов начинаются с одного и того же префикса (например, системный промпт), можно сохранить KV-кэш для этого префикса и переиспользовать его во всех последующих запросах. Провайдеры (Anthropic, Google) реализуют это на своей стороне, предоставляя API для управления кэшем.

3. Prompt caching у провайдеров: общая идея

Оба провайдера позволяют явно указать, какую часть промпта нужно кэшировать. Обычно это делается через параметры в API (например, cache_control у Anthropic). Кэш живёт определённое время (TTL — Time To Live) и инвалидируется при изменении префикса.

Преимущества

• Снижение latency: до 2–10 раз быстрее для запросов с кэшированным префиксом.
• Снижение cost: провайдеры взимают меньшую плату за токены, прочитанные из кэша (Anthropic: до 90% дешевле для кэшированных токенов).
• Увеличение пропускной способности: меньше вычислений на сервере.

4. Anthropic: API и пример использования

Anthropic (модели Claude) поддерживает prompt caching через параметр cache_control в сообщениях. Кэшировать можно системный промпт, первые сообщения в диалоге или длинные контексты.

Пример запроса (Python с библиотекой anthropic):

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Ты — эксперт по RAG. Отвечай кратко и по делу.",
            "cache_control": {"type": "ephemeral"}  # кэшируем системный промпт
        }
    ],
    messages=[
        {"role": "user", "content": "Что такое prompt caching?"}
    ]
)

Ключевые моменты

• cache_control указывается только для статической части (системный промпт или первые сообщения).
• Тип ephemeral означает, что кэш живёт ограниченное время (обычно 5 минут, но может меняться).
• Anthropic возвращает в ответе информацию о том, сколько токенов было прочитано из кэша (cache_read_input_tokens).

Экономия Anthropic заявляет до 90% снижения стоимости для кэшированных токенов. Например, если системный промпт содержит 1000 токенов, а вы делаете 1000 запросов, то без кэша вы платите за 1 млн токенов ввода, а с кэшем — за 1000 токенов (первый запрос) + 999 * (стоимость чтения из кэша, значительно ниже).

5. Google (Gemini): Context Caching

Google предлагает аналогичную функциональность под названием Context Caching (или cached content). Она доступна для моделей Gemini (например, gemini-1.5-pro). Кэш создаётся через отдельный API или указывается в запросе.

Пример (Python с google-generativeai):

import google.generativeai as genai

genai.configure(api_key="YOUR_API_KEY")

# Создаём кэш для системного промпта
cache = genai.caching.CachedContent.create(
    model='models/gemini-1.5-pro',
    display_name='system_prompt_cache',
    system_instruction="Ты — помощник по программированию.",
    ttl="300s"  # время жизни кэша
)

# Используем кэш в запросе
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("Напиши код на Python для сортировки.")

Отличия от Anthropic

• Кэш создаётся явно как отдельный ресурс (CachedContent), а не через параметр в сообщении.
• Можно задать TTL в секундах (до нескольких дней).
• Google также снижает стоимость: плата за хранение кэша + сниженная цена за токены при использовании.

6. Сравнение Anthropic vs Google

7. Когда использовать prompt caching

• Системные промпты: если вы используете один и тот же системный промпт для всех запросов (например, «Ты — эксперт по RAG»).
• Few-shot примеры: если вы передаёте несколько примеров в начале каждого запроса.
• Длинные контексты: при работе с большими документами (например, кодовая база, юридические документы), которые повторяются во многих запросах.
• Чат-боты с длинной историей: можно кэшировать первые N сообщений диалога, а добавлять только последние.
• Agentic RAG: когда агент делает несколько вызовов LLM с одинаковым контекстом (например, системный промпт + инструкции).

8. Best practices

1. Структурируйте промпт: разделите на статическую (кэшируемую) и динамическую части. Статическую помещайте в начало.
2. Используйте cache_control только для действительно повторяющихся частей. Не кэшируйте уникальные запросы — это не даст выгоды.
3. Управляйте TTL: если контекст редко меняется, можно установить большой TTL (Google). Для часто меняющегося — маленький.
4. Мониторьте использование кэша: проверяйте метрики (cache_read_input_tokens у Anthropic), чтобы убедиться, что кэш действительно применяется.
5. Комбинируйте с другими оптимизациями: например, с prompt compression (сжатие промпта) для ещё большего снижения затрат.
6. Тестируйте latency: измеряйте время ответа с кэшем и без, чтобы оценить реальный выигрыш.

9. Ограничения и подводные камни

• Размер кэша: провайдеры могут ограничивать максимальный размер кэшируемого контента (например, Anthropic — до 200K токенов для Claude 3.5 Sonnet).
• Инвалидация: если вы измените кэшированную часть, старый кэш станет недействительным. Нужно явно создать новый кэш (Google) или просто изменить промпт (Anthropic автоматически пересоздаст).
• Стоимость хранения: у Google есть плата за хранение кэша (per token per hour). У Anthropic — только за запись в кэш (первый запрос) и чтение.
• Не все модели поддерживают: проверяйте документацию (например, Claude 3 Haiku не поддерживает кэширование).
• Безопасность: кэш может быть разделён между разными пользователями? Обычно нет — кэш привязан к API-ключу или сессии.

10. Альтернативы prompt caching

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

• Локальный KV-кэш: сохранять KV-кэш на своей стороне (возможно только при локальном развёртывании модели, например, с vLLM).
• Prompt compression: сжимать промпт (например, через LLMLingua) перед отправкой.
• Batching: группировать запросы с одинаковым префиксом (некоторые провайдеры автоматически кэшируют внутри батча).
• Сокращение контекста: удалять нерелевантные части перед отправкой.

Пет-проект для закрепления

Задача: Реализовать чат-бота с системным промптом, использующего prompt caching для снижения затрат.

Инструменты: Python, Anthropic API (или Google Gemini API), библиотека anthropic (или google-generativeai).

Шаги:

1. Создайте системный промпт объёмом ~500 токенов (например, инструкции для поддержки клиентов).
2. Напишите функцию, которая отправляет запрос с cache_control для системного промпта.
3. Сделайте 10 запросов с разными вопросами пользователя. Замерьте время ответа и количество кэшированных токенов (из ответа API).
4. Сравните с запросами без кэширования (уберите cache_control).
5. Посчитайте экономию в токенах и стоимости (используйте цены из документации Anthropic).

Ожидаемый результат: Вы увидите, что latency снизилось в 2-5 раз, а количество входных токенов (оплачиваемых) уменьшилось примерно на размер системного промпта для каждого запроса после первого.

Связь с другими вопросами

Навигация

• Предыдущий: 218
• Следующий: 220
• Индекс: 00. Индекс разборов