Platform For AI:付録：サービスステータスコードと一般的なエラー

404 Not Found

400 Bad Request

リクエストボディの形式が正しくありません。JSON 構造、フィールド名、データ型など、リクエストボディの形式を注意深く確認してください。

401 認証失敗

504 timeout

450：キュー満杯によるリクエスト破棄

サーバー側のコンピューティングインスタンスがリクエストを受信すると、まずリクエストをキューに配置します。インスタンス内のワーカーが利用可能になると、キューからデータを取得して処理します。ワーカーのデフォルト数は 5 で、サービス作成時の JSON ファイルの metadata.rpc.worker_threads フィールドを使用して調整できます。ワーカーの処理時間が長すぎると、リクエストがキューに蓄積される可能性があります。キューが満杯になると、インスタンスは新しいリクエストを即座に 450 ステータスコードで拒否し、過剰なキューイングによるレイテンシーの増加やサービスの利用不能を防ぎます。デフォルトのキューの長さは 64 で、サービス作成時の JSON ファイルの metadata.rpc.max_queue_size フィールドを使用して調整できます。

503 no healthy upstream

オンラインデバッグ中に、「no healthy upstream」というメッセージとともに 503 エラーが表示されます：

次のように問題をトラブルシューティングしてください：

1. インスタンスのステータスを確認します。インスタンスが停止している場合は、[Restart Service] を実行してください。

2. サービスのステータスが [Running] の場合、インスタンスのリソース (CPU、メモリ、GPU メモリなど) が不足している可能性があり、バッファースペースの不足につながります。

   • パブリックリソースを使用している場合は、オフピーク時間にもう一度呼び出しを試みるか、別のリソース仕様またはリージョンに切り替えてください。

   • 専用リソース (EAS リソースグループ) を使用している場合は、リソースグループがインスタンス用に十分な CPU、メモリ、および GPU メモリを予約していることを確認してください。バッファとして少なくとも 20% のリソースを空けておくことを推奨します。

3. もう 1 つの一般的なシナリオは、サービスのステータスが「Running」であり、デプロイ後にすべてのインスタンスが Ready である場合です。しかし、リクエストがコード内のバグをトリガーし、バックエンドサービスインスタンスがクラッシュして応答しなくなります。この状況では、ゲートウェイはクライアントに 503 ステータスコードを返します。バグを特定して修正するには、ログを使用してください。

エラー：Unexpected token 12606 while expecting start token 200006

vllm を使用して gpt-oss をデプロイすると、サービスの呼び出しで次のエラーが返されることがあります：

解決策：SGLang アクセラレーションを使用してデプロイしてみてください。

curl 呼び出しエラー： no URL specified

次のコマンドでリクエストを送信した後、no URL specified エラーが表示されます：

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

原因： curl コマンドは -X フラグを使用していますが、POST などのメソッドが欠落しています。

呼び出しで ASCII エンコーディングが返される問題

次のようにコードを変更してください：

from flask import Flask, Response

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

サービスログの「[WARN] connection is closed: End of file」または「Write a Invalid stream: End of file」を解決する方法

この警告ログは、クライアントまたはサーバーが接続を閉じ、サーバーがその閉じた接続に応答を書き込もうとしていたことを示します。接続は 2 つの方法で閉じることができます：

• サーバー側のタイムアウト：プロセッサモードでは、デフォルトのサーバー側タイムアウトは 5 秒です。これは、サービスの metadata.rpc.keepalive パラメーターを使用して変更できます。タイムアウトに達すると、サーバーは接続を閉じ、モニタリングに 408 ステータスコードを記録します。

• クライアント側のタイムアウト：呼び出し元のコードの設定によって、クライアント側のタイムアウトが決まります。クライアントが設定されたタイムアウト期間内に HTTP 応答を受信しない場合、クライアントは自発的に接続を閉じます。その後、サーバーはモニタリングに 499 ステータスコードを記録します。

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

持続的な接続タイムアウトやインスタンス負荷の不均衡などの問題が、通常このエラーを引き起こします。サーバー側の処理時間がクライアントで設定された HTTP タイムアウトを超えると、クライアントはリクエストを破棄し、自発的に接続を閉じます。その後、サーバー側のモニタリングに 499 ステータスコードが表示されます。モニタリングメトリックを確認すると、さらに詳細がわかります。時間のかかる推論タスクについては、非同期推論サービスをデプロイしてください。

Tensorflow/Pytorch プロセッサでデプロイされたサービスのオンラインデバッグの失敗を解決する方法

パフォーマンス上の理由から、TensorFlow/PyTorch プロセッサはリクエストボディに非プレーンテキストの protobuf 形式を使用します。現在、オンラインデバッグはプレーンテキスト入力のみをサポートしています。したがって、これらのプロセッサでデプロイされたサービスをコンソールで直接デバッグすることはできません。提供されている EAS SDK を使用してサービスを呼び出してください。さまざまな言語の SDK については、「サービス呼び出し SDK」をご参照ください。