# Prompt caching в OpenRouter: почему скидку нужно проверять по usage

Как проверить prompt caching в OpenRouter: повторяющийся префикс, фактический провайдер, usage, стоимость записи и чтения кеша, а также влияние резервных маршрутов.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-cache-cost/
Language: ru

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

В этом материале речь идёт о кешировании входного контекста, а не о выдаче полностью сохранённого ответа. Эти механизмы не следует объединять в одном расчёте.

## Определите повторяемую часть

[OpenRouter Prompt Caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching) описывает различия между провайдерами. Одни сценарии используют автоматическое кеширование, другие требуют явной разметки. Перед настройкой проверьте документацию конкретного исполнителя и поддерживаемый формат запроса.

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

## Сохраните контрольный и повторный вызов

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

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

## Различайте показатели

| Наблюдение | Какой вывод допустим |
| --- | --- |
| Ответ стал быстрее | Изменилась задержка; причина ещё не доказана |
| Usage содержит данные о cached input | Есть основание изучить учтённый кеш |
| Снизилась полная стоимость сопоставимой задачи | Подтверждена экономия в условиях теста |
| Сменился провайдер | Предыдущий кеш нельзя считать автоматически доступным новой цели |

При интерпретации смотрите единицы и формат полей выбранного API. Не применяйте названия из одного провайдера к другому без проверки соответствия.

## Учтите маршрутизацию

[Provider Routing](https://openrouter.ai/docs/guides/routing/provider-selection) описывает выбор исполнителя и приоритеты запроса. Настройки маршрута могут влиять на то, где обрабатывается повторный контекст. Поэтому конфигурацию выбора провайдера необходимо сохранять вместе с результатами кеш-теста.

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

## Посчитайте весь цикл

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

Для оператора GPU кеширование также меняет профиль нагрузки: сокращение повторной работы не равнозначно росту выручки. Полезнее измерить освобождённую ёмкость и возможность обслужить другие задачи. Дальше читайте про [prefix caching на GPU](/ru/journal/prefix-caching/) и [учёт запроса OpenRouter](/ru/journal/openrouter-usage-accounting/).