Открываем воскресную рубрику #лёшапочиталгодноту, буду читать статьи умных людей и делиться TLDR. Надеюсь, не сольюсь через одну неделю.

Сегодня в разборе - три статьи от Сергея Нотевского про кеширование промтов, которые форвардил несколько дней назад: @sergeinotevskii622

Еще раз, статьи - золото:

- Главное понятие, с которым нужно подружиться: KV-cache hit rate, то есть как часто ответы вашей LLM достаются из кэша, а также процент вашего промта, который кешируется

- У провайдеров разные политики кэширования. Есть автоматические и есть явные. Лучше начинать с автоматических, смотреть кеш хитрейт и думать, стоит ли ручной тюнинг

- Ключевое правило – кэшироваться будет та часть промта, которая одинакова между запросами в LLM с точностью до символа. Как только в промт попадает что-то меняющееся, например, сегодняшняя дата с секундами, кэш отрежется, и все, что идет после, не будет закэшировано

- Промт лучше структурировать так: Tools, System, Messages. Брейкпоинты кэша ставить либо в конце System, либо в начале Messages, в зависимости от того, насколько динамичные у вас диалоги и какая часть из них одинаковая. Для Tools обязательно используйте sort_keys=True, иначе некоторые библиотеки могут случайно менять порядок тулзов, и кеширования не будет вообще. Плюс думайте про динамические списки тулзов - озможно, такая оптимизация убьет вам всю экономику и агент будет стоить в пять раз дороже

- cache_control нужно ставить ни в коем случае не в системный промпт, а на уровне API Anthropic в нужные JSON-блоки обращения в модель

- Посмотрите на свои логи и перенесите все, что динамически меняется от диалога к диалогу, ближе к концу: таймстемпы, имена пользователей, некие статистики, информацию специфичную этому диалогу. В идеальном мире большая часть вашего промта должна быть одинакова, лежать в начале и не меняться даже на тысячах запросов у разных пользователей

- Если вы используете OpenRouter вместо походов напрямую, он добавляет дополнительный уровень маршрутизации между внутренними провайдерами, и ваш запрос может попасть на непрогретый сервер без кэша (Bedrock вместо Vertex), и вы получите кэш-мисс

- У антропиков можно явно выставить руками кеш-брейкпоинты, но не больше четырех. Например, парочку в секциях System и один в Messages. Тогда если у нас что-то меняется в конце System, сработает первый в System, а если ничего не будет меняться, сработает последний Messages закеширована будет большая часть промта

- У антропиков есть два варианта кэширования на пять минут и на час разной по стоимости. Первый обойдется на 25% дороже, а второй в два раза. Зато чтение из кэша обойдется в 10 раз дешевле стандартной стоимости

- Также кеш влияет на время ответа от модели. Например, на промпте в 50 000 токенов без кэша время ответа может быть 12 секунд, а с кэшом 1 секунду

- У провайдеров есть минимальный размер промта для кэширования. Например, у Haiku это 4000 символов, у других моделей порядка 1000. То есть если у вас слишком простой промт, то кэширование будет доступно лишь при определенном наполнении истории

- В том же Anthropic кэширование работает не на уровне API ключей, а на уровне Workspace, для того чтобы нам было удобно иметь много разных проектов, агентов и не плодить для них разные API ключи

- Кэш живет ограниченное количество времени. Где-то это час, где-то пять минут, где-то больше. Помните, что он не вечен

- С точки зрения мониторинга hit rate и latency ответа не должны сильно бегать от релиза к релизу и в течение дня, когда у вас система прогрета. Посматривайте на эти графики

- Если у вас широкая рассылка, инициация разговора с большим количеством пользователей, сначала прогрейте кэш на первом клиенте и потом отправляйте основную часть коммуникации. Если ответ на первое сообщение будет 20 сек, а у вас хорошая многопоточность, вы за это время можете отправить тысячи запросов, не попавших в кэш

———
Уперся в лимит сообщения, на этом все!

Увидимся в новых сериях