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

Prompt caching повторно використовує обчислення для однакового початку запиту: системних інструкцій, tool schemas, few-shot прикладів або великого спільного контексту. Це не semantic cache готових відповідей. Модель усе одно генерує новий результат для змінної частини, тому кеш не повинен підміняти перевірку якості, актуальності чи дозволів.

Корисний дизайн має три зони: довгоживучий спільний префікс, версіонований контекст команди або tenant і динамічний хвіст із запитом користувача та свіжими даними. Стабільне розміщують раніше, змінне — пізніше. Будь-який timestamp, випадковий ID, нестабільний порядок JSON-полів або персональні дані на початку можуть розбити збіг і перетворити очікувану економію на постійні cache writes.

• Кешуйте лише повторюваний префікс, достатньо великий для правил конкретної моделі.
• Версіонуйте інструкції, tools, schema і corpus замість прихованої мутації.
• Вимірюйте read, write, miss, uncached input, latency та якість окремо.
• Не змішуйте tenants або рівні доступу заради вищого hit rate.
• Перевіряйте чинні model, region, retention і pricing rules перед rollout.

OpenAI документує автоматичне кешування придатних точних префіксів і телеметрію cached tokens; у новіших моделях також доступні cache key, точки кешування та керування режимом. 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. Серіалізація має бути байтово стабільною в межах provider contract. Навіть семантично тотожний JSON з іншим порядком полів може не збігтися як точний префікс.

Cache identity формуйте з provider, model family, prompt version, tool-schema version, policy version, locale, tenant або access scope і corpus revision. Не кладіть секретний текст у логи чи cache key: використовуйте непрозорий digest із контрольованих ідентифікаторів. Зміна моделі, дозволів, системної політики або джерела, яке має бути негайно відкликане, створює нову версію; старий кеш перестає отримувати трафік і природно спливає або видаляється через доступний API.

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

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

Cache reuse не дає права послаблювати authorization. Спільний префікс може містити лише дані, дозволені всім запитам у його scope. Tenant-specific документи, персональні дані та результати tools із різними ACL потребують окремої identity або мають залишатися після безпечної межі. Cache key є підказкою маршрутизації чи ідентифікатором ресурсу, а не механізмом доступу; сервер усе одно повинен авторизувати запит і формувати дозволений контекст.

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

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 і низькоризиковий workload; quality eval підтверджує, що перестановка блоків не змінила instruction precedence, tool behavior або groundedness.

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