AI Gateway: native versus OpenAI-compatibele providers

Een AI Gateway centraliseert oproepen naar externe LLM-providers achter één enkele interface, in plaats van elke SDK-integratie aan de applicatiezijde te coderen. API-sleutels blijven aan de serverzijde en worden nooit blootgesteld aan de client. De gateway voegt een gemeenschappelijke laag van opnieuw proberen, failover en kostentelling toe bovenop providers met verschillende antwoordformaten.

Op een Postgres-backend zoals Aurabaseheeft deze keuze een direct gevolg: dezelfde gateway stuurt de applicatiechat, de NL2SQL (natuurlijke taalvertaling naar SQL) en de RAG (pgvector vector search) aan. Een slecht geïntegreerde provider verslechtert alle drie de functies tegelijk, en niet slechts één. Dit maakt het onderscheid native/compatibel meer dan een implementatiedetail.

Een native client codeert de echte vorm van de API van de provider: verzoekstructuur, antwoordformaat, gebruiksvelden die specifiek zijn voor deze provider. Dit is het geval van Anthropic, waarvan de “Messages” API niet lijkt op die van OpenAI, of van Gemini, wiens telling van redeneertokens (thoughtsTokenCount) wordt toegevoegd aan de uitvoerteller in plaats van daar al te zijn opgenomen.

Een OpenAI-compatibel eindpunt hergebruikt de bestaande OpenAI-client en verandert alleen de basis-URL. Dit werkt omdat de externe provider (Mistral, Scaleway AI, Ollama) ervoor koos het API-contract van OpenAI te imiteren, vaak met afwijkingen: geen apart redeneringstokenveld, geen garantie op de exacte vorm van fouten. Compatibiliteit eindigt waar imitatie eindigt.

Het bestand dat de providers in aura-ai organiseert, laat geen ruimte voor dubbelzinnigheid. Drie modules, één per native provider, verder niets aangegeven.

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

Elke module implementeert de eigenschap ChatProvider (voltooiing, streaming, modelnaam). Twee van hen, OpenAI en Gemini, implementeren bovendien EmbeddingProvider. Anthropic heeft het niet nodig: Claude onthult geen insluitings-API aan de kant van de leverancier, een productfeit van Anthropic zelf, en geen tekortkoming van de Aurabase-code.

Voor het configureren van Mistral, Scaleway AI of Ollama is geen nieuwe module nodig: dezelfde OPENAI_BASE_URL variabele leidt de openai.rs client om naar een ander compatibel eindpunt. Dit is een configuratieschakelaar, geen ontwikkeling.

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

# Schakel over naar een OpenAI-compatibele provider (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# bijv. Mistral: https://api.mistral.ai/v1

Gedrag verandert dienovereenkomstig. HTTP-fouten blijven geclassificeerd door hetzelfde mechanisme (429 → snelheidslimiet, 5xx → tijdelijk en opnieuw te proberen, 404 → onbekend model), omdat de classificatie zich op het HTTP-transportniveau bevindt en niet op providerspecifieke parsering. Wat niet volgt: het nauwkeurig tellen van redeneertokens, specifiek voor de speciale Gemini-client.

De Aurabase-gateway voegt drie veerkrachtmechanismen toe bovenop de drie native clients. Een stroomonderbreker per paar (project, provider) verbreekt oproepen naar een herhaaldelijk mislukte provider, waarbij een probe-token in een semi-open staat staat voordat deze opnieuw wordt geopend. Een exponentiële nieuwe poging tot uitstel met jitter herstart tijdelijke fouten (time-out, 5xx, 429), zonder afhankelijkheid van een externe bibliotheek met willekeurige getallen.

Elke provider noemt de reden voor het stoppen van een reactie ook anders: length bij OpenAI, MAX_TOKENS bij Gemini, max_tokens bij Anthropic, voor dezelfde realiteit (truncatie). De code normaliseert deze drie vocabulaires naar een gemeenschappelijke set (stop, length, content_filter, tool_use, other). Zonder deze standaardisatie zou een klant van meerdere leveranciers alle drie de vocabulaires moeten kennen om een ​​afgeknot antwoord te kunnen detecteren.

Facturering illustreert hetzelfde risico. Bij OpenAI en Anthropic is de redenering van het model al opgenomen in de teller van de in rekening gebrachte outputtokens. Bij Gemini wordt thoughtsTokenCount afzonderlijk toegevoegd aan candidatesTokenCount: als u dit negeert, worden de werkelijke kosten van een zoekopdracht onderschat. Een generieke OpenAI-compatibele adapter heeft geen reden om deze bijzonderheid te kennen, specifiek voor het eigen reactieformaat van Gemini.

De markt bevestigt dat een AI Gateway een verwachte bouwsteen is geworden, en geen geïsoleerd marketingargument. Neon publiceert twee speciale productpagina's, "AI Gateway" en "Backend voor AI-agents", beide gericht op Postgres-ontwikkelaars. LiteLLM heeft zichzelf gevestigd als een open source-referentieproject om oproepen naar een groot aantal providers te verenigen achter een formaat dat dicht bij OpenAI ligt. Braintrust publiceert op zijn beurt zijn eigen vergelijkingen over dit onderwerp, een teken dat de categorie sterk genoeg is om speciale redactionele inhoud te rechtvaardigen.

Deze spelers spelen in op een reële behoefte: het verminderen van de koppeling tussen de applicatiecode en een bepaalde LLM-provider. Het verschil met Aurabase is de integratie. De gateway woont niet naast de backend: hij deelt dezelfde service als NL2SQL en RAG, op dezelfde Postgres-database. Het tegenovergestelde compromis bestaat ook: een speciale proxy zoals LiteLLM dekt doorgaans meer providers dan een gateway die is geïntegreerd in een applicatie-backend.

Een native gateway als die van Aurabase heeft een reëel voordeel als de backend en de AI in hetzelfde systeem moeten blijven: NL2SQL, RAG en applicatiechat delen dan hetzelfde veerkrachtbeleid en dezelfde facturering, zonder dat er aanvullende diensten moeten worden uitgevoerd.

Het tegenovergestelde compromis bestaat. Als het uw prioriteit is om een ​​zeer groot aantal providers te dekken, of als de gateway meerdere onafhankelijke backends moet bedienen en niet alleen een Postgres-project, dan blijft een algemene proxy zoals LiteLLM vaak de juiste keuze. Aurabase wil niet concurreren met deze dekkingsbreedte: de weddenschap is de diepte van drie grote providers, geïntegreerd met de rest van de backend.

Om te begrijpen hoe deze integratie het gebruik van NL2SQL concreet verandert in vergelijking met een aanpak waarbij gebruik wordt gemaakt van externe connectoren, is de door Supabase gekozen aanpak, zie Supabase afhankelijk van connectoren, niet van native NL2SQL.

Samenvatting van de criteria die de twee benaderingen echt onderscheiden, zonder waardeoordeel: elk beantwoordt aan een andere behoefte.

Om deze gateway in een concreet geval aan het werk te zien, zie de NL2SQL tutorial op Postgres. Voor details over de native AI-mogelijkheden van Aurabase, zie de Native AIpagina.