ほとんどのチームは、プロンプトの書き直しや手動でのモデル切り替えによって推論コストを削減しようとする。どちらのアプローチも継続的な人間の判断を必要とし、大量リクエスト下では機能しなくなる。プロンプトルーターはこの問題をアーキテクチャレベルで解決する。各リクエストを推論前に分類し、適切なモデルへ自動的に振り分ける。
結果として、小さなモデルで正しく処理できるタスクにGPT-4クラスの料金を支払わずに済む。
プロンプトルーターが実際に行うこと
プロンプトルーターはアプリケーションとモデルエンドポイントの間に位置する。受信リクエストを受け取り、ルーティング基準に照らして評価し、ティアを割り当て、適切なモデルへ転送する。
プロンプトは変更しない。出力フォーマットも変更しない。どのモデルがリクエストを処理するかを決定するだけだ。
ルーティングの決定はミリ秒単位で行われる。コスト削減はすべてのリクエストにわたって積み重なる。
4つのルーティング基準
ルーティングロジックを書く前に、判断基準を定義する。4つの基準がほとんどの本番ケースをカバーする。
タスクの複雑さ。 これはルックアップか、分類か、要約か、それとも多段階の推論タスクか？ルックアップと分類にフロンティアモデルが必要なことはほとんどない。
トークン数。 入力トークン長は複雑さの信頼できる代理指標だ。300トークン未満のリクエストは通常軽量である。2,000トークンを超える場合は複雑なタスクを示すことが多い。
レイテンシ要件。 ユーザー向けで1秒以内の応答が必要なリクエストもあれば、10秒が許容されるバッチジョブもある。レイテンシ許容度は対象モデルの選択に影響する。
コスト閾値。 ティアごとにリクエスト単価の上限を設定する。例：軽量ティア ≤ $0.001、標準ティア ≤ $0.005、複雑ティア ≤ $0.02。これらの数値により、タスクタイプごとの許容コストを明示できる。
何かを構築する前に、この4つの基準を文書化する。これがルーティング仕様になる。
ステップバイステップ：リクエストをティアに分類する
3つのティアでほとんどのワークロードをカバーできる。
- 軽量： 単純な抽出、yes/no分類、短形式のルックアップ。トークン数400未満。レイテンシ重視または高ボリューム。
- 標準： 要約、構造化出力生成、中程度の推論。トークン数400〜1,500。中程度のレイテンシ許容度。
- 複雑： 多段階推論、長文書分析、コンテキスト付きコード生成。トークン数1,500超または明示的な複雑さシグナル。
リクエストを自動分類するには、メインの推論呼び出しの前に軽量分類器を実行する。この分類器は小さなモデル、ルールベースの関数、またはその組み合わせで構成できる。
実用的な出発点はルールベースの関数だ：
- 入力トークンをカウントする。
- リクエストメタデータ内の明示的な複雑さシグナルを確認する（例：アプリケーションがすでに設定している
task_typeフィールド）。 - 既知の複雑タスクタイプに対するキーワードリストを適用する（例：「比較」「分析」「コード生成」）。
- 合算スコアに基づいてティアを割り当てる。
この分類器がパイプラインに追加するレイテンシは20〜50ms以内に抑える。分類にモデルを使用する場合は、利用可能な最小のものを使う。7Bパラメータのモデルやファインチューニング済み分類器で十分だ。フロンティアモデルを使うかどうかの判断にフロンティアモデルを使ってはならない。
すべての分類決定をログに記録する。2週間後にログを監査する。誤分類されたリクエストが見つかるはずだ。実データに基づいてルールを調整するか、分類器を再トレーニングする。
ティアごとにモデルターゲットを割り当てる
ティアが定義されたら、各ティアをプライマリモデルにマッピングする。
マッピング例：
- 軽量 →
gpt-4o-miniまたは同等の小型モデル - 標準 →
gpt-4oまたは中間ティアモデル - 複雑 → 拡張コンテキスト付き
gpt-4o、または推論最適化モデル
モデル名をコードベース全体に文字列としてハードコードしてはならない。ティアとモデルのマッピングは単一の設定ファイルに保存する。モデルが廃止されたり、プロバイダーを切り替えたい場合は、1つのファイルを変更するだけで済む。
フォールバックチェーンを構築する
すべてのティアにフォールバックが必要だ。モデルエンドポイントはダウンする。レート制限に達することもある。フォールバックチェーンのないルーターは単一障害点になる。
各ティアに対して以下を定義する：
- プライマリモデル — デフォルトのターゲット。
- セカンダリモデル — 同じティア、異なるプロバイダーまたはエンドポイント。
- エスカレーションモデル — 1つ上のティア。プライマリとセカンダリの両方が利用不可の場合のみ使用。
軽量ティアのフォールバックチェーン例：
- プライマリ：
gpt-4o-mini - セカンダリ：
claude-haiku（または同等品） - エスカレーション：
gpt-4o（標準ティアモデル、最終手段としてのみ使用）
エスカレーションステップはコストが高くなる。それは許容範囲だ。代替はリクエストの失敗だからだ。
各モデル試行にタイムアウトを設定する。プライマリが800ms以内に応答しない場合はセカンダリへ移行する。セカンダリが1,200ms以内に応答しない場合はエスカレーションする。すべてのフォールバックイベントをログに記録する。フォールバック使用量の急増は、プライマリエンドポイントが劣化しているという早期シグナルだ。
実際の動作例
ルーティングなしで1日50,000リクエストを処理するチームは、すべてをフロンティアモデルに送信する。リクエスト平均$0.01とすると、1日$500になる。
60%のリクエストを軽量と正しく分類し、$0.0008/リクエストの小型モデルに送るルーターを使用した場合：
- 軽量リクエスト30,000件 × $0.0008 = $24
- 標準/複雑リクエスト20,000件 × $0.01 = $200
- 合計：$224/日
これは55%のコスト削減だ。プロンプトは変更していない。軽量タスクの出力は同等だ。変わったのは各リクエストの送信先だけだ。
機能させるための運用規律
ルーターは一度構築すれば終わりではない。以下が必要だ：
- 分類精度の週次レビュー
- 出力品質チェックからティア割り当てへのフィードバックループ
- ティアとモデルのマッピングのバージョン管理（コードとして扱う）
- フォールバック使用量が閾値を超えた場合のアラート
この規律がなければ、ルーターは劣化する。タスクが誤分類される。コストが再び上昇する。品質がサイレントに低下する。
ルーターの構築には1日かかる。フィードバックループの維持が、それを機能し続けさせるものだ。
AIワークフローを大量に実行していて、現在の推論コスト構造を監査したい場合は、お問い合わせはこちら →