AI Gateway: собственные и OpenAI-совместимые провайдеры

AI Gateway централизует вызовы к внешним поставщикам LLM через единый интерфейс вместо кодирования каждой интеграции SDK на стороне приложения. Ключи API остаются на стороне сервера и никогда не доступны клиенту. Шлюз добавляет общий уровень повторных попыток, аварийного переключения и подсчета затрат поверх поставщиков с разными форматами ответов.

В серверной части Postgres, такой как Aurabase, этот выбор имеет прямое следствие: один и тот же шлюз обеспечивает чат приложения, NL2SQL (перевод естественного языка в SQL) и RAG (поиск векторного вектора pg). Плохо интегрированный провайдер ухудшает сразу все три функции, а не только одну. Именно это делает различие между собственным и совместимым не просто деталями реализации.

Нативный клиент кодирует реальную форму API провайдера: структуру запроса, формат ответа, поля использования, специфичные для этого провайдера. Это случай Anthropic, чей API «Сообщений» не похож на API OpenAI, или Gemini, чей подсчет токенов рассуждения (thoughtsTokenCount) добавляется в выходной счетчик вместо того, чтобы быть уже включенным туда.

Конечная точка, совместимая с OpenAI, повторно использует существующий клиент OpenAI и меняет только базовый URL-адрес. Это работает, потому что сторонний поставщик (Mistral, Scaleway AI, Ollama) решил имитировать контракт API OpenAI, часто с отклонениями: нет отдельного поля токена обоснования, нет гарантии точной формы ошибок. Совместимость заканчивается там, где заканчивается имитация.

Файл, который организует поставщиков в aura-ai, не оставляет места для двусмысленности. Три модуля, по одному на каждого собственного провайдера, больше ничего не заявлено.

pub mod anthropic;
pub mod gemini;
pub mod openai;

Каждый модуль реализует признак ChatProvider (завершение, потоковая передача, имя модели). Два из них, OpenAI и Gemini, дополнительно реализуют EmbeddingProvider. Anthropic в этом не нуждается: Клод не предоставляет API для встраивания на стороне поставщика, что является фактом продукта самой Anthropic, а не недостатком кода Aurabase.

Для настройки Mistral, Scaleway AI или Ollama не требуется новый модуль: та же переменная OPENAI_BASE_URL перенаправляет клиента openai.rs на другую совместимую конечную точку. Это переключатель конфигурации, а не разработка.

# Поставщик по умолчанию: собственный OpenAI
OPENAI_API_KEY=sk-...

# Переключитесь на провайдера, совместимого с OpenAI (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# например Мистраль: https://api.mistral.ai/v1

Соответственно меняется и поведение. Ошибки HTTP по-прежнему классифицируются по тому же механизму (429 → ограничение скорости, 5xx → временные и повторные попытки, 404 → неизвестная модель), поскольку классификация находится на уровне транспорта HTTP, а не на анализе, зависящем от поставщика. Чего не следует: точный подсчет токенов рассуждения, специфичный для выделенного клиента Gemini.

Шлюз Aurabase добавляет три механизма устойчивости поверх трех собственных клиентов. Автоматический выключатель на пару (проект, провайдер) прерывает вызовы к неоднократно сбойному провайдеру, при этом пробный токен находится в полуоткрытом состоянии перед его повторным открытием. Экспоненциальная повторная попытка отсрочки с джиттером перезапускает временные ошибки (тайм-аут, 5xx, 429) независимо от внешней библиотеки случайных чисел.

Причину остановки ответа каждый провайдер называет также по-разному: length у OpenAI, MAX_TOKENS у Gemini, max_tokens у Anthropic, для одной и той же реальности (усечения). Код нормализует эти три словаря к общему набору (stop, length, content_filter, tool_use, other). Без этой стандартизации клиенту, работающему с несколькими поставщиками, пришлось бы знать все три словаря, чтобы обнаружить усеченный ответ.

Выставление счетов иллюстрирует тот же риск. В OpenAI и Anthropic обоснование модели уже включено в счетчик начисленных выходных токенов. В Gemini thoughtsTokenCount добавляется отдельно к candidatesTokenCount: его игнорирование приводит к занижению реальной стоимости запроса. У универсального адаптера, совместимого с OpenAI, нет причин знать эту особенность, специфичную для собственного формата ответа Gemini.

Рынок подтверждает, что AI Gateway стал ожидаемым кирпичиком, а не изолированным маркетинговым аргументом. Neon публикует две специальные страницы продуктов: «AI Gateway» и «Backend для AI-агентов», обе ориентированы на разработчиков Postgres. LiteLLM зарекомендовал себя как эталонный проект с открытым исходным кодом, позволяющий унифицировать обращения к большому количеству провайдеров в формате, близком к OpenAI. Braintrust, со своей стороны, публикует собственные сравнения по этой теме, что является признаком того, что категория достаточно сильна, чтобы оправдать специальный редакционный контент.

Эти игроки реагируют на реальную потребность: уменьшение связи между кодом приложения и конкретным поставщиком LLM. Разница с Aurabase заключается в интеграции. Шлюз не находится рядом с серверной частью: он использует тот же сервис, что и NL2SQL и RAG, в той же базе данных Postgres. Существует и противоположный компромисс: выделенный прокси-сервер, такой как LiteLLM, обычно охватывает больше провайдеров, чем шлюз, интегрированный в серверную часть приложения.

Собственный шлюз, подобный шлюзу Aurabase, имеет реальное преимущество, когда серверная часть и ИИ должны оставаться в одной системе: NL2SQL, RAG и чат приложений затем используют одну и ту же политику устойчивости и один и тот же биллинг без необходимости работы дополнительных сервисов.

Существует противоположный компромисс. Если вашим приоритетом является покрытие очень большого количества провайдеров или если шлюз должен обслуживать несколько независимых бэкэндов, а не только проект Postgres, общий прокси, такой как LiteLLM, часто остается правильным выбором. Aurabase не стремится конкурировать с такой широтой покрытия: ставка делается на глубину трех основных поставщиков, интегрированных с остальной частью серверной части.

Чтобы понять, как эта интеграция конкретно меняет использование NL2SQL по сравнению с подходом, использующим внешние соединители, подходом, выбранным Supabase, см. Supabase полагается на соединители, а не на собственный NL2SQL.

Краткое изложение критериев, которые действительно различают два подхода, без оценочных суждений: каждый отвечает разным потребностям.

Чтобы увидеть работу этого шлюза в конкретном случае, см. учебник NL2SQL по Postgres. Подробную информацию о собственных возможностях искусственного интеллекта Aurabase см. на странице Native AI.