Vorige maand nam ik een project voor intelligente klantenservice over. De business wilde tegelijkertijd drie grote modellen integreren: DeepSeek, Tongyi Qianwen en Doubao, met als reden "gebruik de goedkoopste, en schakel over als er een limiet is". Klinkt redelijk, maar tijdens de implementatie ontdekte ik: de auth-methoden, factureringslogica en time-out/retry-strategieën van de drie SDK's zijn volledig verschillend. DeepSeek gebruikt Bearer Token, Tongyi gaat via DashScope's API-KEY met signature, en Doubao's auth-velden zijn weer anders. Qua facturering wordt bij sommige input- en output-tokens apart berekend, bij andere gecombineerd, en sommige geven korting bij cache-hits. Time-outs zijn nog vervelender: de ene standaard 30 seconden, de andere 60 seconden, en retry-aantallen en backoff-strategieën moeten apart worden geschreven.
Toen ik klaar was met coderen, telde ik: alleen de adapterlaag voor het inkapselen van de drie clients was al meer dan 800 regels, exclusief foutcode-mapping. Dit is waarom het concept model gateway sinds vorig jaar steeds weer opduikt in de Chinese AI-engineeringwereld. In één zin: een model gateway is een tussenlaag die de verschillen tussen meerdere grote model-API's verbergt en een uniforme interface biedt aan de bovenliggende business.
Directe verbinding, zelfbouw of aggregatieplatform: de technische kosten van drie opties
Eerst directe verbinding met de officiële SDK. Drie modellen betekent drie sets auth, drie sets foutafhandeling, drie sets retry-logica. De businesscode staat vol met if-else om te bepalen welk model wordt gebruikt. Een nieuw model toevoegen betekent de adapterlaag opnieuw aanpassen. We hebben berekend dat het onderhouden van drie directe verbindingen ongeveer 15% van de totale backend-werkzaamheden van het project kost. Bij vijf of meer modellen loopt dit aandeel uit de hand.
Een zelfgebouwde gateway is de tweede optie. Het kernidee is een proxy-laag schrijven die verzoeken doorstuurt naar de verschillende API's. Het voordeel is controle, het nadeel is dat je zelf protocolconversie, sleutelrotatie, rate-limiting queues en gebruiksstatistieken moet regelen. We hebben intern ingeschat dat een productieklare zelfgebouwde gateway minstens twee engineers en zes tot acht weken kost, plus doorlopend onderhoud voor API-versiewijzigingen. Voor kleine en middelgrote teams is dat niet rendabel.
De derde optie is een AI API-aggregatieplatform. Dergelijke platforms verpakken meerdere grote model-API's uniform en bieden één set interfaces aan. De technische kosten zijn het laagst, en de integratietijd wordt meestal in dagen gerekend. In ons project gebruiken we SiCore TokenWorks, compatibel met de OpenAI SDK — één regel base_url wijzigen is genoeg om te wisselen. Let hier op een valkuil: verschillende aggregatieplatforms hebben verschillende standaardstrategieën voor time-outs en retries. Controleer vóór integratie of het platform aangepaste time-outs ondersteunt, anders worden incidentele langzame responses in productie voortijdig afgebroken door de platformlaag, en de foutmelding laat niet zien of het een gateway-time-out of model-time-out is.
De vier kerncapaciteiten van een model gateway
Protocol-normalisatie is de basis. De request-formaten, response-formaten en foutcodes van verschillende aanbieders worden omgezet naar één standaard. In de ideale situatie kent de bovenliggende business slechts één interfaceformaat, en wisselen van model betekent alleen configuratie aanpassen, niet code. Dit is ook de reden waarom OpenAI-compatibele interfaces populair zijn in China — de meeste ecosysteem-tooling ondersteunt dit formaat.
Routeringsstrategie is waar de waarde van de gateway zit. Je kunt routeren op taaktype, bijvoorbeeld eenvoudige vragen naar Doubao en complexe redeneringen naar DeepSeek; op kosten, waarbij je naar de goedkoopste optie gaat; of op beschikbaarheid, waarbij je automatisch overschakelt bij rate-limiting. Toen we de multi-model routering van SiCore TokenWorks testten, ontdekten we dat een strategie op basis van taakcomplexiteit in klantenservicescenario's de totale kosten flink kon drukken, omdat veel eenvoudige vragen niet het krachtigste redeneermodel nodig hebben.
Rate-limiting met degradatie en gebruiksaggregatie zijn essentials in een productieomgeving. Rate-limiting moet 429-fouten herkennen en automatisch in de wachtrij plaatsen voor retry; degradatie moet overschakelen naar een reservemodel wanneer een dienst niet beschikbaar is. Gebruiksaggregatie verzamelt de verspreide aanroepen, token-verbruik en kosten bij verschillende aanbieders op één plek, handig voor kostenberekening en budgetbeheer. Deze twee zelf bouwen is geen klein werk, vooral gebruiksaggregatie, omdat de factureringslogica per aanbieder verschilt en de reconciliatielogica apart moet worden geschreven.
Gefaseerde implementatie op basis van businessvolwassenheid
Als het project net begint en slechts één model gebruikt, is directe verbinding met de officiële SDK voldoende. Een gateway is dan niet nodig — een extra laag betekent een extra storingspunt. Wacht tot de business stabiel is en een tweede model nodig is, en overweeg dan een gatewaylaag; de overstapkosten zijn dan nog laag.
Als de business al drie of meer modellen gebruikt en beschikbaarheidseisen heeft, is het raadzaam direct een AI API-aggregatieplatform te nemen en de integratie- en onderhoudskosten uit te besteden. Let bij de selectie op drie punten: of het compatibel is met de OpenAI SDK, of het aangepaste time-outs en retries ondersteunt, en of de gebruiksstatistieken duidelijk zijn. Wat betreft een zelfgebouwde gateway: tenzij er specifieke compliance-eisen zijn of het team voldoende operationele capaciteit heeft, is het niet aan te raden om daar in een vroeg stadium in te investeren.
Een model gateway lost de technische complexiteit van multi-model integratie op, niet het probleem van modelcapaciteit. Met de juiste keuze kan het team zijn energie terugbrengen naar de businesslogica zelf.