エンジン同時実行分析は、vLLM または SGLang 推論エンジン内のすべてのリクエストの実行スナップショットを単一のタイムライン上にプロットし、同じ瞬間に実行されているリクエストを比較できるようにします。このビューは、大規模なプレフィルによるデコードのブロッキングや、同時実行数の急増によるリクエストのキューイングなど、単一のリクエストトレースでは説明できないパフォーマンス低下の診断に役立ちます。
同時実行ビューが必要な理由
大規模言語モデル (LLM) の推論は通常、計算能力ではなくメモリ帯域幅によってボトルネックが発生します。LLM の場合、各トークンを生成するには、数十 GB のモデルの重みを GPU メモリから計算ユニットに移動する必要があります。単一リクエストの行列乗算はその計算能力のごく一部しか使用しないため、GPU はほとんどの時間をデータの待機に費やします。バッチ処理により、複数のリクエストで 1 回の重み読み取りを共有してメモリ アクセス コストを分散させることができ、多くの場合、単一 GPU のスループットが数倍向上します。
静的バッチ処理は LLM には適していません。
無駄なスロット — バッチ内では出力長が大きく異なるため、生成を完了した短いリクエストは、最も長いリクエストが終了するまでアイドル状態になり、その計算用スロットは無駄になります。
最初のトークンまでの時間が長くなる — 新しく到着したリクエストは、バッチ全体が解放されるまでキューに入れる必要があるため、最初のトークンまでの時間 (TTFT) が長くなります。
継続的バッチ処理は、スケジューリングの単位をバッチ全体から単一のイテレーションに縮小します。各デコード ステップの後、エンジンはキューをチェックし、終了したリクエストを即座に削除してその KV キャッシュを解放し、解放されたスロットを待機中のリクエストで埋めます。バッチは飽和状態に維持され、GPU はロングテール リクエストを待つ必要がなくなり、スループットとテール レイテンシの両方が改善されます。これが、継続的バッチ処理が vLLM や SGLang などの最新の推論エンジンのデフォルトのスケジューリングポリシーである理由です。
トレードオフとして、遅いリクエストのトラブルシューティングは、そのリクエスト自体のステージ期間を確認するだけでは不十分です。同じ瞬間にバッチを共有した他のリクエストに関する情報も考慮する必要があります。たとえば、プロンプトの長さ、プレフィル段階にあるかどうか、同時実行リクエスト数が上限に達しているかどうかなどです。エンジン同時実行分析 は、この情報を 1 つのタイムラインにプロットすることで、リクエストのバッチ環境を直接観測可能にします。
前提条件
「vLLM および SGLang の可観測性」で説明されているように、Application Real-Time Monitoring Service (ARMS) Python エージェントがインストールされていること。
推論エンジンがエージェントを介して起動され、トレース データを報告していること。
制限事項
ステージ期間が必須 — このトピックの診断方法は、リクエストの待機、プレフィル、デコードの各ステージの期間に依存します。
vLLM ステージの子スパン — vLLM の場合、
wait、prefill、decodeステージの子スパンは、収集粒度が1以上の V1 エンジンによってのみ生成されます。エージェントのデフォルトは1です。収集粒度が0に設定されている場合、リクエスト レベルのllm_requestスパンのみが生成されます。各収集スイッチのデフォルト値と有効な条件については、「vLLM および SGLang の収集設定」をご参照ください。
エンジン同時実行分析の開始
同時実行分析ビューは、推論サービス アプリケーションごとに表示されます。まずターゲット アプリケーションを開き、次に [Engine Concurrency Analysis] タブに切り替えて、クエリする時間範囲を指定します。
Cloud Monitor 2.0 コンソール にログインし、ターゲット ワークスペースを選択します。左側メニューで、[All Features] > [Reasoning Services Observability] を選択し、ターゲットの推論サービス アプリケーションをクリックします。
上部メニューで [Engine Concurrency Analysis] をクリックします。
ページの右上隅にある時間範囲ピッカーで、クエリする時間範囲を設定します。ビューには、その時間範囲内のエンジン内のすべてのリクエストの実行スナップショットが表示されます。
同時実行分析ビューの読み方
同時実行分析ビューは、一定期間にわたる推論エンジン内のすべてのリクエストの実行スナップショットです。横軸はタイムラインであり、各ブロックはエンジン内での 1 つの推論リクエストの実行間隔を表します。タイムライン上の特定の時点を選択して垂直線を描画すると、その線と交差するすべてのブロックが、その瞬間に実行されている推論リクエストになります。リクエストにカーソルを合わせると、待機、プレフィル、デコードを含む各ステージの期間が表示されます。
ビュー内の同時実行ブロックの数は、エンジンの最大同時実行リクエスト数によって制限されます。たとえば、最大同時実行リクエスト数が 8 に設定されている場合、同時に最大 8 つのリクエストが実行されるため、ビューには最大 8 つのブロックが表示されます。特定の時点でエンジンが完全にロードされているかどうかを確認するには、垂直線が交差するブロックの数を数えます。
エンジン同時実行分析は、PD (プレフィル/デコード) 分離デプロイメントと非 PD 分離デプロイメントの両方をサポートします。同時実行分析ビューのレイアウトは、2 つのデプロイメント タイプで異なります。
非 PD 分離デプロイメント — エンジン内のすべてのリクエストが 1 つのタイムラインにプロットされます。
PD 分離デプロイメント — プレフィル ワーカーとデコード ワーカーは別々のパネルに表示され、同じリクエストの 2 つのステージは破線でリンクされます。破線をたどってデコード側から対応するプレフィル リクエストを特定し、各側のキューイング期間と実行期間を個別に評価します。
大規模なプレフィルによるデコードのブロッキングに起因する TPOT 増加の診断
大規模なプレフィル リクエストは、同じバッチ内のデコード リクエストをブロックします。そのバッチのデコード期間は、大規模なプレフィル リクエストが到着する前よりも著しく長くなり、これはメトリクス上では出力トークンあたりの時間 (TPOT) の増加として現れます。次のようにして、同時実行分析ビューでブロッキングの原因を特定します。
デコード期間が長くなっている時間ウィンドウを見つけ、延長されたデコード ステージを、同じ時間ウィンドウ内の他のリクエストと照らし合わせます。
これらのリクエストのプロンプト トークン数を比較します。1 つのプレフィル リクエストのプロンプト トークン数が他のリクエストよりも著しく多い場合、その大規模なプレフィル リクエストが主なブロッキングの原因です。
PD 分離デプロイメントでは、デコード側から破線をたどって、ブロックされた各デコード リクエストに対応するプレフィル リクエストを特定し、プロンプト トークン数を比較します。
例 — 最大 8 つの同時実行リクエストを持つ非 PD 分離デプロイメントでは、1 つのプレフィル リクエストのプロンプト トークン数が、同じ期間の他のリクエストよりも著しく多くなっています。このプレフィル リクエストと重複するデコード ステージの期間は、このリクエストがバッチに入った時点から長くなります。
同時実行数の急増に起因するリクエスト キューイングの診断
リクエスト トレースの待機ステージが異常に長い場合は、同じ期間の同時実行分析ビューを確認します。
待機ステージが異常に長い時間ウィンドウを見つけ、その時間ウィンドウ内の同時実行リクエスト数を以前の期間の数と比較します。
同時実行リクエスト数が急に増加し、同時に長い待機ステージが現れた場合、トラフィックスパイクがその時点での推論エンジンの処理能力を超え、新しいリクエストがキューイングされたことを示します。
原因を絞り込むために、最大同時実行リクエスト数を使用します。同時実行ブロックの数が長時間にわたって上限にとどまっている場合、エンジン自体のキャパシティが不足しています。1 つの時間ウィンドウ内でのみ急に増加した場合は、トラフィックスパイクが原因です。
PD 分離デプロイメントでは、プレフィル側とデコード側のキューイング期間を個別に評価します。