リアルタイムのリソースメトリクスおよびスケジューリングポリシーに基づくインテリジェントなトラフィックルーティングにより、大規模言語モデル(LLM)の推論パフォーマンスを最適化します。LLM インテリジェントルーターは、推論インスタンス間でコンピューティングリソースとメモリ割り当てを動的に分散することで、クラスターのリソース利用率およびサービス信頼性を向上させます。
仕組み
アーキテクチャ概要
LLM インテリジェントルーターは、バックエンドの LLM 推論インスタンスクラスター向けにインテリジェントなトラフィック分散および管理を提供するため、以下の 3 つのコアコンポーネントで構成されます:
LLM ゲートウェイ:HTTP/SSE および WebSocket プロトコルをサポートする主要なトラフィック入口およびリクエスト処理コンポーネント
LLM スケジューラ:リアルタイムメトリクスを集約し、ポリシーに基づいたスケジューリング判断を行う中央知能コンポーネント
LLM エージェント:各推論インスタンスにサイドカーコンテナーとして展開される分散型監視プローブ
LLM インテリジェントルーターは特殊な EAS サービスであり、正常に機能させるには、推論サービスと同じサービスグループ内にデプロイする必要があります。
コアワークフローの処理手順は以下のとおりです:
インスタンス登録:推論サービスが起動すると、
LLM エージェントは推論エンジンの準備完了を待機した後、LLM スケジューラにインスタンスを登録し、定期的に健全性ステータスおよびパフォーマンスメトリクスを報告します。トラフィック受信:ユーザーからのリクエストは、まず
LLM ゲートウェイで受信されます。スケジューリング判断:
LLM ゲートウェイがLLM スケジューラに対してスケジューリング要求を送信します。インテリジェントスケジューリング:
LLM スケジューラは、すべてのLLM エージェントから報告されたスケジューリングポリシーおよびリアルタイムメトリクスに基づき、最適なバックエンドインスタンスを選択します。リクエスト転送:
LLM Schedulerは、LLM Gatewayに判断結果を返し、LLM Gatewayがユーザーの元のリクエストをターゲット インスタンスに転送します。リクエストバッファリング:すべてのバックエンドインスタンスが高負荷状態の場合、新規リクエストは一時的に
LLM ゲートウェイのキュー内でバッファリングされ、LLM スケジューラによる適切な転送機会の検出を待ちます。これにより、リクエスト失敗を防止します。
コアコンポーネント
コンポーネント | 主な責任 |
LLM ゲートウェイ | 主要なトラフィック入口およびリクエスト処理コンポーネント。すべてのユーザーからのリクエストを受信し、
|
LLM スケジューラ | リクエスト分散のための中央知能コンポーネント。すべての |
LLM エージェント | 分散型監視およびレポートプローブ。各推論インスタンスにサイドカーコンテナーとして展開され、推論エンジンからパフォーマンスメトリクスを収集し、 |
フェイルオーバー機構
本システムでは、サービスの安定性を確保するために、複数層のフォールトトレランス機構を実装しています:
LLM ゲートウェイ(高可用性):LLM ゲートウェイはステートレスなトラフィックイングレスレイヤーです。高可用性を確保するためには、最低でも 2 つのインスタンスをデプロイしてください。1 つのインスタンスが障害を起こした場合、トラフィックは自動的に健全なインスタンスに切り替わり、継続的なサービス可用性が保証されます。
LLM スケジューラ(劣化フォールトトレランス):LLM スケジューラはリクエストスケジューリングコンポーネントであり、グローバルスケジューリングを可能にするために単一インスタンスで実行されます。もし
LLM スケジューラが障害を起こした場合、LLM ゲートウェイはハートビート障害後に自動的に劣化モードに移行します。このモードでは、ラウンドロビン ポリシーを使用して、リクエストをバックエンドインスタンスに直接転送します。これによりサービス可用性は確保されますが、スケジューリングパフォーマンスは低下します。その後、LLM スケジューラが復旧すると、LLM ゲートウェイは自動的にインテリジェントスケジューリングモードへ復帰します。推論インスタンスまたは LLM エージェント(自動削除):推論インスタンスまたは関連する
LLM エージェントが障害を起こすと、LLM エージェントとLLM スケジューラ間のハートビート接続が切断されます。LLM スケジューラは、即座に当該インスタンスを利用可能なインスタンス一覧から削除し、新たなトラフィックの割り当てを停止します。インスタンスが復旧し、ハートビート接続が再確立された後は、自動的にサービス一覧に再登録されます。
マルチ推論エンジン対応
異なる LLM 推論エンジンは、それぞれの /metrics エンドポイントを通じて異なるメトリクス情報を返却するため、LLM エージェントはこれらのメトリクスを収集し、標準化されたフォーマットに変換した上で報告します。このため、LLM スケジューラは特定の推論エンジンの実装詳細を理解する必要がなく、標準化されたメトリクスに基づくスケジューリングアルゴリズムのみを実装すればよいことになります。現在対応している LLM 推論エンジンおよびその対応メトリクスは以下のとおりです:
LLM 推論エンジン | メトリクス | 説明 |
vLLM | vllm:num_requests_running | 実行中のリクエスト数。 |
vllm:num_requests_waiting | キュー内で待機中のリクエスト数。 | |
vllm:gpu_cache_usage_perc | GPU KV キャッシュ使用率(パーセント)。 | |
vllm:prompt_tokens_total | プロンプトトークンの総数。 | |
vllm:generation_tokens_total | 生成トークンの総数。 | |
SGLang | sglang:num_running_reqs | 実行中のリクエスト数。 |
sglang:num_queue_reqs | キュー内で待機中のリクエスト数。 | |
sglang:token_usage | KV キャッシュ使用率(パーセント)。 | |
sglang:prompt_tokens_total | プロンプトトークンの総数。 | |
sglang:gen_throughput | 1 秒あたりの生成トークン数。 |
制限事項
更新時の追加不可:LLM インテリジェントルーター機能は、新規サービス作成時のみ設定可能です。サービス更新 操作によって既存の推論サービスにインテリジェントルーティング機能を追加することはできません。
推論エンジンの制限:本機能は、現時点では vLLM または SGLang のみを推論エンジンとしてサポートしています。
複数推論インスタンスのデプロイ:LLM インテリジェントルーターは、複数の推論インスタンスとともにデプロイされる場合に最も効果的です。
クイックスタート:LLM インテリジェントルーターの使用
ステップ 1:LLM インテリジェントルーターサービスのデプロイ
PAI コンソール にログインし、ページ上部でターゲットリージョンを選択します。
左側のナビゲーションウィンドウで、Elastic Algorithm Service (EAS) をクリックし、対象のワークスペースを選択して EAS ページに移動します。
Deploy Service をクリックし、Scenario-based Model Deployment > Deploy LLM gateway を選択します。
パラメーターを設定します:
パラメーター
説明
Basic Information
Service Name
サービス名をカスタマイズします(例:
llm_gateway)。Resource Information
Deployment Resources
LLM ゲートウェイのリソース構成です。高可用性を確保するため、デフォルトの Number of Replicas は 2 です。この設定をそのまま使用してください。デフォルトの CPU は 4 コア、メモリ は 8 GB です。Scheduling configuration
LLM スケジューラのリソース構成です。デフォルトの CPU は 2 コア、メモリ は 4 GB です。Scheduling Policy
バックエンド推論インスタンス向けのロードバランスポリシーを選択します。デフォルトは Prefix cache です。詳細な比較および選択ガイドについては、「スケジューリングポリシーの詳細および選択方法」をご参照ください。
Deploy をクリックします。サービスステータスが Running に変わると、デプロイが成功したことを意味します。
デプロイが成功すると、システムは自動的に group_<LLM インテリジェントルーターサービス名> という名前のサービスグループを作成します。EAS ページに移動し、Elastic Algorithm Service (EAS) ページの Canary Release タブでサービスグループを確認できます。
インテリジェントルーティングはサービスキューと競合するため、同一のサービスグループ内に共存できません。
ステップ 2:LLM サービスのデプロイ
LLM サービスをデプロイし(詳細については、「大規模言語モデルのデプロイ」をご参照ください)、先に作成したインテリジェントルーターサービスに関連付けます:
Features セクションで、LLM Intelligent Router スイッチをオンにします。
ステップ 1 でデプロイした LLM インテリジェントルーターサービスをドロップダウンリストから選択します。
LLM インテリジェントルーターサービスが Prefix cache スケジューリングポリシーを使用する場合、vLLM のデプロイ時に プレフィックスキャッシュ 機能が有効になっていることを確認してください。
ステップ 3:サービスのテスト
すべてのリクエストは、特定のバックエンド推論サービスのエンドポイントではなく、LLM インテリジェントルーターサービスのエンドポイントに送信する必要があります。
アクセス認証情報の取得。
LLM インテリジェントルーターサービスをクリックして、Overview ページに移動します。Basic Information セクションで、View Endpoint Information をクリックします。
エンドポイント情報 ページで、Internet Endpoint および トークン を Service-specific Traffic Entry セクションからコピーします。

リクエスト URL の構築およびサービス呼び出し。
URL 構造:
<LLM インテリジェントルーターのエンドポイント>/<LLM サービスの API パス>例:
http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions
リクエストの例:
# <YOUR_GATEWAY_URL> および <YOUR_TOKEN> を実際の値に置き換えます # <model_name> を実際のモデル名に置き換えます curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -H "Content-Type: application/json" \ -N \ -d '{ "model": "<model_name>", "messages": [{"role": "user", "content": "Hello"}], "stream": true }'応答の例:
data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"role":"assistant","content":""},"logprobs":null,"finish_reason":null}]} data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"content":"<think>","tool_calls":[]}}]} ... data: [DONE]
高度な構成
JSON ベースのスタンドアロンデプロイメントでは、より柔軟な構成オプションが提供され、LLM ゲートウェイ のリソース仕様を指定したり、リクエスト処理動作を微調整したりできます。
手順:Inference Service ページで、Deploy Service をクリックします。次に、Custom Model Deployment セクションで、JSON Deployment をクリックします。
構成例:
{ "cloud": { "computing": { "instance_type": "ecs.c7.large" } }, "llm_gateway": { "max_queue_size": 128, "retry_count": 2, "wait_schedule_timeout": 5000, "wait_schedule_try_period": 500 }, "llm_scheduler": { "cpu": 2, "memory": 4000, "policy": "prefix-cache" }, "metadata": { "group": "group_llm_gateway", "instance": 2, "name": "llm_gateway", "type": "LLMGatewayService" } }パラメーター:
パラメーター
説明
metadata
type
必須。固定値
LLMGatewayServiceを指定します。これは LLM インテリジェントルーターサービスのデプロイを示します。instance
必須。
LLM ゲートウェイのレプリカ数です。単一障害点を回避するため、最低でも 2 を指定してください。cpu
LLM ゲートウェイのレプリカあたりの CPU コア数です。memory
LLM ゲートウェイのメモリ量(GB)です。group
LLM インテリジェントルーターサービスが所属するサービスグループです。
cloud.computing.instance_type
LLM ゲートウェイのリソース仕様を指定します。この場合、metadata.cpuおよびmetadata.memoryの設定は不要です。llm_gateway
max_queue_size
LLM ゲートウェイのバッファーキューの最大長です。デフォルト値は 512 です。バックエンド推論フレームワークの処理能力を超えた場合、過剰なリクエストはこのキューにバッファリングされ、スケジューリングを待ちます。
retry_count
リトライ試行回数です。デフォルト値は 2 です。バックエンド推論インスタンスが障害を起こした場合、リクエストは別のインスタンスに再試行・転送されます。
wait_schedule_timeout
バックエンドエンジンがフルキャパシティの場合、リクエストは一定間隔でスケジューリングを試行します。このパラメーターは、スケジューリング試行の総時間(ミリ秒)を指定します。デフォルト値は 10 秒です。
wait_schedule_try_period
各スケジューリング試行の間隔(ミリ秒)です。デフォルト値は 1 秒です。
llm_scheduler
cpu
LLM スケジューラの CPU コア数です。デフォルト値は 4 コアです。memory
LLM スケジューラのメモリ量(GB)です。デフォルト値は 4 GB です。policy
スケジューリングポリシーです。デフォルト値は
prefix-cacheです。利用可能な値および説明については、「スケジューリングポリシーの詳細および選択方法」をご参照ください。prefill_policy
policy を pd-split に設定した場合、Prefill および Decode 各フェーズ向けに別々のスケジューリングポリシーを指定します。有効な値: prefix-cache, llm-metric-based, least-request, least-token。
decode_policy
スケジューリングポリシーの詳細および選択方法
適切なスケジューリングポリシーを選択することは、LLM インテリジェントルーターの効果を最大化する上で極めて重要です。以下に、各ポリシーのロジック、適用シーン、メリット、留意点を比較表形式で示し、最適なポリシー選択を支援します。
ポリシー名 | JSON 値 | コアロジック | 適用シーン | メリット | 留意点 |
Prefix cache | prefix-cache | (推奨) これは包括的なポリシーであり、過去に同一の文脈(プロンプト)で実行されたリクエストを、すでに該当する KV キャッシュを保持しているインスタンスに優先的に送信します。 | 固定のシステムプロンプトを使用するマルチターン対話ボットおよび検索拡張生成(RAG)システム。 | 初回トークン到達時間(TTFT)を大幅に短縮し、マルチターン対話のパフォーマンスおよびスループットを向上させます。 | 推論エンジンでプレフィックスキャッシュ機能が有効である必要があります。 |
LLM Metrics | llm-metric-based | 実行中のリクエスト数、キュー内のリクエスト数、KV キャッシュ使用率など、バックエンドインスタンスの包括的な負荷メトリクスに基づいて、リクエストをインテリジェントにスケジューリングします。 | 多様なリクエストパターンを持ち、明確な対話的特徴がない一般的な LLM ワークロード。 | インスタンス間の負荷を効果的に分散し、リソース利用率を向上させます。 | スケジューリングロジックが比較的複雑であり、特定のシナリオではプレフィックスキャッシュポリシーと比較して最適な結果を提供できない可能性があります。 |
Minimum Requests | least-request | 現在処理中のリクエスト数が最も少ないインスタンスに新規リクエストを送信します。 | リクエストの計算複雑度(トークン長や生成長など)が比較的均一なシナリオ。 | シンプルかつ効率的です。インスタンス間のリクエスト数を素早くバランス化します。 | 実際のリクエスト負荷を認識しません。そのため、短いリクエストを処理するインスタンスはアイドル状態になりながら、長いリクエストを処理するインスタンスが過負荷になる可能性があります。 |
Minimum tokens | least-token | 現在処理中の入力および出力トークンの総数が最も少ないインスタンスに新規リクエストを送信します。 | トークン数がリクエスト処理コストの妥当な指標となるシナリオ。 | 「最少リクエスト数」ポリシーと比較して、実際のインスタンス負荷をより正確に反映します。 | トークン数の推定に依存します。すべてのエンジンがこのメトリクスを報告するわけではありません。 |
Static PD Disaggregation | pd-split | インスタンスをあらかじめ Prefill および Decode グループに分割し、各グループに個別のスケジューリングポリシーを指定する必要があります。 | Prefill および Decode の各フェーズが著しく異なる計算およびメモリ特性を持ち、分離デプロイメントが大きなメリットをもたらすシナリオ。 | 深い最適化によりハードウェア利用率を最大化します。 | 複雑な構成:このポリシーは、モデルおよびビジネスロジックへの深い理解に加え、Prefill および Decode サービスの独立したデプロイメントを必要とします。 |
Dynamic PD Disaggregation | dynamic-pd-split | インスタンスに事前に役割を定義する必要はありません。スケジューラがリアルタイム負荷に基づき、リクエストの Prefill または Decode フェーズを最も適したインスタンスに動的に割り当てます。 | 静的分離ポリシーと同様ですが、負荷が動的に変化するシナリオに適しています。 | 静的分離よりも柔軟性が高く、負荷の変化に自動的に適応します。 | 極めて複雑な構成:このポリシーは、スケジューラおよびエンジンに対してより高い要件を課します。 |
サービス監視メトリクスの表示
サービスをデプロイした後、EAS コンソールでコアパフォーマンスメトリクスを表示し、インテリジェントルーティングの効果を評価できます。
Elastic Algorithm Service (EAS) ページで、デプロイ済みの LLM インテリジェントルーターサービスの名前をクリックして、サービス詳細ページに移動します。Monitoring タブで、以下のコアメトリクスを監視できます:
トークンスループット LLM の入力および出力トークンのスループットです。
| GPU キャッシュ使用率 LLM エンジンの GPU KV キャッシュ使用率(パーセント)です。
|
エンジンの同時リクエスト数 LLM エンジンのリアルタイム同時リクエスト数です。
| ゲートウェイの同時リクエスト数 LLM インテリジェントルーターのリアルタイムリクエスト数です。
|
初回トークン到達時間(TTFT) リクエストの初回トークンの遅延時間です。
| 出力トークンごとの処理時間(TPOT) パッケージ単位のリクエスト遅延時間です。
|
付録:Claude Code の使用方法
EAS インテリジェントルーターサービスから提供される BASE URL および TOKEN を、Claude Code に設定します。
# <YOUR_GATEWAY_URL> および <YOUR_TOKEN> を実際の値に置き換えます export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL> export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>Claude Code ツールを直接実行します。
claude "Python の Hello World を記述してください"
付録:パフォーマンステストの比較
Distill-Qwen-7B、QwQ-32B、Qwen2.5-72B モデルにおけるテスト結果によると、LLM インテリジェントルーターは推論サービスの速度およびスループットを大幅に向上させます。テスト環境および結果は以下のとおりです。
以下のテスト結果は参考用です。実際のパフォーマンスは、お客様の具体的なテスト環境によって異なります。
テスト環境
スケジューリングポリシー: prefix-cache
テストデータセット: ShareGPT_V3_unfiltered_cleaned_split.json(マルチターン対話データセット)
推論エンジン: vLLM(0.7.3)
バックエンドインスタンス数: 5
テスト結果
テストモデル | Distill-Qwen-7B | QwQ-32B | Qwen2.5-72b | ||||||
カードタイプ | ml.gu8tf.8.40xlarge | ml.gu8tf.8.40xlarge | ml.gu7xf.8xlarge-gu108 | ||||||
並行性 | 500 | 100 | 100 | ||||||
メトリクス | LLM インテリジェントルーター未使用時 | LLM インテリジェントルーター使用時 | 改善 | LLM インテリジェントルーター未使用時 | LLM インテリジェントルーター使用時 | 改善 | LLM インテリジェントルーター未使用時 | LLM インテリジェントルーター使用時 | 改善 |
成功したリクエスト | 3698 | 3612 | - | 1194 | 1194 | - | 1194 | 1194 | - |
ベンチマーク実行時間 | 460.79 s | 435.70 s | - | 1418.54 s | 1339.04 s | - | 479.53 s | 456.69 s | - |
合計入力トークン数 | 6605953 | 6426637 | - | 2646701 | 2645010 | - | 1336301 | 1337015 | - |
合計生成トークン数 | 4898730 | 4750113 | - | 1908956 | 1902894 | - | 924856 | 925208 | - |
リクエストスループット | 8.03 req/s | 8.29 req/s | +3.2% | 0.84 req/s | 0.89 req/s | +5.95% | 2.49 req/s | 2.61 req/s | +4.8% |
出力トークンスループット | 10631.17 tok/s | 10902.30 tok/s | +2.5% | 1345.72 tok/s | 1421.08 tok/s | +5.6% | 1928.66 tok/s | 2025.92 tok/s | +5.0% |
合計トークンスループット | 24967.33 tok/s | 25652.51 tok/s | +2.7% | 3211.52 tok/s | 3396.38 tok/s | +5.8% | 4715.34 tok/s | 4953.56 tok/s | +5.0% |
平均 TTFT | 532.79 ms | 508.90 ms | +4.5% | 1144.62 ms | 859.42 ms | +25.0% | 508.55 ms | 389.66 ms | +23.4% |
中央値 TTFT | 274.23 ms | 246.30 ms | - | 749.39 ms | 565.61 ms | - | 325.33 ms | 190.04 ms | - |
P99 TTFT | 3841.49 ms | 3526.62 ms | - | 5339.61 ms | 5027.39 ms | - | 2802.26 ms | 2678.70 ms | - |
平均 TPOT | 40.65 ms | 39.20 ms | +3.5% | 68.78 ms | 65.73 ms | +4.4% | 46.83 ms | 43.97 ms | +4.4% |
中央値 TPOT | 41.14 ms | 39.61 ms | - | 69.19 ms | 66.33 ms | - | 45.37 ms | 43.30 ms | - |
P99 TPOT | 62.57 ms | 58.71 ms | - | 100.35 ms | 95.55 ms | - | 62.29 ms | 54.79 ms | - |





