Prompt caching в OpenAI, Anthropic и Gemini: архитектура и выбор

Prompt caching повторно использует вычисления для одинакового начала запроса: системных инструкций, tool schemas, few-shot примеров или большого общего контекста. Это не semantic cache готовых ответов. Модель всё равно генерирует новый результат для переменной части, поэтому кеш не должен подменять проверку качества, актуальности или прав доступа.

Полезный дизайн имеет три зоны: долговечный общий префикс, версионированный контекст команды или tenant и динамический хвост с запросом пользователя и свежими данными. Стабильное размещают раньше, переменное — позже. Timestamp, случайный ID, нестабильный порядок полей JSON или персональные данные в начале могут разрушить match и превратить ожидаемую экономию в постоянные cache writes.

• Кешируйте только повторяемый префикс, достаточно большой для правил выбранной модели.
• Версионируйте инструкции, tools, schemas и ревизии corpus вместо скрытой мутации.
• Измеряйте reads, writes, misses, uncached input, latency и качество отдельно.
• Не смешивайте tenants или уровни доступа ради более высокого hit rate.
• Проверяйте актуальные model, region, retention и pricing rules до rollout.

OpenAI документирует автоматическое кеширование подходящих точных префиксов и телеметрию cached tokens; в новых моделях также доступны cache keys, точки кеширования и управление режимом. Anthropic поддерживает top-level automatic caching и явные cache breakpoints через cache_control, возвращая отдельные cache-creation и cache-read tokens. Gemini предлагает implicit caching, а в совместимом Generate Content API — explicit cached content с управляемым TTL; доступность зависит от API и модели.

Не скрывайте эту разницу за флагом cache=true. Provider adapter должен описывать capabilities: implicit или explicit, минимальный префикс, допустимые breakpoints, TTL, write/read billing, telemetry, region и data-retention constraints. Если capability неизвестна, система выполняет обычный запрос и отмечает cache status как unsupported или unknown, а не придумывает hit.

Собирайте запрос детерминированно: неизменные policy и system instructions, стабильно отсортированные tool definitions, schema, проверенные примеры, затем общие документы и только после них user-specific input. Сериализация должна быть byte-stable в рамках provider contract. Даже семантически идентичный JSON с другим порядком полей может не совпасть как точный префикс.

Cache identity формируйте из provider, model family, prompt version, tool-schema version, policy version, locale, tenant или access scope и corpus revision. Не помещайте секретный текст в logs или cache key; используйте непрозрачный digest контролируемых идентификаторов. Изменение модели, прав, system policy или источника, который нужно немедленно отозвать, создаёт новую версию; старый кеш перестаёт получать трафик и естественно истекает или удаляется через доступный API.

Считайте один логический cohort: cache-write tokens и storage, cache-read tokens, uncached input, output, число повторов, time to first token и cost per successful task. Break-even зависит от тарифов конкретной модели, TTL и фактического числа повторных обращений. Не переносите процент скидки одного provider или модели на другой контракт и не считайте hit гарантированным только из-за одинакового текста.

Низкий hit rate часто означает не слабость сервиса, а неправильную форму workload: короткие prompts, редкие повторы, раздробленные cache keys, частые изменения в начале или параллельный burst до завершения первого write. Сравнивайте контролируемые варианты на одинаковом traffic slice. Если canonicalization усложняет систему, увеличивает write spend или задерживает отзыв данных сильнее, чем экономит, обычный uncached request — лучшее решение.

Cache reuse не даёт права ослаблять authorization. Общий префикс может содержать только данные, разрешённые всем запросам в его scope. Tenant-specific документы, персональные данные и результаты tools с разными ACL требуют отдельной identity или должны оставаться после безопасной границы. Cache key — это подсказка routing или идентификатор ресурса, а не механизм доступа; сервер всё равно должен авторизовать запрос и формировать разрешённый контекст.

Явный кеш может создавать persistent application state на время TTL. Проверьте data residency, zero-data-retention compatibility, encryption, deletion и incident response в актуальной документации и договоре. Для legal hold или срочного revocation нужен документированный путь: остановить новые reads, изменить version или scope, удалить cache object там, где это поддерживается, и проверить, что последующие traces не используют retired revision.

Trace должен сохранять provider, model, cache mode, безопасный fingerprint префикса, version, breakpoint, requested TTL, read/write/uncached token counts, latency, outcome и miss reason без сырого приватного prompt. Нормализуйте provider fields в общие категории, но сохраняйте original usage payload в защищённом audit layer для проверки billing semantics.

Dashboard показывает eligible requests, hit rate среди eligible, cached-token share, write amplification, cost per accepted outcome и latency для hit/miss. Alert нужен при резком падении после deploy, неожиданном cross-scope fingerprint, writes без последующих reads или использовании retired version. Hit rate сам по себе не KPI качества: неизменный, но ошибочный system prompt тоже отлично кешируется.

Сначала измерьте повторяемость префиксов без изменения поведения. Затем включите canonical rendering и сравните exact fingerprints, исключив чувствительные cohorts. Canary должен охватить один provider/model и low-risk workload; quality eval подтверждает, что перестановка блоков не изменила instruction precedence, tool behavior или groundedness.

Release gate требует нулевых cross-tenant defects, корректной usage attribution, приемлемой write amplification и non-regression task quality. Rollback отключает явные breakpoints или ссылки на cache resources, возвращает предыдущий renderer и переводит трафик на обычные запросы. Старые cache objects не считаются удалёнными без provider evidence; их expiry или deletion отслеживается отдельно от application rollback.