Нова робота, опублікована на arXiv у серпні 2026 року, підраховує ціну того, що в теорії мало б бути безкоштовним: повторне використання вже обчисленого контексту в LLM-системах. Дослідники розкладають цю операцію на три складові — композицію, перебудову та виправлення кешованої пам'яті — і показують, що кожна з них має власну, окрему вартість.

Для будь-якої системи на базі LLM, яка тримає довгий контекст — історію діалогу, витяги з бази знань, результати виклику інструментів — кеш ключів і значень уваги (KV-cache) є головним способом не платити за одні й ті самі токени двічі. Але щойно хоча б частина цього контексту змінюється, кеш перестає бути валідним, і система стикається з питанням: перебудувати все з нуля чи спробувати виправити лише те, що змінилося.

Саме цю дилему й досліджує нова робота. За даними arXiv, автори порівнюють вартість трьох стратегій роботи з попередньо обчисленою пам'яттю LLM-агента в умовах, коли контекст постійно оновлюється.

Що саме розглядають автори дослідження?

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

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

Чому перебудова кешу взагалі коштує грошей?

Кешування контексту працює лише тоді, коли новий запит починається з того самого префікса токенів, що й попередній, — так влаштоване, наприклад, prompt caching в API великих провайдерів. Якщо змінюється навіть один токен на початку контексту — оновився system prompt, підвантажився інший документ, змінився порядок повідомлень, — увесь кеш «ламається» від точки зміни й далі. Систему змушують пересилати ці токени через модель заново, тобто платити повну ціну інференсу за те, що мало бути повторним використанням.

Кому це найбільше вдарить по бюджету?

Найдорожче ця динаміка коштує агентним і RAG-системам, де контекст оновлюється на кожному кроці. Агент, який після кожного виклику інструмента дописує новий результат у контекст, або пайплайн, що на кожен запит перебирає інший набір топ-k документів, руйнує кеш регулярно — і економія, заради якої кешування взагалі впроваджували, зникає. Це особливо помітно в багатокрокових агентних архітектурах на кшталт тих, що AWS будує довкола MCP-агентів через AgentCore, де контекст агента постійно поповнюється проміжними результатами інструментів.

Висновок AiiN: що це означає для тих, хто будує агентів зараз?

За нашою оцінкою, головний практичний висновок роботи — не «кешування не працює», а «структура контексту вирішує, скільки коштує його оновлення». Команди, які проєктують агентні пайплайни, отримують прямий важіль впливу на рахунок за інференс ще до запуску в продакшн: досить розташувати стабільну частину промпту (системні інструкції, опис інструментів) на початку контексту, а мінливу — результати пошуку, нещодавні повідомлення — в кінці. Це не усуває вартість перебудови кешу повністю, але зменшує зону, яку доводиться перераховувати щоразу. Для команд, що вже експлуатують RAG у продакшні, це означає окремий пункт у чек-листі оптимізації витрат — поруч із вибором моделі та розміром контексту.

• Тримайте стабільну частину промпту (системні інструкції, опис інструментів, схеми виклику) на початку контексту.
• Виносьте мінливі фрагменти — результати пошуку, свіжі повідомлення, виводи інструментів — у кінець контексту.
• Відстежуйте не лише кількість токенів, а й частку влучань у кеш (cache hit rate) як окрему метрику витрат.

Що таке кешування контексту (prompt caching) в LLM?

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

Чи можна повністю уникнути перебудови кешу?

Ні — будь-яка зміна на початку контексту рано чи пізно змусить систему перерахувати частину кешу. Мета не в тому, щоб уникнути перебудови повністю, а в тому, щоб звести до мінімуму обсяг контексту, який потрапляє під перерахунок, і обирати між композицією, перебудовою й виправленням залежно від того, наскільки критична коректність результату в конкретному сценарії.