AIGC、ビデオ処理、およびその他の長時間実行される推論ワークロードでは、同期推論が原因で接続タイムアウトやレプリカ負荷の不均衡が発生する可能性があります。PAI の非同期推論を使用すると、サブスクリプションまたはポーリングを通じてリクエストを送信し、結果を取得できます。
背景情報
特長
-
非同期推論
低レイテンシーのオンライン推論では、通常、同期推論が使用されます。クライアントはリクエストを送信し、同じ接続で結果を待機します。
推論時間が長い、または予測不可能な場合、同期的に待機すると、HTTP 接続の切断やクライアントのタイムアウトを引き起こす可能性があります。非同期推論を使用すると、クライアントはリクエストを送信し、後でポーリングまたは通知の購読によって結果を取得します。
-
キューサービス
ショートビデオ処理、オーディオ/ビデオストリーム分析、または集中的な画像処理などの準リアルタイムのシナリオでは、一定時間内に結果を返す必要があります。これらのシナリオには、以下の課題があります。
-
ラウンドロビンの負荷分散アルゴリズムは不適切です。リクエストは各レプリカの実際の負荷に基づいて分散する必要があります。
-
レプリカに障害が発生した場合、その未完了のタスクは処理のために他の正常なレプリカに再割り当てする必要があります。
PAI は、これらのリクエスト分散問題を解決するためのキューサービスフレームワークを提供します。
-
仕組み
-
非同期推論サービスには、推論サブサービス と キューサブサービス という 2 つのサブサービスが含まれます。キューサブサービスには、入力キューとシンクキューという 2 つの組み込みキューがあります。リクエストは最初に入力キューに送られます。各推論サブサービスのレプリカは入力キューをサブスクライブし、リクエストを処理して、応答をシンクキューに書き込みます。
-
シンクキューが満杯になると、サービスフレームワークは結果が配信不能になるのを防ぐため、入力キューからの消費を停止します。
推論結果を直接 OSS または独自のメッセージミドルウェアに書き込む場合は、HTTP 推論インターフェイスから空の応答を返します。これにより、シンクキューは無視されます。
-
キューサブサービスは、クライアントのリクエストを受信し、同時実行性能に基づいて推論レプリカに分散します。各レプリカはリクエストのウィンドウをサブスクライブすることで、過負荷を防ぎ、すべてのデータが最終的にクライアントに返されることを保証します。
説明たとえば、各レプリカが 5 つのオーディオストリームを処理できる場合、ウィンドウサイズを 5 に設定します。レプリカが 1 つのストリームを完了して結果をコミットすると、キューサブサービスは新しいストリームをプッシュします。これにより、各レプリカの同時ストリーム数が 5 つに制限されます。
-
キューサブサービスはレプリカの接続を監視します。レプリカに障害が発生した場合、その未処理のリクエストを正常なレプリカに再分散し、データが失われないようにします。
非同期推論サービスの作成
非同期推論サービスを作成すると、キューサブサービスを持つ同名のサービスグループが自動的に作成されます。キューサブサービスは、デフォルトで 1 つのレプリカ (1 コア、4 GB メモリ) で構成され、推論サブサービスとともに最大 2 つのレプリカまでスケールアップします。カスタマイズするには、キューサブサービスのパラメーターを調整してください。
EAS は、非同期推論のために 2 つのデプロイ方法をサポートしています。
コンソール経由でのデプロイ
-
[カスタムデプロイ] ページに移動し、次の主要パラメーターを設定します。その他のパラメーターについては、「カスタムデプロイ」をご参照ください。
-
推論アクセラレーション: イメージデプロイメント または プロセッサのデプロイメント を選択し、非同期キュー チェックボックスにチェックを入れます。
-
-
パラメーターを設定した後、デプロイメント をクリックします。
eascmd クライアント経由でのデプロイ
-
service.json という名前のサービス設定ファイルを準備します。
-
モデルとプロセッサーベースのデプロイ を使用します。
{ "processor": "pmml", "model_path": "http://example.oss-cn-shanghai.aliyuncs.com/models/lr.pmml", "metadata": { "name": "pmmlasync", "type": "Async", "cpu": 4, "instance": 1, "memory": 8000 } }主要なパラメーターは以下で説明します。その他のパラメーターについては、「JSON ベースのデプロイ」をご参照ください。
-
type:非同期推論サービスを作成するには、このパラメーターを
Asyncに設定します。 -
model_path:値をモデルへのパスに置き換えてください。
-
-
イメージベースのデプロイ を使用します。
{ "metadata": { "name": "image_async", "instance": 1, "rpc.worker_threads": 4, "type": "Async" }, "cloud": { "computing": { "instance_type": "ecs.gn6i-c16g1.4xlarge" } }, "queue": { "cpu": 1, "min_replica": 1, "memory": 4000, "resource": "" }, "containers": [ { "image": "eas-registry-vpc.cn-beijing.cr.aliyuncs.com/pai-eas/chat-llm-webui:3.0.1", "script": "python webui/webui_server.py --port=8000 --model-path=Qwen/Qwen-7B-Chat", "port": 8000 } ] }主要なパラメーターは以下で説明します。その他のパラメーターについては、「JSON ベースのデプロイ」をご参照ください。
-
type:非同期推論サービスを作成するには、このパラメーターを Async に設定します。
-
instance:推論サブサービスのレプリカ数です。これにはキューサブサービスのレプリカは含まれません。
-
rpc.worker_threads:EAS サービスフレームワークのスレッド数で、サブスクリプションのウィンドウサイズに相当します。キューサブサービスは最大でこの数のメッセージを同時にプッシュし、さらに送信する前に結果を待機します。
たとえば、各レプリカが一度に 2 つのストリームを処理するビデオストリームサービスの場合、これを 2 に設定します。キューサブサービスは最大で 2 つのビデオストリーム URL をプッシュし、結果を受信した後にのみ新しい URL を送信します。
-
-
-
サービスを作成します。
eascmd クライアントにログインした後 (クライアントのダウンロードと認証)、create コマンドを実行します。
eascmd create service.json
非同期推論サービスへのアクセス
システムは同名のサービスグループを作成します。キューサブサービスが着信トラフィックを処理するため、次のエンドポイントを通じて直接アクセスしてください。キューサービスへのアクセス。
|
エンドポイントタイプ |
フォーマット |
例 |
|
入力キューエンドポイント |
|
|
|
シンクキューエンドポイント |
|
|
非同期推論サービスの管理
非同期推論サービスは、通常のサービスと同様に管理します。システムはサブサービスを自動的に管理します。サービスを削除すると両方のサブサービスが削除され、推論サブサービスを更新してもキューサブサービスは変更されません。
レプリカを 1 つ設定した場合でも、インスタンスリストにはキューサブサービスのインスタンスが追加で表示されます。
レプリカ数は推論サブサービスのレプリカを指します。キューサブサービスのレプリカは自動的にスケーリングされます。たとえば、推論レプリカを 3 にスケーリングすると、キューレプリカは 2 に増加します。
レプリカのスケーリングルール:
-
サービスが停止すると、両方のサブサービスは 0 レプリカにスケーリングされます。
-
推論レプリカが 1 つの場合、キューサブサービスも (別途設定しない限り) 1 つのレプリカになります。
-
推論レプリカが 2 つ以上の場合、キューサブサービスは (別途設定しない限り) 2 つのレプリカになります。
-
オートスケーリングで最小レプリカ数0が許可されている場合、推論レプリカが0にスケールダウンされると、キューサブサービスはスタンバイレプリカを1つ保持します。
キューサブサービスのパラメーター
ほとんどの場合、キューサブサービスはデフォルト設定で動作します。カスタマイズするには、JSON ファイルの最上位にある queue フィールドで設定してください。
{
"queue": {
"sink": {
"memory_ratio": 0.3
},
"source": {
"auto_evict": true,
}
}
以下のセクションでは、設定オプションについて説明します。
キューサブサービスのリソース
デフォルトでは、キューサブサービスのリソースは metadata から継承されます。必要に応じて、これらを個別に設定できます。
-
queue.resource を使用して、キューサブサービスのリソースグループを設定します。
{ "queue": { "resource": "eas-r-slzkbq4tw0p6xd****" // デフォルトでは、推論サブサービスのリソースグループを使用します。 } }-
デフォルトは推論サブサービスのリソースグループです。
-
キューサブサービスをパブリックリソースグループにデプロイするには、resource を空の文字列 (
"") に設定してください。これは、専用リソースグループに CPU またはメモリが不足している場合に便利です。説明可能な場合は、キューサブサービスをパブリックリソースグループにデプロイすることを推奨します。
-
-
queue.cpu と queue.memory を使用して、各キューサブサービスのレプリカの CPU (コア単位) とメモリ (MB 単位) を設定します。
{ "queue": { "cpu": 2, // デフォルト:1 "memory": 8000 // デフォルト:4000 } }デフォルト (1 CPU コア、4 GB メモリ) は、ほとんどのシナリオで十分です。
重要-
200 を超えるサブスクライバー (推論サブサービスのレプリカ) の場合は、2 コア以上の CPU を設定します。
-
本番環境では、キューサブサービスのメモリを減らさないでください。
-
-
queue.min_replica を使用して、キューサブサービスの最小レプリカ数を設定します。
{ "queue": { "min_replica": 3 // デフォルト:1 } }キューサブサービスのレプリカは、実行中の推論レプリカとともに自動的にスケーリングされます。デフォルトの範囲は
[1, min{2, 推論サブサービスのレプリカ数}]です。オートスケーリングが 0 へのスケーリングを許可している場合、1 つのキューレプリカが保持されます。queue.min_replica を使用して、この最小値を調整できます。説明キューレプリカを増やすと可用性は向上しますが、パフォーマンスは向上しません。
キューサブサービスの機能
キューサブサービスは、次の機能設定をサポートしています。
-
シンクキューと入力キューの自動データエビクションを、それぞれ queue.sink.auto_evict または queue.source.auto_evict を使用して設定します。
{ "queue": { "sink": { "auto_evict": true // シンクキューの自動エビクションを有効にします。デフォルト:false }, "source": { "auto_evict": true // 入力キューの自動エビクションを有効にします。デフォルト:false } } }デフォルトでは自動エビクションは無効になっており、キューが満杯になると新しいデータを拒否します。エビクションを有効にすると、最も古いデータが破棄され、新しいエントリのためのスペースが確保されます。
-
queue.max_delivery を使用して、最大配信試行回数を設定します。
{ "queue": { "max_delivery": 10 // 最大配信試行回数は 10 回です。デフォルト:5。0 に設定すると、この機能は無効になり、データは無制限に配信できます。 } }配信試行回数がしきい値を超えると、メッセージはデッドレターとしてマークされます。デッドレターポリシー。
-
queue.max_idle を使用して、メッセージの最大処理時間を設定します。
{ "queue": { "max_idle": "1m" // 単一メッセージの最大処理時間を 1 分に設定します。この時間を超えると、メッセージは別のサブスクライバーに配信され、配信回数が増加します。デフォルト値は 0 で、最大処理時間がないことを意味します。 } }サポートされている時間単位:
h(時間)、m(分)、s(秒)。処理が設定された期間を超えた場合:-
queue.max_deliveryのしきい値を超えていない場合、メッセージは他のサブスクライバーに再配信されます。 -
queue.max_deliveryのしきい値を超えている場合、デッドレターポリシーが適用されます。
-
-
queue.dead_message_policy を使用して、デッドレターポリシーを設定します。
{ "queue": { "dead_message_policy": "Rear" // 値は Rear (デフォルト) または Drop です。Rear はメッセージをキューの末尾に移動します。Drop はメッセージを削除します。 } }
キューの長さまたは最大ペイロードサイズ
キューレプリカのメモリは固定されています。メッセージあたりの最大ペイロードサイズを増やすと、最大キュー長は減少します。
-
デフォルト設定 (4 GB メモリ、8 KB 最大ペイロード) では、各キューは最大 230,399 件のメッセージを保存できます。より多く保存するには、メモリを増やしてください。システムは総メモリの 10% を予約します。
-
同じキューに対して、最大長と最大ペイロードサイズの両方を設定することはできません。
-
シンクキューと入力キューの最大長を、それぞれ queue.sink.max_length または queue.source.max_length を使用して設定します。
{ "queue": { "sink": { "max_length": 8000 // シンクキューの最大長を 8,000 メッセージに設定します。 }, "source": { "max_length": 2000 // 入力キューの最大長を 2,000 メッセージに設定します。 } } } -
シンクキューと入力キューのメッセージあたりの最大ペイロードサイズを、それぞれ queue.sink.max_payload_size_kb または queue.source.max_payload_size_kb を使用して設定します。
{ "queue": { "sink": { "max_payload_size_kb": 10 // シンクキューのメッセージあたりの最大ペイロードサイズを 10 KB に設定します。デフォルト:8 KB }, "source": { "max_payload_size_kb": 1024 // 入力キューのメッセージあたりの最大ペイロードサイズを 1024 KB (1 MB) に設定します。デフォルト:8 KB } } }
メモリ割り当て比率
-
queue.sink.memory_ratio を使用して、入力キューとシンクキュー間のメモリ割り当て比率を調整します。
{ "queue": { "sink": { "memory_ratio": 0.9 // シンクキューのメモリ比率を設定します。デフォルト:0.5 } } }説明デフォルトでは、入力キューとシンクキューはメモリを均等に共有します。シンクキューにより多くのスペースが必要な場合 (たとえば、テキスト入力と画像出力)、
queue.sink.memory_ratioを増やしてください。逆の場合は減らしてください。
水平オートスケーリング
仕組み
システムは、キューの状態に基づいて推論レプリカを動的にスケーリングします。これには、キューが空の場合のゼロへのスケーリングも含まれます。次の図は、そのメカニズムを示しています。
操作手順
-
サービスリストで、対象のサービス名をクリックします。
-
オートスケーリング タブに移動します。 Auto Scaling セクションで、 Auto Scaling の有効化 をクリックします。
-
自動スケーリング設定 ダイアログボックスで、パラメーターを設定します。
-
基本設定:
パラメーター
説明
例
[最小レプリカ数]
サービスがスケールインできるレプリカの最小数。最小値は 0 です。
0
[最大レプリカ数]
サービスがスケールアウトできるレプリカの最大数。最大値は 1000 です。
10
[一般的なスケーリングメトリック]
スケーリングをトリガーするために使用される組み込みのパフォーマンスメトリック。
[非同期キューの長さ] は、レプリカあたりのキューに入れられたタスクの平均数を表します。
選択は非同期キューの長さ とし、しきい値を 10 に設定します。
-
詳細設定:
パラメーター
説明
例
[スケールアウトの所要時間]
スケールアウト決定のための観測ウィンドウ。スケールアウトがトリガーされた後、システムはこの期間中にメトリックを観測します。メトリック値がしきい値を下回った場合、スケールアウトはキャンセルされます。単位は秒です。
デフォルト値は
0秒で、スケールアウトが即座に実行されることを意味します。0
[スケールインの反映時間]
スケールイン決定のための観測ウィンドウ。これは、サービスのジッターを防ぐための重要なパラメーターです。スケールインは、メトリックがこの期間全体でしきい値を下回り続けた後にのみ発生します。単位は秒です。
デフォルトは
300秒です。この値は、トラフィックの変動による頻繁なスケールインイベントに対する中心的な保護策です。サービスの安定性に影響を与える可能性があるため、この値を低く設定しすぎないでください。300
[0 へのスケールインの有効期間]
最小レプリカ数 が
0に設定されている場合、このパラメーターはスケールイン条件が満たされてからレプリカ数が0に減少するまでの遅延を指定します。600
[0 からスケールアウトするレプリカ数]
コールドスタート中にサービスが
0レプリカからスケールアウトする際に一度に追加するレプリカの数。1
すべてのパラメーターの詳細と eascmd の使用法については、「水平オートスケーリング」をご参照ください。
-