Elke provider geeft je een sleutel. Na de derde zijn sleutels geen gemak meer, maar een systeem dat je moet bouwen en onderhouden. Je hebt N providers, elk met een eigen base-URL, een eigen auth-header, eigen rate-limit-semantiek, eigen foutcodes, een eigen factureringspagina. Op het moment dat je een verzoek wilt routeren naar "het best beschikbare model" in plaats van "het model dat ik hardgecodeerd heb", heb je een routeringsprobleem, en dat is wat een gateway oplost.
Het probleem is niet de API, het is de operations
De ruwe API-aanroepen zijn eenvoudig. Het is alles eromheen dat zich opstapelt:
•Verspreide credentials. Een sleutel per provider, volgens verschillende schema's geroteerd, opgeslagen in verschillende secret managers.
•Rate limits. Elke provider throttelt anders, en hun foutresponses zijn niet consistent, dus je retry-logica moet voor elk een uitzondering maken.
•Inzicht in verbruik. Elke provider heeft een eigen dashboard. Er is geen enkele plek die de totale uitgaven over alle providers toont.
•Failover. Als provider A uitvalt, betekent verkeer naar provider B verplaatsen opnieuw uitrollen met een nieuwe sleutel en een nieuw endpoint.
Niets hiervan is zichtbaar in een demo. Het komt naar boven in productie om 2 uur 's nachts, wanneer een provider platligt en je retry-wachtrij zich opstapelt.
Wat een gateway werkelijk is
Een gateway zit tussen je applicatie en de modelproviders. Je app praat met één endpoint met één sleutel. De gateway regelt auth, routering, rate limiting, verbruiksadministratie en fallback. Voor je code ziet het er precies uit als één enkele LLM-API.
+------------------+
| Je app |
+--------+---------+
| één sleutel, één base-URL
v
+--------+---------+
| LLM-gateway |
| auth / routering|
| rate limiting |
| verbruiksmeting |
+--+-----+----+----+
| | |
v v v
Provider A B C
(GPT-4o) (DeepSeek) (Qwen)De belangrijke ontwerpbeslissing is dat de gateway aan de inkomende kant het OpenAI-compatibele protocol spreekt. Dat betekent dat je bestaande SDK-code geen nieuwe clientbibliotheek nodig heeft. Je verandert de base-URL en de sleutel, en je blijft normale chat.completions.create-aanroepen schrijven.
Eén sleutel, één endpoint, vele modellen
Hier is de volledige integratie aan de clientzijde:
from openai import OpenAI
client = OpenAI(
base_url="https://api.token8341.com/v1",
api_key="sk-one-key-for-everything",
)
for model in ["gpt-4o", "claude-3-5-sonnet", "deepseek-chat", "qwen-max"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Reply with the word 'ok'"}],
)
print(model, "->", resp.choices[0].message.content)Dezelfde sleutel autoriseert elk model in de catalogus. Je hoeft geen vier accounts in te richten of vier saldi bij te houden. Je betaalt één gemeten factuur, en het verbruik is uitgesplitst per model, zodat je kunt zien waar de tokens daadwerkelijk naartoe zijn gegaan.
De gateway maakt routering ook een configuratiebeslissing in plaats van een codewijziging. Wil je een goedkoop model voor de hoogvolume-lane en een frontier-model voor de moeilijke lane? Dat is een mapping op één plek:
ROUTES = {
"summarize": "deepseek-chat",
"reason": "qwen-max",
"frontier": "gpt-4o",
}En fallback wordt gewone control flow in plaats van een multi-vendor-integratie:
def call_with_fallback(prompt, primary, backup):
try:
return ask(primary, prompt)
except Exception:
return ask(backup, prompt)Wanneer je een gateway nodig hebt, en wanneer niet
Een gateway is overhead die je niet op je moet nemen als je die niet nodig hebt. Als je één provider en één model gebruikt en je hebt geen failover-vereiste, dan is een directe sleutel eenvoudiger en dat is de juiste keuze. Een extra hop en een extra leverancier aan het kritieke pad toevoegen heeft een prijs.
Een gateway verdient zijn plek wanneer ten minste één van deze waar is:
•Je gebruikt twee of meer modellen en wilt vrij tussen ze kunnen wisselen.
•Je hebt fallback nodig wanneer een provider uitvalt of rate-limited is.
•Je wilt één factuur en één plek om uitgaven per model te zien.
•Je wilt modellen A/B-testen op live verkeer zonder opnieuw uit te rollen.
Als een van deze van toepassing is, wegen de operationele besparingen op tegen de extra hop. De daadwerkelijke toegevoegde latency van een goed draaiende gateway is een paar milliseconden, klein genoeg om te verdwijnen naast de model-inferentietijd.
Managed of self-hosted?
Eén beslissing die je bewust moet nemen, is of je je eigen gateway draait of er een huurt. Self-hosted routers zoals LiteLLM en one-api zijn uitstekend en geven je volledige controle over routeringstabellen, sleutels en logging. Ze geven je ook een service om te draaien, te monitoren, te patchen en hoog beschikbaar te houden, wat precies de operationele last is die je probeerde af te schudden.
Een managed gateway keert de afweging om. Je geeft controle over de interne werking op en wint dat je ze niet hoeft te beheren: iemand anders houdt het endpoint overeind, roteert upstream-sleutels en absorbeert provider-storingen. Voor een klein team is dat meestal de juiste deal. Voor een groter team met een platformgroep in dienst kan self-hosting de moeite waard zijn, alleen al vanwege de auditability. Hoe dan ook, houd het inkomende contract OpenAI-compatibel, zodat de keuze omkeerbaar blijft.
SiCore TokenWorks is rond dit idee gebouwd: één API-sleutel, één OpenAI-compatibel endpoint op https://api.token8341.com/v1, en een catalogus die GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, Spark en Pangu omvat, met gemeten facturering en verbruik uitgesplitst per model.