Кешування промптів LLM може зробити преміальний API дешевшим за недостатньо завантажений локальний GPU для повторюваного контексту. Але воно також може взагалі не дати економії. Визначальними змінними є не прайс-листи моделей. Це повторне використання префікса, вартість запису в кеш, знижки на читання, термін дії, витіснення, завантаженість і вартість невдалої роботи.
Аудиторія: досвідчені практики, відповідальні за вартість, затримку або інфраструктурні рішення платформи LLM.
Практичне правило: виміряйте читання з кешу та інвалідацію на реальному робочому навантаженні, перш ніж купувати GPU-потужності. Нове тематичне дослідження enterprise coding-agent підкріплює цю думку вражаючим результатом із показником cache-hit 99,3%, але його автори досліджували одного розробника, два послідовні 28-денні періоди, різні сімейства моделей і одну production codebase. Сприймайте цю роботу як стимул до вимірювань, а не як остаточний висновок щодо хмари та локальної інфраструктури.
Що змінює кешування промптів LLM
LLM обробляє вхідні дані у дві широкі фази:
На рівні serving prefix caching може зберігати повторно використовувані стани attention або key-value для префікса промпту. Наступний запит із тим самим допустимим префіксом може пропустити частину повторної роботи prefill. Змінний суфікс усе одно потрібно обробити, а модель усе одно декодує нову відповідь.
Ця відмінність важлива. Кешування промптів — це не кешування відповідей. Воно не повертає збережену відповідь, не скорочує вихід, не виправляє слабкий промпт і не гарантує нижчу наскрізну затримку. Воно переважно спрямоване на повторювані обчислення вхідних даних і часто покращує time to first token.
Оригінальна стаття про Prompt Cache формалізувала повторно використовувані модулі промптів і повідомила про покращення prototype time-to-first-token від 8× на GPU до 60× на CPU. Це результати для моделей, обладнання, промптів та реалізації, протестованих у статті, а не прогноз для сучасних комерційних API.
Тематичне дослідження з показником 99,3%: корисні докази з вузькими межами
У препринті від липня 2026 року *Inference Economics of Enterprise Coding Agents* порівнювали два послідовні 28-денні періоди в одному production monorepo:
Автори проаналізували телеметрію LLM та історію Git. Вони повідомили про 99,3% prompt-cache hit rate для періоду API, ефективну вартість API $0,573 за мільйон оброблених токенів і амортизовану собівартість одиниці $2,83 для спільно використовуваного on-premise-розподілу. API обробив у 16,9 раза більше токенів, тоді як локальне обладнання мало низьку завантаженість, тому ці нормалізовані ціни за токен не дають остаточної відповіді на інфраструктурне питання.
Результати загальної вартості вказують у різні боки залежно від розподілу. За припущеннями авторів щодо тайванського ринку та праці, спільно використовувані локальні потужності зменшили оцінену сукупну вартість володіння на 40,1%. Резервування виділених локальних потужностей коштувало на 43,8% дорожче за API з кешуванням. Локальний період також був пов’язаний із вищим співвідношенням fix-комітів: 74,9% проти 45,9%.
Що вимірювали автори
Що вони вивели
Чого дослідження не може встановити
Дизайн був нерандомізованим і послідовним. Кодова база, розробник, набір завдань і робочі практики могли змінитися між періодами. Можливості моделі, serving stack, harness і квантизація змінювалися одночасно. Перший автор знав гіпотезу. Мітка fix-коміту є proxy-показником, а не незалежним аудитом дефектів. Не було опубліковано необроблену production-телеметрію та повне середовище відтворення.
Стійкіший висновок вужчий за заголовкові цифри: повторне використання промптів і завантаженість GPU можуть домінувати над порівняннями прайс-листів, тоді як робота з виправленнями може домінувати над економією токенів.
Визначте контракт вимірювань до розрахунку hit rate
«Cache hit rate» неоднозначний, якщо явно не визначити знаменник. Одна dashboard може ділити кешовані токени на токени допустимого префікса. Інша — ділити запити з будь-яким читанням із кешу на всі запити. Третя може показувати кешовані токени як частку всього input, включно з некешованим суфіксом.
Використовуйте окремі метрики:
Зберігайте поля використання, надані провайдером, окремо від метрик, які ви виводите самостійно. Кількість токенів також може змінюватися залежно від токенізаторів і шаблонів моделей; пояснення token tax для LLM→ показує, чому кількість необроблених символів є слабкою заміною.
Поточна поведінка API та self-hosted-рішень не є однаковою
Наведений нижче огляд перевірено 30 липня 2026 року. Перевірте пов’язану документацію ще раз, перш ніж використовувати її для закупівель або білінгу.
| Платформа | Керування кешем | Спостережуваний сигнал | Операційне обмеження |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 підтримує implicit та explicit prompt caching | `cached_tokens` і `cache_write_tokens` | Поточні рекомендації для GPT-5.6 оцінюють explicit writes у 1,25× від uncached input; reads мають знижку |
| Anthropic API | Automatic caching або явні block breakpoints | Окреме використання для створення та читання кешу | Порядок префікса: tools, system, потім messages; стандартний TTL — 5 хвилин, доступний платний варіант на 1 годину |
| Gemini Interactions API | Implicit context caching увімкнено за замовчуванням для Gemini 2.5 і новіших моделей | `usage.total_cached_tokens` | Спільний контент має бути на початку; поточні мінімуми становлять від 2 048 до 4 096 токенів залежно від моделі |
| vLLM | Automatic Prefix Caching можна ввімкнути в engine | Метрики engine і час виконання запитів | Ваша команда відповідає за потужність, eviction, ізоляцію, оновлення та observability |
Поточні рекомендації OpenAI щодо моделей радять користувачам GPT-5.6 відстежувати записи й читання з кешу, оскільки explicit writes коштують дорожче за uncached input. Документація Anthropic щодо prompt caching описує 5-хвилинні записи за ціною 1,25× від базового input, 1-годинні записи за ціною 2× і читання з кешу за ціною 0,1×. Посібник Google із context caching зазначає, що implicit caching є автоматичним у його Interactions API, а кешовані токени відображаються у usage. Приклад Automatic Prefix Caching у vLLM демонструє ту саму ідею спільного префікса в self-hosted engine.
Ці реалізації мають спільний принцип, але не універсальний billing contract. Мінімальна довжина префікса, область кешу, зберігання, плата за storage, поля usage та ізоляція можуть відрізнятися.
*Виміряйте кеш, перш ніж змінювати інфраструктуру: стабілізуйте префікс, виконайте cold і warm тести, примусово перевірте інвалідацію, а потім порівняйте загальну вартість.*
Формула беззбитковості для повторно використовуваного префікса
Нехай:
Ігноруючи плату за storage, середня плата за повторно використовуваний префікс на один запит становить:
`(W + (N - 1) × R) / N`
Кешування дешевше за обробку цього префікса без кешу, коли:
`N > (W - R) / (U - R)`
Це рівняння ізолює повторно використовуваний префікс. Воно не враховує змінний суфікс, вихідні токени, мінімальну кешовану довжину, storage fees, промахи через eviction, ефекти concurrency, інженерну працю та невдалі завдання.
Для однієї датованої ілюстрації мультиплікатори Anthropic для 5-хвилинного кешу станом на 30 липня 2026 року були такими: `U = 1`, `W = 1.25` і `R = 0.1`. Поріг лише для input становить `N > 1.28`, тому друге використання протягом часу життя кешу амортизує вищу плату за запис для цього допустимого префікса. Це не означає, що два загальні виклики API роблять кешування прибутковим. Короткий префікс, довгий некешований суфікс, промах кешу або дорогий output можуть нівелювати економію.
Використовуйте рівняння як unit test для вашої моделі вартості. Замініть кожну змінну значеннями з поточного контракту провайдера та виміряного робочого навантаження.
Чому, здавалося б, стабільні промпти не потрапляють у кеш
Більшість промахів починається у формуванні промпту, а не в моделі.
Мінливі дані з’являються надто рано
Timestamp, request ID, випадковий nonce, ім’я користувача або свіжий результат retrieval на початку змінює кожен наступний токен. Розміщуйте стабільні tools, policies, templates і повторно використовувані документи першими. Перемістіть специфічні для запиту дані після повторно використовуваного префікса або явної breakpoint.
Серіалізація змінюється між запитами
Порядок ключів JSON, пробіли, порядок tools і порядок документів можуть змінити інакше еквівалентний префікс. Використовуйте детерміновану серіалізацію. Сортуйте визначення tools і retrieved documents за стабільними ідентифікаторами, якщо це допускає семантика.
Context manager руйнує безперервність префікса
Агресивне pruning може заощадити input tokens, водночас інвалідувавши кешовані префікси. TokenPilot, препринт у процесі роботи від червня 2026 року, розглядає це як спільну задачу оптимізації. Його автори стабілізують ingestion і відкладають eviction, доки контекст не втратить цінність для завдання. Вони повідомляють про зниження вартості на 56–87% у двох benchmark і двох режимах виконання, зберігаючи конкурентну якість завдань. Ці результати потребують відтворення за межами робочих навантажень статті та інтеграції LightMem2.
Кеш завершує дію або витісняється під реальним навантаженням
Теплий локальний тест може приховати межі TTL і тиск на capacity. Self-hosted prefix caching має ту саму реальність обмеженої пам’яті, що й інші системи KV-cache. Докладніший посібник із KV-cache eviction→ пояснює, чому повторне використання може зникнути зі зростанням concurrency та довжини послідовностей.
Модель або template змінюється
Версія моделі, tokenizer, chat template, налаштування image detail, схема tools або safety preamble можуть створити новий префікс. Розглядайте релізи та міграції промптів як події інвалідації кешу.
Поточні інженерні обговорення у vLLM демонструють цей тиск. Пропозиція context-aware retention стверджує, що одночасні agent workloads можуть витісняти цінні префікси, тоді як пропозиція semantic KV-cache досліджує повторне використання за межами точних збігів. Це відкриті design discussions, а не production guarantees або вимірювання adoption.
Відтворюваний тест prompt-cache
Використовуйте той самий набір завдань, який ви застосували б, щоб порівняти AI-моделі для реальної роботи→. Тест кешу додає контрольовані зміни префікса та облік інфраструктури.
1. Зафіксуйте репрезентативне робоче навантаження
Виберіть від 30 до 100 завдань із production traffic або privacy-safe replay set. Збережіть реальний розподіл довжини префікса, довжини суфікса, довжини output, tools, документів і concurrency. Визначте успішність завдання до запуску тесту.
Не оптимізуйтеся на одному довгому demo prompt. Workflow підтримки, сприятливий до кешування, і workflow дослідження, несприятливий до кешування, можуть мати протилежну економіку.
2. Розділіть стабільний і мінливий контент
Позначте кожен сегмент промпту:
Створіть детермінований prompt assembler. Записуйте непрозору версію префікса або keyed hash, щоб кожен запит ідентифікував префікс, який він намагався повторно використати. Не додавайте secrets або необроблений customer content до логів.
3. Запустіть контрольовану матрицю
Для кожного класу завдань виміряйте:
| Trial | Зміна | На яке питання відповідає |
|---|---|---|
| --- | --- | --- |
| Cold | Новий префікс без повторно використовуваного стану | Яка базова вартість запису або prefill? |
| Warm | Ідентичний допустимий префікс | Чи повідомляє провайдер або engine про read? |
| Early mutation | Змінити один токен на початку | Яка частина повторного використання зникає? |
| Late mutation | Змінити лише суфікс | Чи залишається стабільний префікс повторно використовуваним? |
| TTL boundary | Повторити до та після завершення дії | Як часто production traffic надходитиме вчасно? |
| Concurrency | Поетапно збільшувати паралельні запити | Чи зменшують eviction або scheduling повторне використання? |
| Version change | Змінити модель, tools або template | Які deployment інвалідують кеш? |
Виконайте достатньо повторів, щоб звітувати про розподіли, а не про одне число затримки. Розділяйте p50 і p95 для time to first token та end-to-end latency.
4. Записуйте billing і якість разом
Фіксуйте:
Повторне використання стану для точного префікса має уникати повторного обчислення prefill; це не скасовує перевірку якості. Зміна моделі, рівня квантизації, політики маршрутизації або serving stack може змінити якість output, навіть якщо сам механізм кешу працює правильно.
5. Розрахуйте три варіанти вартості
Якщо локальний варіант залежить від стабільної завантаженості, перевірте припущення щодо utilization. Купівля GPU не стає економічно вигідною лише тому, що spreadsheet призначає кожну годину простою майбутньому попиту.
Cloud API, локальний GPU чи hybrid routing?
Рішення рідко буває бінарним.
Обирайте кешований API, коли
Обирайте shared local capacity, коли
Використовуйте hybrid routing, коли
Безкоштовні або субсидовані endpoints можуть допомогти з прототипами, але не усувають потребу в обліку workload. Тематичне дослідження free AI models API→ є корисною відправною точкою для відокремлення ціни доступу від production reliability.
Безпека prompt-cache потребує окремого тесту
Кешування створює data-dependent timing: повторно використаний префікс може повернути свій перший токен швидше, ніж промах. Аудит ICML 2025 використовував вимірювання часу для тестування реальних API та повідомив про ознаки спільного використання кешу між користувачами у семи провайдерів протягом періоду дослідження.
Це історичні, специфічні для провайдерів докази. Вони не встановлюють, як ці сервіси ізолюють кеші сьогодні.
Запитайте поточних провайдерів і внутрішніх власників платформи:
Для self-hosted систем додайте тести timing і eviction між tenant. Не записуйте чутливі повторно використовувані префікси лише для налагодження кешу. Зберігайте hashes, кількість токенів, ідентифікатори версій і metadata, дозволені policy.
Чекліст рішення
Не схвалюйте купівлю GPU або міграцію API лише на основі прайс-листів. Вимагайте:
Prompt caching цінне, оскільки повторюваний контекст є поширеним. Воно небезпечне як скорочений шлях до закупівель, оскільки повторне використання залежить від workload. Виміряйте префікс, виміряйте промахи, а потім порівняйте загальну вартість.
Перевірка тверджень
| Важливе твердження | Тип доказу | Перевірка та обмеження |
|---|---|---|
| --- | --- | --- |
| Дослідження coding-agent повідомило про 99,3% prompt-cache hit rate | Первинне дослідження, препринт від липня 2026 року | Один розробник, одна кодова база, два послідовні періоди; результат не є універсальним |
| У статті повідомлено про $0,573/M оброблених API-токенів проти $2,83/M для shared local allocation | Первинне дослідження | API обробив у 16,9 раза більше токенів, а local utilization була низькою; total spend і TCO є сильнішими порівняннями |
| Shared local capacity заощадила 40,1% TCO, тоді як dedicated capacity коштувала на 43,8% дорожче | Первинне дослідження | Залежить від припущень статті щодо hardware, allocation, тайванського ринку, праці та якості |
| Prefix caching повторно використовує attention state для повторюваних сегментів промпту | Рецензоване первинне дослідження та офіційна документація engine | Воно зменшує повторну роботу prefill; decoding і робота зі змінним суфіксом залишаються |
| 5-хвилинні cache writes Anthropic коштують 1,25×, а reads — 0,1× від базового input | Офіційна документація, перевірена 30 липня 2026 року | Ціни та підтримувані моделі можуть змінюватися; приклад не враховує output, suffix і storage |
| Gemini implicit caching є стандартним для Gemini 2.5 і новіших моделей у Interactions API | Офіційна документація, оновлена 7 липня 2026 року | Мінімальна кількість токенів і підтримка explicit-cache відрізняються залежно від API та моделі |
| TokenPilot повідомив про зниження вартості на 56–87% у протестованих налаштуваннях | Первинне дослідження, препринт у процесі роботи | Два benchmark і специфічна інтеграція; потрібна незалежна реплікація |
| Timing prompt-cache може розкривати інформацію, якщо область кешу перетинає межі користувачів | Первинне дослідження ICML 2025 | Історичний аудит протестованих провайдерів; не робіть висновків про поточну поведінку vendor |