AI 게이트웨이: 기본 공급자와 OpenAI 호환 공급자

AI 게이트웨이는 애플리케이션 측에서 각 SDK 통합을 코딩하는 대신 단일 인터페이스 뒤에 외부 LLM 공급자에 대한 호출을 중앙 집중화합니다. API 키는 서버 측에 유지되며 클라이언트에 노출되지 않습니다. 게이트웨이는 다양한 응답 형식을 가진 공급자 위에 재시도, 장애 조치 및 비용 계산의 공통 계층을 추가합니다.

Aurabase와 같은 Postgres 백엔드에서 이 선택은 직접적인 결과를 가져옵니다. 동일한 게이트웨이가 애플리케이션 채팅, NL2SQL(SQL로 자연어 번역) 및 RAG(pgVector 벡터 검색)를 지원합니다. 제대로 통합되지 않은 공급자는 하나가 아닌 세 가지 기능 모두를 동시에 저하시킵니다. 이것이 구현 세부 사항보다 네이티브/호환성 구별을 더 중요하게 만드는 것입니다.

기본 클라이언트는 공급자 API의 실제 형식(요청 구조, 응답 형식, 이 공급자와 관련된 사용 필드)을 인코딩합니다. 이는 "메시지" API가 OpenAI와 유사하지 않은 Anthropic 또는 추론 토큰(thoughtsTokenCount)의 계산이 이미 출력 카운터에 포함되는 대신 출력 카운터에 추가되는 Gemini의 경우입니다.

OpenAI 호환 엔드포인트는 기존 OpenAI 클라이언트를 재사용하고 기본 URL만 변경합니다. 이는 타사 제공업체(Mistral, Scaleway AI, Ollama)가 종종 편차가 있는 OpenAI의 API 계약을 모방하기로 선택했기 때문에 작동합니다. 별도의 추론 토큰 필드가 없고 정확한 오류 형태에 대한 보장이 없습니다. 모방이 끝나는 곳에서 호환성도 끝납니다.

aura-ai의 공급자를 구성하는 파일에는 모호성의 여지가 없습니다. 세 개의 모듈(네이티브 공급자당 하나씩), 그 외에는 선언되지 않았습니다.

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

각 모듈은 ChatProvider 특성(완성, 스트리밍, 모델 이름)을 구현합니다. 그 중 OpenAI와 Gemini 두 가지는 EmbeddingProvider를 추가로 구현합니다. Anthropic은 이를 필요로 하지 않습니다. Claude는 Aurabase 코드의 단점이 아니라 Anthropic 자체의 제품 사실인 공급업체 측 임베딩 API를 노출하지 않습니다.

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)를 다시 시작합니다.

또한 각 공급자는 동일한 현실(잘림)에 대해 응답을 중지하는 이유를 다르게 지정합니다. OpenAI에서는 length, Gemini에서는 MAX_TOKENS, Anthropic에서는 max_tokens입니다. 코드는 이러한 세 가지 어휘를 공통 세트(stop, length, content_filter, tool_use, other)로 정규화합니다. 이러한 표준화가 없으면 다중 공급업체 클라이언트는 잘린 응답을 감지하기 위해 세 가지 어휘를 모두 알아야 합니다.

청구도 동일한 위험을 보여줍니다. OpenAI와 Anthropic에서는 모델의 추론이 이미 청구된 출력 토큰 카운터에 포함되어 있습니다. Gemini에서는 thoughtsTokenCount가 candidatesTokenCount에 별도로 추가됩니다. 이를 무시하면 쿼리의 실제 비용이 과소평가됩니다. 일반 OpenAI 호환 어댑터는 Gemini의 기본 응답 형식과 관련된 이러한 특수성을 알 이유가 없습니다.

시장에서는 AI 게이트웨이가 고립된 마케팅 주장이 아니라 기대되는 벽돌이 되었음을 확인합니다. Neon은 Postgres 개발자 중심의 두 가지 전용 제품 페이지인 "AI 게이트웨이"와 "AI 에이전트용 백엔드"를 게시합니다. LiteLLM은 OpenAI에 가까운 형식으로 수많은 공급자에 대한 호출을 통합하기 위한 참조 오픈 소스 프로젝트로 자리매김했습니다. Braintrust는 해당 주제에 대한 자체 비교를 게시합니다. 이는 해당 카테고리가 전용 편집 콘텐츠를 정당화할 만큼 강력하다는 신호입니다.

이러한 플레이어는 애플리케이션 코드와 특정 LLM 제공자 간의 결합을 줄이는 실제 요구 사항에 응답합니다. Aurabase와의 차이점은 통합입니다. 게이트웨이는 백엔드 옆에 있지 않습니다. 동일한 Postgres 데이터베이스에서 NL2SQL 및 RAG와 동일한 서비스를 공유합니다. 반대의 절충안도 존재합니다. LiteLLM과 같은 전용 프록시는 일반적으로 애플리케이션 백엔드에 통합된 게이트웨이보다 더 많은 공급자를 포함합니다.

Aurabase와 같은 기본 게이트웨이는 백엔드와 AI가 동일한 시스템에 유지되어야 할 때 실질적인 이점을 제공합니다. NL2SQL, RAG 및 애플리케이션 채팅은 추가 서비스 운영 없이 동일한 복원력 정책과 동일한 청구를 공유합니다.

반대의 타협이 존재합니다. 매우 많은 수의 공급자를 포괄하는 것이 우선순위이거나 게이트웨이가 Postgres 프로젝트뿐만 아니라 여러 개의 독립적인 백엔드를 제공해야 하는 경우 LiteLLM과 같은 일반 프록시가 올바른 선택인 경우가 많습니다. Aurabase는 이러한 광범위한 적용 범위와 경쟁하려고 하지 않습니다. 베팅은 나머지 백엔드와 통합된 3개의 주요 제공업체에 대한 깊이입니다.

이 통합이 Supabase가 선택한 접근 방식인 외부 커넥터를 사용하는 접근 방식과 비교하여 NL2SQL의 사용을 구체적으로 어떻게 변경하는지 이해하려면 Supabase는 기본 NL2SQL이 아닌 커넥터에 의존합니다를 참조하세요.

가치 판단 없이 두 접근 방식을 실제로 구별하는 기준 요약: 각각은 서로 다른 요구에 응답합니다.

To see this gateway at work in a concrete case, see the NL2SQL tutorial on Postgres. For details of Aurabase's native AI capabilities, see the Native AIpage.