この記事のゴール
「Llama を本番で動かすと、結局いくらかかるの？」——案件で最初に聞かれる問いです。本稿は、これに感覚ではなく TCO（総保有コスト）で答えます。Llama を本番投入する全体像の「原価」の章を、式と実数とコードで詰め切るのが狙いです。
読み終えたとき、次ができる状態を目指します。
- API とセルフホストの原価を同じ土俵で計算できる。
- 自社の volume で損益分岐がどこかを、式に当てはめて出せる。
- どのレバーを引けば一番効くかを、設計順に判断できる。
信頼性の開示：GPU 原価は、私が動画AIローカライズ基盤で実際に向き合った領域です。本稿の数値は2026年6月時点の公開情報に基づく例であり、料金は変動します。価値は「式と考え方」にあります——絶対値ではなく、自分の数字を入れて判断してください。
30秒の結論
| API（Bedrock 等・従量） | セルフホスト（GPU を借りて自前運用） | |
|---|---|---|
| 課金 | 使った分だけ（入力/出力トークン） | GPU 時間が固定費（動いていなくても課金） |
| 初期/運用 | ほぼゼロ | 環境構築・スケール・監視・障害対応 |
| 原価が下がる条件 | 低〜中 volume・変動が大きい | 高く安定した稼働率 |
| 向く | プロト・変動需要・少量多品種 | 定常大量・データ主権・1リクエスト単価の最小化 |
本質はこの一行：API は変動費だけ、セルフホストは固定費（GPU時間）。だから「GPU をどれだけ暇させずに回せるか（稼働率）」が、セルフホストの勝ち負けを決めます。
原価式：同じ土俵に乗せる
API（従量）の原価
トークン単価のかけ算です。シンプルゆえに予測しやすいのが利点。
APIコスト = (入力トークン / 1e6) × 入力単価 + (出力トークン / 1e6) × 出力単価
2026年6月時点の例（Amazon Bedrock・on-demand・要確認）：
| モデル | 入力 / 1M | 出力 / 1M | 位置づけ |
|---|---|---|---|
| Llama 4 Scout | $0.17 | $0.66 | 長文脈・標準 |
| Llama 4 Maverick | $0.24 | $0.97 | 高品質フラグシップ |
セルフホストの原価
固定の GPU 時間料金を、その時間に実際に吐けたトークン量で割ります。ここに稼働率が効きます。
セルフホスト 出力1Mあたり = (GPU時間料金 × GPU台数) ÷ (実効出力スループット[tok/s] × 3600 × 稼働率 / 1e6)
2026年6月時点の例（要確認）：H100 は概ね $1.5〜4 / GPU時（オンデマンド中央値 ≈ $3、スポット ≈ $1〜2.5）。実効スループットは必ず自分でベンチしてください（モデル・量子化・バッチ・文脈長で大きく変わる）。
検証可能なコスト計算機（純粋関数）
“世界最高峰”は派手なコードではなく、テストできる小さな純粋関数です。副作用ゼロ・入力だけで決まるので、そのまま単体テストに載ります（型安全の規律）。
// lib/llm-cost.ts — API とセルフホストを同じ単位($/1M出力tok)で比較する純粋関数群
export type TokenPrice = { readonly inputPer1M: number; readonly outputPer1M: number };
/** API の従量コスト（USD）。入力・出力トークンと単価から決定的に決まる。 */
export function apiCost(inputTokens: number, outputTokens: number, p: TokenPrice): number {
return (inputTokens / 1e6) * p.inputPer1M + (outputTokens / 1e6) * p.outputPer1M;
}
/** セルフホストの「出力1Mトークンあたり原価」。稼働率が全てを左右する。 */
export function selfHostCostPer1MOutput(params: {
gpuHourlyUsd: number; // 例: 3.0（H100 オンデマンド）
gpuCount: number; // 例: 2（テンソル並列）
aggOutputTokPerSec: number; // 例: 2500（要ベンチ：連続バッチ時の集約スループット）
utilization: number; // 0〜1（GPUが実際に生成に使われている割合）
}): number {
const { gpuHourlyUsd, gpuCount, aggOutputTokPerSec, utilization } = params;
const tokensPerHour = aggOutputTokPerSec * 3600 * utilization;
if (tokensPerHour <= 0) return Infinity; // 暇なGPUは原価無限大＝丸損
return (gpuHourlyUsd * gpuCount) / (tokensPerHour / 1e6);
}
/** セルフホストが API の出力単価を下回るのに必要な“損益分岐稼働率”。 */
export function breakEvenUtilization(params: {
gpuHourlyUsd: number; gpuCount: number; aggOutputTokPerSec: number; apiOutputPer1M: number;
}): number {
const fullUtilCost = selfHostCostPer1MOutput({ ...params, utilization: 1 });
return Math.min(1, fullUtilCost / params.apiOutputPer1M);
}
数字を入れてみる（例・要ベンチ）
H100×2 を $3/GPU時、集約 2,500 tok/s（連続バッチ時の仮スループット）と置くと：
- 100%稼働の出力原価 =
(3×2) ÷ (2500×3600×1.0 / 1e6)= 約 $0.67 / 1M 出力tok - Bedrock Scout の出力 $0.66 / 1M とほぼ同額——つまり 100%稼働でようやくトントン。
- 損益分岐稼働率 ≈
0.67 / 0.66≈ 1.0。スループットがもっと出る（例 5,000 tok/s）なら分岐は ~0.5 に下がる。
💡 読み解き：セルフホストは「GPU を暇させた瞬間に負ける」。24時間ほぼ満稼働で回る定常ワークロードでなければ、API（変動費だけ）の方が安いことが多い。まず API で品質と需要を確かめ、稼働が steady に高くなってからセルフホストへ——が原価の定石です。スポット（$1〜2/時）や Bedrock の Provisioned Throughput はこの分岐を動かすレバーです。
コスト削減レバー（効果の大きい順）
原価は「式のどの項を殴るか」で決まります。設計で効く順に並べます。
1. モデルルーティング（一番効く）
全部を最上位モデルに通すのは最大の無駄。タスクの難度でモデルを振り分けます。
// 難度に応じて安いモデルへ。簡単8割を安く流すだけで総額は大きく下がる。
function pickModel(task: { kind: "classify" | "extract" | "reason" }): string {
switch (task.kind) {
case "classify": return "meta/llama-3.3-8b"; // 分類・モデレーションは小型で十分
case "extract": return "meta/llama-4-scout"; // 抽出は中位
case "reason": return "meta/llama-4-maverick"; // 難所だけ上位
}
}
2. 量子化（FP8）
vLLM で FP8 を使えば、VRAM を圧縮して同じGPUにより多くを詰め、スループット（=分母）を上げられる。--kv-cache-dtype fp8 は使える文脈を実質的に広げ、精度劣化は実用上小さいことが多い。
3. 連続バッチ（continuous batching）
vLLM の真価。多数のリクエストを動的に束ねて GPU を遊ばせない。これが「実効スループット」を決め、セルフホストの損益分岐を左右します。稼働率を上げる＝原価を下げるの本丸。
4. 冪等キャッシュ（再生成ゼロ）
同じ入力に同じ生成を二度走らせない。sha256(モデル+プロンプト+パラメータ) をキーにキャッシュするだけで、連打・リトライ・重複依頼のコストが消える（ピラー記事の冪等ルート実装）。プロンプトの定型部分には prompt caching も効く。
5. スポット/プリエンプティブル GPU
セルフホストの GPU 時間料金そのものを半額以下にできる。ただし中断耐性（チェックポイント・ドレイン・リトライ設計）が前提。
| レバー | 効く項 | 体感効果 | 前提 |
|---|---|---|---|
| モデルルーティング | 単価×件数 | 大 | 難度判定 |
| 量子化(FP8) | スループット | 中〜大 | 対応GPU |
| 連続バッチ | 稼働率/スループット | 大 | vLLM |
| 冪等キャッシュ | 件数 | 中 | KV/Redis |
| スポットGPU | GPU時間料金 | 中〜大 | 中断耐性 |
可観測性：測っていないものは下げられない
コスト最適化は計測から始まります。呼び出しごとに入出力トークン・モデル・レイテンシを構造化ログへ落とし、モデル別・用途別の単価をダッシュボードで見える化する。これ無しの「なんとなく高い」は、改善の打ち手を持てません（OpenTelemetry での可観測性）。PII（プロンプト本文）は載せない——メタデータだけで原価は十分追えます。
よくある質問（FAQ）
Q. 結局、API とセルフホストどちらが安い？ A. 少量・変動が大きいなら API、定常的に大量（高い稼働率を維持できる）ならセルフホスト。境界は「GPU をどれだけ満稼働で回せるか」。本稿の式に自分のスループット実測と volume を入れて出してください。
Q. スループットは何 tok/s で計算すればいい？
A. 必ず自分でベンチしてください。モデル・量子化・バッチ・文脈長・GPU で数倍変わります。本稿の 2,500 tok/s は例です。vllm の負荷試験で実測値を取り、式に入れます。
Q. Provisioned Throughput とは？ A. Bedrock で専有スループットを時間課金で予約する方式。定常大量で従量が高くつくとき、自前GPU運用の手前の選択肢になります。「マネージドの楽さ × 大量時の単価」を両取りしたい場合に検討します。
Q. 入力トークンと出力トークン、どちらを気にすべき？
A. 一般に出力単価が高い（例：Scout は入力$0.17 / 出力$0.66）。長い生成を垂れ流さない・maxTokens を絞る・要約は簡潔にが効きます。一方で長文脈RAGは入力が膨らむので、検索で文脈を絞るのも原価対策です。
Q. 一番効く一手は？ A. モデルルーティング。簡単なタスクを安いモデルに流すだけで総額が大きく動きます。最上位モデルは“難所だけ”に使ってください。
まとめ
Llama の原価は、モデル選びより設計で決まります。API は変動費、セルフホストは固定費（GPU時間）——この違いを式で捉え、稼働率を主役に据えれば、「いくらかかるか」は感覚ではなく計算になります。
- まず API で品質と需要を確かめる（変動費・運用ゼロ）。
- 計測してモデル別・用途別の単価を可視化する。
- ルーティング → 量子化 → バッチ → 冪等キャッシュ → スポットの順に削る。
- 稼働率が steady に高くなったら、式でセルフホスト/Provisioned の損益分岐を確かめて移行する。
LLM スタックの原価設計（損益分岐の算出、ルーティング、セルフホスト移行）まで含めて伴走できます。GPU 原価に向き合った実績をご覧のうえ、お気軽にご相談ください。一人 × 生成AIで、速く・安く・安全に。
出典・公式リソース
- Amazon Bedrock 料金 — Llama 各モデルの従量単価（要確認）
- Meta's Llama in Amazon Bedrock — モデルと提供形態
- vLLM Blog: Llama 4 — スループットと量子化
- クラウド GPU 料金は各プロバイダの公開価格を参照（本稿の H100 概算は2026年6月時点）
※ 料金・スループットは変動・実測依存です。本稿の数値は例であり、実装前に自社の実数で再計算してください。