大規模言語モデル (LLM) のワークロードは、リクエストの長さが可変であること、トークンの生成がランダムであること、GPU 使用率が変動することなどの課題を抱えています。従来のロードバランサーはバックエンドの負荷をリアルタイムで検出できないため、インスタンスの負荷が不均一になり、システムパフォーマンスが低下します。これらの課題に対処するため、EAS は LLM インテリジェントルーターを提供します。これは、インテリジェントなスケジューリングと可視化された O&M を統合したサービスです。リアルタイムの LLM メトリックに基づいて計算能力と GPU メモリを動的にバランスさせ、高いスループットと安定性を確保します。サービスに組み込まれた WebUI ワークベンチは、ライブモニタリング、動的な構成更新、および ID 分離によるマルチユーザー API キー管理を提供し、運用の複雑さを大幅に削減します。
仕組み
コアコンポーネント
LLM インテリジェントルーターサービスは、以下の 2 つのコアコンポーネントで構成されています。
-
LLM Gateway:トラフィックのエントリポイントであり、リクエスト処理センターです。ユーザーリクエストを受信し、
LLM Schedulerからの決定に基づいてターゲットの推論インスタンスに転送します。-
HTTP (HTTP_SSE) および WebSocket プロトコルをサポートします。
-
デフォルトでは、Anthropic API プロトコル変換機能が有効になっています。この機能は、Anthropic 準拠のリクエストを自動的に OpenAI 互換のフォーマットに変換します。これにより、Claude Code などのエコシステムツールを使用して、コードを変更することなく OpenAI API 標準に準拠したモデルサービスを呼び出すことができます。詳細については、「Claude Code を使用した呼び出し」をご参照ください。
-
-
LLM Scheduler:インテリジェントなスケジューリングエンジンです。プレフィックスキャッシュルーティングなどのスケジューリングポリシーに基づいて、各リクエストに最適なターゲットインスタンスを選択します。
ワークフロー
以下は主要なワークフローです。
-
リクエストの受信:ユーザーリクエストが
LLM Gatewayに到着します。バックエンドの推論インスタンスの負荷が高い場合、ゲートウェイはリクエストをキューに入れます。 -
インテリジェントスケジューリング:
LLM GatewayはスケジューリングリクエストをLLM Schedulerに送信します。LLM Schedulerは、スケジューリングポリシーと各インスタンスからのリアルタイムメトリックに基づいて最適なインスタンスを選択します。 -
リクエストの転送:スケジューリングの決定を受け取った後、
LLM Gatewayはユーザーリクエストを選択されたインスタンスに直接転送します。
フェイルオーバーメカニズム
多層的なフォールトトレランスメカニズムにより、サービスの安定性が保証されます。
-
LLM Gateway:少なくとも 2 つのインスタンスをデプロイすることを推奨します。インスタンスに障害が発生した場合、トラフィックは自動的に正常なインスタンスにフェイルオーバーします。
-
LLM Scheduler:スケジューラに障害が発生した場合、
LLM Gatewayは自動的にラウンドロビンルーティングにフォールバックします。これにより、インテリジェントなスケジューリングを犠牲にして可用性が確保されます。スケジューラが回復すると、自動的にインテリジェントなスケジューリングを再開します。 -
推論インスタンス:推論インスタンスに障害が発生した場合、
LLM Schedulerはすぐに利用可能なプールからそれを削除し、新しいトラフィックのルーティングを停止します。インスタンスが回復すると、スケジューラは自動的にそれをプールに戻します。
制限事項
-
サービスグループの要件:
-
LLM インテリジェントルーターが正しく機能するためには、推論サービスと同じサービスグループにデプロイする必要があります。
-
インテリジェントルーターサービスとキューサービスは、同じサービスグループ内に共存できません。
-
-
インテリジェントルーターサービスは、新しい推論サービスを作成するときにのみ設定可能:サービスのグループメンバーシップは作成時に設定され、後で変更することはできません。したがって、インテリジェントルーティング機能は新しい推論サービスを作成するときにのみ設定できます。既存の推論サービスに対してサービスの更新を使用してインテリジェントルーティングを追加または変更することはできません。
-
推論エンジンの制限:vLLM または SGLang のみがサポートされています。
-
NLB および Nacos との非互換性:NLB または Nacos を介して公開されている推論サービスで LLM インテリジェントルーターを使用することはできません。
-
複数インスタンスの推奨:LLM インテリジェントルーターは、複数の推論インスタンスをデプロイした場合にのみスケジューリングの利点を提供します。
クイックスタート:LLM インテリジェントルーター
ステップ 1:LLM インテリジェントルーターのデプロイ
-
PAI コンソールにログインし、ページ上部でターゲットリージョンを選択します。
-
左側のナビゲーションウィンドウで、Elastic Algorithm Service (EAS) をクリックします。EAS ページで、ターゲットワークスペースを選択します。
-
モデルのアップロードとデプロイメント をクリックし、シナリオベースのモデルデプロイ > LLM インテリジェントルーターのデプロイメント を選択します。
-
パラメーターを設定します。
パラメーター
説明
基本情報
サービス名
サービスのカスタム名を入力します。例:
llm_gateway。リソースのデプロイメント
リソースのデプロイメント
LLM Gatewayのリソース構成を指定します。高可用性のために、インスタンス数: はデフォルトで 2 に設定されています。この設定を維持することを推奨します。デフォルトの構成は 4 vCPU と 8 GB のメモリです。スケジューリング設定
LLM Schedulerのリソース構成を指定します。デフォルトは 2 vCPU と 4 GB のメモリです。スケジューリングポリシー
バックエンド推論インスタンスの負荷分散ポリシーです。デフォルトは プレフィックスに基づくキャッシュ です。選択に役立つ詳細な比較については、「スケジューリングポリシーのリファレンス」をご参照ください。
高度な機能
Redis の設定
任意。ユーザー情報と使用統計を永続化します。設定しない場合、サービスはローカルメモリを使用し、サービスが停止するとデータは失われます。詳細については、「Redis 永続ストレージの設定」をご参照ください。
-
デプロイメント をクリックします。サービスステータスが 実行中 に変わると、デプロイは成功です。
デプロイ後、システムは自動的に group_<LLM インテリジェントルーターのサービス名> という名前のサービスグループを作成します。グループを表示するには、Elastic Algorithm Service (EAS) ページに移動し、グループサービス タブをクリックします。
ステップ 2:LLM サービスのデプロイ
新しい LLM サービスをデプロイする際に、インテリジェントルーター機能を設定する必要があります。既存のサービスに更新アクションでこの機能を追加することはできません。
以下の手順では、Qwen3-8B のデプロイを例として使用します。
-
モデルのアップロードとデプロイメント をクリックし、シナリオベースのモデルデプロイ > LLM 大規模言語モデル を選択します。
-
以下の主要なパラメーターを設定します。
パラメーター
値
基本情報
モデル設定
パブリックモデル を選択し、Qwen3-8B を検索して選択します。
推論エンジン
vLLM を選択します (推奨、OpenAI API と互換性あり)。
説明LLM インテリジェントルーターサービスが プレフィックスに基づくキャッシュ スケジューリングポリシーを使用し、推論エンジンとして vLLM を選択した場合、エンジンのプレフィックスキャッシュ機能が有効になっていることを確認してください。
デプロイテンプレート
単一ノードを選択します。システムはテンプレートから推奨されるインスタンス仕様、イメージ、その他のパラメーターを自動的に入力します。
サービス機能の設定
LLM インテリジェントルーター
トグルをオンにし、ドロップダウンリストからステップ 1 でデプロイした LLM インテリジェントルーターサービスを選択します。
-
デプロイメント をクリックします。デプロイには約 5 分かかります。サービスステータスが 実行中 に変わると、デプロイは成功です。
ステップ 3:サービスのテスト
すべてのリクエストは、バックエンドの推論サービスではなく、LLM インテリジェントルーターサービスのアクセスエンドポイントに送信する必要があります。
-
サービスグループ内のいずれかの推論サービスでトラフィック分散が有効になっている場合、サービスグループの集約トラフィックエントリを介して送信されたリクエストは、インテリジェントルーターをバイパスし、スケジューリングの失敗を引き起こす可能性があります。
-
サービスグループ内でトラフィック分散が有効になっているのは、インテリジェントルーターサービスのみであることを確認してください。リクエストは、インテリジェントルーターサービスの専用トラフィックエントリ URL を介して送信してください。
-
アクセス認証情報の取得
-
LLM インテリジェントルーターサービスの 概要 ページに移動します。基本情報 セクションで、エンドポイント情報の表示 をクリックします。
-
[エンドポイント情報] ページの 独立したサービストラフィックの入口 で、インターネットエンドポイント と トークン をコピーします。
重要ここでのサービストークンは、管理者 API キーです。管理者が WebUI ワークベンチを介して別の API キーを割り当てた場合は、以下の例で
<YOUR_TOKEN>をご自身の API キーに置き換えてください。 -
-
リクエスト 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> を実際の値に置き換えてください curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -H "Content-Type: application/json" \ -N \ -d '{ "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] -
サービスをデプロイした後、WebUI ワークベンチを使用して、ライブモニタリングや構成管理などのタスクを実行できます。詳細については、「LLM インテリジェントルーターワークベンチの使用」をご参照ください。
Redis 永続ストレージの設定
LLM インテリジェントルーターには、マルチユーザー管理、ロールベースアクセス制御、監査ログ、データ概要をサポートする組み込みのユーザー管理機能が含まれています。外部の Redis インスタンスを使用して、ユーザー情報と使用統計を永続化できます。Redis が設定されていない場合、サービスはローカルメモリを使用し、サービスが停止するとすべてのデータが失われます。本番デプロイでは、永続ストレージ用に Redis を設定してください。
ステップ 1:Tair (Redis) インスタンスのプロビジョニング
-
Tair 購入ページからインスタンスを購入します。
重要インスタンスを作成する際は、LLM インテリジェントルーターサービスと同じ VPC と vSwitch を選択してください。その他のオプションについては、最小仕様から始めることができます。
-
LLM インテリジェントルーターサービスの vSwitch の CIDR ブロックをインスタンスの許可リストに追加します。詳細については、「許可リストの設定」をご参照ください。
-
ターゲットインスタンス ID をクリックして詳細ページを開きます。LLM インテリジェントルーターサービスをデプロイする際に、接続情報が必要になります。
-
接続アドレスとポート:[インスタンス情報] セクションの[接続情報] で、VPC 接続アドレスとポート番号を確認します。
-
ユーザー名とパスワード:[アカウント管理] ページで、デフォルトのアカウントを見つけます。インスタンス作成時にパスワードを設定しなかった場合は、ここで設定またはリセットできます。デフォルトのアカウントの代わりに新しいアカウントを作成することもできます。
-
ステップ 2:Redis の設定
基本構成に加えて、VPC を構成し、Redis 接続パラメーターを追加して永続ストレージを有効にする必要があります。
-
VPC の設定:VPC と vSwitch は、ステップ 1 でプロビジョニングした Tair インスタンスと同じである必要があります。これにより、LLM インテリジェントルーターサービスが Tair インスタンスに接続できるようになります。
-
Redis の設定:
コンソール
高度な機能 セクションで、Redis の設定 を有効にし、以下のパラメーターを入力します。
パラメーター
説明
Redis アドレス
Tair インスタンスの接続アドレス。形式は
<VPC アドレス>:<ポート>です。例:r-uxxx.redis.rds.aliyuncs.com:6379。Redis ユーザー名
Tair インスタンスのユーザー名。
Redis パスワード
Tair インスタンスのパスワード。
JSON
JSON 本文の
llm_gatewayノードに、以下のパラメーターを追加します。パラメーター
説明
enable_user_managementユーザー管理を有効にします。デフォルトは
trueです。redis_addrsTair インスタンスの接続アドレス。形式は
<VPC アドレス>:<ポート>です。例:r-uxxx.redis.rds.aliyuncs.com:6379。redis_usernameTair インスタンスのユーザー名。
redis_passwordTair インスタンスのパスワード。
JSON の例:
{ "llm_gateway": { "enable_user_management": true, "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379", "redis_username": "xxx", "redis_password": "xxx" } }
高度な設定 (JSON)
LLM Gateway のリソース仕様を設定し、そのリクエスト処理を微調整するには、JSON デプロイメントを使用します。
オンライン推論サービス ページで、モデルのアップロードとデプロイメント をクリックします。カスタムモデルのデプロイ セクションで、JSON 独立デプロイメント をクリックします。
設定例
{
"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",
"rpc": {
"disable_auth": true
}
}
}
パラメーター
|
パラメーター |
説明 |
|
|
metadata |
type |
必須。LLM インテリジェントルーターサービスのデプロイを示す |
|
instance |
必須。 |
|
|
cpu |
各 |
|
|
memory |
|
|
|
group |
LLM インテリジェントルーターサービスが属するサービスグループ。 |
|
|
rpc.disable_auth |
必須。 |
|
|
cloud.computing.instance_type |
|
|
|
llm_gateway |
max_queue_size |
リクエストがバックエンドの推論フレームワークの容量を超えた場合、超過したリクエストはこのキューに保持され、スケジューリングを待ちます。 |
|
retry_count |
リトライ回数。デフォルト:2。バックエンドの推論インスタンスに障害が発生した場合、システムはリクエストをリトライし、正常なインスタンスに転送します。 |
|
|
wait_schedule_timeout |
バックエンドエンジンが全容量で稼働している場合、このパラメーターはリクエストのスケジューリングにかかる合計タイムアウトをミリ秒単位で指定します。デフォルトは 5000 (5 秒) です。 |
|
|
wait_schedule_try_period |
スケジューリング試行の間隔 (ミリ秒単位)。デフォルトは 500 (0.5 秒) です。 |
|
|
request_stream_prefill_timeout |
ストリーミングリクエストのプレフィルタイムアウト (秒単位)。これは、最初のトークンを待つ最大時間です。デフォルト:300。 |
|
|
request_stream_decode_timeout |
ストリーミングリクエストのデコードタイムアウト (秒単位)。これは、連続するチャンク間の最大アイドル間隔です。デフォルト:300。 |
|
|
request_stream_total_timeout |
ストリーミングリクエスト全体に対する合計タイムアウト (秒単位)。デフォルト:0 (タイムアウトなし)。 |
|
|
request_non_stream_timeout |
非ストリーミングリクエストのタイムアウト (秒単位)。これは、完全な応答を得るまでの最大時間です。デフォルト:900。 |
|
|
llm_scheduler |
cpu |
|
|
memory |
|
|
|
policy |
スケジューリングポリシー。デフォルト: |
|
|
prefill_policy |
policy が pd-split に設定されている場合、Prefill と Decode の各ステージに対して個別のスケジューリングポリシーを指定する必要があります。有効な値は、prefix-cache、llm-metric-based、least-request、および least-token です。 |
|
|
decode_policy |
||
付録
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 "Write a Python Hello World program"
スケジューリングポリシー
この表は、各スケジューリングポリシーのロジック、ユースケース、利点、および考慮事項を比較したものです。
|
ポリシー |
JSON 値 |
説明 |
ユースケース |
利点 |
考慮事項 |
|
プレフィックスに基づくキャッシュ |
prefix-cache |
(推奨) 同じ会話履歴 (プロンプト) を持つリクエストを、一致する KV キャッシュを持つインスタンスに優先的にルーティングする複合ポリシー。 |
固定のシステムプロンプトを持つマルチターンチャットボットおよび RAG システム。 |
最初のトークンまでの時間 (TTFT) を大幅に短縮し、マルチターン対話のパフォーマンスとスループットを向上させます。 |
推論エンジンでプレフィックスキャッシュが有効になっている必要があります。 |
|
最小リクエスト |
least-request |
現在最も少ないリクエストを処理しているインスタンスに新しいリクエストをルーティングします。 |
リクエストの複雑さが比較的一様なワークロード (同様のトークン長と生成長)。 |
シンプルで効率的です。インスタンス間でリクエスト数を迅速に均等化します。 |
リクエストの実際の計算コストを考慮しません。短いリクエストを処理するインスタンスはアイドル状態になる可能性があり、長いリクエストを処理するインスタンスは過負荷になる可能性があります。 |
|
最小トークン |
least-token |
現在最も少ない合計トークン (入力 + 出力) を処理しているインスタンスに新しいリクエストをルーティングします。 |
トークン数が処理コストを確実に反映するワークロード。 |
最小リクエスト数ポリシーよりも実際のインスタンス負荷をより正確に反映します。 |
トークン数の推定に依存し、すべての推論エンジンがこのメトリックを報告するわけではありません。 |
|
静的 PD 分離 |
pd-split |
インスタンスは Prefill グループと Decode グループに事前に分割され、各グループに個別のスケジューリングポリシーが設定されます。 |
Prefill と Decode のステージで計算およびメモリアクセスパターンが大幅に異なり、分離が明確な利点をもたらすワークロード。 |
ステージ固有のチューニングにより、ハードウェア使用率を最大化します。 |
設定が複雑です。モデルとワークロードを理解し、個別の Prefill および Decode サービスをデプロイする必要があります。 |
パフォーマンスベンチマーク
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 |
||||||
|
メトリック |
スマートルーターなし |
スマートルーターあり |
改善 |
スマートルーターなし |
スマートルーターあり |
改善 |
スマートルーターなし |
スマートルーターあり |
改善 |
|
成功したリクエスト |
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 |
+6.1% |
|
中央値 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 |
- |