スマートルーティング：あなたのプロンプトに十分な速さで対応できる最も安価なプロバイダー
複数のプロバイダーが同じモデルを提供しており、最も安価なものが長いプロンプトでは最も遅いことが多いです。そのため、UberLLMはすべてのリクエストで、各プロバイダーがそのプロンプトサイズでどれだけ早く応答を開始するか、そのリクエストの費用がいくらになるかをチェックし、十分な速さのプロバイダー（最も速いものから2x以内、または1秒未満）を候補として残し、その中で最も安価なプロバイダーにリクエストを送信します。設定は不要です。独自のルーティングオプションを指定しない限り、すべてのチャットリクエストで自動的に実行されます。
最も安価なプロバイダーでは不十分だった理由
DeepSeek V4.1 Flashのようなモデルは、複数のプロバイダーから異なる価格で販売されています。最も安価なプロバイダーにすべてのリクエストを送る方法は、短いプロンプトには機能します。しかし、長いプロンプトでは破綻します。モデルが最初の単語を書き出す前にプロンプト全体を読み込む必要があり、一部のプロバイダーは他のプロバイダーよりもはるかに遅く長いプロンプトを読み込むためです。
私たちは2026年10月28日のライブトラフィックでこれを測定しました。DeepSeek V4.1 Flashでは、最も安価なプロバイダーは32k～128kトークンのプロンプトで最初の単語を送信するのに15秒かかり、128kを超える場合は34秒かかりました。別のプロバイダーは、同じプロンプトに対して1.5～2秒かかりました。
これはコーディングエージェントにとって最も重要です。Claude Code、Cline、および同様のツールは、ターンごとに作業コンテキスト全体を送信します。これはしばしば60k～130kトークンにもなり、そのほとんどがcache readです。
価格だけを考慮すると、これらのプロンプトでも選択が誤っていました。通常の入力価格でランキングすると、cache readの価格が無視されるため、別のプロバイダーが$0.0013を請求しているにもかかわらず、長いキャッシュされたプロンプトが100万cached tokensあたり$0.07を請求する再販業者に送られる可能性がありました。その呼び出しはより遅く、約50xも高価でした。
各リクエストの処理内容
- プロンプトサイズ別に速度を測定。 UberLLMは、各モデルの各providerのtime to first tokenを、4つのサイズグループ（8k token未満、8k–32k、32k–128k、128k超）に分けて記録します。同じproviderが31 tokenのプロンプトに1.7秒で、105k tokenのプロンプトに15.5秒で応答したため、providerごとに1つの数値だけでは不正確です。データは実際の呼び出しから得られます。5分ごとに約20k、60k、150k tokenで個別の速度チェックを行うことで、短い呼び出しが高速であっても、特定のサイズでの速度低下を検知します。
- 各providerでこの正確なリクエストの価格を算出。 入力、キャッシュされた入力、出力は、このリクエストのtokenの組み合わせに基づいて個別に価格が設定されます。長いagentプロンプトの場合、キャッシュ読み取り価格が通常、請求額の大部分を占めます。
- 十分な速度のproviderを維持。 providerは、その典型的なtime to first tokenが、測定された最速のproviderの2x以内であるか、または1秒未満である場合に適格とされます。速度は中央値に基づいて判断されます。providerが少なくとも10のサンプルを持つ場合、遅い外れ値は4分の1の重みでカウントされるため、1回の悪い呼び出しで良いproviderが排除されることはありません。
- その中で最も安価なproviderにリクエストを送信。 最速のproviderは、より安価なproviderが遅すぎる場合にのみ選択されます。
- データを最新の状態に保つ。 リクエストの5%は、データが不足しているproviderに送信されるため、高速になったproviderは認識されます。呼び出しを拒否したproviderは使用不可と見なされ、15分以内に再度試行されます。
モデルの速度データがまだない場合、リクエストは利用可能な最も安価なproviderに送信されます。モデルの通常の価格よりも高い価格のproviderは、モデルの公式リスト価格よりも少なくとも50%安い場合にのみ、速度のために選択されます。
長いプロンプト：最初のプロバイダーが遅い場合のセカンドプロバイダー
速いプロバイダーでも、起動が遅いことがあります。あるキャッシュされた120k-tokenのプロンプトでは、同じプロバイダーが3回連続の呼び出しで0.45秒、3.7秒、8.5秒かかりました。適切なプロバイダーを選ぶだけではこれを解決できないため、長いstreamingリクエストにはバックアップが用意されています。
- 32k～128k tokenのプロンプト： 1秒経っても最初の単語が届かない場合、同じリクエストが別の速いプロバイダーにも送信されます。
- 128k tokenを超えるプロンプト： 両方のリクエストが同時に開始されます。
- 最初に回答したプロバイダーが返信をstreamingします。最初の単語が届き次第、もう一方のリクエストはキャンセルされます。
お客様は1つの返信を受け取り、1つの返信に対してのみお支払いいただきます。キャンセルされたリクエストについては、当社が固定の日次予算から支払います。その予算が尽きると、長いリクエストは翌日（UTC）まで1つのプロバイダーに送信されます。
別のプロバイダーでリトライ
呼び出しの応答があなたに届く前に失敗した場合、UberLLMは別のルートで最大4回までリトライします。スマートルーティング導入前は、リトライが再び同じ遅いプロバイダーに送られる可能性がありました。すべての試行で失敗した呼び出しは、$0かかります。詳細はモデルとルーティングをご覧ください。
ライブトラフィックでの結果
DeepSeek V4.1 Flash、最初の単語までの時間:
| プロンプトサイズ | 以前 | 以降 |
|---|---|---|
| 32k–128k tokens | 18 s | 3.3 s |
| Over 128k tokens | 40 s | 3.4 s |
32k tokensを超えるストリーミング呼び出し (2026年10月28日) では、最も遅い10%の呼び出しが57秒から8.7秒になりました。これらの呼び出しの1,000のコストは、キャッシュ読み取り価格が選択肢に含まれるようになったため、$2.49から$1.04になりました。10月29日、203k-token promptが約4秒で応答を開始しました。
1つの制限: どのプロバイダーも100k-token promptを即座に開始することはありません。すべてのプロバイダーで数秒かかります。スマートルーティングは、遅いプロバイダーからの余分な待ち時間を排除します。高速なプロバイダーがプロンプトを読み込むのに必要な時間を排除することはできません。
お支払いについて
各リクエストは、それを処理したプロバイダーが請求した料金で課金され、UberLLMの手数料は追加されません。すべての呼び出しとその費用は、ダッシュボード → アクティビティに記載されています。料金に上限を設定するには、promptとcompletionの両方とともにprovider.max_priceを送信します。スマートルーティングは、設定した上限以下のプロバイダーのみを選択し、リクエストがその上限を超える料金で請求されることはありません。
代わりに独自のルーティングを使用する
スマートルーティングを利用するために、何も変更する必要はありません。provider.only、provider.ignore、またはprovider.orderでプロバイダーを指定した場合、provider.sortを設定した場合、またはモデルIDに:floorまたは:nitroのサフィックスを追加した場合、お客様の選択が使用され、そのリクエストではスマートルーティングは実行されません。
{
"model": "deepseek/deepseek-v4.1-flash",
"provider": { "sort": "price" },
"messages": [{ "role": "user", "content": "Hello" }]
}
provider.max_priceは例外です。これはスマートルーティングと連携して動作します。すべてのオプションはモデルとルーティング]に記載されています。