Platform For AI:Annexe : Codes d'état du service et erreurs courantes

404 Introuvable

400 Requête incorrecte

Le format du corps de la requête est incorrect. Vérifiez attentivement le format du corps de la requête, tel que la structure JSON, les noms des champs et les types de données.

Échec de l'autorisation 401

Délai d'attente 504

450 : Requête rejetée car la file d'attente est pleine

Lorsqu'une instance de calcul côté serveur reçoit une requête, elle place d'abord la requête dans une file d'attente. Lorsqu'un worker de l'instance devient disponible, il récupère les données de la file d'attente pour traitement. Le nombre par défaut de workers est de 5, que vous pouvez ajuster en utilisant le champ metadata.rpc.worker_threads dans le fichier JSON de création d'un service. Si le temps de traitement des workers est trop long, les requêtes peuvent s'accumuler dans la file d'attente. Lorsque la file d'attente est pleine, l'instance rejette immédiatement les nouvelles requêtes avec un code d'état 450 pour éviter qu'une mise en file d'attente excessive n'augmente la latence et ne rende le service indisponible. La longueur par défaut de la file d'attente est de 64, que vous pouvez ajuster en utilisant le champ metadata.rpc.max_queue_size dans le fichier JSON de création d'un service.

503 aucun upstream sain

Vous recevez une erreur 503 avec le message « no healthy upstream » lors du débogage en ligne :

Résolvez le problème comme suit :

1. Vérifiez l'état de l'instance. Si l'instance s'est arrêtée, redémarrez le service.

2. Si l'état du service est Running, l'instance peut manquer de ressources, telles que CPU, mémoire ou mémoire GPU, ce qui entraîne un manque d'espace tampon.

   • Si vous utilisez des ressources publiques, essayez d'effectuer l'appel à nouveau pendant les heures creuses, ou passez à une spécification de ressource ou à une région différente.

   • Si vous utilisez une ressource dédiée (groupe de ressources EAS), assurez-vous que le groupe de ressources a réservé suffisamment de CPU, de mémoire et de mémoire GPU pour l'instance. Nous recommandons de laisser au moins 20 % des ressources libres comme tampon.

3. Un autre scénario courant est que l'état du service est Running et que toutes les instances sont Ready après le déploiement. Cependant, une requête déclenche un bug dans le code, ce qui provoque le crash de l'instance de service backend et la rend injoignable. Dans cette situation, la passerelle renvoie un code d'état 503 au client. Pour identifier et corriger le bug, utilisez les journaux.

Erreur : Unexpected token 12606 while expecting start token 200006

Lorsque vous utilisez vllm pour déployer gpt-oss, les appels de service peuvent renvoyer l'erreur suivante :

Solution : Essayez de déployer avec l'accélération SGLang.

Erreur d'appel curl : no URL specified

Vous recevez une erreur no URL specified après avoir envoyé une requête avec la commande suivante :

curl -X http://17****.cn-hangzhou.pai-eas.aliyuncs.com/api/predict/service_name/**path** \
-H "Content-Type: application/json" \
-H "Authorization: **********==" \
-d '{"***":"****"}'

Cause : La commande curl utilise l'indicateur -X mais il manque la méthode, telle que POST.

L'appel renvoie un encodage ASCII

Modifiez votre code comme suit :

from flask import Flask, Response

@app.route('/hello', methods=['POST'])
def get_advice(): 
    result = "result"
    return Response(result, mimetype='text/plain', charset='utf-8')

Comment résoudre « [WARN] connection is closed: End of file » ou « Write a Invalid stream: End of file » dans les journaux de service ?

Ce journal d'avertissement indique que le client ou le serveur a fermé la connexion et que le serveur tentait d'écrire une réponse vers cette connexion fermée. Une connexion peut être fermée de deux manières :

• Délai d'attente côté serveur : En mode Processeur, le délai d'attente par défaut côté serveur est de 5 secondes. Vous pouvez modifier ce paramètre en utilisant le paramètre metadata.rpc.keepalive du service. Lorsque le délai d'attente est atteint, le serveur ferme la connexion et enregistre un code d'état 408 dans sa surveillance.

• Délai d'attente côté client : Les paramètres de votre code d'appel déterminent le délai d'attente côté client. Si le client ne reçoit pas de réponse HTTP dans le délai configuré, il ferme activement la connexion. Le serveur enregistre alors un code d'état 499 dans sa surveillance.

upstream connect error or disconnect/reset before headers. reset reason: connection termination

Des problèmes tels qu'un délai d'attente de connexion persistant ou des charges d'instance déséquilibrées provoquent généralement cette erreur. Si le temps de traitement côté serveur dépasse le délai d'attente HTTP configuré sur le client, le client abandonne la requête et ferme activement la connexion. Un code d'état 499 apparaît alors dans la surveillance côté serveur. Vous pouvez vérifier les métriques de surveillance pour une confirmation supplémentaire. Pour les tâches d'inférence longues, déployez un service d'inférence asynchrone.

Comment résoudre les échecs de débogage en ligne pour les services déployés avec un processeur Tensorflow/Pytorch ?

Pour des raisons de performance, les processeurs TensorFlow/PyTorch utilisent un format protobuf non texte brut pour le corps de la requête. Le débogage en ligne prend actuellement en charge uniquement l'entrée de texte en texte brut. Par conséquent, vous ne pouvez pas déboguer directement les services déployés avec ces processeurs dans la console. Utilisez les SDK EAS fournis pour appeler le service. Pour plus d'informations sur les SDK dans différents langages, consultez SDK d'appel de service.