Прибыль:
- Объясните логику сопоставления префиксов при кэшировании подсказок.
- Увеличивает попадание в кеш, помещая сначала фиксированный контекст, а затем переменный контекст.
- Может рассчитать экономику записи/чтения кэша и точку безубыточности.
Продукт LLM в прототипе выглядит дешево; Когда вы поднимаетесь на весы, счет удивляет. В большинстве рабочих нагрузок большая часть счета поступает из одного и того же фиксированного контекста, который отправляется снова и снова с каждым запросом: длинное системное приглашение, свод правил, справочная документация. Оперативное кэширование устраняет именно эти потери. В этом модуле вы узнаете, как работает кэш, как организовать подсказку для попадания и как рассчитать точку безубыточности экономики кэша. При правильной установке он сам по себе может сократить ваш счет вдвое или даже ниже.
Как работает кеш? Одно непреложное правило
Быстрое кэширование — это совпадение префиксов. Поставщик временно сохраняет токены, которые он обработал с момента начала вашего запроса. Если при следующем запросе приглашение начинается с того же префикса, эта общая часть не пересчитывается; Читать гораздо дешевле, чем кэшировать.
Из этого следует одно неизменное правило: если в любом месте префикса изменяется один байт, с этого момента весь кэш становится недействительным. То есть фиксированное содержимое должно быть в начале, а переменное — в конце. Если вы поставите в начало системной подсказки строку, которая меняется при каждом запросе, например «Сегодняшняя дата: 18.07.2026», все, что находится за ней, не сможет попасть в кеш.
Порядок обработки обычно следующий: инструменты → системная подсказка → сообщения. Вы помещаете точку кэша (точку останова) в конце фиксированного раздела.
Экономия кэша
Cache имеет три ценовых уровня:
- Кэш пишет: Сохраняю впервые. ~1,25x от обычной входной цены (за 5 минут хранения).
- Чтение кэша: Чтение последующих запросов. Примерно в 0,1 раза превышает нормальную цену входных ресурсов, то есть одну десятую.
- Обычный ввод: часть, которая не попадает в кэш и каждый раз обрабатывается за полную стоимость.
Точка безубыточности: за первый запрос выплачивается премия за запись (1,25×). Со второго запроса в игру вступает чтение (0,1×). Грубо говоря, вы будете идти рука об руку по двум запросам; После этого это чистая экономия. Чем больше фиксированный контекст и чем больше запросов он используется повторно, тем больше становится выигрыш.
Сценарий
Кэш работает?
Большая фиксированная системная подсказка, тысячи запросов
Да — самый высокий заработок
Много вопросов по одной и той же справочной документации
Да
Совершенно другой короткий текст для каждого запроса
Нет — бонус за запись потрачен впустую
Разовый запрос
Нет, вообще не читаю
Дата/идентификатор меняется при каждом запросе по запросу системы.
Нет — префикс неверен, попадание равно нулю
Шаг за шагом: как настроить подсказку о попадании?
- Разделите константу и переменную. Какой контент никогда не меняется (системная подсказка, книга правил, документация)? Что меняется при каждом запросе (вопрос пользователя, дата, идентификатор)?
- Поставьте константу в начале. При обработке та часть, которая идет первой (инструменты, система), должна быть стабильной.
- Поместите переменную в конец. Текущий вопрос пользователя, последний.
- Поместите знак в конце границы. Поместите точку кэша в последний блок фиксированной части.
- Проверьте попадание. Проверьте, больше ли значение 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}}" } ]}
Совет: не угадывайте попадания в кеш, измеряйте их. Если значение use.cache_read_input_tokens по-прежнему равно нулю для последовательных запросов, запускается тихий прерыватель (datetime.now() в системном приглашении, неупорядоченный JSON, список инструментов, меняющийся с каждым запросом). Сравните необработанное приглашение двух запросов побайтно и найдите разницу.
Тихие нарушители
Типичные шаблоны, которые неосознанно повреждают кэш:
# BREAKER: встраивание информации в системную подсказку, которая меняется при каждом запросе "Сегодняшняя дата: {{сейчас}}. Вы ассистент..." ← префикс меняется при каждом запросе, попадание равно нулю# TRUE: перемещает переменную в систему сообщений: "Вы ассистент..." ← константа вводит в кэш сообщения: [{role: user, content: "Сегодня {{сейчас}}. Вопрос: ..."}] ← переменная в конце
Другие нарушения: JSON сортируется по-разному при каждом запросе (хранить ключи в фиксированном порядке), список инструментов варьируется в зависимости от пользователя (инструменты обрабатываются первыми; в случае их изменения ничего не попадает в кеш), изменение модели в середине разговора (кеши зависят от модели).
Слабое приглашение/Сильное приглашение (структура, дружественная к кэшу)
# СЛАБАЯ (сборка очистки кеша)система: "Дата: 18.07.2026 14:32. Пользователь: Ахмет (id 8842). Вы бот поддержки. Правила: ...(2000 токенов)..."
# СИЛЬНАЯ (кэш-структура) система: «Вы бот поддержки. Правила: ...(2000 токенов, никогда не меняются)...» [знак кэша]messages: [ { role: user, content: «Дата: 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 тыс. токенов в зависимости от модели) не будут автоматически входить в кеш.
Глубже: проектирование кэша по типу рабочей нагрузки
Фактическая отдача от кэширования зависит от характера вашей рабочей нагрузки; поэтому сначала узнайте свой трафик. Три типовые схемы и правильная установка:
Общая системная подсказка, разные вопросы. Самый распространенный корпоративный шаблон: большое системное приглашение (роль, правила, возможно, справочный документ) с сотнями различных вопросов пользователя. Здесь фиксированная часть (система) кэшируется изначально; каждый новый вопрос платит полную цену только за свою небольшую часть. Выигрыш очень велик, потому что большая часть повторяется повторно за десятую часть цены.
Многораундовый монолог. По мере того, как разговор затягивается, каждый новый раунд строится на основе всей предыдущей истории. Если вы установите флаг кэширования в конце последнего раунда, каждый запрос повторно использует префикс предыдущего диалога; хиты накапливаются по мере развития разговора. Это значительно снижает стоимость длительных сеансов ассистента.
Общий префикс — это последний бит, который нужно изменить. Множественные запросы имеют большой набор фиксированных априорных значений (набор образцов, инструкции), но в конце разделяются одним вопросом. Вы помещаете указатель кэша в конец общей части; В противном случае каждый запрос будет записывать свой отдельный кеш, и ничего из него не будет прочитано.
Один нюанс: кэш зависит от модели и определенного минимального размера. Очень маленькие префиксы (менее нескольких тысяч токенов, в зависимости от модели) не будут автоматически входить в кеш, даже если вы их пометите — кэш_создание_вход_токенов останется нулевым. Кроме того, изменение модели в середине разговора делает недействительным весь кеш; Если для другой задачи требуется дешевая модель, сохраните основной поток в одной модели и вынесите побочную работу в отдельный вызов.
В заключение
Кэширование подсказок — это совпадение префиксов: фиксированное содержимое должно быть в начале, переменное содержимое — в конце. Для большого повторно используемого контекста стоимость чтения составляет десятую часть полной стоимости, что примерно равно безубыточности в двух запросах. Самая распространенная ошибка — повреждение префикса путем внедрения переменных данных в системную подсказку; Вы проверяете попадание, измеряя его в поле использования.
Задача приложения
Выберите рабочую нагрузку. (1) Разделите содержимое на две колонки: «никогда не меняется» и «меняется при каждом запросе». (2) Перерисуйте структуру подсказки, поместив постоянную часть в начало и переменную часть в конец. (3) Оцените размер токена фиксированной части и сравните ежемесячную стоимость с кэшем или без него. (4) Обратите внимание, из какого поля (cache_read_input_tokens) вы будете проверять попадание.
контрольный список
- [ ] Я могу объяснить, что кэш — это сопоставление префиксов и единственное неизменяемое правило.
- [ ] Я могу повысить точность, поместив фиксированное содержимое в начале и переменную в конце.
- [ ] Я знаю экономику записи/чтения и точку безубыточности с двумя запросами.
- [ ] Я могу распознать тихие нарушители (дата, неупорядоченный JSON, изменение списка транспортных средств).
- [ ] Я могу проверить попадание с помощью use.cache_read_input_tokens.