Как решить проблему неэффективного кеширования LLM‑запросов в Cloudflare AI Gateway

Проблема кеширования в Cloudflare AI Gateway

Cloudflare AI Gateway предоставляет единый прокси‑слой для доступа к крупным языковым моделям (LLM) от OpenAI, Anthropic, Gemini и других провайдеров. Встроенные возможности — кеширование, ограничение запросов, автоматические повторные попытки и аналитика — позволяют значительно упростить интеграцию ИИ в продукты. Однако механизм кеширования работает только при полном совпадении входных запросов. Любое отклонение в структуре JSON‑payload, порядке полей или даже в пробелах приводит к пропуску кеша, что заставляет сервис каждый раз обращаться к провайдеру модели. При больших объёмах запросов такие «мелкие» различия быстро превращаются в миллионы лишних вызовов и, соответственно, в сотни‑тысячные расходы.

Почему точное совпадение запросов не работает

LLM‑приложения обычно формируют запросы динамически: в тело передаются пользовательский ввод, контекст диалога, метаданные о сессии, тайм‑стемпы и прочие служебные параметры. Для конечной модели существенны лишь смысловые части — сам запрос‑промпт и, в некоторых случаях, ограничение токенов. Остальные поля являются «шумом», меняющимся от вызова к вызову, но не влияющим на результат. При кешировании по точному хешу запроса такие поля делают каждый запрос уникальным, даже если смысловой запрос идентичен.

Cloudflare предоставляет заголовок cf-aig-cache-key, позволяющий задать собственный ключ кеша. Это решение работает только если приложение заранее знает, какие поля следует исключить, и гарантирует их одинаковую обработку во всех клиентских реализациях. На практике такой уровень согласованности трудно достичь: разные микросервисы, версии SDK и обновления фронтенда могут изменять структуру payload, создавая «пробелы» в логике формирования ключа.

Обход ограничения: кастомный ключ кеша

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

1. Детерминированное исключение служебных полей (тайм‑стемпы, идентификаторы сессий, пользовательские токены).
2. Нормализация текста промпта — приведение к единому регистру, удаление лишних пробелов и знаков препинания, сортировка параметров, если порядок не важен.
3. Классификация запросов по волатильности: некоторые запросы требуют свежих данных (например, запросы к актуальной статистике), другие могут быть полностью кешированы.
4. Обнаружение семантической эквивалентности — сравнение запросов с использованием хешей, построенных на основе векторных представлений или простых правил (например, игнорирование синонимов).

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

Создание собственного слоя семантической обработки

Для построения такого слоя использовалась полностью управляемая платформа Cloudflare Workers. Workers позволяют писать сервер‑less функции на JavaScript/TypeScript, которые исполняются на краевых узлах сети Cloudflare, обеспечивая микросекундные задержки и масштабируемость.

Основные компоненты решения:

• Парсер входящего JSON: извлекает поля prompt, messages, max_tokens и остальные параметры.
• Фильтр шума: удаляет известные служебные атрибуты (request_id, timestamp, user_id). Список полей хранится в KV‑хранилище Workers KV, что упрощает обновление без деплоя.
• Нормализатор текста: приводит промпт к нижнему регистру, убирает повторяющиеся пробелы, сортирует массив сообщений по времени создания (если порядок не критичен).
• Генератор кеш‑ключа: собирает отфильтрованные и нормализованные данные в строку, вычисляет SHA‑256 хеш и записывает его в заголовок cf-aig-cache-key.
• Классификатор волатильности: простая таблица, сопоставляющая конечные точки (например, /weather, /stock) с политикой «fresh»/«stale». При «fresh» запросы обходятся кеша.

Эти шаги реализованы в едином Worker‑скрипте, который размещается перед AI Gateway в цепочке запросов. В случае ошибки парсинга запрос передаётся дальше без изменения кеш‑ключа, чтобы не нарушить работоспособность системы.

Архитектура решения на платформе Cloudflare

Client → Cloudflare Edge (Worker) → AI Gateway → LLM Provider

1. Клиент отправляет запрос к публичному endpoint.
2. Worker на краевом узле получает запрос, выполняет очистку и генерирует кеш‑ключ.
3. AI Gateway получает уже подготовленный запрос с кастомным cf-aig-cache-key. Если такой ключ уже находится в кеш‑хранилище, ответ возвращается мгновенно, без обращения к провайдеру.
4. LLM Provider обрабатывает запрос только в случае кеш‑промаха.

Все компоненты работают в пределах нескольких миллисекунд, что сохраняет общую латентность в пределах 100–150 мс, даже при наличии дополнительного слоя.

Результаты и экономический эффект

Тестирование в production‑окружении показало:

• Сокращение количества запросов к LLM на 68 % при типичном потоке поддержки клиентов, где 70 % запросов повторяются в разных сессиях.
• Экономия расходов: при среднем тарифе $0,0005 за токен и среднем объёме 150 токенов на запрос, ежемесячные затраты снизились с $12 000 до $3 800.
• Уменьшение латентности: ответы из кеша доставляются в среднем за 30 мс, что ускорило пользовательский опыт.
• Устойчивость к всплескам: в часы пик количество запросов в кеш не превышало 5 % от общего объёма, что позволило избежать ограничения rate‑limit провайдера.

Эти цифры подтверждают, что правильная семантическая обработка запросов может стать ключевым фактором оптимизации расходов на LLM‑сервисы.

Практические рекомендации

• Внедрять слой очистки на краевых узлах: Workers и аналогичные serverless‑платформы позволяют обрабатывать запросы до их попадания в кеш.
• Поддерживать актуальный список шумовых полей: использовать KV‑хранилище или конфигурационный файл, чтобы быстро адаптироваться к изменениям API‑клиентов.
• Тестировать классификатор волатильности: начать с простых правил, а затем добавить более сложные модели (например, машинное обучение) для определения «свежести» запроса.
• Мониторить эффективность кеша: собирать метрики hit‑rate и cost‑savings, чтобы своевременно корректировать правила нормализации.
• Обеспечить обратную совместимость: при изменении логики очистки сохранять возможность отключения нового слоя, чтобы не нарушить работающие интеграции.

Внедрение собственного семантического кеш‑слоя на базе Cloudflare Workers превращает ограниченный механизм точного совпадения в гибкую систему, способную существенно снизить затраты и улучшить производительность LLM‑приложений.