В этом материале
Кеширование префикса нужно подтверждать по данным исполнения. Похожий запрос, быстрый ответ и одинаковое имя модели сами по себе не доказывают попадание в кеш или экономию.
Prompt caching в OpenRouter может уменьшать повторную обработку поддерживаемого префикса запроса, но экономию нужно проверять по фактическому использованию и начислениям. Похожесть двух сообщений и снижение задержки сами по себе не доказывают кеширование. Правила зависят от выбранной модели и исполнителя.
В этом материале речь идёт о кешировании входного контекста, а не о выдаче полностью сохранённого ответа. Эти механизмы не следует объединять в одном расчёте.
Определите повторяемую часть
OpenRouter Prompt Caching описывает различия между провайдерами. Одни сценарии используют автоматическое кеширование, другие требуют явной разметки. Перед настройкой проверьте документацию конкретного исполнителя и поддерживаемый формат запроса.
Условный помощник получает одну и ту же большую инструкцию, а затем разные короткие вопросы. Кандидат на повторное использование — общая начальная часть. Если приложение каждый раз добавляет туда текущее время или случайный идентификатор, фактическое совпадение может измениться ещё до пользовательского вопроса.
Сохраните контрольный и повторный вызов
Подготовьте нейтральный тестовый контекст. Выполните первый запрос, затем повтор с неизменной общей частью и контролируемым отличием задачи. Запишите модель, фактический маршрут, размер входа, сведения usage, время и стоимость.
Не меняйте одновременно длину ответа, модель и исполнителя. Иначе сравнение смешает эффект кеша с другими причинами. Отдельно выполните проверку после периода ожидания: условия сохранения контекста могут влиять на повторяемость результата.
Различайте показатели
| Наблюдение | Какой вывод допустим |
|---|---|
| Ответ стал быстрее | Изменилась задержка; причина ещё не доказана |
| Usage содержит данные о cached input | Есть основание изучить учтённый кеш |
| Снизилась полная стоимость сопоставимой задачи | Подтверждена экономия в условиях теста |
| Сменился провайдер | Предыдущий кеш нельзя считать автоматически доступным новой цели |
При интерпретации смотрите единицы и формат полей выбранного API. Не применяйте названия из одного провайдера к другому без проверки соответствия.
Учтите маршрутизацию
Provider Routing описывает выбор исполнителя и приоритеты запроса. Настройки маршрута могут влиять на то, где обрабатывается повторный контекст. Поэтому конфигурацию выбора провайдера необходимо сохранять вместе с результатами кеш-теста.
Если основной маршрут недоступен, резерв может вернуть правильный ответ с другой структурой расходов. Это нормальный предмет измерения: приложение сохранило функцию, но предполагаемая экономия могла измениться. В отчёте не нужно скрывать такой случай ради красивого среднего значения.
Посчитайте весь цикл
Сравните подготовку кеша, повторные обращения и работу после смены маршрута. Если применимы разные ставки записи и чтения, учитывайте их отдельно. Смета должна относиться к ожидаемому числу повторов, а не к одному удачно дешёвому запросу.
Для оператора GPU кеширование также меняет профиль нагрузки: сокращение повторной работы не равнозначно росту выручки. Полезнее измерить освобождённую ёмкость и возможность обслужить другие задачи. Дальше читайте про prefix caching на GPU и учёт запроса OpenRouter.