インテリジェントモデルルーティングは、リクエスト内容を動的に分析し、候補セットから最適なモデルを自動的にマッチングすることで、複雑なシナリオにおける企業のAIリソース配分を最適化します。
概要
model-codeは固定のauto-modelプレフィックスに8文字のランダムな文字列が続く形式です（例：auto-model-abcd1234）。クライアントがこのmodel-codeを呼び出すと、→ ルーティングがリクエスト内容を動的に分析して候補セットから最も適したモデルをマッチングし → 実際のモデルが推論を行い → レスポンスを返します（レスポンスボディは実際の実行モデルを示し、実際のトークン使用量を保持します）。
適用範囲：
| 次元 | 説明 |
|---|---|
| リージョン | 北京（cn-beijing）+ シンガポール（ap-southeast-1） |
| モデルタイプ | テキスト入力のみ |
| 呼び出しプロトコル | OpenAI互換インターフェース（Chat Completions、Responses）とAnthropicプロトコル（Messages）をサポート。ネイティブのDashScopeプロトコルはサポートされていません |
| 課金 | 従量課金 |
| スロットリング | 実際のルーティング先モデルに基づき、アカウントおよびワークスペースレベルで適用されます |
- モデル効果の最大化：タスクごとに最適なモデルを自動的にマッチングするため、極めて高い品質要件を持つユーザーに最適です。
- 正確なコスト削減：シンプルなタスクは軽量モデルに、複雑なタスクはハイエンドモデルにルーティングし、過剰なプロビジョニングを回避してコストと需要の正確な整合を実現します。
- モデル選定の難しさを解消：手動でのモデル評価や比較は不要です。プラットフォームが最適なソリューションを自動選択するため、モデル選定の障壁が大幅に低下します。
- 学習コストの最小化：通常のモデルアクセスと同様で、model-codeを使用してコード変更なしで呼び出せます。
モデルルーターの作成
Bailianコンソールの「Model Inference > Dedicated Deployment」で、Deploy New Modelをクリックして作成ページに入り、「デプロイモード」でインテリジェントルーティングを選択します。
前提条件
- Bailianワークスペースが有効化されていること。
- 対象のルートモデルバージョンが公開されており、現在のアカウントにそのバージョンおよび候補モデルの呼び出し権限があること。
手順
- サービス名を入力します（必須、最大50文字）。
- デプロイモードで、「インテリジェントルーティング」を選択します。
- ルートモデルバージョンで、公開済みのバージョン（プラットフォームにより維持）を選択します。
- ルーティング戦略で、「Effect First」または「Cost First」を選択します。
- 候補モデルセットで、候補モデルを選択します（少なくとも2つ）。
- Confirm Deployをクリックして作成を完了します。
model-code（形式：auto-model-XXXXXXXX）を生成します。model-codeは削除後に再利用されません。
ルーティング戦略
ルーティング戦略は、候補セット内のどのモデルが各リクエストを実行するかを決定します。どちらの戦略もリクエスト内容に基づいて動的にマッチングを行います（固定ルーティングではありません）。選択は作成時に行われます。
戦略 | 選択メカニズム | 適用シナリオ |
|---|---|---|
効果優先（EFFECT_FIRST） | リクエストごとに候補セット内で最も効果の高いモデルを選択 | 品質が厳格に求められる重要なビジネス、複雑な推論、高品質なコンテンツ生成 |
コスト優先（COST_FIRST） | 品質の下限を満たしつつ、軽量モデルをインテリジェントにスケジュール | コスト重視、高並行性、レイテンシおよび単価を意識するシナリオ |
候補モデルの設定
候補モデルセットは、ルーティングサービスが選択できる範囲です。モデルルーターを作成する際、候補モデルセットエリアの候補リストからルーティングに参加するモデルを選択します。少なくとも2つの候補モデルが必要であり、それ以外の場合はデプロイがブロックされます。
RAMユーザーは、呼び出し権限を持つ候補モデルのみ選択できます。選択可能なモデルが2未満の場合は、まずそのワークスペースでRAMユーザーにモデル呼び出し権限を付与してください。
- model-router-20260908
候補モデル | 入力 | キャッシュ済み入力 | 出力 |
|---|---|---|---|
| $0.15 | $0.016 | $0.47 |
| $3 | $0.3 | $15 |
| 0-256K：$0.4 256k-1M：$1.2 | 0-256K：$0.08 256k-1M：$0.24 | 0-256K：$1.6 256k-1M：$4.8 |
| $0.44 | $0.044 | $1.32 |
| $0.22 | $0.022 | $0.66 |
| $2.5 | $0.5 | $7.5 |
| $1.4 | $0.28 | $4.4 |
| $1.32 | $0.132 | $3.96 |
| $0.66 | $0.066 | $1.98 |
| $2 | $0.25 | $6 |
| 0-32K：$0.03 256k-1M：$0.2 32k-256K：$0.1 | 0-32K：$0.006 256k-1M：$0.04 32k-256K：$0.02 | 0-32K：$0.13 256k-1M：$0.8 32k-256K：$0.4 |
候補モデルを選択する際は、各モデルのクォータ制限に注意し、ルーティング先のモデルでクォータ不足によるスロットリングが発生しないようにしてください。十分なクォータを持つモデルを選択するか、作成前に関連モデルのアカウントRPM/TPMクォータを引き上げてください。
モデルルーターの呼び出し
作成後は、モデルルーターの呼び出しは通常のモデルの呼び出しと同じです。リクエスト内のmodelパラメータをルーターのmodel-code（例：auto-model-abcd1234）に置き換えるだけで、クライアントはコード変更なしで統合できます。OpenAI互換インターフェース（Chat Completions、Responses）とAnthropicプロトコルの3つの呼び出し方法がサポートされており、呼び出し例はプロトコルごとのタブに分かれています。
- OpenAI互換（Chat Completions）
- OpenAI互換（Responses）
- Anthropicプロトコル
curl
modelフィールドには実際に呼び出されたモデルの識別子が含まれています（これを使用してルーティングが有効になったことを確認できます）。ボディは実際のトークン使用量を保持し、課金は実際にルーティングされたモデルに基づいて行われます。
課金：インテリジェントルーティングは、各リクエストがルーティングされた実際のモデルに基づいて課金されます。ルーティングモデル自体は無料です。
自動フェイルオーバー
モデルルーティングには自動フェイルオーバー機能が組み込まれており、デフォルトで有効になっていて設定は不要です。ターゲットモデルが利用できない場合、ルーティングサービスは推論中に切り替えることなく、別の候補モデルでリクエスト全体を再発行します。
以下は自動フェイルオーバーをトリガーしません。エラーは実際のモデルの元のエラー情報とともにそのまま渡されます：
- 429 (rate limit)
- 400/403/404/500およびその他の確定エラー（モデルを切り替えても失敗する可能性が高い）
- タイムアウトまたはネットワークエラー
- ストリーミングがコンテンツの返却を開始した後のエラー
自動フェイルオーバーでは二重課金は行われません。モデルA → 自動フェイルオーバー → モデルBが成功した場合、モデルBのみが課金されます。
リアルタイムフィルタリングルール
ルーティングサービスは候補セットにリアルタイムフィルタリングを適用します：
- 現在のアカウントに呼び出し権限のないモデルを除外します。
- オフラインのモデルを除外します。
- 現在のリクエストのパラメータと互換性のないモデルを除外します（例：リクエストに
response_formatが含まれる場合、そのパラメータをサポートする候補モデルにのみルーティングされます）。
使用制限
| 制限事項 | 説明 |
|---|---|
| 呼び出しプロトコル | OpenAI互換インターフェース（Chat Completions、Responses）とAnthropicプロトコル（Messages）；ネイティブのDashScopeプロトコルはサポートされていません |
| プロトコル | サポート済み |
|---|---|
| OpenAI互換インターフェース（Chat Completions） | ✓ |
| OpenAI互換インターフェース（Responses） | ✓ |
| DashScopeプロトコル | ✗ |
| Anthropicプロトコル | ✓ |
| リクエストタイプ | テキスト入力のみ対応（Chat Completions、Responses、Messagesのいずれも利用可能）。画像・動画入力、画像生成、バッチ推論、Embedding/Rerank、その他の非生成系インターフェースは未対応です |
| コンテキスト長 | 上限値＝候補モデル群の最小コンテキストウィンドウ。コンテキスト超過時は自動フェイルオーバーを発火させず直接エラーとなります |
| スロットリング | RPM/TPMは実際のルーティング先モデルに基づきアカウントおよびワークスペースレベルでスロットリングされます。フェイルオーバー時は最終的に成功したモデルの消費量のみがカウントされます |
パラメータに関する注意事項
インテリジェントルーティングは、リクエストパラメータに基づいて候補セットをリアルタイムにフィルタリングし、サポートされていないパラメータを拒否します（does not support parameter(s): <パラメータ名>の形式で400エラーを返します）。3つの呼び出しプロトコルでパラメータのサポート状況が異なるため、それぞれ以下に説明します：
- OpenAI互換（Chat Completions）
- OpenAI互換（Responses）
- Anthropicプロトコル
response_format：このパラメータをサポートする候補モデルにのみルーティングされます。enable_search：このパラメータをサポートする候補モデルにのみルーティングされます。reasoning_effort：デフォルトでこのパラメータをサポートする候補モデルにのみルーティングされます。サポートされる列挙値：none、minimal、low、medium、high、xhigh、max。最小以外のティアは非思考モデルにのみルーティングされます。enable_thinking：思考モードをサポートする候補モデルにのみルーティングされます。
| パラメータ | 説明 |
|---|---|
top_logprobs | 返却されるlogprobsの上限 |
logit_bias | トークンバイアス |
stop | ストップシーケンス |
tool_choice | ツール選択 |
parallel_tool_calls | 並列ツール呼び出し |
logprobs | logprobsを返すかどうか |
top_p | Nucleusサンプリング |
temperature | サンプリング温度 |
presence_penalty | プレゼンスペナルティ |
n | 生成数 |
thinking_budget | 思考予算長 |
キャッシュ
インテリジェントルーティングは明示的なキャッシュをサポートしていません。実際に呼び出されたモデルが提供する暗黙的キャッシュのみをサポートします。 キャッシュがヒットするのは、リクエストが同じモデルにルーティングされ、かつプロンプトのプレフィックスがそのモデルのキャッシュ条件を満たす場合に限られます。 異なるリクエストが異なるモデルにルーティングされる可能性があるため、インテリジェントルーティングはキャッシュヒット率を保証しません。 キャッシュの仕組みとサポートされているモデルの詳細については、コンテキストキャッシュを参照してください。
ルートサービスの管理
詳細を表示
デプロイ後、Dedicated Deploymentリストのサービス名をクリックして詳細ページに入ります：
- 基本情報：サービス名、
model-code、実行ステータス、ルーティング戦略タグ。 - ルート設定：ルートモデルバージョン、ルーティング戦略、候補セット、および候補モデルリスト。
- 課金：従量課金制で、実際のモデルの単価に基づいて課金されます。
- デプロイ設定：各候補モデルのTPM/RPMスロットルクォータ。
ルート設定の変更
ルート設定エリアの「編集」をクリックして、ルートバージョン、戦略、および候補モデルを変更できます。バージョンを切り替えると候補セットが変更され、数分以内に有効になりますが、ライブリクエストには影響しません。
特定のバージョンを選択した後、オンラインのルーティング動作は長期的に安定した状態を保ちます。ビジネスへの影響を避けるため、アップグレード前に十分な評価を行ってください。現在のバージョン：model-router-2026-0908。ルートバージョンは自動更新されません。
サービスの削除
専用デプロイメントリストからモデルルーティングサービスを削除します。削除後、model-codeは再利用されません。
ルーティング効果
本章では、ルーティング効果のメトリクスとモニタリングについて説明します。効果メトリクスは詳細ページの「ルーティング効果」タブで確認できます。呼び出しモニタリングはModel Monitoringページで確認できます。
ルーティングメトリクス
詳細ページの「ルーティング効果」タブで以下のメトリクスを確認できます。表示されるメトリクスは推定値であり、参考用です。課金の決済には使用されません。実際の課金は「Cost and Usage」に基づきます：
メトリクス | 意味 | 異常時の対応 |
|---|---|---|
ルーティングリクエスト総数 | 受信したリクエストの総数（フェイルオーバー成功分を含む） | スパイク発生時、上流のスロットリングや異常を調査 |
ルーティング成功率 | 転送されたリクエスト ÷ 総リクエスト × 100% | 低下時、候補モデルの可用性を確認 |
実際のモデルコスト（推定） | 実際のモデルのリスト価格で推定されたフルコスト（段階課金：最下層、ピークバレー：ピーク価格、無料クォータを除く、実際の課金とは異なる場合があります） | 上昇時、ルーティング戦略と候補セットを確認 |
ベースラインモデルコスト（推定） | すべてのリクエストがベースラインモデルで処理された場合の仮定コスト（同じ推定方法論） | — |
節約額 | ベースラインコスト − 実際のコスト（正の値はルーティングによるコスト削減を意味） | — |
課金対象リクエスト数 | 課金が発生する成功したリクエスト | — |
支出シェア | 単一モデルコスト ÷ 総コスト | 異常時、候補セットの分布を確認 |
コストに関する注意事項
コスト分析データには約1時間の遅延があり、リアルタイムではありません。 上記のコストはすべてカタログ価格に基づく推定フルコストであり、アカウント割引や無料クォータは含まれておらず、ルーティングによる節約効果を評価するための参考値としてのみご利用ください。 段階課金モデルは最下層のカタログ価格を使用し、ピークバレー課金モデルはピーク価格を使用します。 実際の課金は「コストと使用量」で確認できます。
モデルモニタリング
より詳細な呼び出しモニタリングを行うには、モデルモニタリングページに移動してください。 ここでは、実際にルーティングされた個々のモデルのモニタリングではなく、auto-modelディメンションでのモデルモニタリングとログが表示されます。