Catatan Debug: Model OpenRouter gpt-oss-120b Tidak Mendukung Permintaan dalam Bahasa Tiongkok

Mencatat pengalaman debugging API, model gpt-oss-120b OpenRouter mengembalikan kesalahan 429 untuk permintaan dalam bahasa Tiongkok, sedangkan permintaan dalam bahasa Inggris merespons secara normal. Fenomena yang aneh.

Saat menggunakan API model gratis yang disediakan oleh OpenRouter, saya mengalami masalah yang membingungkan. Struktur permintaan yang sama, hanya dengan mengubah bahasa prompt, akan menghasilkan hasil yang sangat berbeda.

Reproduksi Masalah

Saya menggunakan model openai/gpt-oss-120b:free untuk pengujian, perbedaan satu-satunya antara kedua permintaan adalah bahasa prompt. Permintaan pertama menggunakan prompt bahasa Tiongkok:

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

Permintaan ini selalu mengembalikan kode status 429, yang menunjukkan permintaan terlalu sering atau melebihi batas kuota. Namun ketika saya menggunakan prompt bahasa Inggris:

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

Permintaan dapat merespons secara normal, mengembalikan output model yang diharapkan.

Proses Debug

Perilaku yang tidak konsisten ini membingungkan. Kesalahan 429 biasanya berarti pembatasan laju, namun masalahnya kedua permintaan dikirim hampir bersamaan, seharusnya tidak ada masalah pembatasan laju. Oleh karena itu, saya mulai secara sistematis memeriksa kemungkinan penyebabnya.

Saya pertama kali memeriksa batas kuota kunci API, mengonfirmasi tidak melebihi batas. Kemudian memverifikasi frekuensi permintaan, ditemukan hanya sedikit permintaan yang dikirim dalam waktu singkat, seharusnya tidak memicu mekanisme pembatasan laju. Setelah mengecualikan penyebab umum ini, saya menyadari variabel tunggal adalah bahasa prompt.

Saat mencari bantuan dari model AI yang lebih canggih, saya berkonsultasi dengan Opus 4.6 Max dan GPT-5.2 Extra High. Meski mereka adalah salah satu model bahasa paling canggih saat ini, keduanya gagal secara jelas mengidentifikasi penyebab akar bug ini. Hal ini menunjukkan beberapa kasus tepi atau keterbatasan spesifik mungkin hanya dapat ditemukan melalui pengujian nyata.

Verifikasi Manual

Karena alat debugging otomatis gagal memberikan jawaban, saya memutuskan untuk memverifikasi berbagai hipotesis secara manual. Menguji berbagai konten bahasa Tiongkok, termasuk sapaan sederhana, pertanyaan teknis, dan teks panjang, semua permintaan bahasa Tiongkok mengembalikan kesalahan 429. Sebaliknya, permintaan dalam bahasa Inggris dengan panjang yang sama dapat merespons secara normal.

Fenomena ini mengarah pada kesimpulan yang jelas: model openai/gpt-oss-120b:free tidak mendukung permintaan bahasa Tiongkok. Pemrosesan model terhadap konten bahasa Tiongkok mungkin memicu mekanisme keterbatasan yang tidak dijelaskan dalam dokumentasi, sehingga API langsung mengembalikan kesalahan 429 alih-alih pesan kesalahan yang lebih ramah.

Ringkasan Pengalaman

Pengalaman debugging ini memiliki beberapa poin yang layak diperhatikan. Pertama, pesan kesalahan API mungkin menyesatkan. Kesalahan 429 biasanya menunjukkan pembatasan laju, namun dalam beberapa kasus dapat menyembunyikan keterbatasan lain. Kedua, meski alat debugging otomatis canggih, bukan sempurna. Beberapa keterbatasan spesifik model atau platform hanya dapat ditemukan melalui pengujian nyata.

Pelajaran penting lainnya adalah kebutuhan verifikasi hipotesis. Ketika beberapa model AI canggih gagal menemukan masalah, pengujian manual yang sistematis tetap merupakan metode paling andal. Dengan mengontrol variasi dan memverifikasi satu per satu, akhirnya dapat menentukan penyebab akar masalah.

Untuk aplikasi yang perlu menangani konten multibahasa, ini juga mengingatkan kita untuk dengan cermat memeriksa dokumentasi atau melakukan pengujian yang cukup saat memilih model. Model gratis seringkali memiliki berbagai keterbatasan, yang mungkin tidak dijelaskan secara jelas dalam dokumentasi utama.

Alat Terkait

Saat menangani terjemahan konten multibahasa, saya mengembangkan ekstensi VS Code Project Translator, khusus untuk alur kerja lokalisasi multibahasa proyek. Ekstensi ini dapat secara otomatis mengidentifikasi file yang perlu diterjemahkan, mengintegrasikan berbagai layanan terjemahan, dan menjaga konsistensi konteks terjemahan.

Ekstensi ini dirancang untuk mengatasi titik nyata pengolahan multibahasa yang dihadapi dalam proyek nyata. Dengan cara otomatis, mengurangi beban kerja terjemahan manual, sambil menjamin kualitas terjemahan. Selama proses pengembangan juga mengalami berbagai keterbatasan API dan kasus tepi, setiap masalah memerlukan debugging dan verifikasi yang cermat.

Kesimpulan

Dalam proses debugging teknis, selalu akan ada masalah yang tidak terduga. Kunci adalah tetap sabar, secara sistematis memeriksa kemungkinan penyebab, tidak melewatkan detail apa pun. Kadang alat paling canggih juga tidak bisa membantu, malah membutuhkan metode verifikasi paling dasar.

OpenRouter menyediakan berbagai pilihan model dan API yang fleksibel, ini adalah keunggulannya. Namun perlu diperhatikan, berbagai model mungkin memiliki keterbatasan dan karakteristik yang berbeda, sebaiknya melakukan pengujian yang cukup sebelum penggunaan. Model gratis terutama demikian, keterbatasannya seringkali lebih ketat dan tidak transparan.