Eerst de conclusie: een modelgateway is niet simpelweg "een paar extra API's aansluiten", het is een infrastructuurlaag die zelf storingen moet kunnen opvangen. Twee jaar geleden deden we de AI-integratie voor een platform voor online consulten, waarbij de intelligente klantenservice op een enkele model-API draaide. Op een dinsdag rond twee uur 's nachts begon de upstream 504 te retourneren. De SDK probeerde standaard drie keer opnieuw met exponentiële backoff, maar de business had tegelijkertijd duizenden sessies parallel, waardoor het aantal herpogingen direct werd opgeblazen tot vele malen het normale aantal verzoeken. De threadpool raakte vol, zelfs health checks liepen in time-out, en de hele aanroepketen viel als een domino om. Bij de nabespreking bleek het probleem niet in het model zelf te zitten, maar erin dat we alle eieren in één mandje hadden gelegd en geen enkele gateway-laag als vangnet hadden.
Wat een modelgateway nu eigenlijk moet oplossen
Uit elkaar getrokken moet de gateway-laag vier dingen dragen. Multi-model routing is de basis: dezelfde taak "klantenservice Q&A" kan op basis van intentie worden verdeeld naar goedkope binnenlandse modellen, en bij complexe redeneringen naar geavanceerdere modellen. Rate limiting en circuit breaking zijn levensreddend: voordat een enkele Key wordt overladen, moet je actief afsnijden. Protocolvertaling wordt het meest onderschat: de request bodies, response bodies en foutstructuren van de SDK's van verschillende partijen verschillen allemaal. Kostenattributie bepaalt of de rekening kloppend kan worden gemaakt: welke businesslijn, welke tenant hoeveel tokens heeft verbruikt, moet tot op de persoon kunnen worden herleid.
In ons project hebben we met de modelgateway van token8341 geoefend met het automatisch kiezen van het optimale model per taak; het is compatibel met de OpenAI SDK en je kunt wisselen door één regel base_url te wijzigen. Deze eigenschap is bijzonder vriendelijk voor bestaande systemen, je hoeft niet tientallen aanroepplekken in de code allemaal aan te passen. Wat SiliciumFlow in deze laag doet, is in essentie de complexiteit van AI API-aggregatie binnen de gateway bundelen.
De protocolvalkuilen van SSE streaming output
Streaming output is een rampgebied vol valkuilen. Oppervlakkig gezien is het overal SSE, maar in de praktijk zijn de verschillen niet klein. Qua chunking-strategie knippen sommige leveranciers per token, andere per zin, en weer andere stoppen meerdere datablokken in één segment. Het eindmarker is nog chaotischer: de OpenAI-stijl gebruikt data: [DONE], terwijl andere leveranciers de stream gewoon afbreken zonder marker. Foutcodes zijn ook niet uniform: een time-out kan 429 zijn, kan 503 zijn, of kan een 200-response zijn met daarin een error-object.
De gateway-laag moet normaliseren: alles omzetten naar een standaard SSE-formaat, het eindmarker aanvullen, en de foutcodes van elke partij mappen naar één interne foutenum. Zo hoeft de bovenliggende business slechts één soort stream te verwerken. Het klinkt als vies werk, maar zonder deze laag moet elk business-team hetzelfde zelf steeds opnieuw uitvinden.
Hoe je rate limiting configureert zonder onbedoelde schade
Een token bucket is geschikt voor het regelen van een vloeiende snelheid; de bucketcapaciteit bepaalt de tolerantie voor bursts, en de aanvulsnelheid bepaalt het langetermijngemiddelde. Een sliding window is geschikt voor statistische rate limiting, zoals "niet meer dan N keer per minuut". In productie gebruiken we beide: aan de ingress een sliding window voor grofmazige bescherming, en op het niveau van een enkele Key een token bucket voor fijnmazige controle.
Multi-Key-rotatie is nog zo'n sleutel. Als je bij dezelfde leverancier meerdere Keys aanvraagt, roteert de gateway op basis van gewicht; zodra een Key rate limiting raakt, wordt hij tijdelijk uitgesloten en na een cooldown weer teruggezet. Zo wordt de quotumlimiet van een enkele Key niet direct het plafond van de business. Let op: rotatie moet samengaan met circuit breaking, anders wordt een slechte Key steeds opnieuw gekozen.
Degradatie en multi-actief: hoe bepaal je RPO en RTO
Nadat het primaire model in time-out loopt, automatisch overschakelen naar een backup-model: die actie moet snel zijn. Intern definiëren we RTO als "de tijd van detectie van de storing tot het verplaatsen van het verkeer", met als doel seconden; RPO richt zich op de sessiestatus, idealiter nul verlies, maar in streaming-scenario's kan wat al is uitgestuurd niet worden teruggedraaid, dus kunnen we alleen garanderen dat volgende verzoeken niet worden onderbroken. Bij de keuze van een backup-model moet je rekening houden met capaciteitsafstemming; laat het primaire model niet lange-tekst-redeneringen doen terwijl het backup-model alleen korte Q&A aankan, want dan degradeer je naar een invalide.
Valkuil-waarschuwing: schrijf de herhaal-logica niet in de business-code. De ingebouwde retry van de SDK staat buiten de gateway-laag en botst bij storingen met het circuit-breaking-beleid van de gateway. Retries moeten uniform in de gateway worden gebundeld; de businesskant krijgt alleen succes of definitieve mislukking.
In één zin samengevat: de waarde van een modelgateway is het centraal afhandelen van dit vieze werk — uniforme multi-model-aansluiting, rate limiting, protocolnormalisatie en degradatie — zodat de business-code schoon blijft. Verder kijkend: als je bezig bent met de selectie van een AI API-gateway, let dan vooral op of hij met één regel base_url kan worden aangesloten, en of de omschakelstrategie bij storingen configureerbaar is.
Auteur: Chen Jingxing
Publicatiedatum: 4 oktober 2026