Промпт-кэширование: 6 фактов о том, как сэкономить на повторных запросах к LLM

Промпт-кэширование: 6 фактов о том, как сэкономить на повторных запросах к LLM

TL;DR. Промпт-кэширование — это механизм, при котором провайдер модели запоминает уже обработанную часть запроса и при следующем похожем обращении не считает её заново. Экономия появляется там, где вы снова и снова отправляете один и тот же большой блок: системную инструкцию, описание продукта, базу знаний, длинный документ. Кэш не «ускоряет всё подряд»: он помогает только при стабильном префиксе промпта и повторных запросах в коротком окне времени. Ниже — как это устроено, где ломается и как считать выгоду, не веря маркетинговым обещаниям на слово.

Материал подготовлен AI Digest (ai-digest.ru) на основе открытой документации провайдеров и практики эксплуатации LLM-приложений. Если вы только начинаете разбираться в теме, сначала посмотрите базовый разбор что такое LLM и как она работает — кэширование имеет смысл уже после того, как понятна сама механика токенов.

Что такое промпт-кэширование и почему оно появилось

Промпт-кэширование (prompt caching) — это переиспользование результатов обработки повторяющейся части запроса. Когда вы отправляете в модель большой текст, провайдер сначала токенизирует его, а затем прогоняет через внутренние слои внимания. Если следующий запрос начинается с того же самого блока, этот блок можно не пересчитывать: достаточно взять заранее посчитанное состояние.

Появилось это не из любви к оптимизации, а из экономики. Типичное корпоративное приложение отправляет в модель не вопрос пользователя, а вопрос плюс несколько тысяч токенов контекста: инструкции, схемы данных, фрагменты базы знаний, историю диалога. Такой «балласт» занимает 80–95% входного запроса, при этом почти не меняется от вызова к вызову. Платить за него полную цену каждый раз — самая заметная статья расходов в бюджете LLM-продукта.

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

Как работает кэш промптов: префикс, TTL и стоимость

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

Второй параметр — время жизни. У разных провайдеров кэш хранится от нескольких минут до часа и дольше; у части платформ продление жизни кэша оплачивается отдельно как хранение. Если между запросами проходит больше времени, чем живёт кэш, экономии не будет, даже если промпт идентичен.

Третий параметр — порог входа. У небольших промптов кэш просто не включается. В документации Gemini API, например, указан минимум в 2 048 токенов для моделей семейства 2.5 и 4 096 токенов для более новых моделей. То есть короткие запросы кэшировать бессмысленно — там нечего экономить.

Четвёртый момент — кто управляет кэшем. Есть два режима, и путаница между ними приводит к неверным ожиданиям.

Важная деталь: у некоторых платформ явное кэширование доступно не везде. В Gemini API, например, оно поддерживается через generateContent API на моделях 3.x и 2.5, но не в Interactions API и не для новых моделей линейки 4. Это значит, что архитектуру приложения стоит проверять до того, как вы пообещали заказчику экономию.

Сколько можно сэкономить на кэше

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

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

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

Отдельно про задержку. Даже без учёта денег кэш полезен в интерактивных сценариях: чат, автодополнение, агент, который делает десять шагов подряд. Здесь выигрыш во времени воспринимается пользователем как «стало быстрее работать», хотя модель та же.

Почему кэш не срабатывает: пять типичных причин

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

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

Третья — разрыв во времени. Кэш живёт ограниченно; при редких запросах он остывает между вызовами. Для фоновых задач «раз в час» экономия обычно нулевая.

Четвёртая — разные модели или разные параметры. Смена версии модели, температуры или системных настроек может привести к тому, что кэш не переиспользуется, даже если текст совпадает.

Пятая — сборка промпта «из кусков» в произвольном порядке. Если шаблонизатор подставляет блоки в зависимости от наличия полей, префикс меняется от запроса к запросу. Лечится фиксированным порядком секций и заглушками для пустых значений.

Как настроить кэширование промптов: пошаговый чек-лист

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

Дальше выстройте промпт в порядке «от стабильного к изменчивому»: роль и правила, справочные данные, история, текущий вопрос. Уберите из начала всё, что генерируется динамически. Затем проверьте, что шаблон не переставляет блоки местами.

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

Если в архитектуре есть шлюз между приложением и провайдерами, настройки кэша придётся согласовывать с ним: не все прокси и балансировщики аккуратно передают служебные поля. Про выбор такого слоя у нас есть отдельный разбор — 5 лучших AI-шлюзов для enterprise. А если задача — просто контролировать расход, посмотрите материал про MitM-прокси для LLM: там разобрано, как считать токены на уровне инфраструктуры.

Какие ограничения есть у промпт-кэширования

Кэш не отменяет главного правила: качество ответа зависит от того, что вы положили в контекст. Он не «запоминает» факты между разными задачами и не заменяет базу знаний или RAG. Это оптимизация доставки, а не памяти.

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

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

Частые вопросы

Что происходит с кэшем, если изменить один символ в промпте?

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

Как кэширование влияет на стоимость в месяц?

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

Можно ли включить кэш для коротких запросов?

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

Кэш заменяет дообучение модели?

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

Стоит ли включать явное кэширование сразу?

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

Итог. Промпт-кэширование — самый дешёвый способ снизить счёт за инференс без потери качества, но работает он только при дисциплине в сборке промпта. Начните с замера повторяющихся токенов, приведите порядок блоков к стабильному виду, включите логирование попаданий — и только потом считайте экономию. Если хотите разобраться, как это встроить в общую архитектуру работы с моделями, читайте материалы AI Digest по инфраструктуре и инференсу: там разобраны шлюзы, прокси и контроль расходов без магии.