Zapis debugowania: model OpenRouter gpt-oss-120b nie obsługuje żądań w języku chińskim

Korzystając z darmowego interfejsu API modelu udostępnionego przez OpenRouter, napotkałem mylący problem. Przy tej samej strukturze żądania, zmiana jedynie języku w prompcie prowadzi do zupełnie różnych wyników.

Reprodukcja problemu

Przetestowałem model openai/gpt-oss-120b:free. Jedyną różnicą między dwoma żądaniami był język w prompcie. Pierwsze żądanie używało podpowiedzi w języku chińskim:

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": "你是一个专业的本地化翻译专家"
    }
  ]
}'

To żądanie zawsze zwraca kod statusu 429, co oznacza, że żądania są zbyt częste lub przekroczono limit przydziału. Jednak gdy użyłem podpowiedzi w języku angielskim:

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"
    }
  ]
}'

Żądanie uzyskało prawidłową odpowiedź i zwróciło oczekiwane wyjście modelu.

Proces debugowania

Takie niespójne zachowanie jest mylące. Błąd 429 zazwyczaj oznacza ograniczenie szybkości (rate limiting), ale problem polega na tym, że oba żądania zostały wysłane niemal jednocześnie, więc nie powinno tu być problemu z ograniczeniem szybkości. W związku z tym rozpocząłem systematyczne sprawdzanie możliwych przyczyn.

Najpierw sprawdziłem limity przydziału klucza API, potwierdzając, że nie zostały one przekroczone. Następnie zweryfikowałem częstotliwość żądań i odkryłem, że w krótkim czasie wysłano tylko niewielką liczbę żądań, co nie powinno wywołać żadnego mechanizmu ograniczania szybkości. Po wykluczeniu tych częstych przyczyn zauważyłem, że jedyną zmienną był język w prompcie.

Zwracając się o pomoc do potężniejszych modeli AI, skonsultowałem się z Opus 4.6 Max i GPT-5.2 Extra High. Mimo że są one jednymi z najbardziej zaawansowanych modeli językowych, żadnemu z nich nie udało się jednoznacznie wskazać głównej przyczyny tego błędu. Pokazuje to, że niektóre przypadki graniczne lub określone ograniczenia można odkryć tylko w rzeczywistych testach.

Weryfikacja ręczna

Skoro zautomatyzowane narzędzia debugowania nie dały odpowiedzi, postanowiłem ręcznie zweryfikować różne hipotezy. Przetestowałem różne treści w języku chińskim, w tym proste powitania, pytania techniczne i długie teksty. Wszystkie żądania w języku chińskim zwracały błąd 429. Z kolei żądania w języku angielskim o tej samej długości były obsługiwane prawidłowo.

To zjawisko wskazuje na jasny wniosek: model openai/gpt-oss-120b:free nie obsługuje żądań w języku chińskim. Przetwarzanie treści w języku chińskim przez model może uruchamiać niedokumentowany mechanizm ograniczeń, powodując, że API zwraca bezpośrednio błąd 429, zamiast bardziej przyjaznego komunikatu o błędzie.

Podsumowanie doświadczeń

To doświadczenie debugowania ma kilka punktów warte odnotowania. Po pierwsze, komunikaty o błędach API mogą być mylące. Błąd 429 zazwyczaj oznacza ograniczenie szybkości, ale w niektórych przypadkach może maskować inne ograniczenia. Po drugie, choć zautomatyzowane narzędzia debugowania są potężne, nie są wszechmocne. Niektóre ograniczenia specyficzne dla modelu lub platformy można wykryć dopiero podczas rzeczywistych testów.

Inną ważną lekcją jest konieczność weryfikacji hipotez. Gdy wiele zaawansowanych modeli AI nie potrafi znaleźć problemu, ręczne i systematyczne testowanie nadal pozostaje najbardziej niezawodną metodą. Dzięki kontrolowaniu zmiennych i po逐一 weryfikacji można ostatecznie zlokalizować źródło problemu.

W przypadku aplikacji wymagających przetwarzania treści wielojęzycznych przypomina nam to również, aby przy wyborze modelu dokładnie sprawdzać dokumentację lub przeprowadzać pełne testy. Darmowe modele często mają różne ograniczenia, które mogą nie być wyraźnie opisane w głównej dokumentacji.

Powiązane narzędzia

Podczas tłumaczenia treści wielojęzycznych opracowałem rozszerzenie do VS Code Project Translator, przeznaczone specjalnie do wielojęzycznych workflow lokalizacji projektów. Może ono automatycznie rozpoznawać pliki wymagające tłumaczenia, integrować wiele usług tłumaczeniowych i zachowywać spójność kontekstu tłumaczeń.

Pierwotnym założeniem tego rozszerzenia było rozwiązanie problemów związanych z przetwarzaniem treści wielojęzycznych w rzeczywistych projektach. Poprzez automatyzację zmniejsza ono ilość pracy przy ręcznym tłumaczeniu, jednocześnie zapewniając jego jakość. W trakcie rozwoju napotkano również różne ograniczenia API i przypadki graniczne, z których każdy wymagał ostrożnego debugowania i weryfikacji.

Podsumowanie

W trakcie technicznego debugowania zawsze napotyka się nieoczekiwane problemy. Kluczem jest zachowanie cierpliwości, systematyczne sprawdzanie możliwych przyczyn i niedopuszczanie do przeoczenia żadnego szczegółu. Czasami najbardziej zaawansowane narzędzia nie pomagają, a trzeba sięgnąć do najbardziej podstawowych metod weryfikacji.

OpenRouter oferuje bogaty wybór modeli i elastyczne API, co jest jego zaletą. Należy jednak pamiętać, że różne modele mogą mieć różne ograniczenia i cechy, dlatego przed użyciem najlepiej przeprowadzić dokładne testy. Dotyczy to w szczególności modeli darmowych, których ograniczenia są często bardziej restrykcyjne i nieprzejrzyste.

• ←Poprzednia
• Następna→