Кэширование длинных префиксов

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

• Попадания в кэш значительно сокращают задержку и стоимость входных данных.
• Экономия растёт вместе с размером префикса и частотой его повторного использования.

Кэши используют для ключа точное совпадение префикса токенов от начала промпта. Кэшируемый фрагмент продолжается от начала до первой точки расхождения. Измените что-либо в начале — и всё после этого места не попадёт в кэш.

Следствие: для максимального числа попаданий сначала размещайте наиболее стабильное содержимое, а наиболее изменчивое — в конце.

Расположите содержимое от самого стабильного к самому изменчивому: неизменяемые системные правила и определения инструментов, затем большие стабильные справочные материалы, затем стабильный в рамках сеанса контекст, а в конце — изменчивые входные данные и вопрос для конкретного запроса.

• Стабильное → в начало (можно кэшировать).
• Изменчивое → в конец (только эта часть вычисляется заново).

Именно этот принцип упорядочивания обеспечивает большинство преимуществ кэширования.

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

Даже без явных маркеров соблюдайте порядок стабильности в структуре, чтобы неявное сопоставление префиксов всё равно помогало.

Незаметные непреднамеренные изменения молча нарушают кэширование: временная метка в системном промпте, идентификатор конкретного запроса, добавленный в начале, переупорядоченные определения инструментов или недетерминированный порядок ключей JSON. Каждое такое изменение сдвигает префикс и вынуждает полностью пересчитывать его.

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

Срок действия кэша истекает через заданное провайдером время жизни; при каждом попадании в кэш этот срок часто продлевается. При слишком редких вызовах промахи холодного кэша повторяются. Для прерывистой высокочастотной нагрузки кэширование окупается, а при редких разрозненных вызовах кэш может истечь между использованиями.

Сопоставляйте характер трафика с TTL и рассмотрите возможность отправки поддерживающих активность запросов для ценных префиксов.

Обычно кэширование немного увеличивает стоимость записи записи в кэш и значительно снижает стоимость её чтения. Экономика кэширования благоприятствует повторному использованию: затраты на одну запись, распределённые между множеством чтений, дают большую чистую экономию; однократное использование, при котором выполняется только запись, может обойтись немного дороже.

• Высокая доля повторного использования → активно используйте кэш.
• Префиксы для однократного использования → кэширование может не окупиться.

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

Рассматривайте кэшированный префикс как артефакт с версией, а не как строку, которую можно небрежно менять.

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

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

Добавьте измерение. Большинство провайдеров сообщают число кэшированных и некэшированных входных токенов для каждого вызова. Отслеживайте долю попаданий в кэш и, если она мала, проверьте префикс на наличие дрейфа. Ухудшение этой доли обычно указывает на недавно добавленное изменяющееся значение в начале промпта.

• Записывайте соотношение кэшированных входных токенов к общему числу входных токенов.
• Настройте оповещение, если после развёртывания доля попаданий в кэш снижается.

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

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