エージェント オプティマイザーのコストとトークンの使用の概要

Foundry Agent Service のエージェント オプティマイザーは、最適化ジョブを送信する前に、モデル化されたコスト見積もりを提供します。 ジョブが完了すると、その結果に、測定されたトークンの使用状況を含めることができます。 計画の見積もりと使用状況の測定を使用して、実行中に発生したモデル アクティビティを把握します。

実行前の見積もりと実行後のトークンの使用は、さまざまな目的に役立ちます。 どちらの値も、Azure請求書の使用制限や代替値でもありません。

プロンプト エージェントの実行前コスト見積もり

Foundry ポータルでプロンプト エージェント最適化ジョブを作成する前に、[ 確認 ] ステップに、要求された設定のコスト見積もりが表示されます。 現在、Hosted-agent 最適化フローでは、この実行前の見積もりは表示されません。

この見積もりでは、モデル呼び出しとトークンの料金が予測されます。 見積もりを要求しても、最適化ジョブが作成されたり、モデルが呼び出されたりすることはありません。 呼び出し数は、ジョブ入力から計算されます。 通貨値は、静的トークンの前提条件と参照モデルの価格をそれらの呼び出し数に適用することによってモデル化されます。

ポータルには、次の 3 つのモデル化された通貨値が表示されます。

この概要では、候補数、データセット行数、エバリュエーター数、および参照価格日付が識別されます。 [ コストの内訳 (見積もり)] を展開して、各フェーズを確認します。

見積もりへの入力

オプティマイザーは、解決されたジョブ構成から呼び出し数の範囲を計算します。 計算では、次の入力が使用されます。

参照先データセットの場合、サービスは見積もりを返す前に行数を解決します。 空でない行数を解決できない場合、想定されるデータセット サイズからの見積もりは作成されません。

モデル選択実行の場合、見積もりでは、検索空間内のすべてのモデルに対してエージェント呼び出しの価格が個別に設定されるわけではありません。 使用可能な場合は、構成されたベースライン エージェント モデルが使用されます。 そのモデルを解決できない場合は、エージェント レイヤーの評価モデル価格が使用されます。

静的トークンの前提条件

見積もりでは、実行のどの部分が合計に寄与するかを確認できるように、モデル アクティビティがレイヤーに分割されます。 次の静的な TokensPerCall の前提条件を使用します。

これらのサービス管理の前提条件は、推定器が調整されるときに変更される可能性があります。 各レイヤーについて、オプティマイザーは呼び出しカウント範囲に静的プロンプトと完了トークンの前提条件を乗算します。 その後、100 万トークンごとに日付付き参照価格が適用されます。

modeled layer cost = calls × ((prompt tokens × input price) + (completion tokens × output price)) / 1,000,000

合計は、価格を設定できるレイヤーの合計です。 モデルの価格またはトークンの想定がレイヤーで使用できない場合、見積もりでは予測されていないレイヤーが識別され、合計から除外されます。

最適化の実行中に何が起こるか

コスト レイヤーを理解するために、オプティマイザーがバックグラウンドで各モデルをどのように使用しているかを把握するのに役立ちます。 最適化の実行は、プロンプト エージェントとホステッド エージェントの両方に対して、次のループに従います。

1. ベースラインを評価します (エージェント + ジャッジ)。 オプティマイザーは、すべてのデータセット行でエージェントを呼び出して応答を収集します。 その後、評価モデルは、各エバリュエーターに対して各応答をスコア付けして、ベースライン スコアを確立します。
2. 候補 (リフレクション) を生成します。 最適化モデルはベースライン スコアを受け取り、弱点を分析し、エージェント構成を改善します。 エージェントの種類に応じて、構成には、書き換えられた命令、洗練されたスキル、より優れたツールの説明、または別のモデルを含めることができます。
3. 候補を評価します (エージェント + ジャッジ)。 オプティマイザーは、同じデータセット行に対して候補構成でエージェントを実行し、応答をスコア付けします。
4. 繰り返します。 ステップ 2 ~ 3 は、追加候補ごとに繰り返します。 各サイクルでは、リフレクション呼び出しと評価呼び出しのラウンドが 1 つ追加されます。

3 つのコスト レイヤーは、このループに直接マップされます。

• エージェントの実行 — エージェント がデータセット行 (ベースラインと各候補) に対して呼び出されるたびに実行されます。
• 応答のスコア付け — 評価モデルがエバリュエーターに対して応答を判断するたびに。
• 改善点の生成 — 最適化モデルが結果に反映され、新しい候補が生成されるたびに。

実例: 2-max-candidate の実行例

次の例は、式が具体的なジョブ構成にどのように適用されるかを示しています。 すべての価格は参考価格です。

ジョブの設定:

推定通話数:

オプティマイザーは、ジョブ構成から呼び出し数を派生させます。

各レイヤーに数式を適用します。

オプティマイザーは、各モデルの日付付き参照入力と出力価格を検索し、数式を適用します。 たとえば、エージェント レイヤーの計算は次のようになります。

60 × ((2,000 × <input price>) + (400 × <output price>)) / 1,000,000

ジャッジ層とリフレクション層にも同じパターンが適用され、それぞれがそれぞれのモデルのトークンの前提条件と参照価格を使用します。 その後、ポータルはすべてのレイヤーを合計して、[確認] ステップに表示される [最小値]、[推定]、および [最大値] の値を生成します。

一般的な 2 候補実行では、リフレクション レイヤー (最適化モデル) は、トークンあたりのレートが高いより能力の高いモデルを使用するため、推定コストの最大のシェアを占めます。 ジャッジ 層は、呼び出しごとにトークンの前提条件が低い小さい評価モデルを使用するため、通常は最も安価です。

推定の前提条件と制限事項

この見積もりは、アルゴリズムの呼び出し予算とモデル化されたトークンの使用を組み合わせたため、最終的な料金ではなく計画値です。

• トークンの前提条件は、各コスト レイヤーの平均です。 実際のプロンプト、応答、推論、キャッシュ トークンの数は、モデルと要求によって異なります。
• 最適化ジョブは、それ以上の改善が見つからないと早期に停止できます。 早期停止では、実際の使用量が [推定] または [最大値] を下回る可能性があります。
• エージェントの使用状況は、指示、会話のターン、応答の長さ、ツール呼び出し、ツールの出力によって異なります。
• 参照モデルの価格は日付が付いているため、サブスクリプション、リージョン、デプロイの種類、または契約の価格とは異なる場合があります。
• 見積もりには、外部 API、データベース、検索サービス、またはエージェントが呼び出すその他のツールからの料金は含まれません。
• 最大値は使用制限ではありません。

実行後の測定済みトークンの使用状況

最適化ジョブが完了すると、その結果に、実行の各フェーズの測定されたトークン使用量を含めることができます。 [トークンの使用状況] ビューは、prompt-agent と hosted-agent の両方の実行で使用できます。

ホストされているエージェントの場合、エージェントの使用状況 の実行 は、エージェントの評価サンプルまたはトレースにトークンの使用状況情報が含まれている場合にのみ使用できます。 ホストされるエージェントが使用状況を報告しない場合、ポータルではエージェント フェーズが 0 として報告されるのではなく、省略されます。 ポータルでは、 スコア付け応答 と 改善の生成 の使用状況は、これらのモデルがレポートの使用状況を呼び出すときに個別にキャプチャされます。

このビューには、オプティマイザーが複数のエージェント モデルを評価するときに 、エージェントを実行 するための複数の行を含めることができます。

ポータルでは、測定されたトークン使用量と参照モデルの価格から推定コストが計算されます。 価格ソースを確認するには、[ 価格の表示 ] を選択します。 見積もりは最終的な請求額ではありません。

フェーズまたはトークン値が不足している場合は、使用状況が測定されなかったことを意味します。 これは、フェーズでゼロ トークンを使用したか、料金が発生しなかったことを意味するものではありません。 一部のホステッド エージェントと古い最適化ジョブでは、エージェントの使用が提供されない場合があります。

基になるジョブの結果には、キャッシュされたトークンと推論トークンの詳細を含めることができます。 キャッシュされたトークンは入力トークンのサブセットであり、推論トークンは出力トークンのサブセットです。 これらのサブセット値を入力または出力の合計に追加しないでください。

測定された使用量からモデル コストを計算する

測定されたトークンの使用状況は、実行前の前提条件よりも代表的ですが、最終的な請求額ではなくトークン数を報告します。 各モデル行の価格を適用して、モデルのコストを概算します。

approximate model cost = ((input tokens × input price) + (output tokens × output price)) / 1,000,000

詳細な使用状況によってキャッシュ トークン数が提供され、モデルにキャッシュされた入力レートが個別に設定されている場合は、入力合計からキャッシュされたトークンを減算し、キャッシュされた部分とキャッシュされていない部分の価格を個別に計算します。

各フェーズとモデルの行を個別に計算し、結果を追加します。 行でモデルが識別されない場合、その使用状況にデプロイ固有の価格を確実に適用することはできません。

サブスクリプション、リージョン、デプロイの種類、課金契約に適用される料金を使用します。 公開されている料金については、Azure OpenAI Service価格に関する記事を参照してください。 その結果、外部ツールやサービスから料金が引き続き除外されます。

関連するコンテンツ

• エージェント オプティマイザーの概要
• クイック スタート: プロンプト エージェントを最適化する
• クイック スタート: ホストされるエージェントを最適化する