Errore 500: cosa fare quando hy3 fallisce

Un 500 significa che il server ha incontrato un errore interno imprevisto durante l'elaborazione. Di solito non è un problema di formato della richiesta, ma un guasto temporaneo lato server o lato modello a monte.

500 Internal Server Error è un errore interno imprevisto del server. La maggior parte dei 500 sono guasti temporanei di un nodo e passano con un retry e backoff esponenziale. Se persiste, probabilmente una combinazione specifica di parametri colpisce un caso limite non gestito.

hy3 è fornito da Tencent. Tutto in questa pagina — cause, soluzioni e dati misurati — è ricavato dal comportamento reale di questo modello al livello del gateway.

Su questo gateway, la causa più comune è: Un guasto temporaneo del servizio modello a monte. La prima azione consigliata è: Riprova dopo una breve attesa: la maggior parte dei 500 è temporanea.

Cause comuni

  • Un guasto temporaneo del servizio modello a monte
  • La richiesta è finita su un nodo in riavvio
  • Il corpo della richiesta ha attivato un caso limite non gestito
  • Un picco di carico momentaneo

Come risolvere

  • Riprova dopo una breve attesa: la maggior parte dei 500 è temporanea
  • Prova un altro modello dello stesso fornitore per capire se è specifico
  • Semplifica il corpo (togli i parametri rari) e riprova
  • Se persiste, contattaci indicando l'ora della richiesta

Retry con backoff esponenziale

Il codice qui sotto ritenta quando hy3 restituisce 500: fino a 5 tentativi, con attesa crescente e jitter casuale per evitare che le chiamate concorrenti ritentino insieme. Leggi base URL e API key dalle variabili d’ambiente, non inserirle hardcoded.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'hy3'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

Dati chiave di questo modello

Endpoint APIhttps://api.airai.cc/v1
Compatibile con OpenAIOpenAI-compatible
FornitoreTencent
Contesto256K
FunzionalitàReasoning, Tools, Open Weights
Formati APIopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Formula di fatturazionep * 0 + cr * 0 + cc * 0 + c * 0

Domande frequenti

Condividere una key tra più servizi rende 500 più probabile?

È soprattutto una questione di quota, non un guasto del modello. Sia alzare il limite del piano sia ridurre la frequenza delle chiamate aiuta. La fatturazione segue p * 0 + cr * 0 + cc * 0 + c * 0: senza output nessun addebito. Con fatturazione p * 0 + cr * 0 + cc * 0 + c * 0, il costo degli output lunghi deriva soprattutto dai token di output. Controlla prima saldo e limiti di velocità nella console, poi il codice.

L’SDK ufficiale già ritenta: serve una mia logica di retry?

Di solito non serve cambiare il codice, solo il ritmo delle chiamate. Con la fatturazione p * 0 + cr * 0 + cc * 0 + c * 0, le richieste fallite non rientrano nel consumo. Imposta il limite di ritenti a 3–5 e aggiungi del jitter. Usa il backoff esponenziale per gli errori ritentabili e restituisci subito l’errore per gli altri.

Devo cambiare i parametri quando hy3 restituisce 500?

I parametri vanno cambiati; riprovare da solo non aiuterà. È un problema di configurazione lato client; lato server non cambia nulla. I tag delle capacità sono Reasoning, Tools, Open Weights e i limiti dei parametri derivano da quel set. Sugli errori di parametro fallisci subito invece di sprecare ritenti. Tronca o riassumi gli input lunghi: riduce notevolmente 500.

Le richieste concorrenti vanno messe in coda o limitate direttamente?

Abbassa prima la concorrenza: la maggior parte dei problemi di throughput scompare. Questo modello ha una finestra di contesto di 256K ed è di Tencent. Un contesto di 256K significa che input lunghi aumentano la latenza del primo token. Appiana i picchi con batch o una coda: più stabile che alzare la concorrenza al volo.

Altri errori su questo modello

Altri modelli con lo stesso errore

Torna alla pagina del modello

Dati aggiornati: 2026-10-10 18:30

Supporto tecnicoAssistenza online
Torna in alto