В RAG-сервисах дорогой частью нередко оказывается не поиск по векторной базе, а повторная отправка одних и тех же 10 тысяч токенов контекста в модель. Кеширование промптов, как пишет The New Stack, позволяет срезать стоимость контекстных токенов до 80% и одновременно уменьшить время до первого токена до миллисекунд. Для русскоязычных команд, которые уже строят внутренние AI-поисковики, ассистентов поддержки и корпоративные knowledge base, это звучит не как красивая оптимизация, а как попытка удержать юнит-экономику от распада.
Материал The New Stack вышел 23 июля 2026 года под заголовком Can prompt caching tame RAG costs without sacrificing accuracy?. Его автор Эммануэль Акита разбирает три типовых поломки production-RAG: синхронную загрузку документов, слабую изоляцию арендаторов в B2B-среде и слишком дорогой inference. Главная мысль простая: собрать демо за пять минут можно, но как только в систему прилетает не аккуратный PDF на десять страниц, а, скажем, 500-страничный compliance manual, архитектура начинает вести себя как учебный стенд, случайно попавший в прод.
Первый узкий участок, по версии автора, появляется уже на этапе ingestion. Наивная схема выглядит знакомо: пользователь загружает документ, сервер парсит текст, режет его на чанки, последовательно дергает API для эмбеддингов и пишет результат в базу. На локальной машине или в бете с дружелюбными пользователями это еще может жить. В реальном B2B-сценарии такой конвейер упирается в таймауты: обработка 500-страничного документа редко укладывается в стандартные 30-60 секунд HTTP-запроса. Следом приходят каскадные сбои: задержка или rate limit у провайдера эмбеддингов превращает весь процесс в ошибку 500, а документ пользователя просто теряется по дороге. Рецепт, который предлагает Акита, менее гламурный, зато рабочий: сырой файл складывается в Amazon S3, API сразу отвечает статусом 202 Accepted, а дальше запускается асинхронная обработка через события и очередь.
Но и здесь, как обычно, дьявол сидит не в слайде, а в деталях. Отправить весь документ одним сообщением в Kafka или RabbitMQ тоже плохая идея: если consumer десять минут непрерывно считает эмбеддинги, брокер решит, что воркер умер, прервет его и начнет ребалансировку. Результат предсказуемый: дублированная работа, остановившийся пайплайн и много инженерного смеха сквозь зубы. Противоположная крайность не лучше. Если превратить каждый чанк в отдельное сообщение, то документ на 1500 чанков создает 1500 событий и по сути запускает самодельную DoS-атаку на downstream-сервисы. Поэтому автор предлагает промежуточный вариант: micro-batching, где документ сначала режется на фрагменты, а затем собирается в небольшие пачки, например по 64 чанка. Дальше embedding workers берут именно эти батчи, а контроль частоты запросов обеспечивается не хрупким sleep(), а token bucket rate limiter или жестким ограничением числа активных партиций.
Вторая проблема касается multi-tenancy, и здесь у многих корпоративных RAG-систем начинается совсем неприятная часть. Распространенный подход хранить все в одном большом индексе и просто помечать векторы через tenant_id выглядит экономно, пока кто-то однажды не забудет фильтр в приложении. Тогда один клиент получает доступ к данным другого, а юридический отдел внезапно становится главным стейкхолдером AI-проекта. Даже если утечки нет, остается проблема noisy neighbor: один крупный заказчик загружает 10 миллионов векторов, и производительность поиска проседает уже у всех соседей по индексу. Автор называет выделенный кластер на каждого клиента слишком дорогим и сложно управляемым вариантом. Вместо этого он советует серверлесс-подход с разделением compute и storage, приводя в пример Pinecone Serverless и managed-реализации Qdrant. В такой схеме данные изолируются по namespace, вычислительные ресурсы поднимаются по запросу, а idle compute не съедает бюджет, пока пользователь спит или согласовывает следующий контракт.
Третий и самый дорогой узел в цепочке связан уже не с ingestion, а с инференсом. Когда асинхронная загрузка заработала, а арендаторы изолированы, каждая пользовательская реплика все равно может дорого обходиться, если на каждый запрос заново отправлять в модель огромный контекст. Индустрия пыталась лечить это семантическим кэшем: запрос пользователя переводится в embedding, затем сравнивается по cosine similarity с предыдущими запросами, и если сходство, например, выше 0,95, система возвращает уже готовый ответ. На бумаге красиво, на практике нет. Пример из статьи показательный: «Какой была политика отпусков в 2023 году?» и «Какая политика отпусков действует в 2024 году?» семантически очень близки, но фактически это разные вопросы. Если подставить кэшированный ответ не туда, получится аккуратная и уверенная ложь, а именно такие ложные срабатывания бизнес особенно не любит.
Отсюда и главный вывод материала: если уж строить кеширование промптов в production, то есть два пути. Первый, более прикладной, это обложить семантический кэш дешевыми проверками: отбрасывать совпадения по лексическим маркерам вроде годов, сумм, артикулов и прогонять пару запросов через легкую intent-модель, которая отвечает простым yes/no, действительно ли им нужен один и тот же фактический ответ. Второй путь, который автор считает более аккуратным инфраструктурно, это нативное кеширование промптов на стороне провайдера LLM. Здесь кэшируется не короткий вопрос пользователя, а тяжелый повторяющийся блок: системные инструкции и извлеченный RAG-контекст, который легко переваливает за 10 тысяч токенов. Приложение все равно отправляет полный запрос целиком, но провайдер распознает повторяющийся контекст, снижает цену на эти токены до 80% и сокращает TTFT до миллисекунд. То есть экономия появляется не за счет рискованной подмены ответа, а за счет повторного использования уже обработанной подложки.
Для российских и русскоязычных команд вывод у этой истории довольно приземленный. Если ваш RAG-проект пока живет в ноутбуке, то почти любая схема кажется приемлемой. Если же речь идет о SaaS, внутреннем корпоративном поиске, документации, поддержке или HR-сценариях с чувствительными данными, без дисциплины распределенных систем все быстро превращается в дорогую импровизацию. Кеширование промптов здесь не серебряная пуля, а один из элементов взросления стека вместе с асинхронной загрузкой, микробатчингом и жесткой изоляцией арендаторов. Открытый вопрос теперь не в том, нужен ли RAG кэш, а в том, готовы ли команды перестать воспринимать LLM как магический черный ящик и начать проектировать такие системы так же скучно, строго и надежно, как любой другой критичный backend.
