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

Platform For AI:LLM インテリジェントルーターによる推論効率の向上

最終更新日:Aug 06, 2026

大規模言語モデル (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:インテリジェントなスケジューリングエンジンです。プレフィックスキャッシュルーティングなどのスケジューリングポリシーに基づいて、各リクエストに最適なターゲットインスタンスを選択します。

ワークフロー

以下は主要なワークフローです。

  1. リクエストの受信:ユーザーリクエストが LLM Gateway に到着します。バックエンドの推論インスタンスの負荷が高い場合、ゲートウェイはリクエストをキューに入れます。

  2. インテリジェントスケジューリングLLM Gateway はスケジューリングリクエストを LLM Scheduler に送信します。LLM Scheduler は、スケジューリングポリシーと各インスタンスからのリアルタイムメトリックに基づいて最適なインスタンスを選択します。

  3. リクエストの転送:スケジューリングの決定を受け取った後、LLM Gateway はユーザーリクエストを選択されたインスタンスに直接転送します。

フェイルオーバーメカニズム

多層的なフォールトトレランスメカニズムにより、サービスの安定性が保証されます。

  • LLM Gateway:少なくとも 2 つのインスタンスをデプロイすることを推奨します。インスタンスに障害が発生した場合、トラフィックは自動的に正常なインスタンスにフェイルオーバーします。

  • LLM Scheduler:スケジューラに障害が発生した場合、LLM Gateway は自動的にラウンドロビンルーティングにフォールバックします。これにより、インテリジェントなスケジューリングを犠牲にして可用性が確保されます。スケジューラが回復すると、自動的にインテリジェントなスケジューリングを再開します。

  • 推論インスタンス:推論インスタンスに障害が発生した場合、LLM Scheduler はすぐに利用可能なプールからそれを削除し、新しいトラフィックのルーティングを停止します。インスタンスが回復すると、スケジューラは自動的にそれをプールに戻します。

制限事項

  • サービスグループの要件

    • LLM インテリジェントルーターが正しく機能するためには、推論サービスと同じサービスグループにデプロイする必要があります。

    • インテリジェントルーターサービスとキューサービスは、同じサービスグループ内に共存できません。

  • インテリジェントルーターサービスは、新しい推論サービスを作成するときにのみ設定可能:サービスのグループメンバーシップは作成時に設定され、後で変更することはできません。したがって、インテリジェントルーティング機能は新しい推論サービスを作成するときにのみ設定できます。既存の推論サービスに対してサービスの更新を使用してインテリジェントルーティングを追加または変更することはできません。

  • 推論エンジンの制限vLLM または SGLang のみがサポートされています。

  • NLB および Nacos との非互換性:NLB または Nacos を介して公開されている推論サービスで LLM インテリジェントルーターを使用することはできません。

  • 複数インスタンスの推奨:LLM インテリジェントルーターは、複数の推論インスタンスをデプロイした場合にのみスケジューリングの利点を提供します。

クイックスタート:LLM インテリジェントルーター

ステップ 1:LLM インテリジェントルーターのデプロイ

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

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

  3. モデルのアップロードとデプロイメント をクリックし、シナリオベースのモデルデプロイ > LLM インテリジェントルーターのデプロイメント を選択します。

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

    パラメーター

    説明

    基本情報

    サービス名

    サービスのカスタム名を入力します。例:llm_gateway

    リソースのデプロイメント

    リソースのデプロイメント

    LLM Gateway のリソース構成を指定します。高可用性のために、インスタンス数: はデフォルトで 2 に設定されています。この設定を維持することを推奨します。デフォルトの構成は 4 vCPU と 8 GB のメモリです。

    スケジューリング設定

    LLM Scheduler のリソース構成を指定します。デフォルトは 2 vCPU と 4 GB のメモリです。

    スケジューリングポリシー

    バックエンド推論インスタンスの負荷分散ポリシーです。デフォルトは プレフィックスに基づくキャッシュ です。選択に役立つ詳細な比較については、「スケジューリングポリシーのリファレンス」をご参照ください。

    高度な機能

    Redis の設定

    任意。ユーザー情報と使用統計を永続化します。設定しない場合、サービスはローカルメモリを使用し、サービスが停止するとデータは失われます。詳細については、「Redis 永続ストレージの設定」をご参照ください。

  5. デプロイメント をクリックします。サービスステータスが 実行中 に変わると、デプロイは成功です。

    デプロイ後、システムは自動的に group_<LLM インテリジェントルーターのサービス名> という名前のサービスグループを作成します。グループを表示するには、Elastic Algorithm Service (EAS) ページに移動し、グループサービス タブをクリックします。

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

新しい LLM サービスをデプロイする際に、インテリジェントルーター機能を設定する必要があります。既存のサービスに更新アクションでこの機能を追加することはできません。

以下の手順では、Qwen3-8B のデプロイを例として使用します。

  1. モデルのアップロードとデプロイメント をクリックし、シナリオベースのモデルデプロイ > LLM 大規模言語モデル を選択します。

  2. 以下の主要なパラメーターを設定します。

    パラメーター

    基本情報

    モデル設定

    パブリックモデル を選択し、Qwen3-8B を検索して選択します。

    推論エンジン

    vLLM を選択します (推奨、OpenAI API と互換性あり)。

    説明

    LLM インテリジェントルーターサービスが プレフィックスに基づくキャッシュ スケジューリングポリシーを使用し、推論エンジンとして vLLM を選択した場合、エンジンのプレフィックスキャッシュ機能が有効になっていることを確認してください。

    デプロイテンプレート

    単一ノードを選択します。システムはテンプレートから推奨されるインスタンス仕様、イメージ、その他のパラメーターを自動的に入力します。

    サービス機能の設定

    LLM インテリジェントルーター

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

  3. デプロイメント をクリックします。デプロイには約 5 分かかります。サービスステータスが 実行中 に変わると、デプロイは成功です。

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

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

説明
  • サービスグループ内のいずれかの推論サービスでトラフィック分散が有効になっている場合、サービスグループの集約トラフィックエントリを介して送信されたリクエストは、インテリジェントルーターをバイパスし、スケジューリングの失敗を引き起こす可能性があります。

  • サービスグループ内でトラフィック分散が有効になっているのは、インテリジェントルーターサービスのみであることを確認してください。リクエストは、インテリジェントルーターサービスの専用トラフィックエントリ URL を介して送信してください。

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

    1. LLM インテリジェントルーターサービスの 概要 ページに移動します。基本情報 セクションで、エンドポイント情報の表示 をクリックします。

    2. [エンドポイント情報] ページの 独立したサービストラフィックの入口 で、インターネットエンドポイントトークン をコピーします。

    重要

    ここでのサービストークンは、管理者 API キーです。管理者が WebUI ワークベンチを介して別の API キーを割り当てた場合は、以下の例で <YOUR_TOKEN> をご自身の API キーに置き換えてください。

  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> を実際の値に置き換えてください
    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) インスタンスのプロビジョニング

  1. Tair 購入ページからインスタンスを購入します。

    重要

    インスタンスを作成する際は、LLM インテリジェントルーターサービスと同じ VPC と vSwitch を選択してください。その他のオプションについては、最小仕様から始めることができます。

  2. LLM インテリジェントルーターサービスの vSwitch の CIDR ブロックをインスタンスの許可リストに追加します。詳細については、「許可リストの設定」をご参照ください。

  3. ターゲットインスタンス ID をクリックして詳細ページを開きます。LLM インテリジェントルーターサービスをデプロイする際に、接続情報が必要になります。

    • 接続アドレスとポート[インスタンス情報] セクションの[接続情報] で、VPC 接続アドレスとポート番号を確認します。

    • ユーザー名とパスワード[アカウント管理] ページで、デフォルトのアカウントを見つけます。インスタンス作成時にパスワードを設定しなかった場合は、ここで設定またはリセットできます。デフォルトのアカウントの代わりに新しいアカウントを作成することもできます。

ステップ 2:Redis の設定

基本構成に加えて、VPC を構成し、Redis 接続パラメーターを追加して永続ストレージを有効にする必要があります。

  • VPC の設定VPCvSwitch は、ステップ 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_addrs

    Tair インスタンスの接続アドレス。形式は <VPC アドレス>:<ポート> です。例:r-uxxx.redis.rds.aliyuncs.com:6379

    redis_username

    Tair インスタンスのユーザー名。

    redis_password

    Tair インスタンスのパスワード。

    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 インテリジェントルーターサービスのデプロイを示す LLMGatewayService に設定する必要があります。

instance

必須。LLM Gateway のレプリカ数。単一障害点を避けるために、この値を 2 以上に設定することを推奨します。

cpu

LLM Gateway レプリカの vCPU 数。

memory

LLM Gateway のメモリ (GB 単位)。

group

LLM インテリジェントルーターサービスが属するサービスグループ。

rpc.disable_auth

必須。true に設定する必要があります。

cloud.computing.instance_type

LLM Gateway のインスタンスタイプを指定します。このパラメーターを指定した場合、metadata.cpumetadata.memory を設定する必要はありません。

llm_gateway

max_queue_size

LLM Gateway の最大キュー深度。デフォルト:128。

リクエストがバックエンドの推論フレームワークの容量を超えた場合、超過したリクエストはこのキューに保持され、スケジューリングを待ちます。

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

LLM Scheduler の vCPU 数。デフォルトは 2 です。

memory

LLM Scheduler のメモリ (GB 単位)。デフォルトは 4 GB です。

policy

スケジューリングポリシー。デフォルト:prefix-cache。利用可能な値と説明については、「スケジューリングポリシーのリファレンス」をご参照ください。

prefill_policy

policypd-split に設定されている場合、Prefill と Decode の各ステージに対して個別のスケジューリングポリシーを指定する必要があります。有効な値は、prefix-cache、llm-metric-based、least-request、および least-token です。

decode_policy

付録

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 "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

-