Лучшие практики

Prompt Caching

Prompt Caching — это мощная техника, которая повторно использует кэшированные префиксы промптов между API-вызовами, снижая как задержку, так и стоимость. Поддерживается Claude, GPT-4o и Gemini.

Как это работает

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

ПоказательБез кэшаПри попадании в кэш
Время до первого токенаБазовый уровеньДо 80% быстрее
Стоимость токенов промптаПолная ценаНа 50–90% дешевле

Кэширование включено по умолчанию для всех поддерживаемых моделей — настройка не требуется. Провайдер автоматически управляет жизненным циклом кэша (кэш обычно сохраняется 5–30 минут, в зависимости от провайдера и нагрузки).

Дизайн промптов, оптимизированный для кэширования

Кэш сопоставляет по префиксу — токенам с начала массива сообщений. Проектируйте промпты так, чтобы всё статическое находилось в начале:

python
# ✅ GOOD: Static content first = high cache hit rate
messages = [
    {"role": "system", "content": "You are a legal assistant. Reference case law when answering..."},
    {"role": "user", "content": "What are the elements of negligence?"},
]

# ❌ BAD: Dynamic prefix kills cache
messages = [
    {"role": "user", "content": "What are the elements of negligence?"},  # Cache miss
    {"role": "system", "content": "You are a legal assistant..."},  # Too late
]

Чек-лист по дизайну

  • Системное сообщение первым — всегда размещайте его как первый элемент в messages
  • Статический контекст перед динамическими запросами — Few-shot примеры, извлечённый RAG-контекст, определения инструментов идут перед текущим вопросом пользователя
  • Никаких временных меток / ID в префиксах — не добавляйте уникальные данные запроса перед кэшируемым содержимым
  • Сохраняйте системные промпты идентичными — весь префикс должен совпадать побайтово для попадания в кэш
  • Чем длиннее префикс, тем больше экономия — Кэширование системного промпта на 10K токенов экономит значительно больше, чем на 200 токенов

Мониторинг попаданий в кэш

Объект usage в ответе показывает, попал ли ваш промпт в кэш:

  • Claude (Anthropic): Ищите cache_read_input_tokens и cache_creation_input_tokens
  • GPT-4o (OpenAI): Кэшированные токены отражаются в уменьшенном биллинге prompt_tokens
  • Gemini (Google): Контекстное кэширование отображается в метаданных использования
python
import requests

response = requests.post(
    "https://api.tokspan.com/v1/chat/completions",
    headers={"Authorization": "Bearer sk-your-key"},
    json={"model": "claude-opus-4-8", "messages": [...]},
)

# Check for cache hits in the usage object
usage = response.json()["usage"]
if "cache_read_input_tokens" in usage:
    print(f"Cache hit! {usage['cache_read_input_tokens']} tokens served from cache")
    print(f"Cache creation: {usage.get('cache_creation_input_tokens', 0)} tokens written")
else:
    print("Cache miss — all prompt tokens billed at full price")

Поддерживаемые модели

МодельПровайдерМин. кэшируемых токеновTTL кэша (типичный)
Claude Opus 4.8Anthropic1024~5 мин
Claude Sonnet 4.6Anthropic1024~5 мин
GPT-4oOpenAI1024~5–10 мин
Gemini 2.5 ProGoogle32768Настраивается (context cache API)
Минимальные пороги токенов: Каждый провайдер кэширует промпты только выше минимального количества токенов (обычно 1024 токена для Claude и GPT-4o). Короткие промпты не получат преимуществ. Это делает кэширование наиболее эффективным для приложений с большими системными промптами, RAG-пайплайнами или многоходовыми диалогами с длинной историей.