複数の AI API にわたるチームごとの LLM コスト台帳を構築する方法
スコープ付きキー、リクエストのメタデータ、プロバイダーの請求データ、日次調整を使用して、複数の AI API 全体でチーム、製品、環境、または顧客ごとに LLM 支出を割り当てるための実用的なアーキテクチャ。
プロバイダーのダッシュボードでは、組織が費やした金額を知ることができます。彼らは、財務チームやプラットフォーム チームが実際に答えるべき質問、つまりどのチーム、製品、環境、ワークロード、顧客セグメントが支出の原因となったのか、そしてその支出は予想されていたのかどうかという質問にほとんど答えません。
耐久性のあるパターンは別のダッシュボードではありません。これは内部コスト台帳であり、アプリケーション側のリクエスト メタデータ、範囲指定された API キー、プロバイダーの使用状況データ、請求書レベルの請求合計を組み合わせた記録システムです。この台帳により、エンジニアリング チームはほぼリアルタイムで運用状況を把握できるとともに、財務部門には予算、割り当て、チャージバックをサポートできる調整されたビューが提供されます。
この記事では、タグ付けコントラクト、リクエスト フロー、テーブル、調整プロセス、制御、トレードオフなど、複数の AI API を使用するチーム向けの実用的なアーキテクチャを説明します。
問題: プロバイダの請求は正確ですが、常に割り当てられるわけではありません
ほとんどの AI プロバイダーは、使用状況ダッシュボード、使用状況 API、請求エクスポート、プロジェクト、ワークスペース、サービス アカウント、またはコスト API の組み合わせを公開しています。これらのツールは便利ですが、すべてが同じ詳細レベルで動作するわけではありません。
事実
- 一部のプロバイダ費用エンドポイントは財務レポート用に設計されており、請求書の品目、プロジェクト、または請求期間ごとに支出を分類する場合があります。
- 使用状況 API は運用の詳細を提供することがよくありますが、割引、クレジット、請求の遅延、コミットメント価格、バッチ レート、キャッシュ価格、請求書の調整などにより、使用量記録と最終コスト記録が完全に一致しない場合があります。
- プロジェクト、ワークスペース、サービス アカウント、API キー、IAM プリンシパルなどのネイティブの管理境界は支出の属性に役立ちますが、正確な機能はプロバイダーによって異なります。
- 一部のプラットフォームでは、リクエストごとのメタデータがコスト割り当てレポートではなく呼び出しログに表示されます。チームはログを集計し、料金レートを適用してリクエスト レベルのコストを見積もる必要があります。
推奨事項
プロバイダー データをシステム全体ではなく入力として扱います。運用上と財務上の問題の両方に答えることができる内部台帳を作成し、それをプロバイダーのコスト源と毎日照合します。
台帳のアーキテクチャ
コスト台帳には 5 つの主要なコンポーネントがあります。
<オル>目標は、オペレーションのリクエストごとの推定元帳と、財務の調整された日次元帳という 2 つの関連するビューを作成することです。
これは、単一プロバイダーのレポート モデルに依存せずにエンジニアリング テレメトリを財務責任に結び付けるため、より広範な AI API コスト管理における共通の構成要素です。
ステップ 1: ダッシュボードを構築する前にコスト ディメンションを定義する
財務、エンジニアリング、製品、セキュリティの各チームが一貫して使用するディメンションから始めます。これは、チャートを選択する前、または取り込みジョブを作成する前に行ってください。
実際のスキーマには通常、次のものが含まれます。
- team_id: 所有するエンジニアリング チームまたはビジネス チーム。
- product_id: API を使用する製品、機能領域、または内部プラットフォーム。
- 環境: 本番、ステージング、開発、サンドボックス、デモ、またはテスト。
- ワークロード: チャット、要約、抽出、分類、コード生成、評価、埋め込み、再ランキング、またはバッチ処理。
- customer_segment: エンタープライズ、ミッドマーケット、無料トライアル、社内、パートナー、またはその他の承認されたセグメント。
- budget_owner: 支出の責任を負う個人、チーム、またはコスト センター。
- プロバイダ: リクエストに使用される AI API プロバイダ。
- モデル: 正確なモデルまたはデプロイメント識別子。
- request_class: インタラクティブ、バックグラウンド、バッチ、再試行、フォールバック、評価、または管理者。
エンジニアが実際にスキーマを設定できる程度にスキーマを小さくしてください。フリーテキストの漂流を防ぐためにガバナンスを追加します。たとえば、team_id は、任意のリクエスト ヘッダーからではなく、内部チーム レジストリから取得する必要があります。
実装の詳細
ディメンションをバージョン付きのコントラクトとして表します。必要な運用タグが欠如しているリクエストは、ゲートウェイでフェールクローズされるか、毎日確認される明確に名前が付けられた隔離バケットにルーティングされる必要があります。
{
"スキーマ_バージョン": "2025-01",
"team_id": "プラットフォーム-ai",
"product_id": "サポートアシスタント",
"環境": "生産"、
"ワークロード": "要約",
"顧客セグメント": "企業",
"budget_owner": "コストセンター-4812","request_class": "対話型"
}ステップ 2: チームおよび環境ごとにスコープ指定されたキーを発行する
共有モノリシック API キーにより、コスト割り当てが脆弱になります。すべてのサービスが同じ認証情報を使用している場合、財務部門は自信を持って支出を帰属させることができず、プラットフォーム チームは無関係のシステムに影響を与えずに 1 つのワークロードを無効にすることができません。
可能な限り、範囲指定された認証情報を使用します。
- チームおよび環境ごとに 1 つのキーまたはサービス アカウント
- 本番ワークロードと非本番ワークロードの認証情報を分ける
- リスクの高い実験、評価、バッチジョブには認証情報を分ける
- プロバイダネイティブのプロジェクトまたはワークスペースが内部所有権に明確にマッピングされている場合
これは、すべてのマイクロサービスに固有のプロバイダー アカウントが必要であるという意味ではありません。境界が多すぎると、運用上のオーバーヘッドが発生します。有用な単位は、所有権、予算、運用上の対応が異なる境界です。
セキュリティに関するメモ
URL は通常、ログ、プロキシ、分析ツール、ブラウザ履歴にキャプチャされるため、API キーとセキュリティ トークンを URL で送信しないでください。認証情報をヘッダーまたは管理シークレット ストアに配置し、自動化されたプロセスを通じてローテーションし、インシデント対応のための主要なライフサイクル イベントを記録します。
ステップ 3: ゲートウェイ層またはアプリケーション層でリクエストのメタデータをキャプチャする
台帳にはトークン数以上のものが必要です。支出が発生した理由と、それが役に立ったかどうかを説明するには、十分なコンテキストが必要です。
LLM 呼び出しごとに、以下をキャプチャします。
- 内部リクエスト ID と分散トレース ID。
- 返された場合のプロバイダー リクエスト ID。
- プロバイダー、モデル、リージョン、エンドポイント。
- チーム、プロダクト、環境、ワークロード、顧客セグメント、予算所有者
- 入力トークン、出力トークン、キャッシュされたトークン、推論トークン、埋め込みユニット、画像ユニット、またはその他の請求可能なユニット（利用可能な場合）
- レイテンシ、再試行回数、フォールバック パス、タイムアウト ステータス、エラー コード
- キャッシュのヒットまたはミス
- リクエスト クラス: 本番、評価、再試行、バッチ、または実験。
中央ゲートウェイを使用すると、すべてのプロバイダー呼び出しが 1 つの実施ポイントを通過するため、これが容易になります。中央ゲートウェイが実現できない場合は、共有クライアント ライブラリを使用し、サービスが同じイベント形式を発行するように要求します。
デフォルトではすべてをログに記録しない
プロンプトおよび出力コンテンツはデバッグと監査に役立ちますが、プライバシー、保持、アクセス制御の義務も生じます。多くのチームでは、デフォルトはメタデータ、トークン数、モデル識別子、およびトレース ID である必要があります。プロンプトおよび出力コンテンツは、保持制限とアクセス制御を備えた明示的なポリシーに基づいてのみ保存してください。
ステップ 4: 2 つのコスト テーブルを維持する
1 つのテーブルをあらゆる目的に使用しようとすると、通常は混乱が生じます。異なるジョブを持つ 2 つの台帳を作成します。
リクエストごとの推定元帳
このテーブルは、ほぼリアルタイムの操作をサポートします。これは粒度が高く、高速で、近似的です。
役立つ列は次のとおりです。
リクエスト IDprovider_request_idタイムスタンプチーム ID製品 ID環境ワークロードプロバイダモデル請求可能な単位rate_card_versionestimated_cost_usdlatency_msステータスコード再試行回数fallback_usedキャッシュステータス
推定コストは、利用可能な最良の請求可能単位データとバージョン管理された内部レート表から計算する必要があります。過去の見積もりを後で説明できるように、各行に料金表のバージョンを残しておきます。
請求書と調整された日次元帳
このテーブルは財務レポートをサポートします。粒度が低く、時間がかかり、最終的な請求の現実に近づきます。
役立つ列は次のとおりです。
請求日プロバイダ請求書アカウントプロジェクトまたはワークスペースチーム ID製品 ID環境estimated_cost_usdprovider_reported_cost_usdallocated_adjustment_usdreconciled_cost_usd差異の理由
調整されたテーブルでは、差異を非表示にするのではなく、差異を保持する必要があります。プロバイダーが報告したコストがクレジットのせいで低い場合、またはプロビジョニングされたスループットのせいで高い場合は、その差を明示的に記録します。
ステップ 5: 月末に手動で調整するのではなく、毎日調整する
毎日の和解により、驚きは小さくなります。このプロセスは最初は簡単です:
<オル>一般的な差異カテゴリには、交渉による割引、プロバイダー クレジット、遅延した使用記録、キャッシュされたトークンの価格設定、バッチ価格、プロビジョニングされたスループット、通貨換算、最低料金、メタデータの欠落などがあります。
調整ポリシーの例
プロバイダー プロジェクトが 1 つのチームと環境にのみマッピングされている場合は、プロバイダーが報告した日次コストの全額をそのチームに割り当て、内部見積もりをサポート詳細として記録します。プロバイダー プロジェクトに複数のチームが含まれている場合は、プロバイダーが報告した合計を内部推定コストに比例して割り当て、各チーム行に調整を記録します。
このポリシーは完璧ではありませんが、説明可能です。誤った精度よりも説明可能性が重要です。
ステップ 6: 予算と管理を元帳分析コードに添付する
支出が帰属されると、コントロールはさらに便利になります。組織全体で単一の制限を設定するのは、ほとんどのチームにとって厳しすぎます。
ワークロードごとに異なるコントロールを使用します。
- サンドボックス: 日次または週次の厳しい制限、自動シャットオフ、低い承認基準値。
- 開発: ソフト アラートと適度なハード キャップ。
- 評価: バッチ ウィンドウ、明示的な予算所有者、有効期限。
- 本番環境: ソフト アラート、エスカレーション ワークフロー、緊急制限の引き上げパス。
- パートナーまたは顧客向け API の使用: 顧客レベルの割り当て、割り当ての適用、不正行為の監視
ハードリミットは請求の暴走を防ぎますが、実稼働ワークフローを中断する可能性があります。運用環境では慎重に使用し、エスカレーション ルールと組み合わせてください。非実稼働ワークロードの場合、通常はハード制限を正当化する方が簡単です。
ステップ 7: 総支出額以外の異常を検出する
1 日の合計支出額は遅れシグナルです。より良いアラートでは、台帳の操作フィールドを使用します。
有用な異常チェックには次のものがあります。
- ワークロードごとの成功したリクエストあたりのコスト
- 過去のベースラインと比較した出力トークン比率
- プロバイダー、モデル、サービス別の再試行率
- 安価なモデルから高価なモデルへのフォールバック頻度
- 現在の時間内の支出速度。
- キャッシュによるメリットが期待されるワークロードのキャッシュ ヒット率の低下
- 本番以外の費用は営業時間外に費やされます。
- 必要なコスト ディメンションが不足していることをリクエストします。
支出が多いというアラートは、デプロイメント後に 1 つのサービスからの運用要約リクエストが通常の 3 倍の出力トークンを生成しているというアラートよりも有用性が低くなります。
推奨される実装順序
1 つのリリースで完全なアーキテクチャを構築しようとしないでください。実際のシーケンスは次のとおりです。
<オル>最初の有用なマイルストーンは、完全なチャージバックではありません。これは、どのチームとワークロードが資材支出の変化を引き起こしたかを 1 営業日以内に答える能力です。
明示的に決定するためのトレードオフ
プロバイダ ダッシュボードと内部台帳: プロバイダ ダッシュボードは導入が早いですが、チーム、製品、環境、顧客全体の内部コストの側面と一致することはほとんどありません。
粒度対運用オーバーヘッド: キー、プロジェクト、ワークスペース、タグが増えるとアトリビューションは向上しますが、ガバナンスの作業も増加します。実際の所有権と一致する境界を使用します。
見積もりコストと請求書コスト: リクエスト レベルの見積もりはタイムリーで運用に役立ちますが、クレジット、交渉された価格設定、または請求調整が自動的に反映されるわけではありません。
中央ゲートウェイと分散型計測: ゲートウェイはプロバイダ間で一貫した適用を提供しますが、重要なインフラストラクチャになります。共有クライアント ライブラリは、一部の環境では導入が容易ですが、強制するのは困難です。
監査可能性とプライバシー: コンテンツのログは調査に役立ちますが、多くの場合、メタデータのみのログがより安全なデフォルトです。
予測: コスト台帳は AI プラットフォーム ガバナンスの一部になる
おそらく、プロバイダー固有のレポートが改善される方向性が考えられますが、プロバイダー間の割り当てには依然として内部コンテキストが必要です。プロバイダーは、すべての企業のチーム構造、製品分類、顧客セグメント、承認ワークフロー、チャージバック ポリシーを把握できるわけではありません。
AI の使用がパイロット プロジェクトから実稼働ワークフローに広がるにつれて、コスト台帳は、アクセス制御、キーのローテーション、監査ログ、レート制限、使用状況分析と並んで、通常のプラットフォーム ガバナンスの一部となるでしょう。コスト分類を早い段階で定義したチームは、後で予算、顧客レベルの割り当て、自動化された制御を追加するのが容易になります。
実用的な結論
グラフではなく、説明責任を中心に台帳を作成します。安定したディメンション、スコープ指定された認証情報から始めて、メタデータをリクエストします。エンジニアリング業務についてはリクエストごとの迅速な見積もりを維持し、財務については調整された日次台帳を維持します。見積もりを強制的に正確に見せるのではなく調整し、差異を維持することで、割引、コミットメント、クレジット、請求の遅れが見えるようにします。
有用な最初のバージョンは、1 つのプロバイダー、上位 3 つのワークロード、チームおよび環境ごとの範囲指定されたキー、メタデータのキャプチャ、推定コスト、プロバイダーが報告する合計との日次比較など、範囲が狭い場合があります。それが機能したら、同じ契約をプロバイダー間で拡張し、重要な要素に予算ポリシーを添付します。