AI / LLM
Prompt caching: тест с множественным выбором
Суть Синтез по всему юниту prompt caching в формате выбора: сопоставление префикса, экономика записи/чтения, выбор TTL, правила порядка и тихое отравление префикса.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый отражает реальное решение — куда ставить cache breakpoint, какой TTL покупать, почему счёт утроился — а не определение для пересказа.
Цель
Убедись, что можешь связать сопоставление префикса токен-в-токен, экономику записи/чтения, выбор TTL и тихий режим отказа, к которому вёл урок.
Викторина
Completed
Два запроса несут один и тот же системный промпт и документ на 30k токенов, но в запросе B внутри этого блока один лишний пробел. Сколько в B прочитается из кэша?
Heads-up Кэширование точное по байтам/токенам, не нечёткое. Один вставленный пробел ре-токенизирует ряд и обрывает префикс в этой позиции; частичного прощения токена нет.
Heads-up Prompt caching позиционное, не семантическое. Провайдер никогда не сравнивает смысл — он хэширует ведущий ряд токенов и сопоставляет точно.
Heads-up Cache breakpoints — это вложенные префиксы, а не независимые кэши. Обрыв в начале префикса инвалидирует всё, что ниже него.
Викторина
Completed
Префикс записан один раз (1.25x, дефолтный тариф), затем прочитан дважды (0.1x каждый) до истечения. По сравнению с полной ставкой (1.0x) трижды — кэш помог?
Heads-up В убытке ты только на записи, которую ни разу не перечитали. Уже первое чтение опускает сумму ниже точки окупаемости; ко второму чтению — явный выигрыш.
Heads-up Они не сокращаются: 1.25 один раз плюс 0.1 за чтение — намного ниже 1.0 за запрос, как только у тебя два и более попадания.
Heads-up TTL управляет тем, доживёт ли запись до чтения, а не скидкой на токен. При чтениях внутри окна дефолтный тариф 1.25x уже выигрывает.
Викторина
Completed
У RAG-сервиса стабильный префикс на 30k токенов, но трафик всплесками: запросы кучкуются, затем тишина ~15 минут. Какая настройка кэша верна?
Heads-up 15-минутные паузы превышают 5-минутный TTL, поэтому запись истекает между всплесками и каждый всплеск платит свежую запись 1.25x на 30k токенов. Ты оптимизировал множитель записи и потерял скидку на чтение, которая важна.
Heads-up Это инвертирует правило. Документы и вопрос меняются на запрос, поэтому префикс, начинающийся с них, расходится на нулевом токене и ничего стабильного не кэшируется.
Heads-up 30k, перетарифицированные по 1.0x на каждом запросе, когда 0.1x доступно после одной записи, оставляют ~90% трат на вход на столе. Большой, перечитываемый, стабильный префикс — учебный случай для кэша.
Викторина
Completed
Cache hit rate упал почти до нуля после деплоя. Ошибок нет, выводы выглядят корректно. Наиболее вероятная причина?
Heads-up Промах кэша тихий: вывод побайтно идентичен, попал ты или платишь полную ставку. Единственный сигнал живёт в полях usage, никогда не в исключении.
Heads-up Кэширование не семантическое — оно сопоставляет префикс токен-в-токен, не смысл. Внезапный устойчивый почти-нулевой hit rate указывает на сдвинутый префикс, а не на выводы модели.
Heads-up Истечение TTL означает лишь то, что следующий запрос перепишет запись. Устойчивые почти-нулевые попадания на многих запросах указывают на изменённый префикс, а не на истечение.
Викторина
Completed
На Sonnet ты кэшируешь системный промпт на 600 токенов и не видишь скидки на чтение на повторных запросах, без ошибки. Почему?
Heads-up Дело не в типе блока, а в пороге. Ниже токенного минимума модели ничего не кэшируется, где бы контент ни лежал.
Heads-up Счётчика прогрева нет. Обычная запись происходит на первом запросе, чтения идут со второго. Префикс на 600 токенов просто никогда не пересекает минимум, так что запись вообще не создаётся.
Heads-up Все актуальные модели поддерживают кэширование. Они различаются минимальной кэшируемой длиной — 1 024 для Sonnet, 4 096 для Opus/Haiku 4.5 — а не наличием кэширования.
Викторина
Completed
У тебя длинный слоёный промпт: tools, статический блок system, затем большой документ, меняющийся раз в сутки. Как расставить до 4 cache breakpoints?
Heads-up Один концевой breakpoint означает, что любое изменение где угодно перед ним переписывает всё тело. Стек вложенных breakpoints защищает стабильную верхушку от шевеления ниже.
Heads-up Порядок фиксирован — tools идут первыми и самые стабильные. Breakpoint должен стоять на последнем идентичном блоке, а не перед самым стабильным.
Heads-up Breakpoints — это вложенные префиксы внутри одного запроса, а не независимые кэши на запрос. Записи на запрос с волатильным контентом никогда не перечитаются.
Итог
Сквозная линия юнита — одно правило с экономическим движком за ним: сопоставление идёт токен-в-токен с нулевой позиции, поэтому стабильный контент (tools, затем system, затем большой контекст) идёт первым, а волатильный (таймстампы, найденные документы, вопрос пользователя) — последним, с breakpoint на финальном неизменном блоке. Платишь 1.25x один раз за запись и 0.1x за каждое чтение, так что кэш выигрывает после первого перечитывания внутри TTL — 5 минут по дефолту, 1 час для всплесков с паузами. Ниже минимальной кэшируемой длины модели ничего не кэшируется, тихо. Производственный режим отказа всегда один: байт у нулевого токена отравляет префикс, переворачивает каждый запрос с чтения 0.1x на запись 1.25x, и единственный сигнал — в блоке usage.