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

404 Not Found

400 Bad Request

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

401 Authorization Failed

504 timeout

450 : Demande rejetée car la file d'attente est pleine

Lorsqu'une instance de calcul côté serveur reçoit une demande, elle place d'abord la demande 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 demandes peuvent s'accumuler dans la file d'attente. Lorsque la file d'attente est pleine, l'instance rejette immédiatement les nouvelles demandes 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 no healthy upstream

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 demande déclenche un bug dans le code, ce qui provoque le plantage 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 demande 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 omet 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'expiration côté serveur : En mode Processeur, le délai d'expiration par défaut côté serveur est de 5 secondes. Vous pouvez le modifier en utilisant le paramètre metadata.rpc.keepalive du service. Lorsque le délai d'expiration est atteint, le serveur ferme la connexion et enregistre un code d'état 408 dans sa surveillance.

• Délai d'expiration côté client : Les paramètres de votre code d'appel déterminent le délai d'expiration côté client. Si le client ne reçoit pas de réponse HTTP dans le délai d'expiration 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'expiration 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'expiration HTTP configuré sur le client, le client abandonne la demande 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 chronophages, 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 performances, les processeurs TensorFlow/PyTorch utilisent un format protobuf non textuel pour le corps de la demande. Le débogage en ligne prend actuellement en charge uniquement l'entrée de 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 obtenir des informations sur les SDK dans différents langages, consultez SDK d'appel de service.