До 40% вызовов LLM в проектах могут оказаться повторными, а счета за модели при этом растут на 20-30% месяц к месяцу. На этом фоне AI Gateway из красивой архитектурной схемы быстро превращается в обязательный слой для тех, кто встраивает генеративный ИИ в микросервисы и не хочет однажды разбирать, кто именно сжег бюджет на токены и почему прод начал ждать ответ модели по три секунды.
Об этом сообщает Habr / Карьера в статье Сергея Прощаева, Tech Lead и руководителя направления Java/Kotlin-разработки в FinTech и e-commerce, который описывает типовой сценарий 2026 года: команда разрешает сервисам напрямую обращаться к внешним LLM, быстро выкатывает AI-фичи, а затем получает хаос вместо ускорения. В материале автор разбирает, как AI Gateway должен закрывать маршрутизацию между моделями, кеширование, лимиты, мониторинг, безопасность и устойчивость к сбоям.
Где ломается схема «каждый сервис сам дергает LLM»
Стартовые условия в статье вполне приземленные и потому узнаваемые: Kubernetes-кластер версии 1.28+, несколько Java- и Kotlin-сервисов на Spring Boot, привычный REST и, возможно, уже существующий API Gateway. Снаружи доступны две-три модели, например OpenAI GPT-4 для сложных задач и локальная Llama 3 для быстрых и дешевых ответов. Нагрузка пока не выглядит пугающей: до 1000 запросов в час с пиками, команда 5-10 человек, централизованного управления AI-вызовами нет. Но даже в таком масштабе, пишет автор, прямые синхронные обращения к моделям быстро становятся источником проблем: никто не считает токены, никто не ограничивает rate limit, никто не отслеживает повторяемость запросов, а бизнес уже видит рост расходов без понятной причины.
Прощаев приводит несколько характерных примеров. В одном случае после месяца экспериментов счет от OpenAI дошел до 15 тысяч долларов, и команда не могла объяснить, какой сервис сгенерировал такую нагрузку. В другом один из сервисов начал ждать ответ LLM около трех секунд, из-за чего посыпалась вся продовая цепочка. Еще один кейс автор описывает как стартап, потративший 50 тысяч долларов за месяц без кеширования, потому что каждый запрос уходил в GPT-4. Это не статистика по всему рынку, а иллюстрация того, как быстро LLM из «еще одной API-интеграции» превращаются в отдельный инфраструктурный контур со своими счетчиками, SLA и точками отказа.
На этом фоне AI Gateway в статье определяется как выделенный слой между внутренними сервисами и AI-провайдерами. Его можно реализовать по-разному: отдельным микросервисом, плагином к существующему API Gateway вроде Kong или APISIX, sidecar-компонентом в service mesh или inference proxy. Для примеров выбран Spring Cloud Gateway, что логично для Java/Kotlin-стека: реактивная модель, понятная конфигурация, встроенные механизмы для фильтров и лимитов. Но сам паттерн не завязан на один продукт. Идея в другом: сервисы перестают выбирать модель напрямую и начинают обращаться в единый OpenAI-compatible контракт, а уже шлюз решает, куда отправить запрос с учетом стоимости, SLA, доступности модели и политики компании.
Что именно должен делать AI Gateway
Первый уровень пользы от AI Gateway - маршрутизация. В демонстрационном примере модель выбирается по заголовку: запросы с model-type: premium идут во внешний OpenAI-эндпоинт, а model-type: economy - на локальную Llama. Автор отдельно оговаривает, что в реальном продакшене так делать не стоит: решение о выборе модели должен принимать policy engine внутри шлюза, а не клиентский сервис. Это важный сдвиг. Когда один сервис шлет данные в GPT-4, другой - в локальную модель, а третий решает все через костыли в коде, компания теряет не только контроль над расходами, но и возможность быстро поменять поставщика, перераспределить нагрузку или временно отключить дорогой маршрут.
Второй слой - кеширование, и здесь статья бьет в самую больную точку AI-интеграций. Для точных совпадений запросов достаточно Redis, но основной выигрыш, по мнению автора, дает семантический кеш. Смысл в том, что система хранит не только текст промпта, но и его embedding, а затем ищет близкие по смыслу запросы. В примере фразы про прогноз погоды в Москве на завтра могут считаться эквивалентными, даже если сформулированы по-разному. При этом автор подчеркивает ограничения: в production нельзя строить семантический кеш только на косинусной близости. В ключ должны входить tenant или user scope, версия модели, хеш system prompt и доменный контекст. Иначе можно получить очень неприятный эффект: быстрый ответ из кеша, который формально подходит по смыслу, но относится к другому пользователю, другой версии подсказки или устаревшей модели.
Здесь же появляются конкретные ориентиры, полезные инженерам. Порог срабатывания семантического кеша предлагается настраивать в районе 0,8-0,9 под предметную область. Записи должны жить с TTL и инвалидироваться при смене embedding-модели или версии system prompt. Проверка эффективности предельно практичная: первый запрос уходит в LLM и отвечает, условно, за 500 мс, второй такой же должен вернуться из кеша за 10-30 мс внутри одного региона. Для точного контроля автор предлагает добавлять заголовок X-Cache: HIT. На фоне разговоров о больших AI-стратегиях это почти приземленное удовольствие: сначала вы перестаете повторно платить за одни и те же вопросы, а уже потом рассуждаете о трансформации бизнеса.
Третий набор задач, который AI Gateway берет на себя, касается денег, наблюдаемости и надежности. В статье перечислены cost control, лимиты на сервис, пользователя и сутки, rate limiting по запросам и токенам, мониторинг задержек и качества, а также resilience-паттерны вроде circuit breaker, retry policies, bulkhead и защиты от retry storm. Для микросервисной архитектуры это особенно важно, потому что LLM - не просто внешний API, а медленный и дорогой внешний API с непредсказуемой латентностью. Если несколько внутренних сервисов начинают ретраить ошибки модели без координации, компания получает не отказоустойчивость, а ускоренное самоуничтожение за собственный счет. Отдельно автор выносит безопасность: фильтрацию prompt injection, маскирование PII и аудит запросов. И это уже вопрос не только архитектурной гигиены, но и комплаенса, особенно если через модели проходят клиентские данные.
Для русскоязычной IT-аудитории главный вывод довольно приземленный. Пока AI-функции живут в режиме proof of concept, прямой вызов модели из сервиса действительно кажется быстрым и дешевым. Но как только LLM становятся частью продовой цепочки, они требуют того же инженерного отношения, что и база данных, шина сообщений или API-шлюз. Нужны контракт, лимиты, наблюдаемость, изоляция и правила деградации. Иначе бизнес получает не AI-ускорение, а новый класс инцидентов, которые еще и тарифицируются по токенам.
Следующий этап для команд, похоже, будет не в выборе «какую модель подключить», а в решении, кто внутри компании владеет AI-инфраструктурой как платформой. Если такого владельца не появится, AI Gateway все равно придется строить, только уже после первого неприятного счета или первой ночи, когда весь стек стоит в очереди к слишком умной, слишком дорогой и слишком медленной модели.