Кэширование промптов в API LLM может уменьшить расходы и задержку, если повторные запросы содержат достаточно длинный общий префикс. Но сам факт, что второй вызов прошёл быстрее, ничего не доказывает: на время ответа влияют нагрузка, сеть и очередь. Надёжнее проверять явные счётчики кэшированных входных токенов, повторяя один и тот же запрос и меняя только его конец.
Ниже — воспроизводимая схема теста для интеграции, в которой системные инструкции, описание инструментов или справочный контекст повторяются от вызова к вызову. Она помогает понять, срабатывает ли механизм у выбранного провайдера, а не просто предположить это по низкому счёту или одному удачному замеру.
Что именно кэшируется
При кэшировании промптов провайдер повторно использует обработанный общий участок входа, когда последующие запросы совпадают с подходящим префиксом. Это не то же самое, что кэширование готового ответа: если поменять вопрос в конце, модель всё равно должна обработать новую часть и сгенерировать ответ.
Правила зависят от API. OpenAI описывает автоматическое кэширование подходящих префиксов и отображает использованные кэшированные входные токены в данных об использовании. Anthropic документирует отдельную схему создания и чтения кэша с контрольными точками. Gemini API описывает контекстное кэширование, которое может включать явное создание кеша. Эти механизмы нельзя считать взаимозаменяемыми: минимальная длина, срок хранения, тарифы и формат запроса различаются.
Поэтому сначала уточните, какой именно механизм доступен для вашей модели и конечной точки. Не переносите настройки и ожидания из документации одного поставщика на другой.
Как проверить кэширование промптов в API LLM
Подготовьте три запроса к одной модели:
Первый вызов: длинный общий текст плюс вопрос A.
Повтор: тот же общий текст в том же порядке плюс вопрос B.
3. Контрольный вызов: изменённый или переставленный общий текст плюс вопрос B.
В первых двух запросах общий префикс должен быть побайтно одинаковым, если документация провайдера не определяет совпадение иначе. В контрольном запросе намеренно измените его так, чтобы ранний участок перестал совпадать. Например, поменяйте порядок двух абзацев или вставьте фразу в начало.
Составьте тестовый контекст из материала, который можно безопасно отправлять внешнему API: публичной документации или синтетических данных. Не используйте реальные персональные данные, секреты и внутренние документы, если это не разрешено вашей политикой обработки данных. Повторяйте тест несколько раз и сохраняйте идентификаторы запросов, время отправки, версию модели, настройки генерации и поля usage из ответа.
Контрольный вызов нужен не для проверки скорости. Он показывает, изменится ли счётчик кэшированных токенов, когда общий префикс нарушен. Если провайдер предлагает только явное создание кэша, отдельно проверьте его жизненный цикл: создание, использование, срок действия и удаление — в соответствии с документацией API.
Как подготовить сравнение без ложных выводов
Используйте одну модель, один регион и одинаковые параметры генерации. Зафиксируйте температуру, лимит выходных токенов, инструменты и формат ответа. Убедитесь, что изменение вопроса не меняет системные инструкции или описание инструментов: иначе вместе с контрольной переменной изменится и структура входа.
Уточните токенизацию: число символов не равно числу токенов. Если контекст короче минимального порога, установленного провайдером для кэширования, нулевой результат ожидаем и не говорит о поломке интеграции. Минимальный размер и другие условия нужно проверять в актуальной документации для конкретной модели.
В таблицу или файл результатов для каждого вызова заносите:
- число входных токенов и, если доступно, число кэшированных входных токенов;
- выходные токены;
- задержку от отправки до получения ответа;
- код и статус ответа;
- модель и точное время вызова;
- условия кэширования, которые указаны в API или заголовках.
Чередуйте повторный и контрольный запросы, если тестируете на загруженном сервисе. Иначе нагрузка может совпасть с одним типом вызова и исказить сравнение задержки. Не делайте много параллельных запросов, если цель — проверить поведение кэша: конкуренция сама становится дополнительной переменной.
Какие поля ответа показывают, что кэш сработал
Ищите не только общее количество входных токенов, но и отдельное поле, которое провайдер связывает с повторно использованным входом. Название и расположение этого счётчика зависят от формата ответа и версии API. В OpenAI usage может содержать сведения о кэшированных токенах; у других провайдеров данные об использовании и механизм кэширования устроены иначе. Сверяйтесь с документацией для используемой конечной точки.
Признак срабатывания — счётчик кэшированного входа появляется или увеличивается в повторных вызовах с неизменным префиксом и ожидаемо меняется при контрольном нарушении совпадения. Если в ответе такого поля нет, одной скорости недостаточно: результат теста следует считать неопределённым, а не подтверждённым.
Не путайте число кэшированных токенов с числом всех входных токенов. Запрос может включать общий закэшированный контекст и новый вопрос, а также дополнительные инструкции, автоматически добавляемые приложением. Сравнивайте именно те поля, которые документация определяет как данные об использовании кэша.
Как отделить эффект кэша от случайного ускорения
Запишите задержку каждого вызова отдельно и сравните серии повторных и контрольных запросов, а не одну пару. Используйте медиану и диапазон значений; если разброс велик, увеличьте число повторов или повторите тест в другое время. Для инженерного решения это полезнее, чем выбрать самый быстрый результат.
Также разделяйте задержку API и время в приложении. Замеряйте интервал непосредственно вокруг HTTP-запроса, а не весь пользовательский сценарий, в который входят очередь, обработка данных и вывод ответа. Если доступно, фиксируйте время до первого токена и общее время генерации отдельно.
Кэш может влиять на обработку входа, но не обязан заметно ускорять весь запрос: генерация длинного ответа, сетевые задержки или очередь способны перекрыть этот эффект. Поэтому проверка задержки — вспомогательная метрика. Главный сигнал — явная статистика использования кэша.
Как оценить экономию, а не только наличие кэшированных токенов
Посчитайте стоимость по актуальному тарифу именно для используемой модели и API. Если провайдер назначает отдельную цену на кэшированные входные токены, разделите вход на обычные и кэшированные части и примените соответствующие ставки. Включите в расчёт выходные токены: они могут составлять значительную долю стоимости и обычно не становятся бесплатными из-за повторного использования входа.
Сравнивайте одинаковые сценарии: число вызовов, длина общего префикса, длина изменяемой части и объём ответа. Затем рассчитайте стоимость без кэширования и с наблюдаемым распределением токенов. Если есть плата за создание или хранение кэша, учтите её и срок, в течение которого кэш действительно используется.
Тарифы и условия меняются. Для оценки бюджета используйте страницу цен и документацию на дату расчёта, а не сохранённый пример из старого теста. Экономия на одном запросе не равна экономии всей интеграции: важны частота повторов, доля обращений с совпадающим префиксом и стоимость поддержки кэша.
Почему кэш может не сработать
Проверьте длину общего участка и порог провайдера: короткий префикс может не подходить. Затем сравните точное содержимое и порядок частей запроса. Перемещённое сообщение, новая дата в начале системного текста или изменившееся описание инструмента способны нарушить совпадение раньше, чем кажется.
Учитывайте и нестабильные элементы приложения. Если каждый вызов добавляет случайный идентификатор, текущее время или меняющийся фрагмент перед большим справочным текстом, общий участок может оказаться короче ожидаемого. Практический вариант — разместить действительно постоянные инструкции и справочные данные раньше переменной части, если это согласуется с форматом API и требованиями безопасности.
Наконец, проверьте ограничения срока хранения и область действия кэша: они могут зависеть от провайдера и режима использования. Нельзя предполагать, что кэш сохраняется между любыми запросами или доступен всем ключам и регионам.
Что проверить перед включением в production
Сначала подтвердите работу механизма на безопасном тестовом контексте и убедитесь, что API возвращает понятные счётчики. Затем повторите измерение с репрезентативной длиной промпта и обычным профилем запросов приложения. Запишите модель, регион, конечную точку и дату проверки, чтобы сравнение оставалось воспроизводимым после обновлений.
Перед оптимизацией проверьте, не содержит ли общий контекст устаревающих инструкций или данных, которые не должны повторно использоваться без обновления. Сверьте тарифы, срок хранения, требования к приватности и логи использования. Если явного счётчика нет, попросите команду API уточнить, какие метрики доступны, — не выдавайте снижение задержки за доказательство кэширования.
Для регулярного контроля сохраните три сценария — повторный префикс, изменённый префикс и обычный запрос — как небольшой интеграционный тест. После смены модели или формата запроса сравните счётчики и стоимость заново: поведение кэша определяется документацией и фактическим ответом API, а не названием функции в коде.
