トークンの使用をレビュー可能なユニットエコノミクスに変える
バージョン管理された見積もりが再試行とアプリケーションが実際に評価するダウンストリームの結果に結合されると、プロバイダーの使用がさらに便利になります。
- 1
モデルリクエスト
プロバイダー、モデル、機能、トークン、レイテンシー、キャッシュ、および再試行コンテキストをキャプチャします。
- 2
費用の見積もり
日付の付いた価格ソースを適用し、そのバージョンを見積もりの横に保持します。
- 3
製品の成果
リクエストを、承認、解決、保存、エスカレーション、または破棄された作業に結び付けます。
- 4
ユニットエコノミクス
トークンやリクエスト量だけではなく、レビューされた結果ごとのコストを比較します。
ユースケースとテンプレートの比較
測定するものを選ぶ
ユースケース ガイドを使用して、結果、イベントの境界、分析の質問を選択します。短いコピーアンドペースト実装の概要の準備ができたら、一致するテンプレートを開きます。
エージェントプロンプト
これをコーディングエージェントに貼り付けます
交換する YOUR_API_KEY サインアップ後、エージェントに製品フローを実行して最初のイベントを確認するように依頼します。
OpenAI cost monitoring セットアップ プロンプト
OpenAI と LLM の使用法を理解できるように、このプロジェクトを Telemetry で計測します。
/skill.md とこの Telemetry API キーを使用します: YOUR_API_KEY
ログを記録してください:
1. model、provider、route、feature、input_tokens、output_tokens、total_tokens、estimated_cost_usd、latency_ms、status、該当する場合は error_type を含むすべてのmodel リクエスト。
2. エージェントまたはアシスタントによって行われたツール呼び出し (tool_name、status、latency_ms、result_category など)。
3. ユーザー向けの AI ワークフローの結果 (feature、status、retry_count、ユーザーが結果を受け入れ、コピー、保存、または破棄したかどうかなど)。
4. 日次コスト、featureごとのコスト、modelごとの障害、p95 レイテンシ、許容される出力レートを示すダッシュボード。
私が明示的に保存を承認しない限り、プロンプトと生の入力候補をテレメトリから除外します。セットアップ手順
- 1デフォルトでは、生のプロンプトを保存せずに、各モデルのリクエストをログに記録します。
- 2トークン、推定コスト、レイテンシ、プロバイダー、モデル、ワークフローを記録します。
- 3保存、コピー、承認、再試行などの製品結果イベントを接続します。
- 4マージン、信頼性、ユーザー価値を考慮したダッシュボードを作成します。
キャプチャするイベント
これにより解き明かされる質問
- アクティブ化されたユーザーあたりのコストが最も高い AI 機能はどれですか?
- 1 ドルあたりの許容生産レートが最も優れているのはどのモデルですか?
- 再試行やタイムアウトが変換に悪影響を与えるのはどこですか?
LLM のコストとユニットエコノミクス
プロバイダーの使用状況を正規化し、有用な結果ごとのコストを測定します
トークン支出は、それを生んだ機能、アカウント、再試行経路、レビュー済みのユーザー成果と結び付いて初めて改善に活かせます.電卓を使用して仮定をテストし、複数テーブルの SQL ラボに対して同じ分析を実行します。
月額費用の見積もり
入力した価格は例であり、現在のプロバイダーの価格ではありません。これらを、プロバイダー契約のレートと請求可能なトークン カテゴリに置き換えます。
プロバイダーの試行
105,000
月額費用の目安
$304.50
推定再試行コスト
$14.50
受け入れられる出力
60,000
受け入れられた出力ごとのコスト
$0.0051
このブラウザのみの見積もりは Telemetry には送信されず、プロバイダーの請求書でもありません。
プロバイダーに依存しないイベント コントラクト
必要なプロバイダー応答フィールドを保持しますが、分析面を正規化することで、モデルと価格の変更に新しいダッシュボードが必要なくなります。
| 正規化されたフィールド | 彼らが一緒に属する理由 |
|---|---|
| provider, model, feature | 使用状況をプロバイダーと製品のワークフローに帰属させます。 |
| input_tokens, output_tokens | プロバイダーから報告された使用状況コンポーネントを保持します。 |
| cached_input_tokens, reasoning_tokens | 利用可能な場合は、オプションの請求可能なカテゴリを別にしておいてください。 |
| estimated_cost_usd, pricing_version | 価格が変化した後でも分析見積もりを再現可能にします。 |
| retry_count, cache_hit, latency_ms | 実行パス内のコストと信頼性の変化について説明します。 |
| accepted, saved, discarded, human_handoff | プロバイダーの消費をレビューされた製品の成果に結び付けます。 |
結合分析を実行する
共有アカウントと llm_requests テーブルを使用して、プランごとに受け入れられた出力ごとのコストを計算します。
SQL ラボを開く機能ごとにコストを細分化する
完全なイベント スキーマ、DataFusion クエリ、結果、グラフ、ダッシュボードの推奨事項を検査します。
オープンコストレシピ再試行とキャッシュのコストを測定する
回避可能なプロバイダーの試行とキャッシュの節約を、意図的なユーザーの要求から分離します。
再試行レシピを開く請求の範囲を制限する
プロバイダーの請求書を請求の真実として使用します。イベントレベルのコストは、帰属、製品決定、マージン調査、異常検出のための分析的な見積もりです。
OpenAI API コスト追跡実装ガイドを読むイベントスキーマの例
このワークフローのイベントスキーマ
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します AIエージェントの監視
レビュー可能な SQL を使用して、エージェントの実行、ツールの使用、モデルのコスト、品質、製品の結果を結び付けます。
関連する SQL レシピ
その他のSQL例
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
機能とモデルごとに LLM コストを計算する
LLM の支出を促進しているのはどの製品機能とモデルですか?
レシピを開く1 ドルあたりの受け入れられた AI 出力を測定する
どのモデルと機能の組み合わせが、1 ドルあたり最も受け入れられる出力を生成しますか?
レシピを開くLLM キャッシュの節約と再試行コストを測定する
再試行とキャッシュミスに関連するモデルコストはどれくらいですか?
レシピを開く最初のトークンまでの LLM 時間を測定する
出力が開始される前に速度が遅いと感じるモデルと機能の組み合わせはどれですか?
レシピを開くネストされた AI ツール呼び出しイベントのクエリ
最も失敗した呼び出しに関連する AI ツールと引数はどれですか?
レシピを開く次のステップ
エージェントが使用する API キーを作成します
プロンプトの実行、テスト イベントの送信、最初のダッシュボードの確認には無料プランで十分です。
関連ページ