大規模言語モデル（LLM）のシナリオでは、ユーザーリクエストとモデルレスポンスの長さの差、入力および出力生成フェーズでモデルによって生成されるトークン数のランダム性、単一のリクエストによって占有される GPU リソース量の不確実性のために、従来の負荷分散ポリシーはバックエンドの負荷をリアルタイムで検出できません。その結果、バックエンド推論インスタンスの負荷が不均衡になり、システムのスループットとレスポンスレイテンシに影響します。この問題を解決するために、Elastic Algorithm Service（EAS）は、LLM シナリオのメトリックに基づいてリクエストを動的に分散できる基本コンポーネントとして LLM インテリジェントルーターを提供します。これにより、推論インスタンス全体で計算能力と GPU メモリが均等に割り当てられ、クラスタリソースの利用率とシステムの安定性が大幅に向上します。
仕組み
機能紹介
LLM インテリジェントルーターは、LLM ゲートウェイ、LLM スケジューラ、および LLM エージェントで構成されています。
LLM ゲートウェイ
ユーザーリクエストのトラフィックを転送します。
プロトコル：HTTP（HTTP_SSE）および WebSocket プロトコルをサポートします。
バッファ付きレート制限：バックエンド推論インスタンスの負荷が高く、待機キューにすでにリクエストが含まれている場合、新しく着信したリクエストはすぐにスケジュールされるのではなく、LLM ゲートウェイにキャッシュされます。適切なインスタンスが使用可能になった後に転送されます。
LLM スケジューラ
LLM インテリジェントルーターのコアコンポーネントであり、最適なバックエンド推論インスタンスを選択するために使用されます。
新しいバージョンの LLM スケジューラは、プロンプトプレフィックスに基づくスケジューリングをサポートし（バックエンドのプレフィックスキャッシング機能を有効にする必要があります）、インスタンスの負荷と主要なメトリックに基づいて最適な推論インスタンスを選択します。
LLM エージェント
推論インスタンスと共にデプロイされ、以下の機能をサポートします。
キープアライブと例外処理：LLM スケジューラとのハートビート接続を維持して、推論プロセスのヘルスをリアルタイムで監視します。推論インスタンスの例外が発生した場合、LLM スケジューラに連絡してインスタンスを削除し、インスタンスが回復した後にサービスリストに再統合します。
メトリックの収集とレポート：待機キューの長さ、KV キャッシュの使用率、1 秒あたりの入力または出力トークン数など、推論エンジンに関連するメトリックを収集し、LLM スケジューラに報告します。
推論フレームワークの自動検出：Blade-LLM、vLLM、SGLang などのバックエンド推論フレームワークの自動識別をサポートし、手動構成の必要性を減らします。
実装プロセス
LLM インテリジェントルーターは本質的に特別な EAS サービスであり、推論サービスと同じサービスグループにデプロイする必要があります。 LLM インテリジェントルーターと推論サービスをデプロイすると、LLM インテリジェントルーターはリクエストを推論サービスにインテリジェントにスケジュールできます。具体的な実装プロセスを以下に示します。
インスタンスの登録：LLM スケジューラがリクエストを処理する準備ができたら、LLM エージェントはインスタンスを LLM スケジューラに登録し、関連するエンジンのメトリックをリアルタイムで収集して報告します。
トラフィックイングレス：トラフィックエントリとして、LLM ゲートウェイはリクエストの受信と転送を担当します。サポートされているプロトコルには、HTTP（HTTP_SSE）と websocket が含まれます。
LLM インテリジェントルーターの名前が llm_gateway の場合、それが属するサービスグループは group_llm_gateway で、アクセスアドレスは
http://********.cn-beijing.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completionsです。リクエストのスケジューリングと転送：LLM ゲートウェイがリクエストを受信すると、関連情報を LLM スケジューラに送信します。スケジューリングポリシーは、現在のメトリックに基づいて最適なバックエンドインスタンスを選択し、バックエンドインスタンスを LLM ゲートウェイに返します。次に、LLM ゲートウェイはリクエストをバックエンドインスタンスに送信して推論を行います。
フェイルオーバーメカニズム
このセクションでは、LLM インテリジェントルーターの例外処理機能について説明します。
LLM ゲートウェイ：トラフィックイングレス層として、インスタンス数は通常 2 以上です。インスタンスに障害が発生した場合、トラフィックは自動的に他の正常なインスタンスにリダイレクトされ、継続的なサービスの可用性が確保されます。
LLM スケジューラ：リクエストスケジューリングモジュールとして、現在、グローバルスケジューリングの問題に対処するために単一インスタンスとして実行するように設計されています。 LLM スケジューラに障害が発生した場合、LLM ゲートウェイはその可用性がないことを検知し、自動的にラウンドロビン戦略に切り替えて、リクエストをバックエンド推論インスタンスに転送します。 LLM スケジューラが回復すると、システムはスケジューリングロジックを復元し、通常の動作を再開します。
LLM エージェント：このコンポーネントは、優れたスケーラビリティを維持しながら推論フレームワークに非侵入型であり、複数の LLM 推論エンジンをサポートすることを目的としています。 LLM エージェントに障害が発生した場合、LLM スケジューラはサービスリストからインスタンスを削除して、トラフィックが障害のあるインスタンスに転送されなくなり、他の正常なインスタンスに転送されるようにします。
推論エンジン（BladeLLM、vLLM、または SGLang）：推論エンジンの固有の不安定性のため、障害が発生した場合、LLM エージェントはそれを迅速に検出し、LLM スケジューラのサービスリストからインスタンスを削除し、トラフィック割り当てを一時停止します。インスタンスが回復すると、サービスリストに再統合され、トラフィックの処理が再開されます。
複数の推論エンジン
各 LLM 推論エンジンの /metrics インターフェイスによって返されるメトリック情報の違いにより、LLM エージェントはこれらのメトリックを収集、標準化、および報告する責任があります。 LLM スケジューラは、特定の推論エンジンの実装の詳細に焦点を当てる必要はなく、標準化されたメトリックに基づいてスケジューリングアルゴリズムを開発するだけで済みます。次の表に、サポートされている LLM 推論エンジンと対応するメトリックを示します。
LLM 推論エンジン | メトリック | 説明 |
Blade_LLM | decode_batch_size_mean | 実行中のリクエストの数。 |
wait_queue_size_mean | キューに入れられたリクエストの数。 | |
block_usage_gpu_mean | GPU KV キャッシュの使用率。 | |
tps_total | 1 秒あたりに処理されるトークンの総数。 | |
tps_out | 1 秒あたりに生成されるトークン数。 | |
vLLM | vllm:num_requests_running | 実行中のリクエストの数。 |
vllm:num_requests_waiting | キューに入れられたリクエストの数。 | |
vllm:gpu_cache_usage_perc | GPU KV キャッシュの使用率。 | |
vllm:prompt_tokens_total | プロンプト内のトークンの総数。 | |
vllm:generation_tokens_total | 1 秒あたりに生成されるトークン数。 | |
SGLang | sglang:num_running_reqs | 実行中のリクエストの数。 |
sglang:num_queue_reqs | キューに入れられたリクエストの数。 | |
sglang:token_usage | KV キャッシュの使用率。 | |
sglang:prompt_tokens_total | プロンプト内のトークンの総数。 | |
sglang:gen_throughput | 1 秒あたりに生成されるトークン数。 |
制限事項
LLM インテリジェントルーターは、LLM 推論シナリオに適用されます。バックエンドインスタンスの推論フレームワークとして使用できるのは、BladeLLM、vLLM、および SGLang のみです。
LLM インテリジェントルーターの値は、LLM インテリジェントルーターと複数の推論インスタンスが同じサービスグループにデプロイされている場合にのみ実現できます。
LLM インテリジェントルーターのデプロイ中は、LLM インテリジェントルーターと LLM サービスが同じ推論フレームワークを使用していることを確認してください。
LLM インテリジェントルーターは、LLM サービスをデプロイする場合にのみサポートされます。 LLM サービスを更新する場合にはサポートされていません。
サービスのデプロイ
LLM インテリジェントルーターのデプロイ
以下のデプロイ方法がサポートされています。
方法 1：PAI コンソールでサービスをデプロイする
PAI コンソール にログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS) に入る] をクリックします。
[Elastic Algorithm Service (EAS)] ページで、[サービスのデプロイ] をクリックします。[サービスのデプロイ] ページで、次のいずれかのデプロイ方法を選択します。
[カスタムモデルデプロイメント] > [カスタムデプロイメント] を選択します。
[シナリオベースのモデルデプロイメント] > [LLM デプロイメント] を選択します。
[機能] セクションで、[LLM インテリジェントルーター] をオンにします。次に、ドロップダウンリストで [LLM インテリジェントルーターの作成] をクリックします。
[LLM インテリジェントルーターの作成] パネルで、パラメーターを構成し、[デプロイ] をクリックします。次の表でパラメーターについて説明します。
パラメーター
説明
[基本情報]
[サービス名]
サービスの名前を指定します（例：llm_gateway）。
[リソース構成]
[デプロイメント]
LLM インテリジェントルーターのリソースを構成します。デフォルト構成：
[最小インスタンス]Bearer：2。LLM インテリジェントルーターが複数のインスタンスで実行できるように、 を 2 以上に設定することをお勧めします。
[CPU]：2 コア。
[メモリ]：4 GB。
[スケジュールリソース]
LLM スケジューラのスケジューリングリソースを構成します。デフォルト構成：
[CPU]：2 コア。
[メモリ]：4 GB。
[推論エンジン]
イメージで使用する推論フレームワークを選択します。以下のフレームワークがサポートされています。
[PAI-BladeLLM]
[vLLM]
[SGLang]
[スケジューリングポリシー]
システムは、スケジューリングポリシーに基づいて最適なバックエンド推論インスタンスを選択します。以下のスケジューリングポリシーがサポートされています。
[リクエストマッチ]：この KV キャッシュアフィニティスケジューリングポリシーは、複数のメトリックに基づく包括的なスケジューリングポリシーです。リクエスト処理の効率を最大化するために、類似のリクエストを対応する KV キャッシュインスタンスに転送します。エンジンのプレフィックスキャッシング機能を有効にする必要があります。
[LLM メトリック]：リソース効率を最大化するために、LLM サービスの監視メトリックに基づいてサービストラフィックをインテリジェントに割り当てます。
[最小リクエスト]：サーバーの過負荷の可能性を減らすために、リクエストをサーバー全体にできるだけ均等に分散します。このポリシーは、リクエスト数が最も少ないサーバーを優先的に選択することにより、負荷を分散します。
[PD 分解]：このポリシーは、Prefill-Decode 分解 LLM デプロイメントシナリオでスケジューリング効率を最大化できます。
LLM インテリジェントルーターがデプロイされると、同時にサービスグループが作成されます。[Elastic Algorithm Service (EAS)] ページの [カナリアリリース] タブでサービスグループを表示できます。サービスグループには、group_LLM インテリジェントルーターサービスの名前 の形式で名前が付けられます。
LLM インテリジェントルーターはサービスキューと競合します。したがって、LLM インテリジェントルーターまたはサービスキューのいずれかをサービスグループに追加できます。
方法 2：JSON を使用してサービスをデプロイする
PAI コンソール にログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS) に入る] をクリックします。
Elastic Algorithm Service (EAS) ページで、[サービスのデプロイ] をクリックします。[カスタムモデルデプロイメント] サービスのデプロイページのセクションで、[JSON デプロイメント] をクリックします。
JSON デプロイメントページの構成エディターセクションで、パラメーターを構成し、[デプロイ] をクリックします。
主要なパラメーターについて以下に説明します。その他のパラメーターについては、「JSON デプロイメントのパラメーター」をご参照ください。
metadata.type: このパラメーターを LLMGatewayService に設定して、LLM Intelligent Router をデプロイします。デプロイメントが完了すると、EAS は LLM Gateway と LLM Scheduler を含む複合サービスを自動的に作成します。
LLM Gateway はサービス構成を使用します。
ヒント: インストール中に問題が発生した場合は、WordPress のドキュメントを参照してください。
metadata.instance：LLM ゲートウェイインスタンスの数。単一障害点を防ぐために、このパラメーターを 2 に設定することをお勧めします。
次のサンプルコードは、構成ファイルの例を示しています。基本構成を使用して LLM インテリジェントルーターをデプロイできます。基本構成が要件を満たしていない場合は、詳細構成を使用します。
基本構成：
{ "cloud": { "computing": { "instance_type": "ecs.c7.large" // インスタンスタイプ } }, "metadata": { "type": "LLMGatewayService", // サービスの種類 "cpu": 4, // CPU コア数 "group": "group_llm_gateway", // サービスグループ名 "instance": 2, // インスタンス数 "memory": 4000, // メモリ (MB) "name": "llm_gateway" // サービス名 } }詳細構成：
{ "cloud": { "computing": { "instance_type": "ecs.c7.large" // インスタンスタイプ } }, "llm_gateway": { // LLM ゲートウェイの設定 "infer_backend": "vllm", // 推論バックエンド "max_queue_size": 128, // 最大キューサイズ "retry_count": 2, // リトライ回数 "wait_schedule_timeout": 5000, // スケジュール待機タイムアウト (ms) "wait_schedule_try_period": 500 // スケジュール試行間隔 (ms) }, "llm_scheduler": { // LLM スケジューラの設定 "cpu": 4, // CPU コア数 "memory": 4000, // メモリ (MB) "policy": "prefix-cache" // スケジューリングポリシー }, "metadata": { "cpu": 2, // CPU コア数 "group": "group_llm_gateway", // サービスグループ名 "instance": 2, // インスタンス数 "memory": 4000, // メモリ (MB) "name": "llm_gateway", // サービス名 "type": "LLMGatewayService" // サービスの種類 } }次の表で主要なパラメーターについて説明します。
パラメーター
説明
llm_gateway.infer_backend
LLM によって使用される推論フレームワーク。有効な値：
vllm
bladellm
sglang
このパラメーターを空のままにすると、システムは LLM サービス構成に基づいて推論エンジンを自動的に検出します。
llm_gateway.max_queue_size
LLM ゲートウェイのキャッシュキューの最大長です。デフォルト値：512。
バックエンド推論フレームワークの処理能力を超えた場合、超過したリクエストはスケジューリングのためにキューにキャッシュされます。
llm_gateway.retry_count
再試行回数。デフォルト値：2。リクエストが転送されるバックエンド推論インスタンスが異常な場合、LLM Intelligent Router はリクエストを別のインスタンスに転送しようとします。
llm_gateway.wait_schedule_timeout
バックエンドエンジンが過負荷状態の場合にリクエストがスケジュールされる間隔です。デフォルト値：10。単位：秒。
llm_gateway.wait_schedule_try_period
リクエストがスケジュールされる間隔です。デフォルト値：1。単位：秒。
llm_scheduler.cpu
LLM スケジューラの vCPU 数。デフォルト値：4 です。
llm_scheduler.memory
LLM スケジューラのメモリ。デフォルト値：4。単位：GiB。
llm_scheduler.instance_type
プラグイン注:LLM スケジューラのインスタンスタイプ。インスタンスタイプは、vCPU 数とメモリを定義します。このパラメーターを指定する場合、vCPU 数とメモリを個別に指定する必要はありません。 パラメーターまたは パラメーターのいずれかを設定する必要があります。
llm_scheduler.policy
スケジューリングポリシー。有効な値：
[プレフィックスキャッシュ]（デフォルト）：この KV-Cache アフィニティスケジューリングポリシーは、複数のメトリックに基づく包括的なスケジューリングポリシーです。同様の リクエスト を対応する KV-Cache インスタンス に転送して、リクエスト 処理の効率を最大化します。エンジンのプレフィックスキャッシング機能を有効にする必要があります。
注: このチュートリアルでは、基本的な JavaScript の知識があることを前提としています。
ヒント: インストールプロセス中にデータベースの情報を入力する必要があります。
pd-split: このポリシーは、Prefill-Decode 分離型 LLM デプロイメント シナリオにおけるスケジューリング効率を最大化できます。
LLM サービスをデプロイする
シナリオベースのモデルデプロイメントまたは数回 [モデルギャラリー] をクリックするだけで、LLM サービスをデプロイできます。この例では、シナリオベースのモデルデプロイメントを使用します。
PAI コンソール にログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS) に入る] をクリックします。
Elastic Algorithm Service (EAS) ページで、[サービスのデプロイ] をクリックします。サービスのデプロイ ページで、[LLM デプロイメント] を選択し、主要なパラメーターを構成します。その他のパラメーターについては、「コンソールでのカスタムデプロイメントのパラメーター」をご参照ください。
説明サービスのデプロイ時に、LLM Intelligent Router で使用する推論エンジンを選択します。
vLLM アクセラレーションデプロイメントを使用し、LLM Intelligent Router の作成時に [スケジューリングポリシー] を [リクエストマッチ] に設定する場合は、エンジンのプレフィックスキャッシング機能を有効にする必要があります。
右上隅にある [カスタムデプロイメントに変換] をクリックして、[コマンド] などの関連パラメーターを変更できます。
パラメーター
説明
基本情報
バージョン
2 つのバージョンのいずれかを選択します。
オープンソースモデルクイックデプロイメント: このバージョンを使用する場合は、vLLM、BladeLLM、または SGLang をサポートするモデルタイプを選択します。
高性能デプロイメント: BladeLLM エンジンを使用して、LLM サービスを迅速にデプロイします。イメージバージョンとモデル設定を選択する必要があります。
サービス構成
LLM Intelligent Router
LLM Intelligent Router をオンにし、デプロイした LLM Intelligent Router サービスを選択します。
パラメーターを構成した後、[デプロイ] をクリックします。
追加情報
推論サービスのデプロイ
PAI コンソール にログインします。ページ上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS) に入る] をクリックします。
デプロイした LLM Intelligent Router サービスを見つけ、[サービスの種類] 列の [呼び出し方法] をクリックします。
[呼び出し方法] ダイアログボックスで、サービスにアクセスするためのエンドポイントとトークンを表示します。
サービスにアクセスするためのエンドポイントを設定します。
エンドポイントの設定ルール: <LLM Intelligent Router のアドレス>/<LLM サービスの要求インターフェース>。
<LLM Intelligent Router のアドレス> は、ステップ 3 で取得したエンドポイントです。例:
http://175805416243****.cn-beijing.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway。<LLM サービスの要求インターフェース> は、LLM サービスの API です。例:
v1/completions。
値の例:
http://175805416243****.cn-beijing.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/completions。
アクセスのテスト
詳細については、「Managing Plugins」をご参照ください。
curl -H "Authorization: xxxxxx" -H "Content-Type: application/json" http://********.cn-beijing.pai-eas.aliyuncs.com/api/predict/<サービスグループ名>.<LLM インテリジェントルーターサービス名>/v1/completions -d '{"model": "llama2", "prompt": "I need your help writing an article. I will provide you with some background information to begin with. And then I will provide you with directions to help me write the article.", "temperature": 0.0, "best_of": 1, "n_predict": 34, "max_tokens": 34, "stream": true}'これで WordPress のインストールは完了です。WordPress アプリケーションをお楽しみください！
「Authorization: xxxxxx」: 前のステップで取得したトークンを指定します。
http://********.cn-beijing.pai-eas.aliyuncs.com/api/predict/<Name of a service group>.<Name of LLM Intelligent Router>/v1/completions: 前のステップで取得したエンドポイントで値を置き換えます。
サンプル応答:
data: {"id":"0d9e74cf-1025-446c-8aac-89711b2e****","choices":[{"finish_reason":"","index":0,"logprobs":null,"text":"\n"}],"object":"text_completion","usage":{"prompt_tokens":36,"completion_tokens":1,"total_tokens":37},"error_info":null}
data: {"id":"0d9e74cf-1025-446c-8aac-89711b2e****","choices":[{"finish_reason":"","index":0,"logprobs":null,"text":"\n"}],"object":"text_completion","usage":{"prompt_tokens":36,"completion_tokens":2,"total_tokens":38},"error_info":null}
data: {"id":"0d9e74cf-1025-446c-8aac-89711b2e****","choices":[{"finish_reason":"","index":0,"logprobs":null,"text":""}],"object":"text_completion","usage":{"prompt_tokens":36,"completion_tokens":3,"total_tokens":39},"error_info":null}
...
[完了]JavaScript で REST API を使用する
テストが完了したら、サービス監視メトリックを表示して、サービスのパフォーマンスを理解できます。次の手順を実行します。
Elastic Algorithm Service (EAS) ページで、デプロイした LLM Intelligent Router サービスを見つけ、[ログ / モニタリング] 列の アイコンをクリックします。表示されるページの [モニタリング] タブで、次のメトリックを確認します。
トークンスループット
LLM の入力トークンと出力トークンのスループット。
IN: LLM の入力トークンのスループット。
OUT: LLM の出力トークンのスループット。
GPU キャッシュ使用率
キーバリュー (KV) キャッシュによって消費される GPU メモリの割合。
エンジン現在のリクエスト数
LLM エンジンでの同時リクエスト数（リアルタイム）。
実行中: LLM エンジンが処理中のリクエスト数。
待機中: LLM エンジンでキューに入っているリクエスト数。
ゲートウェイ現在のリクエスト数
LLM Intelligent Router でのリクエスト数（リアルタイム）。
合計: LLM Intelligent Router がリアルタイムで受信したリクエストの総数。
保留中: LLM Intelligent Router にキャッシュされ、LLM エンジンによって処理されるのを待機しているリクエスト数。
最初のトークンまでの時間
最初の出力トークンのレイテンシ。
最大: 最初の出力トークンの最大レイテンシ。
平均: 最初の出力トークンの平均レイテンシ。
最小: 最初の出力トークンの最小レイテンシ。
TPxx: 最初の出力トークンのレイテンシのパーセンタイル。
出力トークンあたりの時間
出力トークンのレイテンシ。
最大: 出力トークンの最大レイテンシ。
平均: 出力トークンの平均レイテンシ。
最小: 出力トークンの最小レイテンシ。
TPxx: 出力トークンのレイテンシのパーセンタイル。