Кешування промптів у LLM: як дешевший сталий префікс скорочує рахунки

Асистент обслуговування клієнтів із 1 800-токенним системним промптом і 600-токенним контекстом із бази знань надсилає при кожному з 15 000 запитів на місяць загалом 2 400 токенів «сталої» частини входу. Це 36 млн токенів на місяць за текст, який не змінюється. Кешування промптів усуває цю вартість без жодного рядка бізнес-коду.

Мовні моделі обробляють кожен виклик з нуля, якщо провайдер не реалізував механізм кешу префіксу. При першому виклику з даним префіксом модель обчислює так звані ключі та значення уваги (KV-cache) для цих токенів і зберігає їх на сервері. Кожен наступний виклик, що починається з ідентичного префіксу, зчитує KV-cache замість його переобчислення.

Умова влучення є точною: префікс має бути ідентичним байтово від початку промпту до визначеної точки поділу. Один змінений символ, переставлена інструкція чи інакше відформатована дата в системному промпті перериває збіг. Це фундаментальна відмінність від семантичного кешу, який працює на основі семантичної подібності та допускає парафразування.

Практичні наслідки цього механізму: сталий системний промпт має бути на початку промпту (перед змінним контекстом користувача), а змінна частина (запит, свіжий контекст RAG, історія розмови) має розташовуватися після блоку, який ви хочете кешувати. Постачальники API, які пропонують цю функцію (зокрема Anthropic, Google Gemini, деякі варіанти OpenAI), вимагають мінімальної довжини кешованого фрагмента, зазвичай 1 024 токени, щоб кеш був вигідним з точки зору інфраструктури.

Вартість влучення в кеш залежить від провайдера: Anthropic стягує 10% ціни звичайного вхідного токену за cache hit, Google Gemini в режимі context caching може знижуватися до 25% базової ціни. В обох випадках запис у кеш (перший виклик) коштує 100-125% звичайної вхідної ціни, тому рентабельність починається з другого запиту з тим самим префіксом.

Ці два механізми працюють на різних рівнях і вирішують різні проблеми. Їх варто порівнювати, оскільки компанії, що впроваджують AI, часто плутають їх або обирають один там, де потрібні обидва.

Кешування промптів працює на рівні інференсу: усуває вартість обробки незмінної частини входу. Не стосується відповіді моделі, не кешує результатів. Кожен запит все одно потрапляє до моделі та отримує унікальну відповідь. Вигода полягає виключно в зменшенні вартості вхідних токенів для сталого префіксу.

Семантичний кеш працює на рівні відповіді: перехоплює пару (запит, відповідь) і при наступному семантично подібному запиті повертає збережену відповідь без участі моделі. Вигода — це як вартість вхідних токенів, так і вихідних, а також повне усунення латентності моделі (10-30 мс замість 300-1500 мс).

Обидва механізми доповнюють один одного: семантичний кеш обробляє повторювані запитання FAQ без моделі, а кешування промптів знижує вартість усіх інших запитів, які все одно потрапляють до моделі зі сталим префіксом. У системі з розвиненим RAG варто розглянути обидва одночасно, про що докладніше йдеться в статті про оптимізацію витрат на токени LLM.

Економія прямо пропорційна двом факторам: частці сталого префіксу в загальній довжині промпту та обсягу запитів. Сценарії з великим множенням цих факторів є природними пріоритетами.

Асистент із довгим системним промптом і великим контекстом RAG. Якщо системний промпт має 2 000 токенів, а до кожного виклику додаєш 1 500 токенів документів із бази знань як сталий продуктовий контекст, префікс налічує 3 500 токенів. При 10 000 запитах на місяць це 35 млн вхідних токенів для усунення. При ціні 0,003 USD/1k токенів економія сягає 80-100 USD на місяць, при преміум-моделі (0,015 USD/1k) перевищує 450 USD на місяць.

Обробка документів у пакетному режимі. Аналіз довгого документа (звіт, контракт, набір даних), розділений на багато аналітичних викликів — класичний випадок: документ є префіксом, а аналітичні запитання змінюються. Кешування промптів скорочує вартість багаторазового аналізу того самого файлу на 60-80%.

Багатоетапні пайплайни агентів. В архітектурі агента, що виконує кілька кроків за одну сесію, де кожен крок бачить той самий системний промпт і історію попередніх дій як префікс, кеш накопичує економію після кожного додаткового кроку.

Коли ефект мінімальний: системи з короткими промптами (менше 1 024 токенів сталого префіксу не кваліфікуються на кеш у більшості провайдерів), системи з великою мінливістю контексту (де «сталий» префікс змінюється кожні кілька запитів) та одноразові виклики, де кожен промпт унікальний.

Порядок блоків у промпті — це інженерне рішення з прямим впливом на TCO системи. Практичне правило: від найстабільнішого до наймінливішого.

Структура, оптимізована під кеш:

1. Системний промпт (інструкції ролі, тон, правила, guardrails) — найстабільніший, змінюється раз на тижні або місяці.
2. Сталий контекст знань (продуктові документи, FAQ, корпоративний глосарій) — змінюється при оновленні бази знань, не при кожному запиті.
3. Історія розмови (попередні тури) — змінюється кожні кілька турів, але в межах сесії зростає поступово.
4. Запит користувача — змінний, в кінці.

Структурні помилки, що руйнують кеш: вставка дати або timestamp у системний промпт (змінюється щосекунди, префікс ніколи не потрапить у кеш), розміщення змінного контексту користувача перед сталими інструкціями, динамічне переформатування сталих блоків при кожному виклику.

Варто вводити токенові сепаратори між блоками, якщо API це дозволяє, щоб визначити точку поділу. Деякі SDK (Anthropic Python SDK від версії 0.28) підтримують анотацію cache_control: {"type": "ephemeral"} на рівні повідомлення, що дозволяє позначити точну точку поділу сталого та змінного сегментів.

Детальні патерни побудови системного промпту, включаючи порядок елементів і структуру інструкцій, описані в статті про промпт-інжиніринг для компаній.

Кешування промптів — це функція інфраструктури на стороні сервера. Моделі, що запускаються локально через Ollama, vLLM або llama.cpp, можуть підтримувати цей механізм, але це залежить від конкретної реалізації сервера інференсу.

vLLM (від версії 0.4.0) підтримує prefix caching автоматично для всіх моделей, якщо enable_prefix_caching=True встановлено при старті. llama.cpp з параметром --cache-prompt зберігає та завантажує KV-cache між сесіями в тому самому процесі. Ollama (станом на 2026) не експонує цю опцію через публічне API, але механізм присутній у шарі llama.cpp, на якому вона базується.

Для self-hosting ключова додаткова вимога — пам'ять: KV-cache для 2 000-токенного префіксу моделі 70B займає 0,5-2 ГБ VRAM (залежить від точності квантизації). Перш ніж увімкнути prefix caching на локальній інфраструктурі, перевірте, чи є резерв VRAM. Економія на часі GPU та пропускній здатності буває значною при великому обсязі запитів до того самого префіксу.

Аналіз порогу рентабельності між API та self-hosting, що враховує витрати на обладнання та кешування промптів з обох сторін, проведете в статті про витрати на утримання агента AI.

Залежить від провайдера. У Anthropic потрібно позначати блоки cache_control у SDK або безпосередньо в запиті API, що вимагає кількох рядків коду. Google Gemini Context Caching має окремий ендпоінт для збереження контексту перед викликом. OpenAI (вибрані моделі) кешує префікси автоматично без анотацій, але лише при повторному використанні точно такого самого префіксу. У будь-якому випадку зміна стосується шару викликів API, а не бізнес-логіки асистента.

Час життя кешу (TTL) відрізняється між провайдерами. Anthropic визначає TTL на 5 хвилин для стандартного кешу, з можливістю оновлення через наступний виклик. Google Gemini Context Caching дозволяє встановити власний TTL (від кількох хвилин до кількох годин) і стягує окрему плату за зберігання кешу на годину. При низькому обсязі запитів (менше кількох на хвилину) TTL 5 хвилин може спричиняти часті cache miss та зменшувати ефективну економію.

Так, кеш префіксу зберігається на стороні провайдера протягом TTL. Якщо системний промпт або контекст RAG містить персональні дані чи конфіденційні корпоративні дані, застосування кешування промптів означає, що ці дані зберігаються на серверах провайдера довше, ніж окремий виклик. Перш ніж увімкнути кеш, перевірте угоду DPA (Data Processing Agreement) з провайдером та оцініть, чи потребує вміст префіксу DPIA. Якщо конфіденційні дані не можуть залишати локальну інфраструктуру, розгляньте self-hosting з vLLM prefix caching.

Так, і це один із відчутних побічних ефектів. Усунення переобчислення KV-cache для великого префіксу скорочує час до першого токену відповіді на 15-40% для типових розмірів системних промптів. Ефект помітний особливо при префіксах понад 2 000 токенів і моделях з довгим контекстом (100k+), де повна обробка префіксу займає кількасот мілісекунд.

Так, це поширений патерн оптимізації. Роутер моделей спрямовує запити до моделей різних класів (дешеві/швидкі vs. дорогі/точні). Кешування промптів варто вмикати окремо для кожного класу моделей, оскільки системний префікс відрізняється для різних моделей у роутері. Роутери, побудовані на n8n або власному коді, можуть передавати ідентифікатор моделі до шару керування промптом, щоб ключ кешу містив версію моделі та уникати влучень між різними моделями, що використовують подібні системні промпти.