Debug-logboek: OpenRouter gpt-oss-120b model ondersteunt geen Chinese verzoeken

Bij het gebruik van de gratis model-API van OpenRouter liep ik tegen een verwarrend probleem aan. Dezelfde verzoekstructuur leidde tot totaal verschillende resultaten, enkel door de taal van de prompt aan te passen.

Probleemreproductie

Ik testte met het openai/gpt-oss-120b:free model. Het enige verschil tussen de twee verzoeken was de taal van de prompt. Het eerste verzoek gebruikte een Chinese prompt:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "你是一个专业的本地化翻译专家"
    }
  ]
}'

Dit verzoek gaf steeds de statuscode 429 terug, wat betekent dat het verzoek te vaak werd verzonden of de limiet was overschreden. Echter, toen ik een Engelse prompt gebruikte:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-or-v1-xxxxxxxxxxxxxxxxxxxxxx" \
  -d '{
  "model": "openai/gpt-oss-120b:free",
  "messages": [
    {
      "role": "user",
      "content": "You are a professional localization translation expert"
    }
  ]
}'

werd het verzoek normaal verwerkt en werd de verwachte modeluitvoer geretourneerd.

Debugproces

Dit inconsistente gedrag was verwarrend. Een 429-fout betekent meestal een rate limiet, maar het probleem was dat beide verzoeken bijna gelijktijdig werden verzonden, zodat een rate limiet geen rol had kunnen spelen. Dus begon ik systematisch mogelijke oorzaken uit te sluiten.

Ik controleerde eerst de quotumlimieten van de API-sleutel en bevestigde dat deze niet waren overschreden. Vervolgens verifieerde ik de verzoekfrequentie en ontdekte dat er slechts een klein aantal verzoeken in korte tijd werd verzonden, wat geen enkele rate limiet-mechanisme had mogen activeren. Na het uitsluiten van deze veelvoorkomende oorzaken, viel op dat de enige variabele de taal van de prompt was.

Bij het vragen om hulp van krachtigere AI-modellen raadpleegde ik Opus 4.6 Max en GPT-5.2 Extra High. Hoewel dit enkele van de meest geavanceerde taalmodellen van dit moment zijn, slaagden ze er niet in om de hoofdoorzaak van deze bug expliciet aan te wijzen. Dit toont aan dat sommige edge cases of specifieke beperkingen alleen door daadwerkelijk testen aan het licht kunnen komen.

Handmatige verificatie

Aangezien de geautomatiseerde debugtools geen antwoord konden geven, besloot ik verschillende hypotheses handmatig te verifiëren. Ik testte verschillende Chinese inhoud, waaronder eenvoudige begroetingen, technische vragen en lange teksten. Alle Chinese verzoeken retourneerden een 429-fout. Daarentegen werkten Engelse verzoeken van dezelfde lengte normaal.

Dit fenomeen wijst op een duidelijke conclusie: het openai/gpt-oss-120b:free model ondersteunt geen Chinese verzoeken. De verwerking van Chinese inhoud door het model activeert mogelijk een ongedocumenteerde beperkingsmechanisme, waardoor de API direct een 429-fout retourneert in plaats van een gebruiksvriendelijker foutmelding.

Lessen

Bij deze debugervaring zijn enkele punten het vermelden waard. Ten eerste kunnen API-foutmeldingen misleidend zijn. Een 429-fout geeft meestal een rate limiet aan, maar kan in sommige gevallen andere beperkingen verbergen. Ten tweede zijn geautomatiseerde debugtools krachtig, maar niet almachtig. Sommige modelspecifieke of platformspecifieke beperkingen worden alleen gevonden door daadwerkelijk te testen.

Een andere belangrijke les is de noodzaak van hypothese-verificatie. Wanneer meerdere geavanceerde AI-modellen het probleem niet kunnen vinden, blijft handmatig, systematisch testen de meest betrouwbare methode. Door variabelen te controleren en ze een voor een te verifiëren, kan uiteindelijk de bron van het probleem worden gelokaliseerd.

Voor applicaties die meertalige inhoud moeten verwerken, dient dit als een herinnering om bij het kiezen van een model de documentatie zorgvuldig te raadplegen of grondig te testen. Gratis modellen hebben vaak verschillende beperkingen die mogelijk niet expliciet in de belangrijkste documentatie worden vermeld.

Gerelateerde tools

Bij het verwerken van meertalige vertalingen heb ik een VS Code-extensie ontwikkeld: Project Translator, speciaal voor meertalige lokalisatieworkflows van projecten. Het kan automatisch bestanden identificeren die vertaling nodig hebben, meerdere vertaalservices integreren en de contextuele consistentie van vertalingen behouden.

Het ontwerpdoel van deze extensie is om de knelpunten bij meertalige verwerking in echte projecten op te lossen. Door automatisering wordt de werklast voor handmatige vertaling verminderd zonder de vertaalkwaliteit in gevaar te brengen. Tijdens het ontwikkelingsproces kwamen we ook verschillende API-beperkingen en edge cases tegen, waarbij elk probleem zorgvuldige foutopsporing en verificatie vereiste.

Conclusie

Bij technische foutopsporing kom je altijd onverwachte problemen tegen. De sleutel is geduld te bewaren, mogelijke oorzaken systematisch uit te sluiten en geen enkel detail over het hoofd te zien. Soms kunnen de meest geavanceerde tools niet helpen en heb je de meest basisverificatiemethoden nodig.

OpenRouter biedt een rijke keuze aan modellen en een flexibele API, wat zijn sterkte is. Maar men moet er ook voorzichtig mee zijn, omdat verschillende modellen verschillende beperkingen en kenmerken kunnen hebben. Het is het beste om voor gebruik grondig te testen. Dit geldt zeker voor gratis modellen, waarvan de beperkingen vaak strikter en minder transparant zijn.

• ←Vorige
• Volgende→