LLM 使用状況ダッシュボードがプロバイダーの請求書と一致しない理由

LLM 使用状況ダッシュボード、プロバイダ コンソール、クラウド請求エクスポート、顧客請求書に異なる数値が表示されている場合でも、最初から 1 つのシステムが間違っていると決めつけないでください。まず、どの番号がどの目的で権限を持っているかを尋ねます。

ゲートウェイ ダッシュボードは通常、操作ビューであり、高速でリクエスト レベルであり、アラートに役立ちます。プロバイダーの請求書は、決済された請求ビューです。プロバイダーの請求ルールに従って、ゆっくりと集計され、調整されます。クラウド請求エクスポートでは、特に請求書データが API リクエストごとではなく、プロジェクト、SKU、地域、使用タイプ、または請求月ごとにグループ化されるマネージド モデル サービスの場合、別のレイヤーが追加されます。

実際的な問題は「実数を見つける」だけではありません。不一致を分類し、それを説明するのに十分な証拠を保存し、ダッシュボード、財務レポート、または顧客への請求にどのような数値が適しているかを判断する必要があります。

1 つの番号ではなく 2 つの元帳を使用する

最も一般的な間違いは、リアルタイムのゲートウェイ見積もりを最終請求書のように動作させようとすることです。これらは異なるジョブの異なるレコードです。

運用使用状況台帳

運用台帳は、ゲートウェイ、SDK ラッパー、プロキシ、またはアプリケーション インストルメンテーションによってリクエスト時に設定されます。速度と帰属を考慮して最適化する必要があります。次のような質問に答えます:

• このリクエストを作成したのはどのテナント、チーム、API キー、プロジェクト、またはワークフローですか?
• どのモデルが呼び出されましたか?
• 観測または推定された入力、出力、キャッシュされた、または推論トークンの数は何ですか?
• リクエストは再試行されましたか、キャンセルされましたか、ストリーミングされましたか、バッチ処理されましたか、または失敗しましたか?
• すぐに請求すべき内部予算または制限はどれですか?

この元帳は LLM コスト管理に不可欠ですが、請求書と必ずしも正確であるとは限りません。プロバイダーが最終的な使用量を返す前に、推定されたトークンが使用される場合があります。古い価格表が適用される場合があります。プロバイダーが請求しない試行リクエスト、またはプロバイダーが請求する再試行を見逃す可能性があります。

決済原価台帳

決済コスト台帳は、プロバイダーが料金を集計して分類した後、プロバイダーのコスト API、プロバイダーの使用状況レポート、またはクラウド請求のエクスポートから入力されます。財務報告用に最適化する必要があります。次のような質問に答えます:

• プロバイダーは、この日、モデル、プロジェクト、キー、項目、または使用量タイプについてどのような費用を報告しましたか?
• どの通貨と請求期間が適用されますか?
• 遅れた修正、クレジット、または調整はありましたか?
• テナントに自信を持って割り当てられるコストはどれですか?
• メタデータが欠落していたために帰属されないままになっているコストはどれですか?

推奨事項: アラート、予算予約、デバッグ、およびほぼリアルタイムのダッシュボードには運用台帳を使用します。決済コスト台帳は、決算、顧客への請求書、マージン分析、最終的なチャージバックに使用します。決済前の数値には推定または暫定のラベルを付けます。

デバッグ前に不一致を分類する

LLM の請求の不一致のほとんどは、5 つのクラスに分類されます。最初にギャップを分類すると、実際の問題が請求書のタイミングにある場合にチームがトークン化の詳細を追跡したり、実際の問題がテナント メタデータの欠如にある場合にクラウド請求書のエクスポートを追跡したりすることがなくなります。

1.タイムウィンドウドリフト

これは、2 つのシステムが同じ使用量を異なる期間にグループ化した場合に発生します。

一般的な原因には、UTC と現地の日付、プロバイダの請求日がダッシュボードの日と一致しない、バッチ ジョブの完了日が送信日と異なる、日付の境界を越えるストリーミング リクエスト、使用状況のタイムスタンプと異なるクラウド請求書の月フィールドなどが含まれます。 Cloud Billing のエクスポートには、後の請求期間での修正や収益化が遅れた使用量も含まれる場合があります。

デバッグ手順:

1. 比較する前に、すべてのタイムスタンプを UTC に変換します。
2. 使用日、リクエストの開始時間、リクエストの終了時間、プロバイダーの処理時間、バッチ完了時間、請求月を個別に比較します。
3. 最初に閉鎖期間を調整します。まだ解決中のプロバイダー レポートに対して今日のダッシュボードを診断することは避けてください。
4. バッチ ワークロードの場合は、リクエストの送信日とバッチの完了日の両方を比較します。

推奨事項: 「使用日」、「決済日」、「請求月」を区切ったレポート カレンダーを定義します。これらのフィールドを 1 つの日付列に折りたたまないでください。

2.寸法ドリフト

これは、ダッシュボードと請求書が異なるものをグループ化している場合に発生します。

ゲートウェイは、テナント、チーム、API キー、環境、またはワークフローごとにグループ化できます。プロバイダーコスト API は、プロバイダーとエンドポイントに応じて、プロジェクト、ユーザー、API キー、モデル、ラインアイテム、またはソースごとにグループ化できます。クラウド請求エクスポートは、プロジェクト、SKU、サービス、場所、使用タイプ、ラベル、または請求月ごとにグループ化できます。マネージド モデル サービスの場合、リクエストごとのプロンプト帰属が請求書のエクスポートにまったく存在しない可能性があります。

デバッグ手順:

1. 各システムで使用される正確なグループ化ディメンションを書き留めます。
2. 合計を比較する前に、モデル ID、リージョン、サービス レベル、トークン タイプ、品目、API ソースを正規化します。
3. プロバイダー プロジェクト、ワークスペース、API キー、クラウド プロジェクト ラベルが内部テナントに正しくマッピングされているかどうかを確認します。
4. 帰属のない支出をテナント バケットに強制的に入れるのではなく、明示的に特定します。

推奨事項: テナントの属性をダッシュボード フィルターではなく、ファーストクラスの請求フィールドとして扱います。 LLM API コスト アトリビューションを信頼できるようにするには、リクエスト時にテナント ID を取得し、後で参加するために必要なプロバイダ側の ID を保存します。

3.価格変動

これは、運用見積もりでプロバイダーの決済済み請求書とは異なる価格設定ロジックが使用されている場合に発生します。

一般的な原因には、キャッシュされたトークンの料金設定、キャッシュ書き込み料金とキャッシュ ヒット料金、個別の入力および出力トークン レート、新しい価格モデルに移行したモデル エイリアス、サービス レベル、推論地理、バッチ割引、ファイル検索または Web 検索の広告申込情報、画像または音声ユニット、通貨換算などが含まれます。合計トークンに 1 つの混合価格を乗算するダッシュボードは、プロバイダーの請求書に複数のトークン タイプまたは項目が含まれるとすぐに変動します。

デバッグ手順:

1. 合計を比較する前に、コストを項目に分割します。
2. 入力トークン、出力トークン、キャッシュ書き込み、キャッシュ ヒット、推論トークン、およびプロバイダーが報告する非トークン ユニットを分離します。
3. 内部価格表をバージョン管理し、各見積もりに使用される価格バージョンを保存します。
4. プロバイダーがモデル エイリアス、モデル スナップショット、または製品ラインアイテムをゲートウェイとは異なる方法で報告するかどうかを確認します。
5. 独自の通貨換算を適用する前に、プロバイダの請求通貨で比較してください。

事実: プロバイダーのレポート画面では、プロバイダーと環境に応じて、バケット化されたコストと、プロジェクト、ユーザー、API キー、モデル、品目、ワークスペース、トークン タイプ、地理、サービス レベル、または通貨などのグループ化ディメンションを公開できます。クラウド エクスポートでは、ラベル、リソース フィールド、使用タイムスタンプ、請求月、クレジット、修正が公開される場合があります。

4.リクエストのライフサイクル ドリフト

これは、1 つの請求対象操作としてカウントされるものについてシステム間で意見が一致しない場合に発生します。

通常、再試行が原因です。アプリケーションがタイムアウト後に再試行した場合、製品ダッシュボードは最終的な成功した回答を 1 つのユーザー アクションとして扱う場合がありますが、プロバイダーは 2 つまたは 3 つのモデル呼び出しに対して請求を行います。 1 つの失敗したプライマリ呼び出しと 1 つの成功したフォールバック呼び出しが 1 つのアプリケーション結果として表示される場合、フォールバック ルーティングによって同じ問題が発生する可能性があります。

ストリーミングにより、別のドリフトの原因が追加されます。ユーザーは、部分的な出力を受信した後にストリームをキャンセルできます。プロバイダーは生成されたトークンをキャンセルまで報告する場合がありますが、アプリケーションは失敗または放棄されたリクエストのみを記録します。バッチ ジョブは異なるライフサイクルを作成します。送信、検証、処理、部分的な失敗、結果の取得、請求は同じタイムスタンプを共有しない場合があります。

デバッグ手順:

1. 安定した内部リクエスト ID をユーザー アクションに割り当てます。
2. プロバイダーの呼び出し、再試行、フォールバックごとに個別の試行 ID を割り当てます。
3. 利用可能な場合は、プロバイダーの応答 ID とリクエスト ID を保存します。
4. レコード ストリーム ステータス: 完了、クライアントのキャンセル、サーバーの終了、タイムアウト、またはネットワーク損失。
5. バッチ ジョブの場合は、バッチ ジョブ ID、入力ファイル ID (該当する場合)、送信時間、完了時間、アイテムごとのステータス (可能な場合) を保存します。

推奨事項: プロバイダーの請求書を、製品レベルのユーザーのアクションではなく、プロバイダーの試行と比較します。その後、試行を製品分析のユーザー アクションまでロールアップします。

5.プロバイダー決済ドリフト

これは、ダッシュボードに数値が表示された後にプロバイダー側の請求データが変更された場合に発生します。

プロバイダー費用 API とクラウド請求のエクスポートは、請求の真実に近づいていますが、後で遅れたり、バケット化されたり、調整されたりする可能性があります。クレジット、修正、到着の遅れ、請求月の変更、製品の再分類などにより、最終的な数値が変動する可能性があります。これは、財務部門が月の初日のダッシュボードのスクリーンショットと、後で生成された請求書のエクスポートを比較する場合に特に重要です。

デバッグ手順:

1. 各プロバイダのコスト バケットがいつ取得されたかを追跡します。
2. 決済コストのインポートの不変スナップショットを保存します。
3. 同じプロバイダー、期間、グループ化ディメンションのインポート間の変更を検出します。
4. 履歴をサイレントに書き換えるのではなく、遅れた調整を調整行として保持します。
5. 終了プロセスを定義します。たとえば、プロバイダーのデータが安定し、差異チェックに合格するまで期間を暫定的に保持します。

推奨事項: 顧客の請求書には決済期間を使用するか、明示的な暫定ラベルを付ける必要があります。ダッシュボードは、開いている期間の小さな変動を許容できます。顧客への請求で不確実性を隠してはいけません。

最小限の証拠スキーマ

調整プロセスは、不一致が現れる前に証拠が保持されているかどうかによって決まります。少なくとも、機密性の高いプロンプト コンテンツを保存せずに、運用記録とプロバイダーの請求記録の間を移動できるメタデータを取得します。

推奨されるリクエストレベルのフィールド:

• 内部識別子: internal_request_id、attempt_id、parent_request_id、tenant_id、team_id、project_id、環境、workflow_id.
• アクセス識別子: gateway_api_key_id、provider_api_key_id (使用可能な場合)、サービス アカウント、user_id (該当する場合)。
• プロバイダ識別子: プロバイダ、provider_project_id、provider_workspace_id、provider_response_id、provider_request_id、cloud_account_id、cloud_project_id.
• モデルとルーティング: requested_model、resolved_model、model_version、route_policy、fallback_from、fallback_to.
• 使用法: input_tokens、output_tokens、cached_input_tokens、cache_write_tokens、reasoning_tokens、token_unit、non_token_quantity、quantity_unit.
• 価格見積もり: estimated_cost、通貨、price_table_version、estimate_source、budget_reservation_id.
• ライフサイクル: ステータス、error_class、retry_number、stream_started、stream_completed、stream_termination_status、batch_job_id、batch_item_id.
• タイミング: request_started_at、request_completed_at、provider_reported_at、batch_submitted_at、batch_completed_at、usage_date_utc.

請求を調整するためだけに生のプロンプトや応答を保存しないでください。通常は、リクエストのメタデータ、トークン数、プロバイダー ID、および正規化されたディメンションで十分です。呼び出しログに機密コンテンツが含まれている可能性がある場合は、使用状況フィールドと ID フィールドを保持しながら、プロンプトと応答のペイロード キャプチャを編集または無効にします。

信頼性の低い共有粒子で比較

リクエストレベルの調整は魅力的に思えますが、常に可能であるとは限りません。適切な比較の粒度は、プロバイダーが何を公開しているかによって異なります。

プロバイダーコスト API

プロバイダーコストエンドポイントが毎日のバケットと、プロジェクト、ユーザー、API キー、モデル、ラインアイテム、ワークスペース、トークンタイプなどのグループ化ディメンションを公開するところから開始します。同じディメンションを使用して、日次決済コスト バケットをゲートウェイの日次ロールアップと比較します。テナントの対象範囲が完全でない限り、テナント レベルのダッシュボードをプロバイダー組織の合計と直接比較しないでください。

比較粒度の例:

• date_utc
• プロバイダ
• provider_project_id または workspace_id
• api_key_id 利用可能な場合
• モデルまたは resolved_model
• line_item または token_type
• 通貨

クラウド請求モデル サービス

クラウド請求サービスの場合、請求書のエクスポートにはリクエストごとの識別子が含まれない場合があります。その場合は、日、モデル、リージョン、使用量タイプなどのより粗い粒度で、呼び出しログをコストと使用量のエクスポートに結合します。テナントの割り当てにはリクエスト レベルのログを使用しますが、請求書の合計にはクラウド請求エクスポートを使用します。

比較粒度の例:

• usage_date_utc
• cloud_account_id または billing_account_id
• cloud_project_id
• 地域
• model_id
• usage_type または SKU
• invoice_month

事実: AWS Bedrock のドキュメントでは、リクエスト ID、トークン カウント、モデル ID、リージョン、リクエスト ID のモデル呼び出しログを使用しながら、モデル、トークン タイプ、サービス レベル、使用量タイプ データのクロスリージョン推論などのコストおよび使用状況レポート フィールドの使用について説明しています。ドキュメントでは、請求書に正確な合計を得るために、モデル、使用量タイプ、日単位で呼び出しログを CUR と結合することを推奨しています。

実際的な調整ワークフロー

財務部門が請求書の不一致を報告する場合は、このワークフローを使用します。

ステップ 1: 比較を凍結する

プロバイダー、請求期間、通貨、および比較基準を 1 つ選択します。ダッシュボード番号、プロバイダーコストレポート、およびクラウド請求のエクスポートを同時にエクスポートします。エクスポートのタイムスタンプを記録します。多くのチームは、移動するターゲットを比較して時間を無駄にしています。

ステップ 2: 見積金額と決済金額を分離する

行を estimated_cost と settled_cost に分割します。推定コストはゲートウェイの価格表から算出されます。決済コストはプロバイダーまたはクラウドの請求データから得られます。一方を他方で上書きしないでください。両方を保存し、差異を追跡します。

ステップ 3: 寸法を正規化する

プロバイダー、モデル、解決されたモデル、品目、トークン タイプ、サービス レベル、リージョン、プロジェクト、ワークスペース、API キー、およびテナントのマッピング テーブルを作成します。 「不明」または「属性のない」バケットを含めます。強制的な割り当ては、運用上の修正を隠すため、明示的なギャップよりも悪いです。

ステップ 4: 合計をトップダウンで調整する

プロバイダー組織の合計とプロバイダー請求書の合計から始めます。次に日ごとに比較します。次に、モデルと品目ごとに比較します。これらのパスを通過した後でのみ、テナントまたは API キーの割り当てを比較する必要があります。この順序により、問題がグローバル価格設定、時間枠のドリフト、またはアトリビューションのいずれであるかがわかります。

ステップ 5: クラスごとの差異を調査する

5 つのクラスをチェックリストとして使用します:

• 時間枠のドリフト: UTC の不一致、ローカル日付グループ、バッチ完了日、請求月、遅延使用。
• ディメンション ドリフト: プロジェクト/ワークスペースの不一致、API キーの欠落、マップされていないモデル、テナント ラベルの欠落。
• 価格変動: キャッシュ トークン、サービス レベル、リージョン、バッチ価格、非トークン品目、古い価格表。
• リクエストのライフサイクル ドリフト: 再試行、フォールバック、ストリーミングのキャンセル、部分的なバッチの失敗、タイムアウト。
• プロバイダ決済のドリフト: クレジット、修正、遅延バケット、変更されたコストのエクスポート。

ステップ 6: 差異しきい値を適用する

ユースケースが異なると、異なる許容値が必要になります。エンジニアリング ダッシュボードは、保留中として明確にマークされている場合、オープン期間の小さな差異を許容することがあります。予算執行システムでは、過剰支出を防ぐために控えめな見積もりが必要になる場合があります。顧客の請求書では、決済されたコストまたは文書化された割り当てポリシーを使用する必要があります。

推奨事項: プロバイダーごとではなく、ユースケースごとにしきい値を定義します。例:

• 運用ダッシュボード: オープン期間の小さな差異を許容し、保留ステータスを表示します。
• 予算アラート: 控えめな見積もりを使用し、後で調整します。
• 内部チャージバック: 解決済みのプロバイダー バケットと帰属範囲チェックが必要です。
• 顧客請求書: クローズド期間、精算済みコストのインポート、しきい値未満の差異、および帰属のない重大な支出がないことが必要です。

実装パターン: 調整表

多くの場合、単純なスキーマで十分です。操作の試行、プロバイダーのコスト バケット、正規化されたロールアップ、および差異の結果には別のテーブルが必要です。

operational_attempts
- attempt_id
- internal_request_id
- tenant_id
- provider
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model_requested
- model_resolved
- region
- input_tokens
- output_tokens
- cached_input_tokens
- cache_write_tokens
- status
- retry_number
- stream_termination_status
- batch_job_id
- estimated_cost
- currency
- price_table_version
- usage_date_utc

provider_cost_buckets
- provider
- bucket_date_utc
- provider_project_id
- provider_workspace_id
- provider_api_key_id
- model
- line_item
- token_type
- service_tier
- region
- quantity
- quantity_unit
- settled_cost
- currency
- invoice_month
- imported_at

reconciliation_results
- period_start
- period_end
- grain_key
- estimated_cost
- settled_cost
- absolute_variance
- percent_variance
- variance_class
- status
- notes
- checked_at

重要な設計上の選択は、推定コストと確定コストの両方を維持することです。プロバイダーのデータが到着すると、その時点でアラートと予算の決定を説明した元の運用記録を破壊することなく、差異を計算できます。

最初の調整後の一般的な修正

通常、最初の調整では運用上のギャップが明らかになります。修正は簡単ですが、プラットフォームと財務全体にわたる所有権が必要です。

• テナント メタデータが欠落しています: ゲートウェイ境界で tenant_id、team_id、または customer_id が必要です。アトリビューション メタデータのないプロダクション リクエストを拒否または隔離します。
• 古い価格表: バージョンの価格、発効日を追跡し、プロバイダー モデルのカタログや価格ページが変更されたときにアラートを送信します。
• 再試行の超過数または過小数: プロバイダ試行 ID から製品リクエスト ID を分離します。
• ストリーミング キャンセル ギャップ: プロバイダーが返すときに部分的な使用状況を記録し、クライアントが切断された場合でも終了ステータスを記録します。
• バッチのあいまいさ: ジョブ ID を保存し、完了日と送信日によって比較します。
• クラウド請求書の不一致: リクエストごとの請求書行を期待するのではなく、日、モデル、リージョン、使用量タイプの粒度で呼び出しログを請求エクスポートに結合します。
• 原因不明の遅延遅延: スナップショット プロバイダーのコスト インポートと遅延クレジットまたは修正の調整行を記録します。

事実、推奨事項、予測

事実: プロバイダーとクラウドの請求システムでは、さまざまな請求の次元と詳細レベルが公開されています。一部のプロバイダー API は、エンドポイントと環境に応じて、日次コスト バケットと、プロジェクト、ユーザー、API キー、モデル、ラインアイテム、ワークスペース、トークン タイプ、サービス レベル、地域、通貨などのグループ化ディメンションを公開します。 Cloud Billing のエクスポートには通常、プロジェクトまたはリソースのラベル、タイムスタンプ、請求月、クレジット、修正、SKU、場所、使用量の種類が含まれます。クラウド請求モデル サービスでは、リクエスト レベルのアトリビューションのために呼び出しログが必要になる場合があります。

推奨事項: 運用使用量台帳と決済コスト台帳を保管してください。信頼できる最低の共有粒度で比較してください。機密ペイロードを保存せずにリクエストレベルの証拠を保存します。比較する前に次元を正規化します。請求書には決済済みのプロバイダーまたはクラウド請求データを使用します。原因不明の支出は、混合割り当てで隠すものとしてではなく、データ品質の問題として扱います。

予測: チームがより多くのキャッシュされたプロンプト、バッチジョブ、サービス層、フォールバックルート、クラウドホスト型のモデルサービスを使用するにつれて、LLM の請求調整はより重要になります。プロバイダーの課金 API は改善される可能性がありますが、プロバイダーは顧客、チーム、またはワークフロー階層を推測できないため、内部テナントのメタデータの必要性がなくなるわけではありません。

結論

LLM ダッシュボードがプロバイダーの請求書と一致しない場合、答えが 1 つのバグであることはほとんどありません。通常、これは運用見積もり、プロバイダーが解決するコスト、クラウドの請求項目、および内部帰属ルールの間の不一致です。

永続的な修正は調整ハンドブックです。運用元帳と決済元帳を別々に保持し、差異を時間枠、ディメンション、価格設定、ライフサイクル、または決済ドリフトに分類し、リクエストレベルの証拠を保存し、差異チェック後に決済期間からのみ請求します。これにより、エンジニアリング チームは財務部門に暫定数値を最終的な金額として信頼するよう求めることなく、迅速な管理が可能になります。

関連資料

• チームごとの LLM コスト台帳の毎日の調整