Registro di debug: il modello OpenRouter gpt-oss-120b non supporta le richieste in cinese

Utilizzando l’API del modello gratuito fornita da OpenRouter, ho riscontrato un problema sconcertante. Con la stessa struttura di richiesta, modificando solo la lingua del prompt, si ottengono risultati completamente diversi.

Riproduzione del problema

Ho utilizzato il modello openai/gpt-oss-120b:free per i test; l’unica differenza tra le due richieste era la lingua del prompt. La prima richiesta utilizzava un prompt in cinese:

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

Questa richiesta restituiva sempre il codice di stato 429, indicando che le richieste erano troppo frequenti o superavano i limiti della quota. Tuttavia, quando utilizzavo un prompt in inglese:

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

La richiesta riusciva e restituiva l’output previsto dal modello.

Processo di debug

Questo comportamento inconsistente era confuso. L’errore 429 di solito significa un limite di velocità, ma il problema era che le due richieste venivano inviate quasi contemporaneamente, quindi non dovrebbero esserci problemi di limite di velocità. Ho quindi iniziato a indagare sistematicamente le possibili cause.

Per prima cosa ho controllato i limiti di quota della chiave API, confermando che non erano stati superati. Successivamente ho verificato la frequenza delle richieste, scoprendo che erano state inviate solo poche richieste in un breve periodo, il che non avrebbe dovuto attivare alcun meccanismo di limite di velocità. Escluse queste cause comuni, ho notato che l’unica variabile era la lingua del prompt.

Chiedendo aiuto a modelli AI più potenti, ho consultato Opus 4.6 Max e GPT-5.2 Extra High. Sebbene siano tra i modelli linguistici più avanzati attualmente disponibili, nessuno dei due ha indicato chiaramente la causa principale di questo bug. Ciò dimostra che alcuni casi limite o restrizioni specifiche possono essere scoperti solo attraverso test effettivi.

Verifica manuale

Poiché gli strumenti di debug automatizzati non hanno fornito una risposta, ho deciso di verificare manualmente varie ipotesi. Ho testato diversi contenuti in cinese, tra cui semplici saluti, domande tecniche e testi lunghi; tutte le richieste in cinese restituivano un errore 429. Al contrario, le richieste in inglese della stessa lunghezza ricevevano una risposta normale.

Questo fenomeno porta a una conclusione chiara: il modello openai/gpt-oss-120b:free non supporta le richieste in cinese. L’elaborazione di contenuti in cinese da parte del modello potrebbe attivare un meccanismo di restrizione non documentato, causando la restituzione diretta di un errore 429 da parte dell’API invece di un messaggio di errore più amichevole.

Lezioni apprese

Questa esperienza di debug presenta diversi punti degni di nota. Innanzitutto, i messaggi di errore delle API possono essere fuorvianti. L’errore 429 indica solitamente un limite di velocità, ma in alcuni casi potrebbe nascondere altre restrizioni. In secondo luogo, sebbene gli strumenti di debug automatizzati siano potenti, non sono onniscienti. Alcune restrizioni specifiche per modello o piattaforma possono essere scoperte solo attraverso test effettivi.

Un’altra lezione importante è la necessità di verificare le ipotesi. Quando più modelli AI avanzati non sono riusciti a trovare il problema, i test manuali e sistematici sono rimasti il metodo più affidabile. Controllando le variabili e verificando una per una, alla fine è stato possibile localizzare la radice del problema.

Per le applicazioni che necessitano di gestire contenuti multilingua, questo ci ricorda anche di consultare attentamente la documentazione o di condurre test approfonditi quando si sceglie un modello. I modelli gratuiti hanno spesso varie restrizioni che potrebbero non essere chiaramente indicate nella documentazione principale.

Strumenti correlati

Quando gestisco la traduzione di contenuti multilingua, ho sviluppato un’estensione VS Code Project Translator, dedicata al flusso di lavoro di localizzazione multilingua dei progetti. Può identificare automaticamente i file che necessitano di traduzione, integrare vari servizi di traduzione e mantenere la coerenza contestuale della traduzione.

L’intento alla base della progettazione di questa estensione è risolvere i problemi di elaborazione multilingua incontrati nei progetti reali. Riducendo il carico di lavoro della traduzione manuale attraverso l’automazione, garantendo al contempo la qualità della traduzione. Anche durante lo sviluppo ho riscontrato varie restrizioni API e casi limite, ognuno dei quali ha richiesto un attento debug e verifica.

Conclusione

Nel processo di debug tecnico, si incontreranno sempre alcuni problemi imprevisti. La chiave è mantenere la pazienza, indagare sistematicamente le possibili cause e non trascurare alcun dettaglio. A volte gli strumenti più avanzati non sono d’aiuto e sono invece necessari i metodi di verifica più basilari.

OpenRouter offre una ricca selezione di modelli e un’API flessibile, che è il suo vantaggio. Allo stesso tempo, è necessario notare che diversi modelli possono avere diversi limiti e caratteristiche, quindi è meglio eseguire test sufficienti prima dell’uso. Questo è particolarmente vero per i modelli gratuiti, i cui limiti sono spesso più rigidi e trasparenti.

• ←Precedente
• Successivo→