Что такое prompt caching

Prompt caching переиспользует вычисления для повторяющейся части input, обычно system instructions, tool schemas, policy и большой стабильный prefix. Это отличается от semantic cache: semantic cache может вернуть готовый прошлый ответ на похожий запрос, а prompt cache ускоряет новый model inference.

Где он даёт максимальный эффект

Наибольшая выгода появляется, когда многие запросы имеют длинный одинаковый prefix: agent instructions, API schemas, product catalog context, policy documents или few-shot examples.

Делайте prefix стабильным

Кэш работает лучше, если неизменяемые блоки стоят в начале и сериализуются одинаково. Не вставляйте timestamp, random IDs и session-specific данные внутрь стабильной части.

Разделяйте static и dynamic context

Static: system policy, tool definitions, long reference docs. Dynamic: user message, retrieved chunks, current state и tool results. Чем чище граница, тем выше cache hit rate.

Versioning важнее TTL

Cache key должен учитывать версию prompt template, tool schema, model и критичных policies. Изменили контракт — меняйте version, даже если старый cache ещё не истёк.

Не кэшируйте секреты без контроля

Если провайдер или собственный gateway хранит cached prefixes, определите правила для PII, credentials и tenant isolation. Один tenant не должен получить вычислительный контекст другого.

Считайте реальную экономию

Логируйте cached input tokens, uncached input tokens, hit rate, latency p50/p95 и стоимость на request. Высокий hit rate сам по себе бесполезен, если prefix маленький.

Ошибки invalidation

Опасный сценарий — обновить policy или tool schema, но продолжить использовать старую cache version. Добавляйте cache version в deployment artifact и проверяйте её в tracing.

Prompt cache и RAG

Не пытайтесь кэшировать динамические retrieved chunks как вечный prefix. Для RAG лучше кэшировать стабильные instructions и schemas, а retrieval оставлять dynamic и versioned по индексу.

Evals

Сравнивайте cached и uncached execution на одинаковом наборе тестов. Ответы должны сохранять качество, а tracing — показывать корректную версию prefix.

Production checklist

  • Выделите стабильный prefix.

  • Уберите volatile fields из начала prompt.

  • Версионируйте templates и tool schemas.

  • Разделите tenants и sensitive data.

  • Настройте TTL как дополнительный механизм, а не замену versioning.

  • Логируйте hit rate, cached tokens, cost и latency.

  • Проверяйте invalidation при каждом deploy.

  • Запустите evals cached vs uncached.

Вывод

Prompt caching полезен там, где LLM постоянно получает большой повторяющийся prefix. Правильная архитектура строится вокруг стабильного ordering, versioned cache keys, безопасной изоляции и измеримой экономии, а не вокруг попытки кэшировать всё подряд.