LLM-шлюз: маршрутизация, аутентификация и контроль затрат для AI-агентов

LLM-шлюз — это HTTP-обратный прокси, расположенный между процессами AI-агентов и вышестоящими эндпоинтами провайдеров моделей, который функционирует как уровень данных для всего исходящего инференс-трафика. Он разрешает непрозрачные дескрипторы ключей на уровне сети до пересылки, применяет квоты регулирования для каждого тенанта с помощью счётчиков скользящего окна, отправляет телеметрию затрат OpenTelemetry для каждого запроса и открывает автоматические выключатели, когда задержка P99 вышестоящего узла превышает заданные пороги — без каких-либо изменений в коде приложения агента. Любой флот с тремя или более одновременными потребителями инференса должен развернуть один такой шлюз.

LLM-шлюз — это HTTP-обратный прокси, находящийся в уровне данных между процессами AI-агентов и эндпоинтами провайдеров моделей, который предоставляет разрешение непрозрачных ключей на уровне сети, применение квот для каждого тенанта через счётчики скользящего окна, телеметрию затрат OpenTelemetry для каждого запроса и отказоустойчивость с автоматическими выключателями — все как примитивы инфраструктуры, невидимые для кода приложения.

Проблема уровня данных в мультиагентном инференсе

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

Эксфильтрация ключей через интроспекцию окружения

Каждый процесс агента, хранящий открытый ключ провайдера в своём окружении, находится в одной враждебной инструкции от его утечки. Поверхность атаки — это само окружение процесса: os.environ, /proc/self/environ на Linux-хостах, подробные обратные трассировки ошибок, сериализующие состояние процесса, и конфигурации журналов отладки, захватывающие исходящие HTTP-заголовки, включая поля Authorization.

Атаки с инъекцией подсказок, вынуждающие агентов отражать состояние окружения, — задокументированный класс атак против агентов с открытыми ключами (OWASP LLM01:2025). Структурное исправление — не улучшенная проверка ввода: это полное удаление открытого ключа из процесса агента. LLM-шлюз, разрешающий непрозрачные дескрипторы ($CRED{openai}) на уровне сети до записи заголовка Authorization, означает, что процесс агента никогда не хранит материал, который можно было бы эксфильтровать.

Сетка OpenLegion реализует это на уровне инфраструктуры: дескрипторы $CRED{} разрешаются на границе хоста сетки. Контейнеры агентов структурно неспособны получить доступ к разрешённому значению — не потому что им указано не делать этого, а потому что разрешение происходит вне их адресного пространства.

Исчерпание квоты через регулирование общих ключей

Вышестоящие провайдеры моделей регулируют на уровне ключа API. В флоте, где двадцать процессов агентов используют один ключ, единственный процесс, отправляющий запросы в 10 раз превышающие ожидаемую скорость — через бурю повторных попыток, неуправляемый цикл или полезную нагрузку инъекции подсказок, вызывающую неограниченные инференс-вызовы — может перевести ключ в зону ограничения скорости для остальных девятнадцати.

Шлюз применяет квоты для каждого тенанта с использованием счётчика скользящего окна, индексированного по идентификатору агента. Когда счётчик агента достигает настроенного предельного значения, шлюз отвечает HTTP 429 на уровне шлюза: никакой вышестоящий запрос не отправляется, никакая квота провайдера не расходуется, и агенты-сиблинги не затрагиваются.

Квота для каждого агента также является структурной мерой противодействия OWASP LLM10:2025 (Неограниченное потребление) — паттерну, при котором враждебные инструкции вынуждают агента генерировать неограниченные инференс-вызовы.

Отсутствие наблюдаемости вышестоящего узла

Без уровня данных инференса телеметрия для каждого запроса требует инструментирования внутри каждого процесса агента. Это одновременно избыточно и непоследовательно. Шлюз отправляет записи журнала OTLP OpenTelemetry для каждого запроса на уровне сети, захватывая: идентификатор агента, вышестоящий эндпоинт, имя модели, количество входных токенов, количество выходных токенов, токены попаданий в кэш, статус HTTP-ответа и продолжительность запроса.

Запись затрат для каждого запроса (входные_токены × цена_за_1k_входных + выходные_токены × цена_за_1k_выходных) накапливается в книге затрат для каждого агента. Эта книга поддерживает ежедневные и ежемесячные ограничения затрат, а также оповещения об аномалиях затрат.

Невидимая деградация вышестоящего узла

Эндпоинты провайдеров деградируют. Хвостовая задержка P99 на GPT-4o во время событий ограничения мощности может достигать 12 секунд (тест производительности инфраструктуры OpenLegion, июнь 2026). Без автоматического выключателя в уровне данных каждый агент флота поглощает эту деградацию при каждом запросе.

Шлюз с автоматическим выключателем отслеживает частоту ошибок и задержку P99 для каждого эндпоинта. При превышении настраиваемого порога сбоев — например, пяти последовательных ответов 5xx или P99 выше 8 секунд в течение 30-секундного окна — цепь открывается: последующие запросы немедленно направляются к настроенному резервному эндпоинту.

Тест производительности OpenLegion в июне 2026 измерил топологию GPT-4o (основной) → Claude 3.5 Sonnet (резервный): P99 снизился с 12 секунд до 3,1 секунды (в 3,9 раза) без каких-либо изменений в коде агента.

Архитектура шлюза: уровень данных vs. уровень управления

Уровень данных: применение для каждого запроса

Каждый инференс-запрос последовательно проходит через уровень данных:

1. Завершение TLS: процесс агента подключается к шлюзу через TLS. Для развёртываний mTLS агент также предоставляет сертификат. mTLS устраняет необходимость в токенах аутентификации для каждого запроса между агентом и шлюзом.

2. Разрешение удостоверения рабочей нагрузки: шлюз сопоставляет подключающуюся рабочую нагрузку с удостоверением тенанта. В развёртываниях mTLS встроенный в клиентский сертификат SPIFFE SVID несёт удостоверение рабочей нагрузки.

3. Разрешение непрозрачного дескриптора: шлюз проверяет исходящий заголовок Authorization на наличие шаблонов дескрипторов $CRED{}. Совпадающие дескрипторы разрешаются по резервному хранилищу секретов шлюза.

4. Проверка квоты: шлюз увеличивает счётчик скользящего окна тенанта и сравнивает его с настроенным пределом. Если счётчик превышает предел, шлюз возвращает 429 с заголовками Retry-After. Никакое вышестоящее соединение не открывается.

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

6. Вышестоящая отправка: шлюз открывает соединение из собственного пула к вышестоящему эндпоинту и передаёт ответ обратно.

7. Отправка телеметрии: по завершении ответа шлюз записывает журнальную запись OTLP в конвейер телеметрии.

Общие накладные расходы на горячем пути: 0,7–2,1 мс. На холодном пути (промах кэша): 2,6–6,6 мс. При задержке инференса провайдера 500 мс–30 с накладные расходы горячего пути составляют менее 0,5% от общего времени обмена.

Уровень управления: конфигурация и политика

Уровень управления регулирует поведение уровня данных. Ключевые обязанности:

Конфигурация удостоверения тенанта и квоты, Топология эндпоинтов, Область разрешения дескрипторов: какие удостоверения рабочих нагрузок могут разрешать какие дескрипторы. Тенант с областью openai:read может разрешить $CRED{openai}, но не $CRED{anthropic}. Это предотвращает горизонтальное перемещение между тенантами.

Политика аудита: какие поля отображаются в журнальных записях OTLP.

API уровня управления не должен быть доступен из сетей на стороне агентов. GHSA-53mr-6c8q-9789 (LiteLLM, CVE-2026-35029, исправлено в v1.83.0) показало, что происходит, когда путь записи конфигурации уровня управления доступен по сети без достаточной авторизации.

Топологии развёртывания

Централизованный вход

Один кластер шлюзов обрабатывает весь исходящий инференс-трафик флота агентов. Подходит для флотов до примерно 50 агентов, где приоритетом является операционная простота.

Паттерн sidecar

Каждый контейнер агента запускает процесс шлюза на своём интерфейсе обратной петли. Область сбоя — один контейнер агента. Подходит для больших флотов (50+ агентов), где приоритетом является изоляция сбоев для каждого агента.

Нативный прокси сетки

В OpenLegion прокси инференса является службой сетки. Нативная модель сетки обрабатывает удостоверение рабочей нагрузки нативно: каждый контейнер агента получает выданное сеткой удостоверение при создании.

Позиция OpenLegion

Набор функций LLM-шлюза — mTLS, применение квот скользящего окна, телеметрия затрат OTLP, отказоустойчивость с автоматическими выключателями — не является дополнительной инфраструктурой для мультиагентных флотов. Это минимально жизнеспособный уровень данных.

Три измерения из тестов инфраструктуры OpenLegion в июне 2026 года количественно определяют риски:

Хвостовая задержка P99 без переключения при сбое: 12 секунд на развёртываниях только с GPT-4o во время событий ограничения мощности провайдера. С Claude 3.5 Sonnet в качестве резервного варианта автоматического выключателя: 3,1 секунды. Улучшение в 3,9 раза не потребовало изменений в коде приложения агента.

Поверхность атаки эксфильтрации ключей: в флоте из 20 агентов, где все агенты хранят открытые ключи в своём окружении, один скомпрометированный через инъекцию подсказок агент (OWASP LLM01:2025) может эксфильтровать ключи для вышестоящих соединений каждого другого агента. В флоте, опосредованном шлюзом с разрешением непрозрачных дескрипторов, тот же скомпрометированный агент не хранит никакого материала для эксфильтрации.

Охват OWASP LLM: применение квот для каждого тенанта на шлюзе решает LLM10:2025 (Неограниченное потребление). Применение области дескрипторов решает LLM06:2025 (Избыточное полномочие).

Для команд, оценивающих паттерны управления учётными данными для AI-агентов, разрешение непрозрачных дескрипторов шлюза является реализацией на уровне развёртывания паттерна vault-прокси, описанного там.

Сравнение LLM-шлюзов

Возможность	Самостоятельный хостинг (LiteLLM)	OpenAI нативный	Прокси сетки OpenLegion
Модель разрешения ключей	Хранилище ключей на базе Postgres	Управляемый сервис	Непрозрачный дескриптор → vault на уровне сети
Удостоверение рабочей нагрузки mTLS	Не поддерживается	Не поддерживается	SPIFFE SVID для каждого контейнера агента
Применение квот	На основе конфигурации, для каждого ключа	Ограничения для каждой организации	Счётчик скользящего окна, для каждого тенанта
Отказоустойчивость с автоматическими выключателями	На основе плагинов	Недоступно	Нативное, с полуоткрытым зондом
Телеметрия затрат OTLP	Частичная	Не экспортируется	Для каждого запроса, все поля
Изоляция уровня управления	Вручную; открыто по умолчанию	Управляемый	Только частная подсеть сетки
История CVE (2024–2026)	GHSA-53mr-6c8q-9789 + другие	Публичных нет	Нет

Выбор шлюза для вашего флота

mTLS vs. аутентификация Bearer-токеном

mTLS (mutual TLS) аутентифицирует как клиента (агента), так и сервер (шлюз) на уровне TLS-рукопожатия до обмена каким-либо HTTP-содержимым. Клиентский сертификат несёт SPIFFE SVID — криптографически верифицируемое удостоверение рабочей нагрузки. В заголовках не передаётся Bearer-токен; нет необходимости выпускать, распространять или ротировать токены.

Для производственных мультиагентных флотов mTLS с выданными SPIFFE SVIDs является правильной моделью аутентификации. Это полностью устраняет поверхность управления токенами.

Счётчики квот скользящего окна vs. фиксированного окна

Счётчики фиксированного окна сбрасываются на границах часов. Агент может сделать всплеск, вдвое превышающий номинальную скорость, запрашивая на полной скорости в последние секунды одного окна и первые секунды следующего. Счётчики скользящего окна ведут непрерывный подсчёт в течение непрерывного временного интервала без используемых границ часов. Для инференс-рабочих нагрузок применение скользящего окна является правильной моделью.

Требования к детализации телеметрии

Записи OTLP для каждого запроса — это минимум для полезной наблюдаемости флота. Оцените, предоставляет ли шлюз эти поля в каждой записи: agent_id, model_id, input_tokens, output_tokens, cache_tokens, upstream_latency_ms, upstream_status. Шлюзы, агрегирующие телеметрию, не могут поддерживать обнаружение аномалий затрат для каждого агента или точную калибровку автоматических выключателей.

Начало работы

Часто задаваемые вопросы

Что такое LLM-шлюз?

LLM-шлюз — это HTTP-обратный прокси, находящийся в уровне данных между процессами AI-агентов и вышестоящими эндпоинтами провайдеров моделей. Он разрешает непрозрачные дескрипторы ключей на уровне сети (процессы агентов никогда не хранят открытые ключи), применяет ограничения квот скользящего окна для каждого тенанта до вышестоящей отправки, отправляет телеметрию затрат OpenTelemetry для каждого запроса и открывает автоматические выключатели, когда вышестоящие эндпоинты превышают настроенные пороги. Эти функции работают как примитивы инфраструктуры, не требующие изменений в коде приложения агента.

Нужен ли мне LLM-шлюз, если я использую только одного провайдера моделей?

Флоты с одним провайдером выигрывают от трёх функций шлюза: разрешения непрозрачных дескрипторов, применения квот для каждого тенанта и телеметрии затрат OTLP для каждого запроса. Накладные расходы горячего пути составляют 0,7–2,1 мс — пренебрежимо мало по сравнению с задержкой инференса провайдера от 500 мс до 30 секунд.

Как работает отказоустойчивость с автоматическими выключателями в LLM-шлюзе?

Шлюз отслеживает частоту ошибок и задержку P99 для каждого эндпоинта в скользящих окнах наблюдения. При превышении настраиваемого порога сбоев — например, пяти последовательных ответов 5xx или P99 выше 8 секунд в течение 30-секундного окна — цепь открывается: все последующие запросы немедленно перенаправляются к настроенному резервному эндпоинту. После периода охлаждения шлюз отправляет полуоткрытый зонд к основному. Успешный зонд закрывает цепь; неудачный зонд перезапускает таймер охлаждения. Тест производительности OpenLegion в июне 2026 измерил снижение P99 с 12 секунд до 3,1 секунды на топологии GPT-4o → Claude 3.5 Sonnet.

Что такое mTLS и почему это важно для LLM-шлюзов?

mTLS (mutual TLS) аутентифицирует как подключающийся процесс агента, так и шлюз на уровне TLS-рукопожатия до обмена какими-либо HTTP-данными. Агент предоставляет клиентский сертификат с SPIFFE SVID — криптографически верифицируемым удостоверением рабочей нагрузки. В HTTP-заголовках не передаётся Bearer-токен; нет необходимости выпускать, распространять или ротировать токены. Удостоверение рабочей нагрузки, полученное из SVID, управляет применением области дескрипторов: шлюз разрешает подключающейся рабочей нагрузке разрешать только непрозрачные дескрипторы в области её SPIFFE-удостоверения.

В чём разница между применением квот скользящего окна и фиксированного окна?

Счётчики фиксированного окна сбрасываются на границах часов. Агент может сделать всплеск, вдвое превышающий номинальную скорость, запрашивая на полной скорости в последние секунды одного окна и первые секунды следующего. Счётчики скользящего окна ведут непрерывный подсчёт без используемых границ часов. Для инференс-рабочих нагрузок применение скользящего окна является правильной моделью.

Чем телеметрия OTLP для каждого запроса отличается от агрегированной отчётности по затратам?

Записи OTLP OpenTelemetry для каждого запроса захватывают отдельные поля при каждом инференс-вызове: идентификатор агента, вариант модели, входные токены, выходные токены, токены попаданий в кэш, вышестоящую задержку и HTTP-статус. Эти записи накапливаются в книгах затрат для каждого агента, которые поддерживают ежедневные и ежемесячные ограничения бюджета, обнаружение аномалий затрат и сравнительный анализ затрат по разным моделям. Агрегированные отчёты не могут поддерживать обнаружение аномалий, поскольку сигнал находится в дисперсии для каждого запроса.

Что уровень управления шлюза не должен раскрывать сетям на стороне агентов?

Уровень управления управляет конфигурацией квот, топологией эндпоинтов, областями разрешения дескрипторов и политикой аудита. Он должен быть развёрнут в частной подсети без внешнего пути доступа. GHSA-53mr-6c8q-9789 (LiteLLM, CVE-2026-35029, исправлено в v1.83.0) задокументировало недостаточную авторизацию в API управления. Сети на стороне агентов должны получать доступ только к порту уровня данных шлюза.

Как калибровать пороги автоматических выключателей для флота?

Собирайте гистограммы задержки P50, P95 и P99 для каждого эндпоинта провайдера в течение двух-четырёх недель производственного трафика. Порог открытия автоматического выключателя должен быть установлен на значение P99, явно ухудшенном по сравнению с обычным SLA провайдера — обычно в 2–3 раза выше медианного P99. Период охлаждения до полуоткрытого зонда должен превышать типичное время восстановления провайдера — 30–60 секунд является разумной исходной точкой.