Skip to main content
ARouter はモデルの可用性、プロバイダーの健全性、コスト効率に基づいて、各リクエストを最適なアップストリームプロバイダーに自動的にルーティングします。ほとんどのユースケースでは、設定なしで自動的に行われます。 高度な制御が必要な場合は、リクエストボディに provider オブジェクトを渡して、ルーティング決定のカスタマイズができます。

provider オブジェクト

任意の /v1/chat/completions リクエストに provider オブジェクトを含めて、ルーティングのデフォルトをオーバーライドします:

フィールドリファレンス(全項目)


デフォルト戦略:コストベースの負荷分散

デフォルトでは、ARouter はコストを優先しながら、正常なプロバイダー間でリクエストを負荷分散します。アルゴリズム:
  1. 過去30秒間に重大な障害があったプロバイダーを除外
  2. 安定したプロバイダーの中で、価格の逆数の二乗で重み付けして選択
  3. 残りのプロバイダーを自動フォールバックとして使用
: プロバイダーAが1/Mトークン、プロバイダーB1/Mトークン、プロバイダーBが2/M、プロバイダーCが$3/Mの場合:
  • プロバイダーAはプロバイダーCより9倍選ばれやすい(逆数二乗重み付け)
  • プロバイダーAが失敗した場合、次にプロバイダーCを試みる
  • プロバイダーB(最近劣化)は最後に試みる
sort または order を設定すると、負荷分散は無効になり、プロバイダーは厳密な順序で試みられます。

プロバイダーソート

sort フィールドを使用してプロバイダー属性に明示的な優先度を付けます。負荷分散は無効になり、プロバイダーは順番に試みられます。 利用可能なソート値:
  • "price" — 最低トークンコストを優先
  • "throughput" — 最高 tokens/秒を優先
  • "latency" — 最低 Time-to-first-token を優先

:nitro:floor ショートカット

モデルスラッグにサフィックスを追加してソートの省略記法として使用:

パーティションを使った高度なソート

候補モデルリスト(models[])を使用する場合、sort フィールドは partition オプションを持つオブジェクトにして、エンドポイントがモデルをまたいでどのようにソートされるかを制御できます。 デフォルト(partition: "model")では、エンドポイントはモデルごとにグループ化されます——最初のモデルのエンドポイントは常に2番目のモデルより先に試みられます。partition: "none" を設定すると、このグループ化が解除され、全候補モデルにわたるグローバルソートが可能になります。

ユースケース1:複数モデルにわたる最高スループットへのルーティング

複数の許容可能なモデルがあり、現在最も速いものを使いたい場合:

ユースケース2:パフォーマンス要件を満たす最安値モデル

partition: "none" とパフォーマンス閾値を組み合わせて、SLAを満たしながら最低コストのオプションを見つける:

パフォーマンス閾値

プロバイダーをフィルタリングするための最低スループットまたは最大レイテンシーの設定。閾値を満たさないプロバイダーは優先度が下げられます(末尾に移動)が、完全に除外されるわけではありません。

パーセンタイルの仕組み

ARouter はローリング5分間ウィンドウでプロバイダーパフォーマンスを追跡します: 高いパーセンタイル(p90/p99)は最悪ケースのパフォーマンスに対する信頼度を高めます。指定した全パーセンタイルカットオフを満たすプロバイダーが優先グループに入ります。
preferred_min_throughputpreferred_max_latency はソフトな設定です——リクエストの処理を阻害することはありません。これは max_price とは異なります。max_price はハード制限です。

特定プロバイダーの順序指定

order を使用して、試みるプロバイダーとその順序を指定します。order が設定されると負荷分散は無効になります。

特定プロバイダーのみを許可

only を使用してルーティングを特定のプロバイダーセットに制限:

プロバイダーの無視

ignore を使用してこのリクエストの特定プロバイダーをスキップ:

フォールバックの無効化

デフォルトでは、プライマリプロバイダーが利用不可の場合、ARouter は代替プロバイダーにフォールバックします。allow_fallbacks: false を設定すると、正確なプロバイダーを要求します:
指定したプロバイダーが利用不可の場合、ARouter は他の場所にルーティングする代わりに 503 エラーを返します。

パラメータサポートの要求

require_parameters: true を設定すると、リクエスト内の全パラメータをサポートするプロバイダーのみにルーティングします。デフォルトでは、ARouter はサポートされていないパラメータを無視するプロバイダーにルーティングする場合があります。

量子化フィルタリング

プロバイダーが提供するモデルの量子化レベルでフィルタリングします。特定の精度/パフォーマンストレードオフが必要な場合に便利です:
一般的な量子化値:"fp32""fp16""bf16""int8""int4"

データ収集ポリシー

ARouter がリクエストデータを保存する可能性のあるプロバイダーにルーティングするかどうかを制御:

Zero Data Retention(ZDR)

最大限のプライバシーのために、Zero Data Retention 保証のあるプロバイダーのみにルーティングを制限:
ZDR プロバイダーはリクエストデータをログ記録、保存、またはトレーニングに使用しません。詳細はデータ収集を参照してください。

最大価格

トークンあたりの支払い上限を設定します。価格要件を満たすプロバイダーがない場合、リクエストは高価なプロバイダーにルーティングされる代わりに失敗します:
パフォーマンス閾値とは異なり、max_price はハード制限です。価格要件を満たすプロバイダーがない場合、リクエストはエラーを返します。

プロバイダーの健全性と可用性

ARouter はサーキットブレーカーメカニズムを使用してプロバイダーの健全性を継続的に追跡します: これは完全に透明です——アプリケーションはプロバイダーレベルの再試行ロジックを実装する必要はありません。

モデルプレフィックスによるプロバイダーの指定

どのプロバイダーがリクエストを処理するかを制御する主な方法は provider/model フォーマットです:
サポートされるフォーマットの完全なリストはモデルルーティングを参照してください。

ネイティブプロバイダープロキシ

完全な制御のために、プロバイダープロキシエンドポイント /{provider}/{path} を使用して、ARouter のモデルルーティング層を完全にバイパスします:
完全なリファレンスはプロバイダープロキシを参照してください。

サポートされるプロバイダー

機能の完全なリストはプロバイダーを参照してください。