LLM-прокси и AI Gateway: архитектура, контроль и компромиссы

LLM-прокси и AI gateway могут находиться в одной точке между приложением и поставщиками моделей, но отвечать за разные задачи. Прокси прежде всего передаёт запросы и ответы. AI gateway обычно добавляет управление с учётом модели: маршрутизацию, fallback, учёт использования, распределение стоимости и правила доступа для отдельных workloads.

Эти названия не являются стандартами. Одни продукты называют «proxy» полноценный слой управления моделями, другие используют слово «gateway» для обычного управляемого endpoint. Поэтому сравнивать нужно проверяемые обязанности, а не маркетинговые категории.

Сначала обязанности, затем название продукта

Оба слоя обычно занимают одинаковое место в сети:

Приложение или coding agent
        ↓
LLM-прокси или AI gateway
        ↓
Поставщик и выбранная модель

Эта схема не показывает реальное поведение промежуточного слоя. Для оценки полезнее матрица ответственности.

Обязанность	LLM-прокси для транспорта	AI gateway с учётом модели
Завершение TLS и передача HTTP	Обычно	Обычно
Обработка upstream URL и Headers	Обычно	Обычно
Передача streaming-ответа	Часто	Как правило, но контракт событий нужно проверять
Изоляция credentials поставщика	Иногда	Обычно, но границы хранения и доступа требуют проверки
Интерфейс OpenAI-compatible	Иногда	Обычно, с различиями по моделям и функциям
Маршрутизация по модели или поставщику	Ограничена или принадлежит приложению	Обычно
Retry и упорядоченный fallback	Не более базового upstream retry	Часто учитывает модель и тип ошибки
Rate или quota для workload	Обычно вне прокси	Обычно
Учёт Token, использования и стоимости	Обычно внешний	Обычно
Диагностика задержки по запросу	Обычно внешняя	Обычно
Политики и аудит	Обычно внешние	Зависит от продукта

«Обычно» не означает гарантированно. Для каждого важного пункта необходимо проверить точный контракт запроса, поведение при сбое, создаваемые записи и доступные оператору средства управления.

Что обычно делает LLM-прокси

Прокси транспортного уровня может быть достаточен, если основная цель — предоставить стабильный endpoint перед upstream API. Он централизует TLS, hostname, выбранные Headers, ограничения размера, timeout и базовые logs. Специализированный LLM-прокси также может понимать Server-Sent Events и передавать streaming без буферизации полного ответа.

Такой слой создаёт контролируемый сетевой путь и позволяет убрать ключи поставщика из части клиентских сред. Это также удобная точка для обычной аутентификации и сетевых правил.

Граница меняется, когда прокси переводит форматы запросов, выбирает поставщика, считает модельные Tokens или стоимость. Это уже модельно-зависимые решения. Такой продукт следует оценивать как gateway, даже если в названии остаётся слово «proxy».

Простой прокси хорошо подходит, когда:

• одно приложение использует одного поставщика и небольшой фиксированный набор моделей;
• retry, учёт использования и диагностика инцидентов уже реализованы приложением;
• нативные функции поставщика должны проходить без преобразования;
• не нужны отдельные политики маршрутизации для команд или workloads;
• требуется минимальный дополнительный операционный слой.

Что добавляет AI gateway

AI gateway рассматривает вызов модели не просто как HTTP-трафик. При выборе маршрута он может учитывать запрошенную модель, протокол, политику Key, доступность групп, лимиты и результаты предыдущих попыток. Затем финальная попытка связывается с Tokens, временем, статусом и стоимостью.

Набор функций различается. Документация Cloudflare AI Gateway описывает analytics, logging, cache, rate limiting, retries и fallback. Документация Kong по метрикам AI Gateway включает метрики моделей, Token, стоимости, cache, задержки и ошибок. Это характерные примеры, но не универсальный стандарт.

Gateway особенно полезен, когда одновременно присутствуют несколько требований:

• нескольким приложениям или agents нужны отдельно учитываемые API Keys;
• одну и ту же запрошенную модель могут обслуживать несколько допустимых маршрутов;
• лимиты должны срабатывать до upstream-работы и расходов;
• нужно разделять аутентификацию, маршрутизацию, ожидание upstream, первый полезный результат и генерацию;
• каждое списание должно объясняться на уровне запроса;
• основной маршрут требует явной и упорядоченной политики fallback;
• несколькими группами моделей нужно управлять из единого операционного представления.

Gateway не делает всех поставщиков взаимозаменяемыми. Он также не заменяет проверку результата, идемпотентность Tools, защиту secrets в приложении и тесты provider-specific функций.

Матрица выбора по workload

Workload	Главное требование	Разумная начальная схема	Причина
Внутренний сервис с одним поставщиком и моделью	Стабильный сетевой путь	Прямой API или небольшой proxy	Сложная политика может не давать текущей ценности
Клиентское приложение с несколькими маршрутами для одной модели	Доступность и данные о попытках	AI gateway	Маршрутизация, ограниченный fallback и диагностика требуют одного владельца
Coding agents для команды	Keys, quota, распределение использования и offboarding	AI gateway	Общий credential и нераспределённые расходы создают операционный риск
Приложение с новой нативной функцией поставщика	Точный Wire Contract	Сначала native endpoint, затем проверенный слой	Нормализованный API может запаздывать или терять новые поля
Batch-процесс со своей Queue и retry	Производительность и восстановление приложением	Proxy/gateway с отключёнными или ограниченными retries	Несколько уровней retry усиливают сбои и дублируют работу
Регулируемый или чувствительный workload	Доказательства пути данных, хранения и доступа	По подтверждённым контролям	Название «gateway» не подтверждает безопасность или compliance

Решение может меняться по мере роста workload. Начать с одного поставщика и позже добавить gateway разумно, если клиент моделей скрыт за чётким внутренним интерфейсом, а контракт миграции тестируется.

Учитывайте скрытые компромиссы

Дополнительный hop необходимо измерять

Proxy или gateway добавляет сетевой и вычислительный слой. Среднего значения задержки недостаточно: измеряйте время до upstream Headers, первого эффективного ответа, первого видимого текста, полную длительность и скорость вывода при реальной конкуренции. Небольшой постоянный overhead может окупаться более быстрым восстановлением, но это зависит от workload.

Совместимость зависит от функции

«OpenAI-compatible» может означать только Base URL, Header аутентификации и базовый запрос Chat Completions. Responses Events, Structured Outputs, Tool Calls, usage-поля и формы ошибок могут отличаться. Проверяйте каждую реально используемую функцию. Руководство по OpenAI-Compatible API даёт базу миграции, а Responses API и Chat Completions объясняет, почему endpoint сам по себе ничего не гарантирует.

Централизация создаёт домен отказа

Централизация Keys, маршрутов, лимитов и logs упрощает владение, но делает этот слой критическим. Проверьте versioning и rollback конфигурации, поведение при недоступности control plane и завершение текущих запросов во время изменений.

Стоимости нужен Source of Truth

Gateway может использовать публичные тарифы, настроенные цены, множители групп или версионированные Billing Expressions. Нужно знать, когда цена выбирается и фиксируется, как учитываются Cached Tokens и Tools и можно ли сопоставить итоговое списание с фактическим использованием. См. AI API Cost Tracking.

Важна стоимость выхода

До перехода на нормализованный интерфейс найдите зависимости от специальных Headers, model aliases, route names и log APIs. Слой должен упрощать эксплуатацию, но сохранять путь обратно к нативному протоколу.

Три практических примера

Внутренний ассистент с одним поставщиком

Внутренний ассистент отправляет non-streaming запросы фиксированной модели. Приложение хранит свои Job IDs и server-side ключ. Обычного прокси может быть достаточно: multi-provider routing пока не решает реальную проблему. Внутренний интерфейс клиента моделей сохранит возможность добавить gateway позднее.

Production-приложение с несколькими маршрутами

Если та же модель должна оставаться доступной при насыщении одного upstream-аккаунта и нужно понимать, какой маршрут создал расходы, подходит gateway. Fallback, billing и диагностика должны использовать одну Request ID. Замена модели меняет качество, задержку, Tools и цену, поэтому она должна быть явной политикой. См. руководство по надёжной маршрутизации AI API.

Coding agents в инженерной команде

Agents создают длинные сессии с Tools на множестве устройств. Один общий ключ усложняет quota, распределение, rotation и offboarding. Gateway может выдавать Keys по workload и связывать использование с проектами. Права repository, sandbox, подтверждение инструментов и проверка кода остаются за пределами маршрутизации.

Место Modelflare

Modelflare предназначен для AI-aware доступа и маршрутизации, а не только для прозрачного HTTP relay. Обычный API Key может выбрать основную группу моделей и упорядоченные fallback-группы. Smart API Key оценивает доступные группы по заданной стратегии. В обоих случаях система ищет маршрут для запрошенной модели и не должна незаметно подменять её другой.

Group RPM применяется к конкретной выбранной группе до billing и upstream-работы. Если группа заполнена, можно рассмотреть следующую допустимую; если маршрутов не осталось, возвращается 429. Usage Logs связывают статус, Tokens, стоимость и timing и разделяют аутентификацию, выбор группы, upstream Headers, первое событие, первый эффективный ответ, первый видимый текст и общую длительность.

Есть важная граница совместимости: трафик GPT, Codex и OpenAI является полностью адаптируемой целью. Другие семейства OpenAI-compatible следует считать Chat Completions pass-through, пока дополнительные функции не проверены. Общий Base URL не гарантирует одинаковый контракт Responses, Tools или Structured Outputs.

Актуальные модели и группы доступны в разделе Models & Pricing, настройка клиентов — в документации Modelflare.

Checklist для production

• Протокол: сохраняются ли используемые формы Request и Response?
• Streaming: передаются ли Events и Tool Arguments без буферизации, потерь и перестановки?
• Model identity: сохраняется ли запрошенная модель при смене маршрута?
• Fallback: какие ошибки допустимы, сколько попыток выполняется и когда цепочка останавливается?
• Лимиты: применяются ли rate и quota до upstream и billing?
• Usage и cost: связаны ли Tokens и итоговая сумма с фактическим маршрутом и ценой?
• Диагностика: разделены ли время gateway, ожидание upstream, первый ответ и генерация?
• Secrets: кто может читать credentials и содержимое запросов?
• Change Control: можно ли проверять и откатывать изменения политик?
• Exit Path: возможен ли возврат к native endpoint без переписывания приложения?

Тесты должны использовать ту же модель, класс Prompt, длину ответа, streaming mode, Tools, регион и реальную конкуренцию. Успешный «Hello World» доказывает только доступность.

Частые вопросы

Каждый OpenAI-compatible proxy является AI gateway?

Нет. Совместимость описывает часть API, а gateway — операционные обязанности. Proxy может предоставлять нужный формат, не управляя маршрутизацией, стоимостью, лимитами и диагностикой.

AI gateway устраняет ключи поставщиков?

Не обязательно. Он может хранить credentials, поддерживать BYOK или самостоятельно выставлять счета. Нужно проверить место хранения и права использования или экспорта.

AI gateway ускоряет запросы?

Не автоматически. Он добавляет hop, хотя может улучшить доступность и диагностику. Измеряйте полную timeline своего workload.

Следует ли fallback выбирать другую модель?

Только если приложение явно принимает изменения качества, совместимости, задержки и цены. Безопасный вариант по умолчанию — другой допустимый маршрут для той же модели и протокола.

Практическое различие простое: proxy подходит для контролируемого транспортного пути; AI gateway — когда маршрутизация, политики, использование, стоимость и доказательства запроса требуют единого владельца. Название продукта само по себе ничего не доказывает.