品質を犠牲にすることなくコストを意識した LLM モデル ルーティングを構築する方法
単純な最安モデルの選択の代わりに、タスク分類、品質下限、プロバイダーの制約、コスト見積もり、監査ログを使用する、コストを意識した LLM モデル ルーティングの実用的なアーキテクチャ。
コストを意識した LLM モデルのルーティングとは、すべてのリクエストを利用可能な最も安価なモデルに送信することを意味するものではありません。これにより、静かな障害モードが発生します。請求書は数週間改善されますが、その後、製品チームがスキーマの破綻、推論の弱さ、口調の一貫性の欠如、または人間によるより多くのクリーンアップが必要なサポート草案を発見します。
より良いパターンは、eval-backed ルーティング ポリシーです。リクエストを分類し、そのタスクの最低許容品質を定義し、機能またはガバナンスの制約を満たすことができないルートを削除し、ルートの経済性を推定して、最低コストの適格モデルを選択します。ルーティングの決定は、開発者の好みや曖昧なプロバイダーのデフォルトではなく、ポリシーのバージョンに関連付けられているため、コストのレビュー中に説明可能になります。
コストを意識したルーティングが最適化するもの
実用的なルーターは、タスクの動作要件を満たしながら、最も安価なルートを最適化します。これは、最も安価なモデルを最適化することとは異なります。
事実: 主要なモデル プロバイダーは、入力トークン、キャッシュされた入力トークン、出力トークン、プロンプト キャッシュ、バッチ処理などの個別の次元でトークンの価格を公開しています。一部のプロバイダーは、キャッシュされたトークンの動作を報告する使用状況フィールドも公開しています。これは、プロンプトの形状、予想される出力の長さ、キャッシュの適格性、およびワークロードが非同期で実行できるかどうかに基づいて、最もコストの低いオプションが変わる可能性があることを意味します。
推奨事項: ルーティングをアプリケーション レベルの switch ステートメントとしてではなく、マルチモデル AI API ゲートウェイ 内のポリシーの問題として扱います。ゲートウェイは、プロバイダー機能レコード、テナント ルール、API キー メタデータ、価格表、使用状況テレメトリ、およびフォールバック動作を 1 か所で確認します。
予測: アプリケーション リポジトリ全体にルーティング ロジックを分散させ続けるチームは、後でコストの変化を説明するのに苦労するでしょう。それでも支出を削減できる可能性はありますが、特定のリクエストで特定のモデルが使用された理由についての証拠が弱くなるでしょう。
プロバイダー名ではなくタスク クラスから始めます
ルーターが有益な決定を下すには、ワークロード ラベルが必要です。単一のデフォルト モデルですべてのリクエストのリスク プロファイルを表すことはできません。
便利なタスク クラスは次のとおりです:
- 抽出: 多くの場合、厳密なスキーマ検証を使用して、非構造化テキストをフィールドに変換します。
- 分類: ラベル、優先度、意図、センチメント、またはルーティング カテゴリを割り当てます。
- 要約: 重要な事実と決定事項を保持しながら、長い入力を圧縮します。
- カスタマー サポートの下書き: 人間が確認または送信できる返信を生成します。
- RAG 回答合成: 引用または根拠の要件を含む、取得したコンテキストからの回答。
- コード レビュー: 差分ファイルまたはソース ファイルの正確性、リスク、またはスタイルの問題を検査します。
- 長い文脈の分析: 契約、記録、ログ、ポリシー、または調査パッケージに関する理由を説明します。
- 影響力の高い意思決定サポート: 間違った回答が金銭、コンプライアンス、安全性、または顧客の信頼に影響を与える可能性があるあらゆるワークフロー。
タスク クラスは、明示的なリクエスト メタデータ、API キー スコープ、アプリケーション ルート、または軽量分類子から取得できます。曖昧なプロンプトではルーターが保守的なデフォルトに向かうため、明示的なメタデータは通常、プロンプト テキストから意図を推測するよりも優れています。
各タスクに品質フロアを添付する
コストを意識したルーティングは、各タスクに品質の下限がある場合にのみ機能します。これがなければ、ルーターは安価なモデルを拒否する原則的な方法を持ちません。
品質フロアにはいくつかのチェックを含めることができます:
- 再生可能な評価セット: 開発および本番環境からの代表的な例。必要に応じて機密データは削除されています。
- スキーマの有効性: 出力は解析し、正規スキーマに対して検証し、サポートされていないフィールドを避ける必要があります。
- 内容の基準: 回答は、タスクのスタイル、拒否、根拠、完全性のルールに従う必要があります。
- 安全基準: 出力は、隠された命令を漏洩したり、ポリシー境界を無視したり、取得したコンテンツから信頼できない命令を実行したりしてはなりません。
- 人間によるレビュー: 影響の大きいワークフローや新しいルートのプロモーションには必要です。
- 回帰しきい値: 候補ルートは、平均スコアだけでなく、重大な障害カテゴリの現在のルート以上である必要があります。
事実: プロバイダーのドキュメントでは、指定されたコンテンツとスタイル基準に対してモデル出力をテストする方法として評価について説明しています。 1 つのホスト型評価製品が廃止される予定であるため、ルーティング システムは、プロバイダーがホストする 1 つの評価面に依存するのではなく、プロバイダーに依存しない評価データセット、期待される出力、評価ルーブリック、および結果を保存する必要があります。
推奨事項: 評価結果をタスク クラス、モデル、プロバイダ アダプタのバージョン、プロンプト バージョン、スキーマ バージョン、および評価バージョンごとに保存します。単にモデルが新しい、または安いという理由だけで路線が対象となるべきではありません。タスクの現在の品質ゲートを通過すると適格になります。
プロバイダー機能レジストリを構築する
コストを見積もる前に、リクエストを満たすことができないルートをすべて削除してください。この手順により、ルーターが必要な機能を欠いた安価なモデルを選択するのを防ぎます。
機能レコードには以下を含める必要があります:
- サポートされている入力および出力モダリティ。
- コンテキスト ウィンドウの制限。
- 構造化された出力とツール呼び出しのサポート。
- ストリーミングのサポート。
- プロンプト キャッシュ サポートとキャッシュ テレメトリの可用性。
- バッチ API のサポート。
- 地域の処理オプション。
- ポリシーにとって重要なデータ保持と不正行為の監視条件。
- レート制限の寸法と電流容量。
- アダプター層の既知の出力コントラクトの違い。
このレジストリは、アプリケーション プロンプトとは別に管理する必要があります。これはルーティング層とプロバイダー アダプター層の近くに属し、システムはプロバイダー固有の前提をすべてのアプリケーションに漏らすことなくモデルを比較できます。
選択する前にルートのコストを見積もる
ルーターは実行前に最終的なコストを知ることはできませんが、適格なルートの中から選択するのに十分な見積もりは可能です。見積もりには、実際に請求書を動かす変数を含める必要があります。
estimated_cost =
input_tokens * input_token_price
+ cached_input_tokens * cached_input_token_price
+ output_tokens_expected * output_token_price
+ tool_call_overhead_expected
+ retry_allowance_expected
- batch_discount_if_eligible
最近のテレメトリを使用して、タスク クラスごとに出力トークンを推定します。たとえば、抽出タスクでは出力の長さが制限されている場合がありますが、長いコンテキストの分析は大きく異なる場合があります。ツールを使用するエージェントには、ツールの呼び出し計画、再試行、中間メッセージによって追加の隠れたコストが発生する可能性があります。
コストの見積もりには、キャッシュとバッチの適格性も考慮する必要があります:
- キャッシュの適格性: 安定したプロンプト プレフィックス、再利用可能なシステム命令、繰り返し取得されるコンテキスト、サポートされるプロバイダーの動作、および十分なキャッシュ ヒット確率。
- バッチの適格性: ワークロードは待機可能で、べき等リクエスト処理があり、永続的なジョブ追跡があり、対話型ストリーミングは必要ありません。
- 出力トークンのリスク: モデルは、同じタスクに対して長いまたは短い答えを生成する傾向があり、切り捨ては品質を損なう可能性があります。
- 再試行のリスク: プロバイダーまたはモデルでは、このタスクのエラー率、スキーマ修復率、または遅延エラーが増加しています。
ここで、コスト ルーティングがより広範な LLM コスト管理に接続されます。価格表だけでは十分ではありません。ルーターは、期待された節約が実際に行われたかどうかを知るために、リクエストのメタデータ、プロンプト構造、キャッシュ ヒットの測定値、および確定した使用状況データを必要とします。
1 つのグローバルデフォルトの代わりにモデル層を使用する
プロバイダー固有の例外の膨大なリストよりも、階層型ポリシーの方が説明が簡単です。各層には、タスク固有のゲートを通過した 1 つ以上の対象モデルが含まれている必要があります。
| 層 | ユースケース | 一般的なルーティング ルール |
|---|---|---|
| 経済 | 単純な抽出、タグ付け、簡単な分類などの低リスクの決定論的な作業 | スキーマと精度のゲートを通過する最低コストのモデルを使用する |
| バランスの取れた | 通常の本番環境のドラフト、要約、RAG 合成 | 安定した品質とレイテンシを備えたコスト効率の高いモデルを好む |
| プレミアム | 一か八かのタスク、あいまいなタスク、コンテキストが長いタスク、または信頼性の低いタスク | 信頼性と評価履歴でダウングレードがサポートされていない限り、高機能モデルを使用してください |
| 制限付き | 規制対象、機密性の高い、地域別、または契約上のワークロード | ガバナンス ポリシーによって承認されたプロバイダーとモデルのみを許可します |
評価値を層で置き換えないでください。モデルは分類には経済的ですが、サポート製図には適さない場合があります。別のモデルは要約には強力ですが、短い決定論的なタグ付けにはコストがかかりすぎます。
明示的な決定シーケンスを持つルート
コスト認識ルーターは、デバッグできるほど十分に決定的である必要があります。正確な実装はさまざまですが、決定シーケンスは安定している必要があります。
- テナント、API キー、環境、およびアプリケーションのメタデータを読み取ります。
- 明示的なメタデータまたは分類子の出力からタスク クラスを特定します。
- そのテナントまたはワークスペースのルーティング ポリシー バージョンを読み込みます。
- データ保持、リージョン、モデル許可リスト、機能制限などのガバナンス制約を適用します。
- 必要な機能でフィルタリングします: コンテキストの長さ、ツール、構造化出力、ストリーミング、モダリティ、バッチ サポート。
- タスク クラスの eval に基づく品質下限によってフィルタリングします。
- 入力トークン、予想される出力トークン、キャッシュ適格性、バッチ適格性、再試行リスクを使用してコストを見積もります。
- 予算ポリシーとテナント設定を適用します。
- 最低コストの対象ルートを選択します。
- フォールバック ルート、タイムアウト、再試行、および修復ポリシーをアタッチします。
- 安定した理由コードを使用して決定を記録します。
疑似コードでは、ルーターはハードコードされたプロバイダー設定ではなく、ポリシー評価のように見える必要があります:
function selectRoute(request):
context = buildRoutingContext(request)
task = classifyTask(context)
policy = loadPolicy(context.tenant_id, task)
candidates = modelRegistry.models
.filter(model => policy.allows(model))
.filter(model => model.supports(context.required_capabilities))
.filter(model => evalStore.passes(task, model, policy.quality_floor))
priced = candidates.map(model => ({
model,
estimated_cost: estimateCost(model, context),
expected_latency: estimateLatency(model, context),
risk_flags: estimateRisk(model, context)
}))
eligible = priced.filter(route => route.risk_flags.noneBlocking())
return minBy(eligible, route => route.estimated_cost)
すべてのルーティング決定を記録する
財務部門がプレミアム モデルが使用された理由を尋ねたり、エンジニアリング部門が品質が低下した理由を尋ねたりした場合、ルーターはログから答える必要があります。事後的にプロンプトから意図を再構築することに依存しないでください。
リクエストごとに次のフィールドをログに記録します:
- リクエスト ID、テナント ID、API キー ID、アプリケーション ID、および環境。
- タスク分類子の結果と信頼度。
- ルーティング ポリシーのバージョン。
- 使用されるデータセットのバージョンと品質ゲートを評価します。
- 適格なモデルと拒否されたモデル。
- 拒否された各モデルが除外された理由。
- 推定入力トークン、キャッシュされた入力トークン、出力トークン。
- 推定ルートコストと最終決済コスト（利用可能な場合）。
- 選択されたプロバイダー、モデル、アダプターのバージョン、および階層。
- フォールバック ルートと再試行ポリシー。
- 利用可能な場合は、テレメトリーのヒットまたはミスをキャッシュします。
- バッチ実行モードと同期実行モード。
- スキーマの検証、修復の試行、拒否ステータス、および安全フラグ。
モデルの選択は支出の一部にすぎないため、これらのログは LLM API コスト アトリビューション もサポートしています。チームは引き続き、テナント、ワークスペース、キー、製品、ワークフロー、または顧客ごとにコストを割り当てる必要があります。
より安いルートを宣伝する前にドリフト コントロールを追加する
モデルの動作、価格設定、プロンプト、ワークロードの組み合わせの変更。先月は安全だったルートも、迅速な改訂やモデルの更新後には脆弱になる可能性があります。
基本的なドリフト制御ループには以下を含める必要があります:
- タスク クラス別の最近のプロダクション リクエストのサンプル。
- ポリシーに従って機密データを削除または変換します。
- 現在のルートと候補ルートを通じてサンプルを再生します。
- 品質、スキーマの有効性、拒否動作、コスト、レイテンシを比較します。
- 集計スコアだけでなく、カテゴリ別に失敗を確認します。
- 品質最低値と運行上の制約を満たす場合にのみ、より安価なルートを宣伝します。
- トラフィックのごく一部に対して新しいルートをカナリア処理します。
- スキーマの障害、コストの超過、レイテンシ違反、または人間によるレビューのエスカレーションが発生した場合は、自動的にロールバックします。
推奨事項: ルートのプロモーションを変更管理イベントにします。誰が承認したか、どの評価セットが通過したか、影響を受けるトラフィックの割合、いつ期限切れになるかレビューが必要になるか、ロールバックの仕組みを記録します。
チームにオーバーライドを与えるが、期限切れにする
プロバイダーのインシデント、予算の緊急事態、コンプライアンスのレビュー、顧客のエスカレーション、モデルの回帰など、ルーティングをオーバーライドする正当な理由があります。問題はオーバーライドではありません。問題は、非表示の永続ポリシーとなるオーバーライドです。
各オーバーライドには以下を含める必要があります:
- スコープ: テナント、アプリケーション、API キー、タスク クラス、モデル、プロバイダー、またはリージョン。
- 理由: インシデント、予算、品質、コンプライアンス、待ち時間、または顧客のリクエスト。
- 承認者
- 開始時刻と有効期限。
- コスト、レイテンシー、品質への予想される影響。
- ロールバック条件。
期限切れのオーバーライドは、通常のルーティング ポリシーに対してフェールクローズされるか、更新が必要です。これにより、緊急の意思決定がコストや品質の隠れたリスクになるのを防ぎます。
明示すべきトレードオフ
コストを意識したルーティングには実際の運用コストがかかります。 LLM の支出が多額の場合でも実行する価値はありますが、トレードオフは明らかであるはずです。
- メタデータの依存関係: ルーティングの品質は、正確なタスク ラベルとワークロード メタデータに依存します。ラベルが欠落していると、トラフィックが保守的なデフォルトに向かうようになります。
- 評価メンテナンス: プロンプト、製品、ユーザーの行動の変化に応じて、タスクの評価を更新する必要があります。
- プロバイダの複雑さ: キャッシュとバッチの割引により経済性は向上しますが、ルーティング ロジックがより複雑になります。
- 移植性のリスク: プロバイダー固有の機能は、製品コードではなくアダプターと機能レコード内に存在する必要があります。
- 推定の不確実性: 最終的な出力の長さ、ツール呼び出し、再試行、およびキャッシュ ヒットは、実行前には完全にはわかりません。
- 説明可能性の負担: 積極的な最適化により、すべての決定がポリシー バージョンと理由コードとともに記録されない限り、製品の動作を説明することが困難になる可能性があります。
実装チェックリスト
- 支出とビジネスへの影響に基づいて、上位の LLM ワークフローのタスク クラスを定義します。
- 各タスク クラスの評価セットと品質下限を作成します。
- プロバイダーとモデル機能のレジストリを構築します。
- プロバイダー、モデル、実行モードごとに現在の価格表と価格設定変更子を保存します。
- 入力トークン、予想される出力トークン、キャッシュ適格性、バッチ適格性、再試行リスクを見積もります。
- コストを最適化する前に、ガバナンスの制約によって候補をフィルタリングします。
- 機能と品質のゲートを通過した後にのみ、最低コストのモデルを選択してください。
- 選択されたルートと拒否されたルートを理由コードとともにログに記録します。
- 推定コストを決済済みの使用量および請求書のデータと比較します。
- 安価なルートを宣伝する前に、定期的なリプレイ評価を実行します。
- カナリアのルート変更とロールバック トリガーの定義。
- 手動オーバーライドには有効期限が必要です。
結論
実際的な目標は、すべてのリクエストをより安価なモデルにルーティングすることではありません。目標は、品質、契約、ガバナンス ルール、説明可能性を保護しながら、日常業務に対する過剰な支払いをなくすことです。
タスク クラス、品質の下限、プロバイダーの機能、コスト見積もり、ポリシー ログを中心にルーターを構築します。次に、最低コストの適格なルートを選択します。 「適格」という 1 つの単語が、コストを意識したルーティングと最も安価なモデルのルーティングを区別します。