すべてのプロダクト
Search
ドキュメントセンター

Platform For AI:LLM インテリジェントルーターのデプロイ

最終更新日:Feb 07, 2026

リアルタイムのリソースメトリクスおよびスケジューリングポリシーに基づくインテリジェントなトラフィックルーティングにより、大規模言語モデル(LLM)の推論パフォーマンスを最適化します。LLM インテリジェントルーターは、推論インスタンス間でコンピューティングリソースとメモリ割り当てを動的に分散することで、クラスターのリソース利用率およびサービス信頼性を向上させます。

仕組み

アーキテクチャ概要

LLM インテリジェントルーターは、バックエンドの LLM 推論インスタンスクラスター向けにインテリジェントなトラフィック分散および管理を提供するため、以下の 3 つのコアコンポーネントで構成されます:

  • LLM ゲートウェイ:HTTP/SSE および WebSocket プロトコルをサポートする主要なトラフィック入口およびリクエスト処理コンポーネント

  • LLM スケジューラ:リアルタイムメトリクスを集約し、ポリシーに基づいたスケジューリング判断を行う中央知能コンポーネント

  • LLM エージェント:各推論インスタンスにサイドカーコンテナーとして展開される分散型監視プローブ

重要

LLM インテリジェントルーターは特殊な EAS サービスであり、正常に機能させるには、推論サービスと同じサービスグループ内にデプロイする必要があります。

image

コアワークフローの処理手順は以下のとおりです:

  1. インスタンス登録:推論サービスが起動すると、LLM エージェント は推論エンジンの準備完了を待機した後、LLM スケジューラ にインスタンスを登録し、定期的に健全性ステータスおよびパフォーマンスメトリクスを報告します。

  2. トラフィック受信:ユーザーからのリクエストは、まず LLM ゲートウェイ で受信されます。

  3. スケジューリング判断LLM ゲートウェイLLM スケジューラ に対してスケジューリング要求を送信します。

  4. インテリジェントスケジューリングLLM スケジューラ は、すべての LLM エージェント から報告されたスケジューリングポリシーおよびリアルタイムメトリクスに基づき、最適なバックエンドインスタンスを選択します。

  5. リクエスト転送: LLM Scheduler は、LLM Gateway に判断結果を返し、LLM Gateway がユーザーの元のリクエストをターゲット インスタンスに転送します。

  6. リクエストバッファリング:すべてのバックエンドインスタンスが高負荷状態の場合、新規リクエストは一時的に LLM ゲートウェイ のキュー内でバッファリングされ、LLM スケジューラ による適切な転送機会の検出を待ちます。これにより、リクエスト失敗を防止します。

コアコンポーネント

コンポーネント

主な責任

LLM ゲートウェイ

主要なトラフィック入口およびリクエスト処理コンポーネント。すべてのユーザーからのリクエストを受信し、LLM スケジューラ の判断に基づき、指定されたバックエンド推論インスタンスに転送します。

  • HTTP(HTTP_SSE)および WebSocket プロトコルをサポートし、バックエンド推論インスタンスが高負荷状態の際にリクエストをバッファリングできます。

  • Anthropic API プロトコル変換をデフォルトで有効化しており、Anthropic 互換リクエストを自動的に OpenAI 互換フォーマットに変換します。コードを変更することなく、Claude Code などのエコシステムツールを直接使用して、OpenAI インターフェイス標準に準拠したモデルサービスを呼び出すことができ、シームレスな統合が可能です。詳細については、「付録:Claude Code の使用方法」をご参照ください。

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 インテリジェントルーターサービスのデプロイ

  1. PAI コンソール にログインし、ページ上部でターゲットリージョンを選択します。

  2. 左側のナビゲーションウィンドウで、Elastic Algorithm Service (EAS) をクリックし、対象のワークスペースを選択して EAS ページに移動します。

  3. Deploy Service をクリックし、Scenario-based Model Deployment > Deploy LLM gateway を選択します。

  4. パラメーターを設定します:

    パラメーター

    説明

    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 です。詳細な比較および選択ガイドについては、「スケジューリングポリシーの詳細および選択方法」をご参照ください。

  5. Deploy をクリックします。サービスステータスが Running に変わると、デプロイが成功したことを意味します。

デプロイが成功すると、システムは自動的に group_<LLM インテリジェントルーターサービス名> という名前のサービスグループを作成します。EAS ページに移動し、Elastic Algorithm Service (EAS) ページの Canary Release タブでサービスグループを確認できます。image

説明

インテリジェントルーティングはサービスキューと競合するため、同一のサービスグループ内に共存できません。

ステップ 2:LLM サービスのデプロイ

LLM サービスをデプロイし(詳細については、「大規模言語モデルのデプロイ」をご参照ください)、先に作成したインテリジェントルーターサービスに関連付けます:

  1. Features セクションで、LLM Intelligent Router スイッチをオンにします。

  2. ステップ 1 でデプロイした LLM インテリジェントルーターサービスをドロップダウンリストから選択します。

説明

LLM インテリジェントルーターサービスが Prefix cache スケジューリングポリシーを使用する場合、vLLM のデプロイ時に プレフィックスキャッシュ 機能が有効になっていることを確認してください。

ステップ 3:サービスのテスト

すべてのリクエストは、特定のバックエンド推論サービスのエンドポイントではなく、LLM インテリジェントルーターサービスのエンドポイントに送信する必要があります。

  1. アクセス認証情報の取得

    1. LLM インテリジェントルーターサービスをクリックして、Overview ページに移動します。Basic Information セクションで、View Endpoint Information をクリックします。

    2. エンドポイント情報 ページで、Internet Endpoint および トークンService-specific Traffic Entry セクションからコピーします。image

  2. リクエスト 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

    policypd-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 の入力および出力トークンのスループットです。image

  • IN:LLM 入力トークンのスループット。

  • OUT:LLM 出力トークンのスループット。

GPU キャッシュ使用率

LLM エンジンの GPU KV キャッシュ使用率(パーセント)です。

image

エンジンの同時リクエスト数

LLM エンジンのリアルタイム同時リクエスト数です。

image

  • 実行中:LLM エンジンが現在実行中のリクエスト数。

  • 待機中:LLM エンジンの待機キュー内のリクエスト数。

ゲートウェイの同時リクエスト数

LLM インテリジェントルーターのリアルタイムリクエスト数です。

image

  • 合計:LLM インテリジェントルーターが現在受信中のリクエストの総数。これはリアルタイムの同時並行数の合計です。

  • 保留中:LLM インテリジェントルーター内でバッファリングされており、LLM エンジンによってまだ処理されていないリクエスト数。

初回トークン到達時間(TTFT)

リクエストの初回トークンの遅延時間です。

image

  • 最大:初回トークンの最大遅延時間。

  • 平均:初回トークンの平均遅延時間。

  • 最小:初回トークンの最小遅延時間。

  • TPxx:初回トークン遅延時間のパーセンタイル値。

出力トークンごとの処理時間(TPOT)

パッケージ単位のリクエスト遅延時間です。

image

  • 最大:パッケージ単位のリクエスト遅延時間の最大値。

  • 平均:パッケージ単位のリクエスト遅延時間の平均値。

  • 最小:リクエスト内のパッケージの最小遅延時間。

  • TPxx:パッケージ単位のリクエスト遅延時間のパーセンタイル値。

付録:Claude Code の使用方法

  1. EAS インテリジェントルーターサービスから提供される BASE URL および TOKEN を、Claude Code に設定します。

    # <YOUR_GATEWAY_URL> および <YOUR_TOKEN> を実際の値に置き換えます
    export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL>
    export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>
  2. 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

-