セルフホスト型LLMの100万トークン当たりコスト：再現可能なGPUコストモデル

セルフホスト型LLMの100万トークン当たりコスト：再現可能なGPUコストモデル

セルフホスト型LLMの100万トークン当たりコストを確実に計算する方法は、総負荷込みのサービングコストを、GPUの公称ピークスループットではなく、ワークロードが実際に受け入れるトークン数で割ることです。

この違いは重要です。GPUはベンチマークで優れた結果を出せても、有償時間中にアイドル状態であったり、非常に長いプロンプトを処理したり、失敗したリクエストを再試行したり、製品が却下する出力を生成したりすると、本番環境では高コストになる可能性があります。本ガイドでは、セルフホスト型LLMの100万トークン当たりコストについて、再現可能なモデル、ワークシート、計算例、およびセルフマネージドエンドポイントとマネージドAPIを公平に比較する方法を提供します。

2026年10月16日更新。以下のすべての金額とスループットは例示的な入力値であり、プロバイダーの見積もりや性能に関する主張ではありません。

セルフホスト型LLMの100万トークン当たりコストの計算式

出力トークンの観点では、次を使用します。

受け入れられた出力トークン100万件当たりのコスト =
  総負荷込みの時間当たりサービングコスト
  /（アクティブ時間帯の出力トークン/秒 × 3,600 × 有償時間稼働率 × 成功率 × 受け入れ率）
  × 1,000,000

各項目の意味は次のとおりです。

分母が重要です。セルフホスト型LLMの100万トークン当たりコストは、GPUベンチマーク当たりのコストではなく、有用な単位当たりのコストであるべきです。

二重計上しないためのルール

次の2つの測定方法のいずれかを使用します。

1. アクティブ時間帯のスループットを測定してから、有償時間稼働率を乗算します。
2. 有償時間の全区間にわたる受け入れトークン数を測定し、アイドル時間がすでに観測値に含まれているため、稼働率を1に設定します。

両方を行ってはいけません。すでにアイドル時間を含む実時間ベースのスループットに稼働率係数を適用すると、トークン当たりのLLM推論コストが実際より高く見えます。アクティブ時間帯のベンチマークから稼働率を除外すると、実際より低く見えます。

コピーして使えるGPUの100万トークン当たりコストのワークシート

モデル、ハードウェアトポロジー、リージョン、ワークロード形状ごとに、スプレッドシートへ1行ずつ記入します。短いチャットのベンチマークと、長いコンテキストを持つ本番ワークロードを混在させないでください。

このワークシートにより、セルフホスト型LLMの100万トークン当たりコストの計算を監査可能にできます。別の運用担当者が入力値を置き換え、測定時間枠を再実行し、結果を再現できる必要があります。

これは例示的な計算であり、特定のGPUの価格表ではありません。5つの入力値を測定値に置き換えることで、独自のGPUの100万トークン当たりコストを算出できます。

計算例：稼働率が結果を変える理由

仮想のエンドポイントについて、総負荷込みの時間当たりコスト$4.07と、アクティブ時間帯の出力トークン/秒900を一定に保ちます。入力値のわずかな変化によって、単位コストは大きく変わります。

ここでの教訓は、特定のアクセラレータを購入することではありません。重要なのは、セルフホスト型LLMの価格設定は運用とスループットのモデルであるという点です。メモリ、バッチ処理の余裕、そしてより多くの有用な作業を持続するための需要が十分にあれば、ノードの時間当たりコストが高くても、受け入れ済み出力当たりのコストは低くなり得ます。時間当たり料金が低くても、アイドル状態のキャパシティと再試行が分母に入ると不利になる場合があります。

ベンチマークの前にprefillとdecodeを分離する

LLMサービングは単一で均質なワークロードではありません。推論にはコンテキスト処理（prefill）フェーズと生成（decode）フェーズがあり、NVIDIAのTensorRT-LLMガイドではこれらを別個のフェーズとして明確に扱い、ワークロード固有のチューニングを重視しています。見出しに示されたtokens-per-secondの数値を代表値として扱う前に、TensorRT-LLMのパフォーマンスチューニングガイドを確認してください。

• 長いプロンプト、検索コンテキスト、大きな添付ファイルは、prefillとKVキャッシュに負荷をかけます。
• 長文の回答、コード生成、エージェントの推論は、decodeキャパシティと出力トークン当たりの時間に負荷をかけます。
• 高い同時実行性では、スケジューラの挙動、バッチ処理、キャッシュの常駐性、メモリの余裕が価格モデルの一部になります。

プロンプトと出力の分布は別々に記録してください。入力トークン20,000、出力トークン300の検索集約型アシスタントでは、出力のみの経済性では実際のボトルネックを見逃す可能性があります。入力トークン2,000、出力トークン4,000のコーディングワークフローでは、decodeが支配的になる場合があります。

厳密なセルフホスト型LLMの100万トークン当たりコストの比較では、少なくとも次の3つの視点を維持してください。

本番テレメトリから分母を測定する

ハードウェア仕様から受け入れ済みスループットを推測してはいけません。サービングスタックは、計算を再現可能にするための入力値をエクスポートする必要があります。

たとえば、vLLMは、プロンプトトークン、生成トークン、リクエスト完了数、受付拒否、キュー時間、prefill時間、decode時間、KVキャッシュ使用量、最初のトークンまでの時間、出力トークン当たりのレイテンシに関するPrometheusメトリクスを文書化しています。これらがあれば、ベンチマークから推測するのではなく、測定記録を作成できます。vLLMのメトリクスリファレンスには、現在のメトリクス名とその意味が一覧されています。

実行ごとに次の記録を取得してください。

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

ハードウェアテレメトリは有用ですが、診断用であり、単位コストの分母ではありません。NVIDIAのDCGMプロファイリングに関するドキュメントでは、アクティビティは区間平均であり、代表的なワークロードのスループットと関連付けるべきだとされています。DCGMプロファイリングメトリクスを使用して、コンピュート、メモリ帯域幅、またはインターコネクトの挙動のどれが実行を制約しているかを調査してください。単一のGPU使用率の割合を、支払い時間の稼働率の代わりに用いてはいけません。

フルロードされた分子を構築する

GPUのレンタル価格は入力値であり、答えそのものではありません。LLMサービングのコストを公平に計算するには、同じ測定期間に必要なキャパシティと運用コストを含めてください。

パイロットでは、次の2つの数値を報告してください。

GPUのみの100万トークン当たりコスト
全費用込みの受理済みトークン100万件当たりコスト

この差は誤りではなく、セルフホスト型サービスの運用コストです。これにより、セルフホスト型LLMの価格判断を監査可能にできます。

再試行と却下された出力を含める

生成トークンが自動的に有用なトークンになるわけではありません。リクエストは、タイムアウト、無効なJSONの生成、ツール呼び出しの失敗、ポリシールール違反、または品質しきい値未達の前に、プリフィルおよび部分的なデコード容量を消費する可能性があります。

プロダクトチームが再現できる受理調整を使用してください。

受理済み出力トークン =
  生成出力トークン
  × 実行成功率
  × プロダクト受理率

受理をリクエスト単位で測定する場合は、評価器のバージョン、サンプリングセット、スキーマバリデーター、人手レビューのプロトコル、またはタスク成功イベントなど、正確なルールを記録してください。ルールをバージョニングせずに変更すると、コストトレンドは意味を失います。

これが、生のトークン当たりLLM推論コストが誤解を招く可能性がある理由でもあります。スループットが30%向上しても、受理済みタスクの成功率が低下する構成は、プロダクト層ではコストが高くなる可能性があります。

同じ単位でセルフホスティングとマネージドAPIを比較する

セルフホスティングは容量を購入します。マネージドAPIは利用量を購入します。分子と分母が一致して初めて比較可能になります。

APIベンチマークが同じ単位で表されている場合は、次の損益分岐スループット確認を使用してください。

必要なアクティブウィンドウ中の出力トークン/秒 =
  全費用込みの時間当たりサービングコスト × 1,000,000
  /（受理済み出力トークン100万件当たりのマネージドAPIコスト × 3,600 × 稼働率 × 成功率 × 受理率）

決定前に、両方の選択肢で次の条件をそろえてください。

• 同一モデル、または明示的に評価された品質同等モデル。
• 同一のプロンプトおよび出力長分布。
• 同一のレイテンシSLOおよび同時実行性の形状。
• 同一の再試行、フォールバック、受理ルール。
• キャッシュヒット、ツール失敗、キャンセルされた処理についての同一の扱い。

GPUの直接制御、カスタム重み、厳格な配置、または専用カーネルスタックが要件である場合、マネージドのベースラインを上回るコストであっても、セルフホスティングが引き続き適切な選択肢となる可能性があります。トラフィックが少ないまたはバースト性が高い場合、モデルが頻繁に変わる場合、あるいはチームが推論インフラを運用したくない場合は、従量課金APIが稼働率リスクを吸収できます。

より広範な購入比較については、FlatkeyのGPUクラウドとモデルAPIのガイドおよびGPUレンタル価格ガイドをご覧ください。GPUの直接制御が不要な場合、マネージドルートは有用なベンチマークになります。Flatkeyは、単一残高で利用できる統合モデル・ツールAPIを提供しているため、チームは個別のプロバイダーキーを管理することなく、マネージド経路をセルフホスト計算と比較できます。同じテストセットと受理ルールでFlatkey APIのベースラインを開始してください。

7ステップの調達テスト

このセルフホスト型LLMの100万トークン当たりコストフレームワークは、単なるエンジニアリングベンチマークではなく、調達資料として使用してください。どのワークロード、容量、品質の前提が結果を変えたのかを正確に示す必要があります。

1. 単位を定義する：入力トークン、出力トークン、混合トークン、受理済み応答、または受理済みタスク。
2. 単一の合成プロンプトではなく、本番に近いトラフィック下でアクティブウィンドウのスループットを測定する。
3. すべての有償レプリカおよびウォームリザーブノードについて、有償時間の稼働率を測定する。
4. すべての運用コストを時間当たりの分子に加える。
5. 成功および受理ルールをバージョニングし、その後に受理済み出力を計算する。
6. 同じワークロードをマネージドAPIのベースラインで実行する。
7. 容量を予約する前に、コスト、p95レイテンシ、信頼性、品質、エンジニアリング工数をまとめてレビューする。

セルフホスト型LLMコストモデルでよくある誤り

ピークベンチマークスループットを使用すること。ピーク値は、制御されたセットアップを比較する際には有用です。しかし、それは本番環境のワークロード構成で期待されるスループットではありません。

GPU使用率を容量稼働率と呼ぶこと。GPUが稼働中であっても、有償需要に対して過剰なエンドポイントに接続されている可能性があります。ユニットエコノミクスには有償時間の稼働率を使用し、その理由の診断にはハードウェアテレメトリを使用してください。

稼働率を二重に適用すること。アクティブウィンドウのスループットと稼働率を選ぶか、すでにアイドル時間を含む実時間ベースのスループットを選んでください。

プロンプトトークンを無視すること。 製品が主に出力に対して課金する場合でも、長いコンテキストはプリフィルとKVキャッシュの負荷を高めます。

生成されたすべてのトークンが受け入れられたとみなすこと。 再試行、無効なツール引数、スキーマ失敗、品質上の却下は、いずれもコストが発生する作業です。

GPU請求額をAPIの定価だけと比較すること。 エンジニアリング、サポート、ストレージ、ネットワーク、可観測性、ウォームキャパシティも、同じ計算に含める必要があります。

完全な判断材料（セルフホスティングが採算に合うタイミング、GPUメモリのサイジング、ツール、段階的なサーバーセットアップ）については、当社のセルフホスト型LLMガイドをご覧ください。

よくある質問

セルフホスト型LLMの100万トークン当たりコストはどのように計算しますか？

完全原価ベースの時間当たりサービングコストを、有償時間当たりの受け入れトークン数で割り、1,000,000を掛けます。理論上のGPUピークではなく、実測した本番相当のスループット、有償時間の稼働率、成功率、受け入れ率を使用してください。

100万トークン当たりのGPUコストは、トークン当たりのLLM推論コストと同じですか？

100万トークン当たりのGPUコストは、GPU専用のインフラストラクチャ指標になり得ます。トークン当たりのLLM推論コストには、関連する運用上の分子と明確に定義された分母を含めるべきです。製品上の意思決定には、受け入れられたレスポンスまたはタスク当たりのコストが、より安全な補完指標となることが多いです。

出力トークンと総トークンのどちらを使用すべきですか？

プロンプトと出力のコストでボトルネックが異なる場合は、両方を使用してください。生成ワークロードでは出力トークンが比較しやすく、長いコンテキストを用いる検索ワークロードでは総トークンまたは重み付きトークンの方が適切に表現できます。セルフホスティングとAPIを比較する際は、単位を同一に保ってください。

セルフホスティングはどのような場合にコスト削減になりますか？

需要が安定しており、キャパシティが高い稼働率を維持し、モデルとデプロイメントが安定していて、直接的な制御に価値がある場合は、コストを削減できる可能性が高くなります。トラフィックがバースト的である場合、モデル選定が頻繁に変わる場合、または運用オーバーヘッドがキャパシティ節約分を上回る場合は、コスト削減につながる可能性が低くなります。

結論

信頼できるセルフホスト型LLMの100万トークン当たりコストは、完全原価ベースの有償キャパシティを受け入れられたスループットで割ったものです。プリフィルとデコードを別々に測定し、アイドル時間は一度だけ計上し、受け入れルールをバージョン管理し、同じ単位でマネージドサービスのベースラインと比較してください。これにより、GPU見積もりを意思決定に使えるコストモデルへと変換できます。

技術リファレンス

• vLLM metrics reference
• NVIDIA TensorRT-LLM performance tuning guide
• NVIDIA DCGM profiling documentation