AI Gateway: dostawcy natywni vs dostawcy kompatybilni z OpenAI

AI Gateway centralizuje połączenia z zewnętrznymi dostawcami LLM za pomocą jednego interfejsu, zamiast kodować każdą integrację SDK po stronie aplikacji. Klucze API pozostają po stronie serwera i nigdy nie są udostępniane klientowi. Brama dodaje wspólną warstwę ponawiania prób, przełączania awaryjnego i liczenia kosztów w stosunku do dostawców z różnymi formatami odpowiedzi.

Na backendie Postgres, takim jak Aurabase, ten wybór ma bezpośrednie konsekwencje: ta sama brama obsługuje czat aplikacji, NL2SQL (tłumaczenie języka naturalnego na SQL) i RAG (wyszukiwanie wektorów pg). Słabo zintegrowany dostawca pogarsza wszystkie trzy funkcje na raz, a nie tylko jedną. To właśnie sprawia, że ​​rozróżnienie natywny/kompatybilny jest czymś więcej niż szczegółem implementacji.

Natywny klient koduje rzeczywistą formę API dostawcy: strukturę żądania, format odpowiedzi, pola użycia specyficzne dla tego dostawcy. Tak jest w przypadku Anthropic, którego API „Messages” nie przypomina API OpenAI, lub Gemini, którego zliczanie tokenów wnioskowania (thoughtsTokenCount) jest dodawane do licznika wyjściowego zamiast być już tam uwzględniane.

Punkt końcowy zgodny z OpenAI ponownie wykorzystuje istniejącego klienta OpenAI i zmienia jedynie podstawowy adres URL. Działa to, ponieważ zewnętrzny dostawca (Mistral, Scaleway AI, Ollama) zdecydował się naśladować kontrakt API OpenAI, często z odchyleniami: brak oddzielnego pola tokenu rozumowania, brak gwarancji co do dokładnej formy błędów. Kompatybilność kończy się tam, gdzie kończy się imitacja.

Plik organizujący dostawców w aura-ai nie pozostawia miejsca na dwuznaczność. Trzy moduły, po jednym dla każdego dostawcy natywnego, nic więcej nie zostało zadeklarowane.

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

Każdy moduł implementuje cechę ChatProvider (ukończenie, przesyłanie strumieniowe, nazwa modelu). Dwa z nich, OpenAI i Gemini, dodatkowo implementują EmbeddingProvider. Anthropic tego nie potrzebuje: Claude nie ujawnia interfejsu API do osadzania po stronie dostawcy, co jest faktem dotyczącym samego produktu Anthropic, a nie wadą kodu Aurabase.

Konfiguracja Mistral, Scaleway AI lub Ollama nie wymaga nowego modułu: ta sama zmienna OPENAI_BASE_URL przekierowuje klienta openai.rs do innego kompatybilnego punktu końcowego. To jest przełącznik konfiguracji, a nie programowanie.

# Domyślny dostawca: natywny OpenAI
OPENAI_API_KEY=sk-...

# Zmień dostawcę kompatybilnego z OpenAI (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# np. Mistral: https://api.mistral.ai/v1

Zachowanie odpowiednio się zmienia. Błędy HTTP są nadal klasyfikowane według tego samego mechanizmu (429 → limit szybkości, 5xx → przejściowe i możliwe do ponowienia, 404 → nieznany model), ponieważ klasyfikacja opiera się na poziomie transportu HTTP, a nie na analizie specyficznej dla dostawcy. Co nie następuje: precyzyjne zliczanie tokenów rozumowania, specyficzne dla dedykowanego klienta Gemini.

Brama Aurabase dodaje trzy mechanizmy odporności do trzech natywnych klientów. Wyłącznik automatyczny na parę (projekt, dostawca) odcina połączenia z dostawcą, który wielokrotnie kończył się niepowodzeniem, a token sondy znajduje się w stanie półotwartym przed jego ponownym otwarciem. Wykładnicza ponowna próba wycofywania z jitterem powoduje ponowne uruchomienie przejściowych błędów (przekroczenie limitu czasu, 5xx, 429) bez zależności od zewnętrznej biblioteki liczb losowych.

Każdy dostawca inaczej podaje również przyczynę wstrzymania odpowiedzi: length w OpenAI, MAX_TOKENS w Gemini, max_tokens w Anthropic, dla tej samej rzeczywistości (obcięcie). Kod normalizuje te trzy słowniki w kierunku wspólnego zestawu (stop, length, content_filter, tool_use, other). Bez tej standaryzacji klient korzystający z wielu dostawców musiałby znać wszystkie trzy słowniki, aby wykryć skróconą odpowiedź.

Rozliczenia ilustrują to samo ryzyko. W OpenAI i Anthropic rozumowanie modelu jest już uwzględnione w liczniku naliczonych tokenów wyjściowych. W Gemini thoughtsTokenCount jest dodawane oddzielnie do candidatesTokenCount: ignorowanie go powoduje niedoszacowanie rzeczywistego kosztu zapytania. Ogólny adapter zgodny z OpenAI nie ma powodu znać tej szczególnej cechy, specyficznej dla natywnego formatu odpowiedzi Gemini.

Rynek potwierdza, że ​​AI Gateway stał się oczekiwaną cegiełką, a nie odosobnionym argumentem marketingowym. Neon publikuje dwie dedykowane strony produktów, „AI Gateway” i „Backend dla agentów AI”, obie zorientowane na programistów Postgres. LiteLLM stał się referencyjnym projektem open source, mającym na celu ujednolicenie połączeń z dużą liczbą dostawców w formacie zbliżonym do OpenAI. Braintrust ze swojej strony publikuje własne porównania na ten temat, co oznacza, że ​​kategoria jest wystarczająco silna, aby uzasadnić dedykowane treści redakcyjne.

Gracze ci odpowiadają na realną potrzebę: zmniejszenie powiązania pomiędzy kodem aplikacji a danym dostawcą LLM. Różnica w przypadku Aurabase polega na integracji. Brama nie znajduje się obok backendu: korzysta z tej samej usługi co NL2SQL i RAG, w tej samej bazie danych Postgres. Istnieje również odwrotny kompromis: dedykowany serwer proxy, taki jak LiteLLM, zazwyczaj obejmuje większą liczbę dostawców niż brama zintegrowana z zapleczem aplikacji.

Natywna brama, taka jak Aurabase, ma prawdziwą zaletę, gdy backend i sztuczna inteligencja muszą pozostać w tym samym systemie: NL2SQL, RAG i czat aplikacji mają wtedy tę samą politykę odporności i te same rozliczenia, bez dodatkowych usług do działania.

Istnieje kompromis odwrotny. Jeśli Twoim priorytetem jest obsługa bardzo dużej liczby dostawców lub jeśli brama musi obsługiwać kilka niezależnych backendów, a nie tylko projekt Postgres, ogólny serwer proxy, taki jak LiteLLM, często pozostaje właściwym wyborem. Aurabase nie stara się konkurować z tak szerokim zasięgiem: zakładem jest głębokość u 3 głównych dostawców, zintegrowana z resztą backendu.

Aby zrozumieć, jak ta integracja konkretnie zmienia użycie NL2SQL w porównaniu z podejściem wykorzystującym zewnętrzne konektory, podejście wybrane przez Supabase, zobacz Supabase opiera się na konektorach, a nie natywnym NL2SQL.

Podsumowanie kryteriów, które naprawdę odróżniają te dwa podejścia, bez oceny wartościującej: każde odpowiada na inną potrzebę.

Aby zobaczyć, jak ta brama działa w konkretnym przypadku, zobacz samouczek NL2SQL na temat Postgres. Aby uzyskać szczegółowe informacje na temat natywnych możliwości sztucznej inteligencji Aurabase, zobacz stronę Natywna sztuczna inteligencja.