Als een geslaagd verzoek toch mislukt
Stel je voor dat je al weken met hetzelfde personage praat. De stem is vertrouwd. De taal is consistent. De antwoorden voelen scherp en levendig.
Dan, zonder dat het personage of het model is veranderd, voelt er iets niet goed.
Het volgende antwoord doet er tien seconden over om te beginnen. Een functie die afhankelijk is van gestructureerde output, werkt opeens niet meer. Het personage begint te wauwelen, voegt flarden uit een andere taal in of antwoordt in een stijl die bij een veel zwakker model lijkt te horen.
Vanuit de server gezien is er niets misgegaan. De API gaf 200 OK terug. Er kwamen tokens binnen. Het verzoek werd gefactureerd.
Vanuit de gebruiker gezien is het model gewoon slechter geworden.
Die kloof is de reden dat we voor Reverie een canary voor aanbieders en een quarantainesysteem voor routering hebben gebouwd.
Eén modelnaam, veel serveromgevingen
OpenRouter is onze belangrijkste gateway voor modellen. Een van de sterke punten is dat één model door veel onafhankelijke inferentieaanbieders kan worden gedraaid. Is één aanbieder niet beschikbaar, dan kan een andere het verzoek overnemen. Dat geeft ons meer capaciteit, scherpere prijzen en meer veerkracht dan wanneer we van één endpoint afhankelijk zouden zijn.
Het levert ook een verborgen variabele op.
De modelnaam blijft misschien hetzelfde, maar de infrastructuur die het model draait, kan van verzoek tot verzoek verschillen. Elke aanbieder kan een andere inferentie-engine, hardwareconfiguratie, kwantisatieniveau, parser, chattemplate, wachtrij of extra beleidslaag gebruiken.
De documentatie van OpenRouter over providerroutering legt uit dat de standaardroutering kijkt naar recente beschikbaarheid en prijs, met andere aanbieders als terugvaloptie. Dat zijn belangrijke signalen—maar een endpoint kan online en goedkoop zijn en toch een onaanvaardbaar resultaat opleveren voor een bepaald product.
OpenRouter heeft ook openlijk geschreven over meetbare verschillen tussen aanbieders die hetzelfde model draaien. In theorie zouden identieke gewichten met identieke precisie zich hetzelfde moeten gedragen. In productie is het draaien van een groot model complex, en ontstaan er verschillen.
Wat we bedoelen met “modeldegradatie”
“Modeldegradatie” is geen gestandaardiseerde diagnose, en het betekent niet automatisch dat een aanbieder opzettelijk een kleiner model heeft ingezet.
We gebruiken de term operationeel: een serverendpoint is gedegradeerd als het onder representatieve prompts niet langer het gedrag, de mogelijkheden of de interactieve prestaties behoudt die we van het gevraagde model verwachten—ook al slaagt het verzoek technisch gezien misschien wel.
Voor Reverie zijn dit de duidelijkste vormen:
- Degradatie in latentie — de verbinding slaagt, maar de tijd tot het eerste token wordt zo lang dat het gevoel van een live gesprek verdwijnt.
- Degradatie in mogelijkheden — een endpoint dat gestructureerde output zou moeten ondersteunen, geeft misvormde tekst terug of voldoet niet meer aan het schema.
- Degradatie in gedrag — antwoorden raken beschadigd, worden onsamenhangend of onverwacht repetitief, of dwalen zichtbaar af naar een andere taal.
- Beleidsconflict — een upstream host voegt een eigen filterlaag toe, waardoor een scène die Reverie ondersteunt verandert in een weigering, een leeg antwoord of een afgekapt antwoord.
Er kunnen veel oorzaken zijn. Kwantisatie met lagere precisie kan invloed hebben op moeilijke prompts, zoals zowel de documentatie van OpenRouter als gepubliceerd onderzoek naar kwantisatie aangeeft. Maar kwantisatie is geen verklaring voor alles: bugs in inferentie-engines, toolparsers, fouten in tokenizers of chattemplates, overbelaste wachtrijen en middleware aan de kant van de aanbieder kunnen net zo belangrijk zijn. OpenRouter heeft vastgesteld dat, met name bij toolaanroepen, de implementatie van parsers vaak een grotere bron van variatie is dan precisie alleen.
De belangrijke vraag is niet “Welke oorzaak klinkt het verdachtst?” Maar “Kunnen we het endpoint isoleren en de fout reproduceren?”
Twee gevallen die het probleem concreet maakten
Voor ons was dit geen theoretische zorg.
In één vastgepinde vergelijking beschadigde een aanbieder het begin van 19 van de 20 antwoorden door er leestekens of een fragment van een ongerelateerd token in te voegen. Bij veertien andere hosts die hetzelfde model draaiden, kwam het probleem 0 keer in 49 antwoorden voor. In roleplay, waar het eerste teken vaak een Markdown-markering voor nadruk is, kon één verdwaalde byte bovendien de opmaak van het hele antwoord breken.
In een andere test produceerde één endpoint in 3 van de 3 generaties een ernstige mengeling van Portugees en Spaans. Dezelfde prompt bleef Portugees op de officiële host van het model en op de andere geteste hosts met dezelfde precisieklasse. Daarmee was “het model is gewoon inconsistent” een zwakke verklaring; het defect volgde het serverendpoint.
Deze fouten zijn subtiel, omdat ze niet per se een foutmelding opleveren. Traditionele uptime-monitoring ziet een gezonde API. De gebruiker ziet een personage dat opeens niet meer fatsoenlijk kan praten.
Ons antwoord: test elke route, niet alleen het model
Elke dertig minuten zoekt onze canary uit welke aanbieders op dat moment het standaard chatmodel van Reverie draaien. Daarna stuurt hij naar elke aanbieder een kleine reeks synthetische verzoeken, vastgepind op alleen die aanbieder en met terugvalopties uitgeschakeld.
Dat vastpinnen is belangrijk. Mag een test terugvallen, dan kan een gezonde tweede aanbieder de fout van de eerste verbergen. We moeten precies weten welke serveromgeving het resultaat heeft opgeleverd.
Het systeem test vier smalle afspraken die een machine kan beoordelen.
1. Tijd tot het eerste token
Bij een gestreamd gesprek is doorvoersnelheid maar de helft van de ervaring. Het eerste token bepaalt hoe lang de gebruiker naar een laadicoontje zit te staren.
We meten dit rechtstreeks uit de stream. Een aanbieder die binnen tien seconden geen tekst produceert, zakt voor de latentietest. De drempel is bewust ruim, en één trage ronde is niet genoeg om een host te verwijderen; tijdelijke drukte in een wachtrij komt nu eenmaal voor.
2. Filtering en stille weigeringen
We sturen een vaste voortzetting van een roleplay die representatief is voor het verkeer dat Reverie ondersteunt. De test controleert de reden waarom de generatie stopte, weigeringspatronen met hoge zekerheid en lege output.
We draaien de test ook op hosts waarvan we weten dat ze filteren, als positieve controle. Slaagt zo'n controle onverwacht, dan feliciteren we niet alle andere aanbieders—dan markeren we de test zelf als zwak. Een test die zijn bekende foutpatroon niet meer kan opsporen, is geen bewijs van gezondheid.
3. Gestructureerde output
We vragen om een klein object met een vast schema en valideren het resultaat. Een transportfout en misvormde output behandelen we verschillend: een verbroken verbinding zegt dat de aanbieder onbereikbaar was, terwijl een geslaagde generatie die niet aan het schema voldoet, wijst op een achteruitgang in mogelijkheden.
Dat onderscheid doet ertoe. “Het endpoint zegt de parameter te ondersteunen” en “het endpoint houdt zich er betrouwbaar aan” zijn niet dezelfde belofte.
4. Taalintegriteit
Reverie ondersteunt 17 interfacetalen, dus een rooktest alleen in het Engels zou een deel van de fouten missen die onze gebruikers echt tegenkomen.
De canary rouleert met synthetische roleplayprompts langs onze ondersteunde talen. Een lokale, deterministische taaldetector zoekt naar een overtuigende taalwissel in het hele antwoord, aanhoudend door elkaar gebruikte talen en duidelijke beschadiging van de tekencodering. Hij stuurt geen echte gesprekken naar de test en vraagt geen ander model om een subjectief oordeel.
Dubbelzinnige of heel korte output is onbeslist, geen fout. Wordt er een taalfout gevonden, dan doet de canary meteen twee bevestigingspogingen en is er een meerderheid nodig. In de volgende ronde wordt dezelfde taal herhaald, zodat een aanbieder niet aan de regel van opeenvolgende rondes kan ontsnappen alleen omdat de rotatie verder is gegaan.
We hebben het zo ontworpen dat het zijn eigen conclusies wantrouwt
Automatisch inferentiecapaciteit weghalen is nuttig, maar een vals positief resultaat kan een grotere storing veroorzaken dan het defect dat het moest oplossen. De canary heeft daarom een aantal remmen:
- Transportfouten tellen niet als kwaliteitsfouten. Time-outs, rate limits en 5xx-responses bevriezen de score in plaats van een reeks richting schorsing te verlengen.
- Eén slechte ronde is niet genoeg. Een aanbieder moet zakken voor twee opeenvolgende halfuurlijkse rondes.
- Observeren en handhaven zijn gescheiden. We kunnen het hele systeem in observatiemodus draaien, vastleggen welke hosts geschorst zouden worden, beheerders waarschuwen en vals-positieven meten voordat we automatische acties inschakelen.
- Capaciteit heeft een ondergrens. De canary schorst een aanbieder niet als er daardoor minder dan twee productiehosts zouden overblijven. In plaats daarvan waarschuwt hij een beheerder.
- Herstel wordt getest. Geschorste aanbieders blijven testbaar. Twee opeenvolgende foutloze rondes herstellen een host eerder.
- Herhaalde fouten worden geleidelijk zwaarder bestraft. Een schorsing duurt bij een eerste incident één dag, bij het volgende drie dagen en daarna zeven dagen. Na veertien foutloze dagen vervaagt de overtredingsgeschiedenis en begint de ladder opnieuw.
Het doel is niet om aanbieders te straffen. Het is om gebruikersverkeer weg te leiden van een route die aantoonbaar en reproduceerbaar ongezond is, met een duidelijke weg terug zodra het probleem is opgelost.
Drie beschermingslagen
De uiteindelijke routeringsbeslissing combineert drie soorten uitsluitingen:
- Beoordeelde ingebouwde uitsluitingen voor defecten of beleidsconflicten die we hebben gemeten en niet per ongeluk opnieuw willen introduceren.
- Runtime-uitsluitingen bij incidenten die een beheerder direct kan toevoegen, zonder op een deployment te wachten.
- Tijdelijke canary-schorsingen voor aanbieders die over de geautomatiseerde foutdrempel gaan.
Deze lijsten worden samengevoegd in de voorkeur provider.ignore van OpenRouter wanneer Reverie een verzoek opbouwt. De gebruiker hoeft niet steeds opnieuw te proberen tot het toeval een betere aanbieder kiest; de ongezonde route wordt simpelweg niet meer overwogen.
Elke geautomatiseerde beslissing wordt vastgelegd, beheerders krijgen een melding bij betekenisvolle overgangen en een schorsing kan zo nodig handmatig worden opgeheven.
Wat dit systeem wel—en niet—garandeert
De canary is bewust smal. Hij kan met code latentie, geldigheid van het schema, filtering met hoge zekerheid, taalintegriteit en de gezondheid van de tekencodering beoordelen. Hij doet niet alsof hij kan beoordelen of een personage grappig genoeg is, emotioneel opmerkzaam genoeg of trouw aan een complexe persoonlijkheid.
Voor die bredere vragen zijn nog steeds evaluaties nodig op basis van representatieve prompts, menselijke beoordeling, telemetrie uit productie en—het belangrijkste—meldingen van gebruikers.
Het systeem betekent ook niet dat elk vreemd antwoord bewijst dat een model gedegradeerd is. Generatieve modellen zijn probabilistisch. In een lang gesprek kan tegenstrijdige context zich opstapelen. Een personagebeschrijving kan instructies bevatten die met elkaar botsen. Soms is een vreemd antwoord gewoon een vreemd antwoord.
Wat wel is veranderd: “hetzelfde model” is niet langer het eindpunt van ons onderzoek. We kunnen nu de serverroute isoleren, objectieve fouten reproduceren en het getroffen verkeer ervan weghouden.
Betrouwbaarheid betekent de ervaring behouden
Routering via meerdere aanbieders blijft waardevol. Het geeft Reverie de capaciteit en veerkracht om gesprekken beschikbaar te houden als afzonderlijke endpoints uitvallen.
Maar veerkracht is meer dan alleen een HTTP-response ontvangen. Een antwoord dat te laat binnenkomt, de vereiste structuur verliest, ondersteunde content weigert of opeens van taal wisselt, is geen gezond resultaat alleen omdat op de factuur staat dat het verzoek is geslaagd.
Voor een product met AI-personages betekent betrouwbaarheid iets menselijkers: het personage moet nog steeds als zichzelf aanvoelen, welke machine er ook toevallig zijn stem levert.
Dat is de norm die onze nieuwe beveiligingen voor routering moeten beschermen.
Merk je een plotselinge verandering in de kwaliteit of de taal van antwoorden, stuur ons dan een melding met de naam van het model en het tijdstip bij benadering. Met die meldingen kunnen we de ervaring die jij had koppelen aan de exacte route die het antwoord leverde.