AI・機械学習
モデルルーティングの第一原理
First Principles of Model Routing (try.works)
要約
この記事では、モデルルーターを構築・利用する上での第一原理を4つ解説しています。モデルを効果的にルーティングするには、各モデルの特性を明確にし、モデルプールを小さく保つこと、相対的で実用的なベンチマークを使用すること、そして過去のルーティング決定を評価してデータを強化することが重要です。これらの原則は、モデルルーターの選択や自作に役立ちます。
全文翻訳
モデルルーティングの第一原理
2026-07-03
ここでは、モデルルーターであるrole-modelを構築する過程で私が開発したモデルルーティングに関するいくつかの原理を紹介します。これらの原理は、モデルルーターを使用する人、または自作する人にとって役立つでしょう。
1. モデルを明確に区別する
コーディングワークフローにおいて、最新のGPTモデルと最新のOpusモデルをそれぞれ異なる役割に割り当てて使用している人を時折見かけます。これは間違っているわけではありませんが、ルーティングの観点からは最適ではありません。GPTとOpusモデルにはそれぞれ異なる経験や好みがありますが、どちらもコーディングに偏った汎用モデルであり、パフォーマンスとコストの層も似ています。このため、ルーティングは困難になります。なぜなら、リクエストの難易度を判断してモデルにマッチさせること自体が十分に難しいのですが、それが完了した後、あらゆる面でほぼ同等であるモデル間で、どちらに行くべきかの決定を下すことはさらに難しいからです。フロンティアモデル同士でルーティングする代わりに、制約の三角形(速度、品質、コスト)の少なくとも一方の側面で優れている別のモデルと、1つのフロンティアモデルの間でルーティングするのが良いでしょう。例えば、GPT 5.5とルーターを組み合わせて、中程度および簡単なリクエストをDeepSeek V4 Proにルーティングすることで、サブスクリプションのクォータを拡張できます。DeepSeek V4 Proは大幅に安価であり、非常に難しいタスクでは大幅に能力が劣るため、ルーティングの決定は容易になります。
2. モデルプールを小さく保つ
これは前のポイントから続くものです。より多くのモデルをルーティング対象に含めることで、プールサイズを増やすことが良いことだと考えるかもしれません。例えば、role-modelをGPT 5.5、Kimi 2.7、DeepSeek V4 Pro、DeepSeek V4 Flash、さらにはいくつかの小規模なGPTモデルを使用するように設定できます。しかし、各モデルが明確な特性を持たない場合、モデルを増やすことはルーティング決定をより難しくするだけです。実際には、このプールはパフォーマンスのためにGPT 5.5と、キャッシュがウォームであるために小規模タスク用に選択され維持される他のモデルのいずれかとの間でルーティングするだけになるでしょう。したがって、モデル間に明確な違いがない限り、モデルを追加しないでください。デフォルトではプールサイズを2に制限し、各モデルの役割を明確に定義できる場合にのみ追加してください。追加することで速度、品質、またはコストが増加しますか?そうでないなら、追加しないでください。
3. 相対的な実世界のベンチマークを使用する
一部のルーターは、コストなどのモデルメタデータに基づいてルーティングするだけですが、他のルーターはArtificial Analysisのようなソースからの外部ベンチマークをメタデータに追加します。これは何もないよりはましですが、理想的ではありません。なぜなら、ベンチマークは十分に詳細なパフォーマンスプロファイルを提供しない可能性があり、実際のワークロードを反映しない可能性があり、厳密に相対的でない可能性があり、特定のモデルのデータが不足している可能性があるからです。さらに、モデルは異なるリモートエンドポイントで異なるパフォーマンスを示し、時間とともに変化する可能性があり、異なるローカルシステムで異なるパフォーマンスを示す可能性があります。プール内のモデルのプロファイルに関する明確なデータを取得するには、ルーター内でベンチマークを実行するのが最善です。このベンチマークは、ツール使用、ビジョンなどの機能、タスク、または役割でタグ付けされた個々のテストを実行し、モデルのパフォーマンスを相対的に比較して、より豊かなルーティングプロファイルを作成します。
4. 過去の履歴決定を評価してルーティング決定データを強化する
ベンチマークは出発点と見なされるべきです。リクエストをルーティングする際、私たちは未来を予測しようとします。つまり、コストや速度などのさまざまなパラメータを与えられた場合に、どのモデルがこのリクエストで最適にパフォーマンスを発揮するかを予測します。これらの決定は、過去のリクエストに基づいたユーザー固有の評価を作成し、モデルプール全体でベンチマークとして実行することによって再検討されるべきです。これは、モデルがどのようにパフォーマンスを発揮し、どのようにルーティングするかについての最良のシグナルとなります。さらに、テレメトリデータは、エンドポイントの安定性、リクエストのターンアラウンドタイム、およびカタログメタデータでは捉えられないその他の情報を提供してくれます。
ここまでたどり着いたなら、role-modelを使って自分でモデルプールを設定し、モデルルーティングを試すことができます。コメントにあるリポジトリリンクをチェックしてください。もしここまで読んだなら、role-modelをチェックして、独自のモデルプールを設定してルーティングを試してみる価値があるかもしれません: https://github.com/try-works/role-model
© Try-Works