Het draaien van dezelfde prompt tegen meerdere modellen zou minuten moeten kosten, geen dagen aan integratiewerk. Wanneer elk model achter รฉรฉn enkel endpoint zit, verandert het vergelijken van GPT-5.6, Claude Sonnet 5, en Gemini 3.1 Pro op je eigen prompts van een sprint-taak in een middagexperiment โ en modelselectie houdt op een gok te zijn.
Waarom modelvergelijking meestal niet gebeurt
Vraag een team hoe ze het model achter een bepaalde feature kozen en het eerlijke antwoord is vaak "het is degene die we als eerste hebben geรฏntegreerd." Niet omdat het de beste fit was โ maar omdat overschakelen om te vergelijken integratiewerk zou hebben betekend waar niemand tijd voor had. Het model dat werd uitgerold, is het model dat bleef, en of een ander goedkoper, sneller of nauwkeuriger zou zijn geweest voor die specifieke feature, blijft een open vraag waar niemand aan toekwam.
De reden is wrijving, niet onverschilligheid. In de traditionele opzet betekent elke provider zijn eigen SDK, eigen authenticatie, eigen request- en responseformaat. Drie modellen correct vergelijken betekent drie providers integreren โ drie sets credentials, drie codepaden, drie sets eigenaardigheden in response-parsing om af te handelen. Dat is echt engineeringwerk, en het concurreert met de feature-backlog. Dus de vergelijking wordt uitgesteld, dan laten vallen, en het eerst geรฏntegreerde model wint standaard. De beslissing die door bewijs zou moeten worden gedreven, wordt in plaats daarvan gedreven door wat het makkelijkst was om aan te sluiten.
Het kernprobleem: Een goede modelvergelijking vereist dat je dezelfde prompt tegen meerdere modellen draait. Wanneer elk model achter zijn eigen integratie zit, is dat dagen aan set-upwerk โ dus het gebeurt niet, en modelselectie valt standaard terug op wat als eerste is geรฏntegreerd. Breng de integratiekosten terug tot vrijwel nul en de vergelijking wordt iets dat je daadwerkelijk doet.
Wat er verandert wanneer elk model slechts รฉรฉn endpoint verder is
De doorbraak is architectonisch. Wanneer elk model achter รฉรฉn OpenAI-compatibel endpoint zit, bereikbaar met รฉรฉn credential, dalen de integratiekosten van modelvergelijking tot vrijwel niets. Je integreert niet langer drie providers om drie modellen te vergelijken โ je verandert รฉรฉn string, de modelnaam, en stuurt dezelfde request naar hetzelfde endpoint. De vergelijking die eerder een sprint kostte, kost nu de tijd die het kost om over een lijst te loopen.
Concreet wordt een modelvergelijking zo eenvoudig. Eรฉn client, รฉรฉn endpoint, en een lus over de modellen die je wilt testen:
from openai import OpenAI client = OpenAI( api_key="sk-your-unified-key", base_url="https://api.cometapi.com/v1") prompt = "Vat dit supportticket samen en stel een prioriteitsniveau voor: ..."models = ["gpt-5.5", "claude-sonnet-4-6", "gemini-3.1-pro"] for model in models: response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}] ) print(f"--- {model} ---") print(response.choices[0].message.content)
Dat is het hele testharnas. Dezelfde prompt, dezelfde request-structuur, dezelfde response-parsing โ het enige dat varieert is de modelstring. Er is geen tweede SDK, geen tweede authenticatie, geen tweede responseformaat om af te handelen. Een vierde model aan de vergelijking toevoegen is รฉรฉn string aan de lijst toevoegen. Dit is het verschil tussen modelvergelijking als project en als middagexperiment.
Omdat de vorm van de response identiek is voor elk model op het endpoint, is alles stroomafwaarts van de call โ het parsen, het scoren, het loggen โ รฉรฉn keer geschreven en werkt het voor allemaal. Je kunt dezelfde lus uitbreiden om latentie, tokenverbruik en kosten per model vast te leggen en zo een snelle oogtest te veranderen in een echte kwantitatieve vergelijking. Gepubliceerde head-to-head-verslagen zoals Claude 4.6/4.7 vs GPT-5.4/5.5 zijn nuttig ter oriรซntering, maar het punt van deze workflow is dat je dezelfde vergelijking op je eigen prompts kunt draaien in plaats van op die van iemand anders te vertrouwen.
Voordat je code schrijft: de playground-laag
Voor de allereerste ronde hoef je vaak helemaal geen code te schrijven. Een live vergelijkings-playground โ een webinterface waarin je een prompt typt en de outputs van meerdere modellen naast elkaar ziet โ verkort de feedbacklus nog verder. Het is de snelste manier om een eerste indruk te krijgen van welke modellen het รผberhaupt waard zijn om in een striktere test op te nemen.
De playground en het codeharnas zijn twee fasen van dezelfde workflow en dienen verschillende momenten:
โข De playground is voor de eerste, snelle indruk. Plak een representatieve prompt, zie hoe drie of vier modellen die naast elkaar afhandelen, en sluit direct de duidelijk ongeschikte uit. Dit kost minuten en vereist geen setup. Hier breng je het veld terug van "elk model" naar "de twee of drie die het waard zijn om goed te testen."
โข Het codeharnas is voor de rigoureuze test. Zodra je het veld hebt verkleind, draait de lus hierboven je echte prompts โ idealiter een batch representatieve gevallen, niet slechts รฉรฉn โ en legt de kwantitatieve signalen vast: outputkwaliteit op je daadwerkelijke inputs, latentie en kosten. Hier wordt de beslissing genomen, op basis van bewijs uit je eigen workload.
De volgorde is belangrijk omdat ze de inspanning afstemt op de informatie. De playground kost vrijwel geen moeite en elimineert snel de evidente non-fits. Het codeharnas vergt iets meer moeite en levert bewijs op beslissingsniveau. Samen brengen ze een modelselectievraag van "daar zouden we scope voor moeten maken" naar "we beantwoordden het vanmiddag."
Wat je daadwerkelijk moet meten
Het doel van een A/B-test is een beslissing, dus meet de zaken die de beslissing voor jouw specifieke feature sturen. Vier dimensies dekken de meeste gevallen; hun relatieve gewicht hangt af van wat de feature nodig heeft.
| Dimensie | Wat vast te leggen | Wanneer het de beslissing domineert* |
|---|---|---|
| Uitvoerkwaliteit | Voldoet de output op je echte prompts aan de norm voor de feature? | Bijna altijd het primaire signaal โ maar alleen meetbaar op je eigen inputs, niet op benchmarks. |
| Latentie | Tijd tot eerste token en totale responstijd per model. | Gebruikersgerichte, interactieve features waarbij responsiviteit onderdeel is van de ervaring. |
| Kosten | Tokenverbruik ร prijs per token voor elk model op jouw prompts. | Hoogvolume-features waar de kosten per call op schaal vermenigvuldigen. |
| Consistentie | Levert het model stabiele output over herhaalde runs? | Features die afhankelijk zijn van voorspelbare structuur of formaat, niet alleen een eenmalig goed antwoord. |
De kritieke discipline: meet dit op jouw prompts, niet in abstracto. Een model dat bovenaan een publieke ranglijst staat, kan onderpresteren op jouw specifieke taak, en een goedkoper model kan ruim voldoende zijn voor wat jouw feature daadwerkelijk nodig heeft. Benchmarks en vergelijkingsrapporten โ zoals het 2026 model benchmark-rapport โ zijn een goed startpunt om te bepalen welke modellen je opneemt, maar de test die jouw feature beslist, is degene die op jouw inputs wordt gedraaid.
De meest voorkomende fout: Een model kiezen op benchmarkreputatie in plaats van op prestaties op je eigen workload. Benchmarks meten algemene capaciteit op gestandaardiseerde taken; jouw feature heeft specifieke prompts, specifieke kwaliteitsnormen en specifieke kosten- en latentie-eisen. De A/B-test bestaat juist om de kloof te dichten tussen "goed in het algemeen" en "goed voor dit."
Een concrete A/B-testworkflow
Alles bij elkaar genomen, hier is een workflow die een modelselectievraag in รฉรฉn middag van open naar beantwoord brengt:
1. Stel een representatieve promptset samen. Trek 10โ20 echte voorbeelden van wat deze feature daadwerkelijk verwerkt โ niet รฉรฉn zorgvuldig gekozen prompt, maar een spreiding die het echte spectrum aan inputs weerspiegelt. Deze set is de ruggengraat van de hele test; een goede steekproef maakt het resultaat betrouwbaar.
2. Verklein het veld in de playground. Laat twee of drie representatieve prompts door een side-by-side playground lopen om evidente non-fits te elimineren en uit te komen op de twee of drie modellen die het waard zijn om rigoureus te testen.
3. Draai de volledige set door het codeharnas. Loop je hele promptset over de shortlist van modellen met het hierboven beschreven single-endpointpatroon. Leg output, latentie en tokenverbruik vast voor elk prompt-modelpaar. Omdat het รฉรฉn endpoint is, is dit รฉรฉn script.
4. Scoor tegen de echte lat van je feature. Beoordeel de outputs tegen wat de feature nodig heeft โ nauwkeurigheid, formaat, toon, wat dan ook belangrijk is. Voor sommige features is dit te automatiseren; voor andere is het een menselijke lezing. Scoor op de daadwerkelijke eisen van de feature, niet op een generiek kwaliteitsgevoel.
5. Weeg kwaliteit af tegen kosten en latentie. Het beste model op kwaliteit is niet automatisch de juiste keuze. Als een model dat een derde kost de kwaliteitslat haalt, is dat het model voor een hoogvolume-feature. Maak de trade-off expliciet, met de cijfers die je hebt vastgelegd.
6. Hertest wanneer het ertoe doet. Modellen updaten, er komen nieuwe bij, en de behoeften van je feature verschuiven. Omdat het harnas al bestaat en het endpoint verenigd is, is de vergelijking later opnieuw draaien goedkoop โ zodat je de beslissing kunt herzien wanneer er een nieuw model verschijnt, in plaats van vast te zitten aan de oorspronkelijke keuze.
De taakspecifieke invalshoek is hier belangrijk: het juiste model varieert echt per feature. Een vergelijking gericht op รฉรฉn dimensie โ bijvoorbeeld welk model te gebruiken wanneer hallucinatie ertoe doet โ kan anders uitpakken dan een vergelijking gericht op kosten of snelheid. Precies daarom maakt het draaien van de test op de prioriteiten van je eigen feature, in plaats van een algemeen oordeel te importeren, het resultaat bruikbaar.
Waar dit je brengt
Modelvergelijking gebeurt meestal niet omdat de integratiekosten het tot een project maken dat niemand plant โ dus de selectie valt standaard op wat het eerst is verscheept. Een verenigd, OpenAI-compatibel endpoint haalt die kosten weg: dezelfde prompt tegen elk model is een lus over modelstrings โ dezelfde request, dezelfde parsing, รฉรฉn script. Dat verandert modelselectie van een gok in een experiment dat je in een middag kunt draaien โ verklein het veld in een playground, laat je echte prompts door een harnas lopen, en beslis op kwaliteit, kosten en latentie gemeten op je eigen workload in plaats van iemand andersโ benchmark.
De praktische volgende stap: Stel 10โ20 echte prompts samen voor een feature waar je over twijfelt, en laat ze lopen over GPT-5.5, Claude Sonnet 4.6 en Gemini 3.1 Pro via รฉรฉn enkel endpoint. De hele test is รฉรฉn script en een middag. Wat het je ook vertelt, je kiest je model op bewijs uit je eigen workload โ en dat is de enige vergelijking die de vraag werkelijk beslist.
A/B-testen van modellen is alleen moeilijk wanneer elk model zijn eigen integratie nodig heeft. Achter รฉรฉn OpenAI-compatibel endpoint is modellen vergelijken een lus over modelstrings โ dezelfde prompt, dezelfde request, dezelfde parsing, รฉรฉn script. Verklein het veld in een playground, test je echte prompts in een harnas, en beslis op kwaliteit, kosten en latentie gemeten op jouw inputs. Modelselectie wordt een middagexperiment in plaats van een permanent default.
Bronnen: Workflowpatronen voor modelvergelijking en gedrag van verenigde endpoints geverifieerd aan de hand van de documentatie van het CometAPI-endpoint en huidige OpenAI-compatibele praktijk, juni 2026. Modelnamen weerspiegelen de huidige generatie per juni 2026 en zullen veranderen naarmate providers nieuwe versies uitbrengen.
.