AI Gateway: native vs. OpenAI-kompatible Anbieter

Ein AI Gateway zentralisiert Aufrufe an externe LLM-Anbieter hinter einer einzigen Schnittstelle, anstatt jede SDK-Integration auf der Anwendungsseite zu codieren. API-Schlüssel bleiben serverseitig und werden dem Client niemals angezeigt. Das Gateway fügt zusätzlich zu Anbietern mit unterschiedlichen Antwortformaten eine gemeinsame Ebene für Wiederholungsversuche, Failover und Kostenzählung hinzu.

Auf einem Postgres-Backend wie Aurabasehat diese Wahl eine direkte Konsequenz: Das gleiche Gateway betreibt den Anwendungschat, NL2SQL (natürliche Sprachübersetzung in SQL) und RAG (pgvector vector search). Ein schlecht integrierter Anbieter beeinträchtigt alle drei Funktionen auf einmal, nicht nur eine. Dies macht die Unterscheidung zwischen nativ und kompatibel zu mehr als nur einem Implementierungsdetail.

Ein nativer Client kodiert die tatsächliche Form der API des Anbieters: Anforderungsstruktur, Antwortformat, anbieterspezifische Verwendungsfelder. Dies ist der Fall bei Anthropic, dessen „Messages“-API nicht der von OpenAI ähnelt, oder bei Gemini, dessen Zählung der Reasoning-Tokens (thoughtsTokenCount) zum Ausgabezähler hinzugefügt wird, anstatt dort bereits enthalten zu sein.

Ein OpenAI-kompatibler Endpunkt verwendet den vorhandenen OpenAI-Client wieder und ändert nur die Basis-URL. Dies funktioniert, weil der Drittanbieter (Mistral, Scaleway AI, Ollama) sich dafür entschieden hat, den API-Vertrag von OpenAI zu imitieren, oft mit Abweichungen: kein separates Argumentations-Token-Feld, keine Garantie für die genaue Form der Fehler. Kompatibilität endet dort, wo Nachahmung endet.

Die Datei, die die Anbieter in aura-ai organisiert, lässt keinen Raum für Mehrdeutigkeiten. Drei Module, eines pro nativem Anbieter, nichts anderes deklariert.

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

Jedes Modul implementiert das Merkmal ChatProvider (Abschluss, Streaming, Modellname). Zwei davon, OpenAI und Gemini, implementieren zusätzlich EmbeddingProvider. Anthropic braucht es nicht: Claude stellt keine herstellerseitige Einbettungs-API offen, eine Produktfaktheit von Anthropic selbst und kein Manko des Aurabase-Codes.

Für die Konfiguration von Mistral, Scaleway AI oder Ollama ist kein neues Modul erforderlich: Dieselbe Variable OPENAI_BASE_URL leitet den Client openai.rs an einen anderen kompatiblen Endpunkt um. Dies ist eine Konfigurationsumschaltung, keine Entwicklung.

# Standardanbieter: Native OpenAI
OPENAI_API_KEY=sk-...

# Wechseln Sie zu einem OpenAI-kompatiblen Anbieter (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# z.B. Mistral: https://api.mistral.ai/v1

Das Verhalten ändert sich entsprechend. HTTP-Fehler bleiben nach demselben Mechanismus klassifiziert (429 → Ratenbegrenzung, 5xx → vorübergehend und wiederholbar, 404 → unbekanntes Modell), da die Klassifizierung auf der HTTP-Transportebene und nicht auf der anbieterspezifischen Analyse erfolgt. Was nicht folgt: die genaue Zählung der Argumentationstoken, spezifisch für den dedizierten Gemini-Client.

Das Aurabase-Gateway fügt zusätzlich zu den drei nativen Clients drei Resilienzmechanismen hinzu. Ein Leistungsschalter pro Paar (Projekt, Anbieter) unterbricht Anrufe an einen wiederholt ausgefallenen Anbieter, wobei sich ein Prüftoken in einem halboffenen Zustand befindet, bevor er ihn wieder öffnet. Ein exponentieller Backoff-Wiederholungsversuch mit Jitter startet vorübergehende Fehler (Timeout, 5xx, 429) neu, ohne Abhängigkeit von einer externen Zufallszahlenbibliothek.

Jeder Anbieter nennt auch den Grund für das Stoppen einer Antwort anders: length bei OpenAI, MAX_TOKENS bei Gemini, max_tokens bei Anthropic, für die gleiche Realität (Trunkierung). Der Code normalisiert diese drei Vokabulare in Richtung eines gemeinsamen Satzes (stop, length, content_filter, tool_use, other). Ohne diese Standardisierung müsste ein Multi-Vendor-Client alle drei Vokabulare kennen, um eine abgeschnittene Antwort zu erkennen.

Die Abrechnung verdeutlicht das gleiche Risiko. Bei OpenAI und Anthropic ist die Begründung des Modells bereits im Zähler der berechneten Ausgabe-Token enthalten. Bei Gemini wird thoughtsTokenCount separat zu candidatesTokenCounthinzugefügt: Wenn man es ignoriert, werden die tatsächlichen Kosten einer Abfrage unterschätzt. Ein generischer OpenAI-kompatibler Adapter hat keinen Grund, diese Besonderheit zu kennen, die für das native Antwortformat von Gemini spezifisch ist.

Der Markt bestätigt, dass ein KI-Gateway zu einem erwarteten Baustein und nicht zu einem isolierten Marketingargument geworden ist. Neon veröffentlicht zwei spezielle Produktseiten, „AI Gateway“ und „Backend for AI Agents“, beide orientiert an Postgres-Entwicklern. LiteLLM hat sich als Referenz-Open-Source-Projekt etabliert, um Aufrufe an eine große Anzahl von Anbietern hinter einem OpenAI-ähnlichen Format zu vereinen. Braintrust wiederum veröffentlicht eigene Vergleiche zu diesem Thema, ein Zeichen dafür, dass die Kategorie stark genug ist, um spezielle redaktionelle Inhalte zu rechtfertigen.

Diese Akteure reagieren auf ein echtes Bedürfnis: die Reduzierung der Kopplung zwischen dem Anwendungscode und einem bestimmten LLM-Anbieter. Der Unterschied zu Aurabase ist die Integration. Das Gateway befindet sich nicht neben dem Backend: Es nutzt denselben Dienst wie NL2SQL und RAG in derselben Postgres-Datenbank. Es gibt auch den umgekehrten Kompromiss: Ein dedizierter Proxy wie LiteLLM deckt in der Regel mehr Anbieter ab als ein in ein Anwendungs-Backend integriertes Gateway.

Ein natives Gateway wie das von Aurabase hat einen echten Vorteil, wenn das Backend und die KI im selben System bleiben müssen: NL2SQL, RAG und Anwendungschat teilen sich dann die gleiche Ausfallsicherheitsrichtlinie und die gleiche Abrechnung, ohne dass zusätzliche Dienste betrieben werden müssen.

Der gegenteilige Kompromiss besteht. Wenn Ihre Priorität darin besteht, eine sehr große Anzahl von Anbietern abzudecken, oder wenn das Gateway mehrere unabhängige Backends und nicht nur ein Postgres-Projekt bedienen muss, bleibt ein allgemeiner Proxy wie LiteLLM oft die richtige Wahl. Aurabase will nicht mit dieser Breite der Abdeckung konkurrieren: Die Wette ist die Tiefe über drei große Anbieter hinweg, integriert mit dem Rest des Backends.

Um zu verstehen, wie diese Integration die Verwendung von NL2SQL im Vergleich zu einem Ansatz mit externen Konnektoren, dem von Supabase gewählten Ansatz, konkret verändert, siehe Supabase setzt auf Konnektoren, nicht auf natives NL2SQL.

Zusammenfassung der Kriterien, die die beiden Ansätze wirklich unterscheiden, ohne Wertung: Jeder geht auf ein anderes Bedürfnis ein.

Um dieses Gateway in einem konkreten Fall bei der Arbeit zu sehen, lesen Sie das NL2SQL-Tutorial zu Postgres. Einzelheiten zu den nativen KI-Funktionen von Aurabase finden Sie auf der Seite Native AI.