Прибуток:
- Поясніть логіку відповідності префіксів кешування підказок
- Збільшує кількість звернень до кешу, розміщуючи фіксований контекст спочатку, а змінний — після
- Може розрахувати економіку запису/читання кешу та точку беззбитковості
Продукт LLM виглядає дешевим у прототипі; Коли стаєш на ваги, рахунок дивує. У більшості робочих навантажень більшість рахунків надходить із того самого фіксованого контексту, який надсилається знову і знову з кожним запитом: довге системне підказка, книга правил, довідкова документація. Оперативне кешування усуває саме ці витрати. У цьому розділі ви дізнаєтесь, як працює кеш-пам’ять, як організувати підказку для звернення та як розрахувати точку беззбитковості економії кешу. При правильній установці він сам по собі може скоротити ваш рахунок вдвічі або навіть менше.
Як працює кеш? Єдине незмінне правило
Кешування підказок — це збіг префікса. Постачальник тимчасово зберігає маркери, які він обробив з початку вашого запиту. Якщо підказка починається з того самого префікса під час наступного запиту, ця загальна частина не обчислюється повторно; Його набагато дешевше читати, ніж кеш.
З цього випливає одне незмінне правило: якщо один байт змінюється будь-де в префіксі, весь кеш стає недійсним з цього моменту і далі. Тобто фіксований вміст має бути на початку, а змінний – у кінці. Якщо на початку системної підказки поставити рядок, який змінюється з кожним запитом, наприклад «Сьогоднішня дата: 18.07.2026», все, що стоїть за нею, не зможе потрапити в кеш.
Порядок обробки зазвичай такий: інструменти → системна підказка → повідомлення. Ви розміщуєте точку кешу (точку зупину) у кінці фіксованого розділу.
Економія кешу
Кеш має три цінові рівні:
- Запис в кеш: Зберігається вперше. ~1,25x нормальна вхідна ціна (за 5 хвилин зберігання).
- Читання кешу: читання наступних запитів. Приблизно в 0,1 раза від звичайної ціни вхідних матеріалів, тобто одна десята.
- Звичайний вхід: частина, яка не потрапляє в кеш і щоразу обробляється за повну вартість.
Точка беззбитковості: перший запит оплачує премію за запис (1,25 ×). З другого запиту в дію вступає читання (0,1×). Грубо кажучи, ви будете навпроти двох запитів; Після цього – чисті заощадження. Чим більший фіксований контекст і чим більше запитів він повторно використовується, тим більшим стає виграш.
Сценарій
Чи працює кеш?
Велика фіксована системна підказка, тисячі запитів
Так — найвищий заробіток
Багато запитань щодо тих самих довідкових документів
так
Абсолютно різний короткий текст для кожного запиту
Ні — бонус за запис витрачається даремно
Одноразовий запит
Ні — не читати взагалі
Дата/ідентифікатор змінюються з кожним запитом у системному запиті
Ні — префікс не працює, попадання нульове
Крок за кроком: як налаштувати підказку звернення?
- Розділіть постійні та змінні. Який вміст ніколи не змінюється (системна підказка, звід правил, документація)? Що змінюється з кожним запитом (питання користувача, дата, ID)?
- Поставте константу на початку. Під час обробки частина, яка йде першою (інструменти, система), повинна бути стабільною.
- Помістіть змінну в кінці. Поточне запитання користувача, останнє.
- Помістіть знак у кінці бордюру. Помістіть кеш-точку в останній блок фіксованої частини.
- Підтвердити попадання. Перевірте, чи cache_read_input_tokens більше нуля в полі використання у відповіді. Якщо нуль, у префіксі є прихований руйнівник.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}
Порада: не вгадуйте звернення до кешу, виміряйте їх. Якщо usage.cache_read_input_tokens все ще дорівнює нулю під час послідовних запитів, працює тихий розрив (datetime.now() у системному запиті, невпорядкований JSON, список інструментів змінюється з кожним запитом). Побайтно порівняйте необроблений запит двох запитів і знайдіть різницю.
Безшумні руйнівники
Типові моделі, які несвідомо пошкоджують кеш:
# BREAKER: вбудовування інформації в підказку системи, яка змінюється з кожним запитом «Сьогоднішня дата: {{now}}. Ви помічник...» ← префікс змінюється з кожним запитом, звернення дорівнює нулю # TRUE: переміщує змінну в систему повідомлень: «Ви помічник...» ← константа вводить повідомлення в кеші: [{role: user, content: «Сьогодні {{now}}. Питання: ..."}] ← змінна в кінці
Інші зламники: JSON сортується по-різному для кожного запиту (ключі зберігаються у фіксованому порядку), список інструментів залежить від користувача (інструменти обробляються першими; якщо вони змінюються, нічого не потрапляє в кеш), змінюється модель під час розмови (кеші залежать від моделі).
Слабка підказка / Сильна підказка (дружня структура для кешу)
# СЛАБКА (побудова кешу) система: «Дата: 18.07.2026 14:32. Користувач: Ahmet (id 8842). Ви бот підтримки. Правила: ...(2000 токенів)...»
# СИЛЬНА (структура, дружня до кешу)система: "Ви бот служби підтримки. Правила: ...(2000 токенів, ніколи не змінюється)..." [знак кешу]повідомлення: [ { роль: користувач, вміст: "Дата: 18.07.2026 14:32. Ідентифікатор користувача: 8842. Питання: як ініціювати відшкодування?" }]
У слабкій версії блок правил з 2000 токенів обробляється за повну вартість кожного запиту. У сильній версії один і той же блок записується один раз і читається на всіх наступних запитах за десяту частину ціни.
Три міні-чохли
Випадок 1 — Кешування книги правил. Автоматизація бухгалтерського обліку додавала книгу правил на 12 000 токенів до кожного рахунку-фактури; 5000 запитів на день. Введення без кешу коштує ~$180 на день. Вони підтримували звід правил постійним і кешували його: перші запити сплачували надбавку за запис, наступні читання – 0,1×. Вхідні витрати впали на ~90% до ~18 доларів США на день.
Випадок 2 — Вартість прихованої лінії дат. Одна команда створила схованку, але не отримала жодних ударів; cache_read_input_tokens завжди дорівнював нулю. Причина: у першому рядку системного підказки було datetime.now(), префікс змінювався з кожним запитом. Коли ми перенесли дату в повідомлення користувача, показник відвідувань раптово зріс з 0% до 94%.
Випадок 3 — Неправильно розміщений кеш. Пошукова програма надсилала абсолютно різні короткі запити з кожним запитом; Вони охоче додали знак схованки. Без загального префікса кожен запит сплачував лише надбавку за запис, без читання — це збільшувало вартість. Зняли табличку. Урок: кеш платить, лише якщо є великий і постійний префікс, який використовується повторно.
Поширені помилки
- Змішування константи та змінної: коли вміст змінної міститься в префіксі, звернення скидається.
- Вбудовування дати/ідентифікатора в системний запит: найпоширеніший тихий руйнівник.
- Не вимірюється звернення: якщо cache_read_input_tokens не позначено, витрати не помічатимуться.
- Додавання кешу, коли немає загальнодоступного префікса: ви платите лише премію за запис, вартість зростає.
- Зміна списку або моделі транспортного засобу: Приставка зламана з самого початку; все переписано.
- Забути про мінімальний розмір кешу: дуже короткі кеші (менше ~1–4 тис. токенів залежно від моделі) не потраплять у кеш безшумно.
Глибше: проектування кешу за типом робочого навантаження
Фактична віддача від кешування залежить від характеру вашого робочого навантаження; тому спочатку дізнайтеся про трафік. Три типові схеми і правильна установка:
Загальна системна підказка, різні запитання. Найпоширеніший корпоративний шаблон: велика системна підказка (роль, правила, можливо, довідковий документ) із сотнями різних запитань користувача. Тут спочатку кешується фіксована частина (система); кожне нове запитання платить повну ціну лише за свою маленьку частину. Прибуток дуже високий, оскільки велика порція повторюється багаторазово за десяту частину ціни.
Багатораундовий монолог. Коли розмова затягується, кожен новий раунд спирається на всю попередню історію. Якщо ви розмістите прапорець кешу в кінці останнього раунду, кожен запит повторно використовує попередній префікс розмови; хіти накопичуються в міру розмови. Це значно знижує вартість тривалих сесій асистента.
Спільний префікс - останній біт, який потрібно змінити. Кілька запитів мають великий набір фіксованих попередніх запитів (набір зразків, інструкції), але розділені одним запитанням у кінці. Ви розміщуєте вказівник кешу в кінці спільної частини; Інакше кожен запит записував би окремий кеш, і жоден із них не читався б.
Одне застереження: кеш залежить від моделі та певного мінімального розміру. Дуже маленькі префікси (менше кількох тисяч токенів, залежно від моделі) не потраплять у кеш, навіть якщо ви позначите їх — cache_creation_input_tokens залишається нульовим. Крім того, зміна моделі під час розмови робить недійсним весь кеш; Якщо інше завдання потребує дешевої моделі, збережіть основний потік в одній моделі, а додаткову роботу помістіть в окремий виклик.
Підсумовуючи
Кешування підказок — це відповідність префіксу: фіксований вміст має бути на початку, змінний — у кінці. Для великого повторно використовуваного контексту вартість читання становить десяту частину від повної ціни, приблизно беззбитковість у двох запитах. Найпоширенішою помилкою є пошкодження префікса шляхом вбудовування змінних даних у системну підказку; Ви перевіряєте збіг, вимірюючи його в полі використання.
Аплікаційне завдання
Виберіть навантаження. (1) Розділіть вміст на дві колонки: «ніколи не змінюється» та «змінюється з кожним запитом». (2) Перемалюйте структуру підказки, поставивши постійну частину на початку, а змінну частину в кінці. (3) Оцініть розмір символів фіксованої частини та порівняйте місячну вартість з/без кеш-пам’яті. (4) Зверніть увагу, з якого поля (cache_read_input_tokens) ви перевірятимете збіг.
контрольний список
- [ ] Я можу пояснити, що кеш — це відповідність префіксів і єдине незмінне правило.
- [ ] Я можу підвищити точність, розмістивши фіксований вміст на початку, а змінну в кінці.
- [ ] Я знаю економіку запису/читання та точку беззбитковості двох запитів.
- [ ] Я можу розпізнавати тихі руйнівники (дата, невпорядкований JSON, зміна списку транспортних засобів).
- [ ] Я можу перевірити збіг за допомогою usage.cache_read_input_tokens.