Corebyte
日本語
English简体中文繁體中文日本語한국어
調達プランを相談
メニュー
← 記事一覧へ戻る

LLM のコストガバナンス：実際に何を測るべきか

利用拡大に伴うモデル支出を予測可能に保つ、少数の指標を実務の視点から解説します。

トークン単価より、受け入れた業務成果の費用を見る

文書回答には検索、生成、ツールによる検証、再試行、人による修正が含まれます。完了の条件、失敗の担当者、キャンセルやタイムアウトの扱いを先に決めます。業務タスクごとに費用をまとめ、同等に使える成果を比較します。提供元のリクエスト成功と業務上の検収は別です。

1タスクの総費用を求める式

C_task = Σ C_model_attempt + C_retrieval + C_tools + C_runtime + C_human
C_model_attempt = (U×p_in + R×p_read + O×p_out + W×p_write) / 1,000,000
C_human = minutes / 60 × hourly_rate
C_per_accepted = batch_total_cost / accepted_task_count

U は未キャッシュ入力、R はキャッシュ読み取り、O は出力、W は別途課金されるキャッシュ書き込みで、単位はトークンです。p はそれぞれの仮の USD／百万トークン単価です。同じ通貨とバッチ範囲で適用項目だけを加算します。書き込みが入力料金に含まれる場合は再加算しません。検索、ツール、実行環境、人件費も重複配賦しません。

失敗した試行も分子に含め、分母は検収済みタスクだけにします。応答を受け取れなくても消費がゼロとは限りません。提供元の記録を照合し、共用キャッシュや実行費には固定の検証可能な配賦ルールを使います。

説明用の仮定：100タスクのバッチ

以下の数値はすべて説明用の仮定です。実際の顧客事例、クラウドやモデルの見積価格、削減保証ではありません。

  • 100タスクを処理し、完全な1試行は入力2,000・出力500トークンです。ここでの失敗は出力完了後の業務検証失敗であり、同じトークン費用が発生します。

  • 主モデルの仮の入力／出力単価は百万トークンあたり2／8 USDで、1試行は0.004 + 0.004 = 0.008 USDです。検索はタスクごとに1回0.001 USD、再試行で同じ資料を再利用します。検証／ツールは1試行0.0005 USD、バッチの実行費配賦は固定0.080 USDです。表の人件費はゼロです。

  • 基準では初回に20件が失敗し、それぞれ1回再試行します。この計算に限り再試行はすべて検収され、100件が完了すると仮定します。実際の評価でこの結果を前提にしてはいけません。

全計算：安いリクエストが良い結果とは限らない

キャッシュ

ヒットは入力1,000トークンを再利用し、仮の読み取り単価は百万トークン0.5 USDです。残り1,000入力は通常単価なので、ヒット1回は0.002 + 0.0005 + 0.004 = 0.0065 USDです。120試行中10回がコールド、110回がヒットです。10回各1,000トークンを書き込み、追加書き込み単価は百万トークン1 USDと仮定します。内容と権限は変わらず、初回失敗は20件のままです。

短いプロンプト

初回は入力1,000・出力500で1回0.006 USDです。ただし制約の不足で初回失敗が40件に増えると仮定します。修正は入力2,000へ戻して各1回再試行し、1回0.008 USDです。短い入力の単価で修正を計算しません。

モデル振り分け

簡単な40件を、仮の入力／出力単価が百万トークン0.5／2 USDの小型モデルへ回し、1回0.002 USDとします。16件が検証に失敗して主モデルへ移ります。残り60件は主モデルで開始し12件を再試行します。主モデルは60 + 16 + 12 = 88回、初回失敗は計28件、全試行は128回です。

Baseline: 120 × 0.008 = 0.960
          0.960 + 0.100 + 0.060 + 0.080 = 1.200
Cache:    10 × 0.008 + 110 × 0.0065 = 0.795
          writes = 10 × 1,000 × 1 / 1,000,000 = 0.010
          0.795 + 0.010 + 0.100 + 0.060 + 0.080 = 1.045
Short:    100 × 0.006 + 40 × 0.008 = 0.920
          0.920 + 0.100 + 0.070 + 0.080 = 1.170
Routing:  40 × 0.002 + (60 + 16 + 12) × 0.008 = 0.784
          0.784 + 0.100 + 0.064 + 0.080 = 1.028
方式 初回失敗／100 全試行 バッチ総費用 USD
基準 20 120 1.200
キャッシュ 20 120 1.045
短い入力 40 140 1.170
振り分け 28 128 1.028
方式 検収1件あたり USD
基準 0.01200
キャッシュ 0.01045
短い入力 0.01170
振り分け 0.01028

別の最終失敗例では、基準費用1.200 USDのまま検収が95件なら、1件あたり1.200 ÷ 95 ≈ 0.01263 USDです。残る5件に各2分、仮の人件費30 USD／時間が必要なら、追加費用は5 × 2 ÷ 60 × 30 = 5 USDです。人が全件修正できたと仮定すると、完了1件は(1.200 + 5) ÷ 100 = 0.062 USDです。この追加仮定は表に含みません。

品質と失敗経路も含めて選ぶ

キャッシュの例で初回失敗を増やさず費用が下がるのは、文書版、権限、期限、キーが正しい場合です。ヒット率低下、頻繁な書き込み、古い内容のヒットで結果は変わります。読み取り単価だけでなくヒット率と品質を測ります。

初回リクエストごとの入力は半分ですが、バッチ全体は120 × 2,000 = 240,000から100 × 1,000 + 40 × 2,000 = 180,000トークンへ変わり、削減は25%です。再試行が削減の一部を相殺し、費用は1.200から1.170にしか変わらず、初回失敗は20から40へ増えます。遅延や修正負担が許容できなければ戻します。

振り分けはこの例の費用を下げますが、初回失敗は28件になります。顧客が明示的に承認した複数モデルのアプリ戦略に限り、Corebyteが購入済みモデルを置き換える意味ではありません。無断で低価格モデルへ切り替えず、実モデル、振り分け理由、フォールバックを記録します。境界的なタスクを含む同じサンプルで分類と移行を検証します。

使用量と請求が一致しない場合の診断

  1. アカウント／プロジェクト、正確なモデルと版、地域と経路、通貨、請求期間、タイムゾーンをそろえます。暫定使用量と確定請求を分けます。

  2. タスクに各試行と提供元リクエストIDを結び付けます。SDK・アプリの再試行、タイムアウト後の再送、ストリーム切断を調べます。1クリックでも複数回課金され得ます。不明結果は照合待ちにし、二重計上や除外を避けます。

  3. 提供元フィールドで入力、出力、キャッシュ読書き、推論／ツール分類と単位を合わせます。総入力にキャッシュが含まれれば再加算しません。トークン、百万トークン、秒、容量時間を別々に換算します。

  4. 請求期間に集計し、計上遅延、パッケージ控除、割引／返金、税、別契約のサービス費を照合します。証拠のない差額を推測の実効単価で消しません。

  5. 差額の大きい順に、未対応費用、重複、計量分類、単価条件を調べます。秘匿化したID、使用量、時刻、請求行を残し、認証情報、完全なプロンプト、顧客文書は原則保存しません。

再利用できる照合チェックリスト

  • task_id、attempt_id、提供元ID、モデル／版、経路、開始終了、技術状態、検収結果を記録する。
  • 元の単位を保持し、モデル、検索、ツール、実行、人件費を出典と配賦ルール付きで分ける。
  • 同じサンプルで費用、検収率、再試行、全体遅延、人による修正を比べる。
  • 出力、ループ、再試行、並列度を制限し、割当不足、タイムアウト、不明結果を定義する。費用通知は実際のレート制限ではない。
  • モデル、キャッシュ、処理変更後に再照合する。サンプルと請求証拠なしに固定削減率を約束しない。

実価格と分類はAmazon Bedrock の料金または利用する提供元の現行条件を確認してください。仮の数値は計算と診断方法の説明専用です。