# Llama 推論コストの設計：API vs セルフホストの損益分岐をTCOで出す

> 『Llama を本番で動かすといくら？』に、感覚ではなくTCOで答える記事。Bedrock等の従量課金とセルフホスト（GPU時間×スループット）の原価式、損益分岐の出し方、モデルルーティング・量子化・バッチ・冪等キャッシュ・スポットGPUといったコスト削減レバーを、検証可能なコードと実数で解説します。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: Llama, コスト最適化, 生成AI, AWS Bedrock, FinOps, GPU, TypeScript
- URL: https://tomodahinata.com/blog/llama-inference-cost-optimization-self-host-vs-api

## 要点

- API（従量）は使った分だけ・運用ゼロ。セルフホストは GPU 時間が固定費——『動いていなくても課金される』のが本質的な違い
- 原価式：API=（入力tok×単価＋出力tok×単価）、セルフホスト=GPU時間料金÷（実効スループット×稼働率）。後者は稼働率が全てを決める
- 実数（2026年6月・要確認）：Bedrock Llama 4 Scout は $0.17/$0.66・Maverick $0.24/$0.97（入力/出力 per 1M）、H100 は概ね $1.5〜4/GPU時
- 損益分岐の目安：セルフホストが API を下回るには高く安定した稼働率が要る。少量・変動はAPI、定常・大量はセルフホストやProvisioned
- 効くレバーは ①モデルルーティング ②量子化(FP8) ③連続バッチ ④冪等キャッシュで再生成ゼロ ⑤スポットGPU。設計順に効果が大きい

---

## この記事のゴール

「Llama を本番で動かすと、結局いくらかかるの？」——案件で最初に聞かれる問いです。本稿は、これに**感覚ではなく TCO（総保有コスト）で**答えます。[Llama を本番投入する全体像](/blog/meta-llama-open-weight-llm-production-guide)の「原価」の章を、**式と実数とコードで**詰め切るのが狙いです。

読み終えたとき、次ができる状態を目指します。

1. **API とセルフホストの原価を同じ土俵で計算**できる。
2. **自社の volume で損益分岐がどこか**を、式に当てはめて出せる。
3. **どのレバーを引けば一番効くか**を、設計順に判断できる。

> **信頼性の開示**：GPU 原価は、私が[動画AIローカライズ基盤](/case-studies/ai-video-localization-lipsync)で実際に向き合った領域です。本稿の数値は**2026年6月時点の公開情報**に基づく**例**であり、料金は変動します。価値は「**式と考え方**」にあります——絶対値ではなく、自分の数字を入れて判断してください。

---

## 30秒の結論

| | API（Bedrock 等・従量） | セルフホスト（GPU を借りて自前運用） |
| --- | --- | --- |
| 課金 | **使った分だけ**（入力/出力トークン） | **GPU 時間が固定費**（動いていなくても課金） |
| 初期/運用 | ほぼゼロ | 環境構築・スケール・監視・障害対応 |
| 原価が下がる条件 | 低〜中 volume・変動が大きい | **高く安定した稼働率** |
| 向く | プロト・変動需要・少量多品種 | 定常大量・データ主権・1リクエスト単価の最小化 |

**本質はこの一行**：API は**変動費だけ**、セルフホストは**固定費（GPU時間）**。だから「**GPU をどれだけ暇させずに回せるか（稼働率）**」が、セルフホストの勝ち負けを決めます。

---

## 原価式：同じ土俵に乗せる

### API（従量）の原価

トークン単価のかけ算です。シンプルゆえに**予測しやすい**のが利点。

```text
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 時間料金**を、その時間に**実際に吐けたトークン量**で割ります。ここに**稼働率**が効きます。

```text
セルフホスト 出力1Mあたり = (GPU時間料金 × GPU台数) ÷ (実効出力スループット[tok/s] × 3600 × 稼働率 / 1e6)
```

**2026年6月時点の例（要確認）**：H100 は概ね **$1.5〜4 / GPU時**（オンデマンド中央値 ≈ $3、スポット ≈ $1〜2.5）。実効スループットは**必ず自分でベンチ**してください（モデル・量子化・バッチ・文脈長で大きく変わる）。

---

## 検証可能なコスト計算機（純粋関数）

“世界最高峰”は派手なコードではなく、**テストできる小さな純粋関数**です。副作用ゼロ・入力だけで決まるので、そのまま単体テストに載ります（[型安全の規律](/blog/typescript-type-safety-discipline-zod-nevererror-no-any)）。

```ts
// 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. モデルルーティング（一番効く）

全部を最上位モデルに通すのは**最大の無駄**。タスクの難度でモデルを振り分けます。

```ts
// 難度に応じて安いモデルへ。簡単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](/blog/vllm-llama-self-hosting-production-inference-server) を使えば、VRAM を圧縮して**同じGPUにより多くを詰め**、スループット（=分母）を上げられる。`--kv-cache-dtype fp8` は使える文脈を実質的に広げ、精度劣化は実用上小さいことが多い。

### 3. 連続バッチ（continuous batching）

vLLM の真価。**多数のリクエストを動的に束ねて GPU を遊ばせない**。これが「実効スループット」を決め、セルフホストの損益分岐を左右します。**稼働率を上げる＝原価を下げる**の本丸。

### 4. 冪等キャッシュ（再生成ゼロ）

同じ入力に同じ生成を二度走らせない。`sha256(モデル+プロンプト+パラメータ)` をキーにキャッシュするだけで、**連打・リトライ・重複依頼のコストが消える**（[ピラー記事の冪等ルート実装](/blog/meta-llama-open-weight-llm-production-guide#冪等性つきの本番ルートハンドラnextjs)）。プロンプトの定型部分には **prompt caching** も効く。

### 5. スポット/プリエンプティブル GPU

セルフホストの GPU 時間料金そのものを**半額以下**にできる。ただし中断耐性（チェックポイント・ドレイン・[リトライ設計](/blog/retry-backoff-circuit-breaker-resilience-patterns-guide)）が前提。

| レバー | 効く項 | 体感効果 | 前提 |
| --- | --- | --- | --- |
| モデルルーティング | 単価×件数 | 大 | 難度判定 |
| 量子化(FP8) | スループット | 中〜大 | 対応GPU |
| 連続バッチ | 稼働率/スループット | 大 | vLLM |
| 冪等キャッシュ | 件数 | 中 | KV/Redis |
| スポットGPU | GPU時間料金 | 中〜大 | 中断耐性 |

---

## 可観測性：測っていないものは下げられない

コスト最適化は**計測から**始まります。呼び出しごとに**入出力トークン・モデル・レイテンシ**を構造化ログへ落とし、**モデル別・用途別の単価**をダッシュボードで見える化する。これ無しの「なんとなく高い」は、改善の打ち手を持てません（[OpenTelemetry での可観測性](/blog/opentelemetry-observability-production-tracing-metrics-logs)）。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時間）——この違いを**式で**捉え、**稼働率**を主役に据えれば、「いくらかかるか」は感覚ではなく**計算**になります。

1. まず **API で品質と需要を確かめる**（変動費・運用ゼロ）。
2. **計測**してモデル別・用途別の単価を可視化する。
3. **ルーティング → 量子化 → バッチ → 冪等キャッシュ → スポット**の順に削る。
4. 稼働率が steady に高くなったら、式で**セルフホスト/Provisioned の損益分岐**を確かめて移行する。

> LLM スタックの原価設計（損益分岐の算出、ルーティング、セルフホスト移行）まで含めて伴走できます。GPU 原価に向き合った[実績](/case-studies/ai-video-localization-lipsync)をご覧のうえ、お気軽にご相談ください。**一人 × 生成AI**で、速く・安く・安全に。

### 出典・公式リソース

- [Amazon Bedrock 料金](https://aws.amazon.com/bedrock/pricing/) — Llama 各モデルの従量単価（要確認）
- [Meta's Llama in Amazon Bedrock](https://aws.amazon.com/bedrock/meta/) — モデルと提供形態
- [vLLM Blog: Llama 4](https://blog.vllm.ai/2025/04/05/llama4.html) — スループットと量子化
- クラウド GPU 料金は各プロバイダの公開価格を参照（本稿の H100 概算は2026年6月時点）

※ 料金・スループットは変動・実測依存です。本稿の数値は例であり、実装前に自社の実数で再計算してください。