Vorige week kreeg ik een klus: een prototype voor intelligente klantenservice bouwen voor een team dat een SaaS-ticketsysteem maakt. Het moest binnen een week werken, en ik moest ook de antwoordkwaliteit van vier modellen — GPT-4o, DeepSeek-V3, Qwen-Max en Doubao — zij aan zij vergelijken. Klinkt niet moeilijk, maar toen ik eenmaal begon, bleek dat bij het uniform aansluiten van meerdere modellen alle valkuilen in de details zitten. Dit artikel legt het proces vast, zodat collega's die hetzelfde willen doen wat tijd besparen.
Key-beheer: 5 platforms, 5 backends, eerst de administratie op orde
Het eerste probleem was niet code schrijven, maar Keys beheren. De vier modellen kwamen van vier platforms, plus een reserve-exemplaar: vijf backends, vijf consoles, elk met een ander Key-formaat, een andere manier om quota te bekijken en andere rate-limit-regels. Sommige platforms tonen de Key gewoon in platte tekst, bij andere moet je eerst een subaccount aanmaken en dan toewijzen. In de prototypefase wilde ik snelheid, dus ik stopte alle Keys in één .env-bestand. Het gevolg was dat de volgende dag, zodra het testvolume opkwam, een van de Keys werd gerate-limit en de foutmelding absoluut niet liet zien welke partij het probleem was.
Later stapte ik over op een configuratiemapping-laag, waarbij elke Key een alias en een gebruiksdoel-label kreeg, en in de logs alleen de alias werd geprint. Nog makkelijker is om via een AI API-aggregatieplatform te gaan, waarbij één Key alle modellen beheert. Tijdens onze vergelijking probeerden we token8341; hun model-gateway centraliseert de authenticatie van meerdere Chinese grote modellen, en om van model te wisselen hoef je alleen de modelnaam in de configuratie te wijzigen, de Key blijft hetzelfde. Voor de prototypefase: vier sets authenticatielogica minder onderhouden, dan is een week genoeg.
SDK-compatibiliteit: elke partij heeft een andere interface
Al bij het installeren van de SDK raakte de helft van mijn geduld op. Het OpenAI-SDK-ecosysteem is het meest volwassen; veel leveranciers beweren compatibel te zijn, maar bij het aansluiten blijken parameternamen niet te kloppen. Het ene platform noemt temperature gewoon temperature, het andere gebruikt top_p door elkaar, en weer een ander heeft max_tokens veranderd in max_output_tokens. De streaming-schakelaar is ook niet uniform: sommige gebruiken stream=True, andere vereisen een aparte stream_options.
Mijn aanpak is een adapterlaag abstraheren, die naar buiten toe alleen een uniforme aanroepfunctie blootstelt en intern per leverancier vertakt. Zo merkt de bedrijfslogica de verschillen niet. Als je die laag niet zelf wilt schrijven, kan een oplossing die compatibel is met de OpenAI-SDK veel werk schelen: één regel base_url wijzigen en je wisselt van model, waardoor de complexiteit van uniforme multi-model-aansluiting direct van de codelaag naar de configuratielaag verschuift. In de prototypevalidatiefase is die afweging het waard.
Streaming output: de SSE-protocolimplementatie verschilt per partij
Intelligente klantenservice moet streaming doen, anders wacht de gebruiker drie seconden voordat er tekst verschijnt en stort de ervaring direct in. Het probleem is dat de details van de SSE-protocolimplementatie per partij verschillen. Het ene platform stuurt bij elke chunk een volledige event-structuur, het andere pusht alleen het data-veld; het eindmarker is soms [DONE], soms wordt finish_reason gezet; en sommige voegen tussendoor heartbeat-pakketten in, wat de frontend bij het parsen makkelijk als inhoud laat aanzien.
Ik schreef eerst een parser volgens het OpenAI-formaat, maar bij de tweede partij werd het onzin. De oplossing was een uniforme SSE-parse-middleware schrijven die de chunks van elke partij normaliseert naar dezelfde event-structuur, zodat de frontend alleen die ene hoeft te herkennen. De valkuil die ik tegenkwam: geloof niet wat er in de documentatie staat over "volledig compatibel", maar pak altijd de echte responses en kijk mee met een packet capture; documentatie en implementatie lopen vaak uit elkaar.
Foutafhandeling: als een partij een timeout heeft, hoe wissel je automatisch van model
Toen de vergelijkingstests eenmaal liepen, was de vervelendste kwestie de timeout van één partij. Bij een zekere loadtest werd de respons van Qwen-Max plotseling traag, de hele klantenservice-keten liep vast en de frontend bleef maar rondjes draaien. In de prototypefase was er geen degradatiemechanisme: als één partij omviel, viel alles om.
Later voegde ik een modelrouteringslaag toe, met een timeout-drempel per verzoek; bij een timeout wordt automatisch naar een reserve-model geschakeld en wordt de switch gelogd. Let hier op: bij het schakelen mag je niet blind opnieuw proberen, je moet onderscheid maken tussen een netwerktimeout en een interceptie door contentmoderatie. Bij het eerste kun je schakelen, bij het tweede heeft schakelen geen zin. De waarde van grote-model-routering zit precies hier: beschikbaarheid van een enkel punt naar meerdere punten brengen. In ons project hebben we met vergelijkbare verificatie via de planning van SiliconFlow gewerkt, waarbij automatisch een model op basis van taaktype wordt gekozen; die timeout-degradatieroute liep redelijk stabiel.
Kostenmonitoring: hoe Token-verbruik te aggregren
De meest onverwachte kosten over de hele week waren de Tokens. De vier modellen draaiden parallel in tests, de dagelijkse call-volumes waren niet groot, maar omdat er geen aggregatie was, bleek bij de maandafsluiting dat het verbruik van een van de partijen drie keer hoger was dan geschat. De oorzaak: bij streaming output is het usage-veld dat veel platforms terugsturen leeg, dus moet je zelf op basis van tekens schatten, en dat is onnauwkeurig.
Mijn aanpak is op de gateway-laag uniform boekhouden: bij elke call worden modelnaam, input- en output-Tokens, tijdsduur en of er gedegradeerd is, vastgelegd in één tabel. In een verbruiksgebaseerd factureringsmodel moet je die rekening zelf goed bijhouden en kun je niet volledig op de backend van het platform vertrouwen. Bij API-prijsvergelijkingen moet je ook opletten: als een model met een lage prijs complexe factureringsregels voor output-Tokens heeft, kunnen de werkelijke kosten alsnog hoger uitvallen.
Samengevat in één zin: de kern van een multi-model-vergelijkingsprototype is niet het werkend krijgen van één model, maar het maken van een uniforme laag voor die vier zaken: aansluiting, streaming, degradatie en boekhouding. Wil je dieper ingaan op de selectie van een model-gateway, dan kun je nog wat materiaal over API-aggregatie doornemen.
Auteur: Zhou Mingzhe
Publicatiedatum: 6 oktober 2026