たった一つの model=auto で、「どのモデルを選ぶか」をゲートウェイに任せましょう。
自動ルーティング(Auto Router) は、リクエスト内容に応じてプラットフォーム上の数百のモデルから最適な一つをリアルタイムで選び出します。あなたは model を auto にするだけ——モデルを選ぶ必要も、価格を比べる必要も、モデルの更新を追いかける必要もありません。
実際にヒットしたモデルで課金され、追加料金はかからず、クライアントのコード変更も不要です。どのモデルがヒットしたかは応答ヘッダーと応答ボディに記録され(実際にヒットしたモデルの確認方法を参照)、完全に追跡可能です。
ユースケース
- 汎用アプリ:ユーザーがどんなタイプのリクエストを送ってくるか分からないとき、内容に応じた振り分けを
autoに任せられます。 - コスト最適化:簡単なタスクを自動的により安く、より速いモデルに割り当てます(
autoはデフォルトでコスト優先)。 - 品質最適化:複雑なリクエストを、より能力の高いモデルへ確実にルーティングします(
auto:quality_first)。 - 低レイテンシ用途:リアルタイム音声や agent の多段ループでは、最も応答が速いモデルを優先します(
auto:latency_critical)。 - 統一エントリ・モデル選定不要:異なるタイプのリクエストを自動的にそれぞれ最適なモデルへ振り分け——「タスク → モデル」の対応表を保守する必要も、モデルの更新を追いかけて手動で価格比較やモデル名の差し替えをする必要もありません。
クイックスタート
model を auto に設定するだけで、その他のリクエストボディは通常の呼び出しとまったく同じです。base_url には https://aihubmix.com/v1 を使用します。
実際にヒットしたモデルの確認方法
これが自動ルーティングの信頼の拠り所です:そのリクエストで最終的にどのモデルが使われたかを、あなたは常に把握できます。- 応答ボディの
modelフィールドには、autoではなく実際にヒットしたモデル(例:mimo-v2.5-pro)が書き戻されます。 - 応答ヘッダーには完全な決定情報が含まれます:
| 応答ヘッダー | 意味 | 値の例 |
|---|---|---|
X-Aihubmix-Router-Resolved-Model | 実際にヒットし、それに基づいて課金されるモデル | xiaomi-mimo-v2.5-pro |
X-Aihubmix-Router-Policy | 今回使用されたポリシー | cost_optimized |
X-Aihubmix-Router-Dimension | 識別されたタスクの次元 | text.overall |
X-Aihubmix-Router-Decision-Id | 今回の決定の一意な ID、トラブルシュートに便利 | 05dbad09-33c5-42de-… |
X-Aihubmix-Router-Reason | 決定の簡潔な説明(ポリシー / 次元 / 最高スコア / 候補数) | policy=cost_optimized dim=text.overall top=0.182 survivors=20/33 |
X-Aihubmix-Router-Fallback | 候補なしのフォールバックが発生したときのみ出現 | true |
HTTP 応答ヘッダーは大文字小文字を区別しません:上表では慣例的に頭文字を大文字にしていますが、実際の HTTP/2 の返却は小文字の x-aihubmix-router-* であり、両者は等価です。
ルーティング決定の読み取り方(curl では応答ヘッダーを見る、SDK では生の応答オブジェクトから header を取得する):
reason の読み方:survivors=20/33 は、33 個の候補のうち 20 個がハードフィルタを通過してスコアリングに進んだことを示し、top=0.182 は勝ち残ったモデルが候補プール内で正規化された後の総合スコア(能力 / コスト / レイテンシをポリシーに従って重み付け)です。
例の
Resolved-Model は本番 catalog の現在の候補と価格に依存し、プラットフォームのモデルの追加・廃止に伴って変化します——これこそが自動ルーティングの価値です:あなたはこうした変化を追いかける必要がありません。決定を後から検証できるようにするには、固定だと仮定せず、応答ヘッダー / 応答ボディに記録された実際のモデル名を基準にしてください。ルーティングポリシー
サフィックスなしのauto はデフォルトポリシー cost_optimized を使用します。auto:<ポリシー> で重視する点を明示的に指定できます:
| ポリシーの書き方 | 重視する点 | 適した場面 |
|---|---|---|
auto(= auto:cost_optimized) | コスト優先:能力が基準を満たせば最も安いものを選ぶ | バッチ処理、コストに敏感な場合 |
auto:balanced | バランス:能力 / コスト / レイテンシを両立 | 汎用、迷ったときの無難な選択 |
auto:quality_first | 品質優先:能力が最も高いものを優先 | 複雑な推論、重要な出力 |
auto:latency_critical | 低レイテンシ優先:応答が最も速いものを優先 | リアルタイム音声、agent ループ |
model にサフィックスを付けるだけです:
What is the meaning of life? で、いずれも text.overall 次元に落ちる):
| ポリシー | ヒットしたモデル | top スコア |
|---|---|---|
auto(= cost_optimized) | xiaomi-mimo-v2.5-pro | 0.182 |
auto:balanced | claude-opus-4-6-think | 0.488 |
auto:latency_critical | claude-opus-4-6 | 0.646 |
auto:quality_first | claude-opus-4-6-think | 0.758 |
latency_criticalは**-think版ではない**ものを選びました——thinking バリアントは推論のレイテンシが高く、低レイテンシポリシーはこれを積極的に避けます。ポリシーの重み付けが「能力 / コスト / レイテンシ」のトレードオフに実際に作用しており、能力だけを見ているのではないことが分かります。
内容も結果を変えます:同じauto:quality_firstをコーディングタスク(上の例のリクエスト)に使うと、次元はtext.overallからtext.codingに変わり、実測ではclaude-opus-4-6-thinkがヒットしました——ポリシーとリクエスト内容が共同で最終的なモデルを決定します。
未知のポリシーサフィックス(例:
auto:fast)はデフォルトポリシー cost_optimized にフォールバックし、エラーにはなりません。仕組み
model=auto を受け取ると、ゲートウェイは 3 ステップで「意図」を「具体的なモデル」に変換します:
リクエスト特徴の抽出
今回のリクエストの入力 / 出力モダリティ(テキスト、画像、ファイル)、内容の意図(コード、数学、OCR、図表、言語、ネット検索の有無など)、およびリクエスト規模(入力 / 出力 token の推定)を分析し、一つのタスク次元へ正規化します。例えば:コードを含む質問 →
text.coding;画像付きで OCR を要求 → vision.ocr;通常のテキスト → text.overall。候補のハードフィルタ
必須の制約を満たさないモデルを直接除外します:必要な入力 / 出力モダリティに非対応、コンテキストウィンドウに収まらない、サーキットブレーカーで切り離されている(信頼性とフォールトトレランスを参照)、またはあなたのこの Key で利用可能なモデルの範囲外、といった場合です。
quality_first ポリシーでの、同一候補プールの top 3。データは本番の決定ログから取得):
| 候補モデル | 能力スコア | 相対コスト | レイテンシ | 総合スコア |
|---|---|---|---|---|
claude-opus-4-6-think | 1504 | 220 | 1963ms | 0.758 |
claude-opus-4-6 | 1498 | 220 | 822ms | 0.721 |
claude-fable-5 | 1510 | 484 | 11130ms | 0.600 |
claude-fable-5 の能力スコアが最も高い(1510)にもかかわらず、コストが高くレイテンシも大きいために総合スコアで 3 位に押し下げられている点に注目してください。これこそが重み付けスコアリングの意義です:「能力至上主義」ではなく、ポリシーに従って能力 / コスト / レイテンシの間でトレードオフを取っているのです。
次元の識別は自動です——自動ルーティングには 30 以上の細分化されたタスク次元(コード / 数学 / OCR / 図表 / 長文 / 中国語 / ネット検索…)が組み込まれており、「モデルファミリーによる大まかな振り分け」よりもはるかに精緻です。同じ auto でも、内容が異なれば異なる次元へルーティングされます:
| あなたのリクエスト | 識別される次元 |
|---|---|
| 通常のテキスト質問 | text.overall |
| コードを含み、プログラムの作成 / デバッグを要求 | text.coding |
| 数学の証明 / 求解 | text.math |
| 非常に長い質問(約 500+ token) | text.longer_query |
| 中国語の質問 | text.language.chinese |
| 画像入力 + “What is in this image?” | vision.overall |
| 画像入力 + “OCR…” / “文字を認識” | vision.ocr |
| 画像入力 + 図表 / フローチャート | vision.diagram |
| ネット検索を有効化 | search.overall |
画像入力も自動ルーティングを通ります:
/v1/chat/completions で画像を含める場合、画像タスクとして視覚能力の高いモデルへルーティングされます。本番での実測——「OCR this image」→ vision.ocr、qwen3.5-397b-a17b がヒット;汎用の画像理解「What is in this image?」→ vision.overall、gpt-5.4-mini がヒット。(ここでいうのは画像の理解です。画像の生成 /v1/images/* は現在 auto に非対応、FAQ を参照。)信頼性とフォールトトレランス
自動ルーティングには多重のフォールトトレランスが組み込まれており、auto パスが理由もなく失敗することは決してありません:
サーキットブレーカー:故障モデルを自動的に切り離す
サーキットブレーカー:故障モデルを自動的に切り離す
ゲートウェイは各モデルについてスライディングウィンドウの失敗率統計を保持します。あるモデルがウィンドウ内で十分な回数失敗し、かつ失敗率がしきい値を超えると、一時的に候補プールから切り離され、一定時間のクールダウン後に自動で復帰します——後続のリクエストを、調子を崩しているモデルに送り続けるのを避けるためです。失敗のシグナルは上流がそのリクエストに返したエラーに由来します。ゲートウェイ自身の「利用可能なチャネルなし」はカウントされません(それはモデル自体の問題ではないため)。
候補なしフォールバック:auto では決して 400 を返さない
候補なしフォールバック:auto では決して 400 を返さない
万が一ハードフィルタですべての候補が除外された場合(例えばあるモダリティの組み合わせに一時的に利用可能なモデルがない場合)でも、ゲートウェイは直接エラーを返さず、出力タイプに応じてフォールバック用のモデルを割り当てて応答を保証し、応答ヘッダーに
X-Aihubmix-Router-Fallback: true を付与してあなたに知らせます。権限逸脱防止線:制限付き Key はフォールバックで回避されない
権限逸脱防止線:制限付き Key はフォールバックで回避されない
あなたの Key が利用可能なモデルの範囲を限定している場合、自動ルーティング(フォールバックを含む)が選ぶモデルは常にその範囲内です。範囲内にこのリクエストを処理できるモデルが本当に一つもない場合は、範囲外(より高価かもしれない)のモデルを黙って使うのではなく、明確に 403 を返します。
課金について
実際にヒットしたモデルの定価で課金され、自動ルーティング自体はいかなる追加料金も徴収しません。 最終的にどのモデルが応答したかに応じて、そのモデルの価格・能力・コンテキスト制限で計算されます——このモデルが、応答ヘッダーX-Aihubmix-Router-Resolved-Model と応答ボディの model フィールドの値です。言い換えれば、自動ルーティングが「こっそり高いモデルを使う」ことはありません:ヒットのたびに応答に記録され、一件ずつ照合できます。
制限事項
-
自動ルーティングは現在チャット補完インターフェース
/v1/chat/completionsを対象としています(詳細は FAQ:対応しているインターフェース を参照)。 -
?router=offまたはリクエストヘッダーX-Router-Offは、model=autoに対して直接 400 を返します——これは「auto を使いたいがルーティングはオフにしたい」という曖昧な使い方を黙って無視するのではなく、明確に拒否するものです: -
候補の集合はプラットフォームの catalog に応じて動的に変化します:同じ
autoでも、時点が異なれば異なるモデルがヒットすることがあります(これは設計上の仕様であり、応答ヘッダーで後から検証できます)。
OpenRouter / LiteLLM との違い
「モデルを自動選択する」のは AIHubMix 独自のものではなく、OpenRouter と LiteLLM も同様の機能を提供しています。違いは主に導入コストとホスティング方式にあります:| 違いの観点 | OpenRouter | LiteLLM | AIHubMix |
|---|---|---|---|
| リクエスト内容に応じた自動モデル選択 | ✅ | ✅ | ✅ |
| 設定不要・すぐ使える(ルーティングルール / utterances の記述が不要) | ✅ | ❌ | ✅ |
| プラットフォームでホスト、proxy の自前構築 / 自己デプロイが不要 | ✅ | ❌ | ✅ |
| コスト / 品質 / レイテンシの複数ポリシーを 1 パラメータで切り替え | ❌ | ❌ | ✅ |
| ヒット決定が追跡可能(応答ヘッダーに dimension / policy / reason を含む) | ❌ | ❌ | ✅ |
| 最終的にヒットしたモデルで課金 | ✅ | ❌ | ✅ |
よくある質問 FAQ
Q:自動ルーティングはどのインターフェースに対応していますか? A:現在model=auto は OpenAI 互換のチャット補完インターフェース /v1/chat/completions に対応しています。画像生成 / 編集(/v1/images/*)、音声、/v1/embeddings、/v1/rerank などのインターフェースは現在 auto に非対応のため、具体的なモデルを直接指定してください。
Q:自動ルーティングは画像入力に対応していますか?
A:対応しています。/v1/chat/completions で画像(image_url)を含めた質問は画像の理解にあたり、画像タスクとして視覚能力の高いモデル(vision.ocr / vision.diagram / vision.overall など)へルーティングされます。注意点:画像の生成は /v1/images/* インターフェースを通り、現在 auto に非対応です。
Q:そのリクエストで結局どのモデルが使われたか、どうやって知るのですか?
A:応答ヘッダー X-Aihubmix-Router-Resolved-Model、または応答ボディの model フィールドを見てください——どちらにも実際のモデル名が書き戻されます。実際にヒットしたモデルの確認方法 を参照。
Q:自動ルーティングはこっそり高いモデルを使いませんか?
A:使いません。デフォルトポリシー cost_optimized はコスト優先です。さらに、ヒットしたモデルは毎回応答に記録され、その定価で課金されるため、一件ずつ照合できます。課金について を参照。
Q:コストはどう制御 / 予測しますか?
A:3 つの手段を重ねます——① デフォルトの auto(cost_optimized)がそもそもコスト優先;② Key の利用可能モデル範囲を使って候補を許容する価格帯に絞り込み、コストの上限を設けるのに相当;③ ヒットのたびに応答ヘッダー Resolved-Model のモデルの定価で課金されるので、一件ずつ照合できます。より高い能力が必要なときに、明示的に auto:quality_first を使ってください。
Q:auto と「モデルマッピング / フォールバック」の違いは何ですか?
A:モデルマッピング / フォールバック は Key レベルの固定エイリアス + 失敗時の順序付きフォールバック(毎回同じターゲット)です;自動ルーティングはリクエストごとの内容に応じた動的なモデル選択です。前者は「クライアントが特定の名前しか認識しない / メインモデルが落ちたら予備に切り替える」を解決し、後者は「どれでもいいので、最も適したものをくれ」を解決します。
Q:自動ルーティングが特定の数モデルからだけ選ぶよう限定できますか?
A:できます——Key の利用可能モデル範囲で制約します:自動ルーティングはその Key で許可されたモデルからのみ選び、範囲外のモデルがヒットすることはありません。
Q:ストリーミングリクエストに対応していますか?
A:対応しています。ルーティングはリクエストが上流に到達する前に完了し、ストリーミング / 非ストリーミングを同等に扱います。
Q:なぜ同じ一文を 2 回呼び出すと異なるモデルがヒットしたのですか?
A:候補の集合と価格はプラットフォームの catalog に応じて動的に変化します。これは設計上の仕様です。応答ヘッダーの Decision-Id と Resolved-Model を使えば、各決定を後から検証できます。
Q:リクエストが安定して同じモデルにヒットするようにするには(例えば prompt キャッシュを再利用したい)?
A:auto は現在の catalog に応じて動的にモデルを選ぶため、決定論性は保証されません。同じモデルへの安定したヒットが必要な場合(例えば上流の prompt キャッシュに依存する、または厳密に再現したい場合)は、具体的なモデル名を直接指定するか、Key で利用可能範囲を単一のモデルに限定してください——この 2 つの方法ではヒットは確定的になります。
関連リソース
- モデルマッピングとフォールバック:Key レベルの固定エイリアス + 失敗時フォールバックで、自動ルーティングを補完します。
- 統一推論パラメータ:モデルをまたいで一貫したリクエストパラメータ。
- AIHubMix モデルページ:モデル名・価格・
Input Modalitiesを確認できます。