Как мы заставили Redis кэшировать POST-запросы к OpenAI/DeepSeek и выжали 4900 RPS на Java 21
В 2026 году интеграция LLM-моделей (OpenAI, DeepSeek) и тяжелой гео-инфраструктуры (Google Maps, Яндекс.Карты , DaData) есть практически в каждом Enterprise-продукте. И всё бы хорошо, но счета за токены и лимиты API растут нелинейно. Когда наш проект столкнулся с тем, что корпоративный чат-бот и аналитические модули начали «проедать» шестизначные суммы в месяц, мы сели анализировать логи. Выяснилась классическая вещь: до 40% запросов от пользователей или внутренних сервисов — это чистой воды дубли. Люди по десять раз переспрашивают у модели схожие аналитические промты, а фронтенд-модули тоннами гоняют идентичные запросы к гео-кодерам. Первая мысль — давайте закроемся кэшем. Но тут мы упёрлись в архитектурный тупик. Почему Nginx и классические прокси здесь не помощники Обычно для кэширования трафика берут Nginx, Varnish или HAProxy. Но все они создавались для классического веба, где правит бал GET -запрос, а уникальным ключом кэширования выступает URL. Современные ИИ-модели и гео-сервисы работают строго через POST . Внутри тела ( payload ) лежит тяжелый JSON. И этот JSON постоянно мутирует:
https://habr.com/ru/articles/1096954/
#java #высокая_производительность #cache #spring_framework #облачные_сервисы