JevのルーティングでLLM費用は下がる？損益分岐点の計算方法

Jevを追加して費用が下がるのは、省ける処理の費用が、Jevの呼び出し、自動処理先、フォールバック、追加の間接費用を上回る場合です。判断用の呼び出しが非常に安くても、ほぼすべてのリクエストが結局同じLLMへ進む場合や、誤った振り分けによって最初からやり直す場合には、請求額が増えることがあります。

この記事では、損益分岐点の式、3つの計算例、ダウンロード可能なPython計算ツールを用意しています。ルーティング構成全体を比較する開発者向けです。計算は例示用で、ローカルで検証していますが、Jevの実APIによる測定やOfoxの見積価格ではありません。インターフェースと制約については、Jev APIの紹介を参照してください。

比較する構成を決める

まず、Jevを追加しなければ導入するはずのシステムを考えます。強力なモデルだけを使う構成は比較対象の1つですが、ルール層や安価な生成モデルのほうが、経済的な代替案として適切な場合もあります。

安価なモデルを選ぶルーターは、生成そのものをなくしているわけではありません。選んだモデルは最終回答を作る必要があります。自動処理先が完全に決定論的な処理であればモデル費用はゼロにできるかもしれませんが、運用費までゼロとは限りません。計算に何を含めるかを明確にしてください。

公開研究も、都合のよい比較対象だけを選ばないよう示唆しています。REFLEXは制御されたエージェントのベンチマークで利点を報告する一方、外部評価では安価な生成モデルのカスケードに対する優位性が限られます。これは安価なカスケードを比較に加える理由であり、Jev全般への賛否を決める結論ではありません。REFLEX論文を参照してください。

具体例として、REFLEXのτ²-bench検証では、1エピソード当たりの報告費用が、強力モデルのみで$0.2111、REFLEXで$0.0572、安価なカスケードで$0.0411でした。観測された成功率は、それぞれ90.0%、85.0%、91.7%です。対応のある成功率の差は統計的に決着しておらず、品質が同じことや普遍的な勝者を示すものではありません。それでも、安価なカスケードを省き、強力モデルのみとの費用差だけを引用すると、購入判断を誤らせる理由は分かります。

論文の別のモデル系列横断実験では、呼び出し数と金額が区別されています。Qwenの強力モデル呼び出しは71.9%減りましたが、検証された金銭的な費用削減は52.2%でした。KimiとDeepSeekの行には、検証済みの金銭的削減値がありません。請求額は省いた呼び出し数だけではなく、トークンの長さと単価にも依存します。これらは論文の過去の結果であり、計算ツールの仮定や当サイトの実測ではありません。

Jevの課金単位を正しく扱う

2026年10月2日の確認時点で、TypeSafeの直接提供モデルのドキュメントは、jev-1.13.0の入力100万トークン当たりUSD 0.042、出力トークン無料と記載しています。また、リクエスト全体の上限と、stateに最長の質問を加えた上限を区別しています。これはTypeSafeが直接公表する単価であり、Ofoxの提供価格や、すべてのゲートウェイの条件を約束するものではありません。現在のモデル資料を参照してください。

2026年10月2日に撮影した英語の公式資料です。予算を組む前に現在の原典を再確認してください。以下の計算では、この日付の単価を保存して使っています。

課金対象の入力には、コード上に見える短い指示だけでなく、stateと質問を含めます。同じstateを別々のリクエストで繰り返し送る場合、提供者の課金資料が明確に別の扱いを定めていない限り、その都度入力として数えます。価格の原典にないキャッシュ割引を作ってはいけません。

入力2,000トークン、課金される試行が1回という例では、次のようになります。

Jev cost = 2,000 × 0.042 / 1,000,000
         = USD 0.000084 per request
100,000 such requests = USD 8.40

このUSD 8.40が表すのは、仮定の下でのJevの判断段階だけです。その先の生成、再試行、監視、間違った操作の費用は含んでいません。

リクエスト費用を計算し、成功タスク当たりでも確認する

Jを、課金される試行を含む、到着リクエスト1件当たりのJev期待費用とします。aは到着リクエストのうち安価な経路で自動処理する割合、Lはその経路の平均下流費用、Hはフォールバック経路の平均下流費用、Xはその他の追加期待費用です。通貨と、1リクエストに含める範囲をそろえます。

単純な2分岐のシステムなら、式は次のとおりです。

Direct cost per request = H
Routed cost per request = J + a × L + (1 − a) × H + X
Savings per request    = a × (H − L) − J − X
Break-even acceptance  = (J + X) / (H − L), when H > L

aは、振り分けに失敗した入力も含む、対象となるすべての到着リクエストに対して測ります。モデルのconfidence値ではありません。例えば閾値0.9は、自動処理率90%を意味しません。confidenceの評価手順を使い、代表的なラベル付きデータから自動処理率を見積もってください。

この単純な式では、フォールバック1件の費用をH、自動処理した経路1件の費用をLと仮定します。安価な処理先を実行した後でさらに引き継ぐなら、その経路では両方の費用が発生します。観測した条件付き平均を式に入れるか、より細かい分岐表を使ってください。フォールバック対象のリクエストが通常より大幅に長い場合、その差を隠す全体平均を再利用してはいけません。

判断が変わる3つのシナリオ

以下の下流費用は、計算を確認しやすくするための仮定値です。特定の提供者や実測したモデルを表していません。いずれも到着リクエストは100,000件で、Jevの判断費用には前述の確認日付き単価を使います。

最初のシナリオでは、自動処理1件が大きな費用差を生むため、損益分岐となる自動処理率は約0.933%です。3つ目では、経路間の費用差が小さいため84%になります。どちらも推奨するconfidence閾値や、実際の自動処理率の予測ではありません。

最初のシナリオの大きな節約額にも、品質の検証が必要です。安価な経路で使い物にならない結果を返すなら、同じサービスを届ける費用を節約したことにはなりません。到着リクエスト当たりの費用とともに、合格条件を満たして正しく完了したタスク当たりの費用を比較します。成功の定義はシステム間でそろえてください。

最初のシナリオで品質を確認する例として、直接処理では100,000件中95,000件が成功し、ルーティングでは40,000件しか成功しなかったと仮定します。直接処理の成功1件当たりは$1,000 / 95,000 = $0.01053、ルーティングでは$468.40 / 40,000 = $0.01171です。請求総額は下がっていても、成功1件は高くなり、失敗も大幅に増えています。この成功件数は分母の重要性を示すために作った数字であり、観測結果ではありません。付属の計算ツールは品質をモデル化せず、この指標を自動では計算しません。

実際の成功件数を得るには、処理履歴ごとに合格条件を判定します。未解決と誤答の両方を報告し、すでに発生した有料のやり直しも含めてください。失敗や人による確認の業務費用が重要なら、両システムで同じ会計範囲に含めます。成功1件当たりのAPI費用だけでは、すべての影響を金額化できません。

計算ツールを実行して条件を変える

オフライン判断キットをダウンロードして展開し、そのディレクトリで実行します。

python3 cost.py
python3 cost.py --accepted 0.005
python3 cost.py --cheap 0.0001 --strong 0.0002

既定値で実行すると、direct_total: 1000.0、routed_total: 468.4、savings: 531.6が返ります。これはローカルで実行確認済みです。スクリプトはPythonの標準ライブラリだけを使い、APIを呼ばず、キーも必要としません。

仮定を観測した入力へ置き換える場合は、例えば次のようにします。

python3 cost.py --requests 100000 --tokens 2000 \
  --rate 0.042 --attempts 1.2 --accepted 0.6 \
  --cheap 0.001 --strong 0.01 --extra 0.0001

ここで--attempts 1.2は、課金されるJev試行回数の平均を仮定したものです。すべての再試行が課金されると主張しているわけではありません。提供者の利用記録で課金を確認してください。--extraは、有料の確認処理や、単純な分岐費用以外で実測した引き継ぎの増分費用など、到着リクエスト1件当たりの追加期待費用です。すでにcheapやstrongに含めた費用は、二重計上しないでください。

強力モデルの経路が安価な経路より高くない場合、計算ツールは通常の損益分岐比率を返しません。これは構成を見直す手掛かりであり、回避すべき計算エラーではありません。負数や非有限の入力、自動処理率の0～1以外の値も拒否します。

再試行、キャッシュ、遅延を含める

再試行： 通信の試行、課金されたリクエスト、完了したタスクを分けます。タイムアウトしたという事実だけでは、上流が処理や課金を済ませたかは分かりません。リクエストIDと利用記録を確認します。再試行回数に上限を設け、下流の副作用を伴う操作を冪等性の制御なしに再実行しないでください。

キャッシュの挙動： プロンプトの変更、短縮、順序変更によって、下流システムのキャッシュ再利用が変わることがあります。ルーティング層が入力長を減らしても、同時にキャッシュヒットを減らす可能性があります。新しいプロンプト構成で実際の下流請求を測定してください。以前のキャッシュヒット込みの請求額から、理論上のトークン削減額をそのまま差し引いてはいけません。

stateの共有： 複数の独立した質問を1回のJevリクエストにまとめられる場合があります。stateの再送を避けられますが、コンテキスト上限や質問の意味上の制約は残ります。先の回答に依存する質問は、同じリクエスト内の回答同士が情報を受け渡すと仮定せず、コードで実際の依存関係を作る必要があります。TypeSafeのfan-outパターンを参照してください。

遅延： フォールバック経路では、逐次実行するJevの判断が、強力なモデルの前に処理を追加します。再試行と待ち行列を含め、リクエスト全体のp50とp95を比較してください。平均トークン請求額が低いことは、遅い側の応答時間が改善した証拠にはなりません。投機的に並列実行すれば待ち時間を減らせる場合がありますが、捨てる処理にも費用が発生するため、この2分岐計算ツールとは別の費用モデルになります。

トレース表で検証してから、小さく導入する

到着タスクごとに1行を記録し、ID、実際のモデルバージョン、振り分け状態、選択した経路、全試行のID、課金使用量、最終結果、端から端までの所要時間を含めます。台帳にはプロンプトと質問のバージョンも残してください。これらがないと、後日の価格やプロンプト変更が、ルーティングの改善に見えることがあります。

現行システムの結果を正式な結果としたまま、シャドーモードで候補の経路を観測します。自動処理した場合の誤りや集団別の挙動を調べられるよう、十分な事例にラベルを付けてください。そのうえで、同じ合格基準を使って代替の処理先を再生評価するか、慎重にテストします。シャドーモードのラベルだけでは、実行しなかった下流呼び出しの品質や請求額は分かりません。

品質、遅延、フォールバック先の処理能力、期待費用が、文書化した基準をすべて満たしてから、限定的に導入します。見積もりと実際の利用量を照合してください。節約効果がなくなった場合は、閾値を変える前に、自動処理率の変化、経路の値上がり、再試行の増加、キャッシュ挙動の変化のどれが原因かを特定します。

Jevの長所と制約の根拠については、ベンチマークの読み方を参照してください。モデルの品質に関する主張と、アプリケーションの採算を分けて考えるためのガイドです。

導入を判断する基準

検証済みの限定された判断によって、十分なトラフィックを、成功できて実際に安い経路へ送れる場合にJevを使います。比較にはルール層や安価なモデルのカスケードも残してください。ほぼすべてが同じ高価なモデルを必要とするなら、ルーターは支払いと保守の対象を1段増やすことになります。

次に行うべきなのは、計算ツールの仮定値であるL、H、aを、自分の経路費用と測定した自動処理率に置き換えることです。他人のワークフローから借りた節約の主張ではなく、中身を確認できる予算になります。