필사 모드: AI 推論エンジン 2026 完全ガイド - vLLM · SGLang · llama.cpp · TGI · TensorRT-LLM · MLX · mistral.rs · DeepSpeed-MII · Aphrodite 徹底解剖

プロローグ — 2026 年、推論は学習より高い

2023 年の LLM エンジニアリングは「どのモデルを使うか」だった。2026 年の LLM エンジニアリングは **「そのモデルをどう配るか」** に移った。

理由はシンプルだ。学習は一度だが、**推論は毎リクエスト発生する。** 同じ Llama 4 405B を回しても、エンジン次第でトークン当たりコストは 5〜10 倍違う。H100 を一枚使いこなすチームとそうでないチームのスループットは 30 倍以上差がつく。

> **GPU は高い。使い方を間違えればさらに高い。** 推論エンジンが GPU の ROI を決める。

本稿は 2026 年 5 月時点の推論エンジン地図を **解剖** する。vLLM、SGLang、TensorRT-LLM、TGI、llama.cpp、MLX、mistral.rs、DeepSpeed-MII、Aphrodite、CTranslate2、ExLlamaV3、OpenVINO、AWS Neuron、Triton — そしてその底で動く PagedAttention、Continuous Batching、Speculative Decoding、Disaggregated Inference、KV 量子化のような技術。最後に日韓の推論インフラとセルフホスト ROI を扱う。

1 章 · なぜ推論が 2026 年の戦場なのか

2024 年、OpenAI の推論コストは学習コストの約 3 倍だったと報じられている。2026 年その差はさらに広がった。学習は一度だが、推論は永遠だ。

**推論コストを決める 4 因子:**

| 因子 | 意味 | 影響 |

| --- | --- | --- |

| TTFT (Time To First Token) | 最初のトークンまでの時間 | UX、対話アプリ必須 |

| TPS (Tokens Per Second) | 秒当たり出力トークン | 体感の生成速度 |

| Throughput | 同時並行のトークン処理量 | GPU 当たりの容量、単価 |

| Latency P99 | 99 パーセンタイル応答時間 | テール遅延、SLA |

エンジン選びはこの 4 因子の **トレードオフ** だ。スループットを上げれば P99 が崩れ、TTFT を下げれば TPS が落ちる。**推論エンジンの本質は、どのワークロード向けにどのトレードオフを最適化するかにある。**

+--------------------------------------------+

| スループット ----> vLLM, SGLang |

| 最低 TTFT ----> TensorRT-LLM |

| ローカル/CPU ----> llama.cpp |

| Apple Silicon ----> MLX-LM |

| エッジ/量子化 ----> Aphrodite |

| 本番ラッパー ----> Triton, TGI |

| サーバレス API ----> Together, Fireworks |

+--------------------------------------------+

2 章 · PagedAttention と Continuous Batching — すべての出発点

推論の世界は vLLM の 2023 年 SOSP 論文 (Kwon ほか「Efficient Memory Management for Large Language Model Serving with PagedAttention」) の前後で分かれた。

**問題:** KV キャッシュはシーケンスごとに可変長。連続メモリを事前確保すると 30〜80 パーセントが無駄になる (断片化)。短いリクエストと長いリクエストが混ざるとさらに悪化する。

**解:** OS の仮想メモリ同様、KV キャッシュを固定サイズページに切り、ページテーブルで写像する。断片化はほぼゼロに。

旧方式: PagedAttention:

[KKKK_____] (50% ロス) [P1][P2][P3] (ページテーブル)

[KKK______] (60% ロス) [P4][P5] (必要時のみ確保)

[KKKKKKKK_] (10% ロス)

これに **Continuous Batching** (Orca 論文、2022) が乗る。従来の静的バッチはバッチ内の全リクエストが終わるまで待つ。継続バッチはトークン単位で新リクエストを差し込む — GPU は一瞬たりとも遊ばない。

**この 2 つは 2026 年のあらゆる本気の推論エンジンの前提だ。** これ無しには始まらない。

3 章 · vLLM — 事実上の標準

[vLLM](https://github.com/vllm-project/vllm) は 2023 年に UC Berkeley Sky Computing Lab で始まり、2026 年にはオープンソース推論のデフォルトになった。2025 年にガバナンスは LF AI & Data Foundation へ移行。

**vLLM V1 エンジン (0.7+):** 2025 年公開の V1 は V0 より 1.5〜2 倍速く、非同期スケジューラ、Chunked Prefill、torch.compile 統合、マルチモーダル既定サポートを備える。

主な機能:

| 機能 | 説明 |

| --- | --- |

| Prefix Caching | 共有プロンプトの KV キャッシュ — システムプロンプト再利用で TTFT を 90 パーセント削減 |

| Speculative Decoding | Draft モデルや EAGLE-3 でデコード 2〜3 倍加速 |

| Chunked Prefill | 長いプロンプトをチャンクに分けデコードとインターリーブ — P99 安定 |

| Tensor Parallelism | 1 モデルを複数 GPU に分割 (NVLink 推奨) |

| Pipeline Parallelism | レイヤを GPU 間で分割 — ノード跨ぎ可 |

| Multi-LoRA | 複数 LoRA を同時にサーブ |

| Structured Output | xgrammar / outlines 統合 |

| Guided Decoding | JSON Schema、正規表現、文脈自由文法 |

サポートモデル: Llama 3.x と 4、Qwen 3、Mistral、DeepSeek V3 / R1、Gemma 3、Phi-4、Mixtral、Command-R、GPT-OSS、Granite など 100 以上。

典型スループット (H100 80GB、Llama 3.1 8B FP16):

- vLLM V1: 約 6,000〜8,000 tok/s (バッチ、短系列)。

- 単一リクエスト デコード: 約 130 tok/s。

4 章 · SGLang — Prefix と Structured Output に強い

[SGLang](https://github.com/sgl-project/sglang) は 2024 年に LMSYS Org が発表し、2026 年の 0.4 で V1 vLLM と真っ向勝負する。

**主要機能:**

- **RadixAttention** — KV キャッシュを木構造で持ち、プレフィックス共有を自動化。システムプロンプトや few-shot が多いワークロードでは vLLM Prefix Caching より速い。

- **Structured Output** — `regex`、`JSON Schema`、`EBNF`、`Choice`、`gen()` DSL を一級市民として扱う。xgrammar 統合でほぼ無償。

- **OpenAI 互換サーバ** — `/v1/chat/completions` 互換に加え `/generate` 拡張。

- **DP Attention** — データパラレル アテンション、DeepSeek V3 MLA 向け最適化。

- **Day-0 モデル対応** — Llama 4、DeepSeek R1、Qwen 3 を発表当日にサポートするのが習慣。

SGLang は特に **エージェント・RAG のようにプレフィックスが多く重なるワークロード** で光る。Anthropic の Claude API も内部で SGLang 風のツリーキャッシュを使うと噂される (未確認だが構造は酷似)。

5 章 · TensorRT-LLM — Blackwell・H100 の絶対王者

[TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM) は NVIDIA 自身が作る (ライブラリ自体は Apache 2.0 だが NIM や Triton 統合は NVIDIA 商用) 推論エンジン。

**速い理由:**

- TensorRT ランタイムをベースに、モデルをエンジン (plan) ファイルへコンパイル。

- CUDA カーネルを H100、H200、B100、B200 向けに手作業で最適化。

- FP8 (Hopper)、FP4 (Blackwell) のネイティブ対応。

- In-flight batching、Paged KV、Speculative Decoding (Medusa、EAGLE)。

**スループット ベンチマーク (Llama 3.1 70B、H100×8 FP8):**

- TensorRT-LLM: 約 13,000〜15,000 tok/s。

- vLLM: 約 9,000〜11,000 tok/s。

差はワークロードとモデルにより ±30 パーセント振れる。Blackwell では FP4 で差が広がる。

**欠点:** エンジンビルドが重く (モデル・系列長・バッチごとに再コンパイル)、デバッグが難しく、モデル追加は NVIDIA のロードマップに縛られる。**NIM (NVIDIA Inference Microservices)** にパッケージしてコンテナで配るのが定石。

6 章 · Hugging Face TGI 3.x — Rust で書き直された

[Text Generation Inference](https://github.com/huggingface/text-generation-inference) (TGI) は HF 公式推論サーバ。HF Inference Endpoints の裏側。

**TGI 3.x (2025〜2026) の変化:**

- ルータとランチャは Rust、モデル実行は PyTorch。

- vLLM・TensorRT-LLM バックエンド選択可 — TGI は「フロントエンド + ルーティング + マルチバックエンド オーケストレーション」へ進化中。

- **3.0 単一 GPU 長文脈**: Llama 3 70B の 32K 文脈で vLLM の 13 倍速いと HF が主張 (HF ブログ、2024-12)。

- gRPC、REST、Messages API。

- Prefix Caching、Flash Attention 2 / 3、Paged KV を既定で。

強みは **HF エコシステム統合** — `transformers`、`datasets`、AutoTrain と滑らかにつながる。弱点は絶対スループットでは vLLM や SGLang にやや劣る点。

7 章 · llama.cpp — 一人が築いた宇宙

[llama.cpp](https://github.com/ggml-org/llama.cpp) は Georgi Gerganov が 2023 年に始めた純 C/C++ 推論エンジン。依存ゼロ、どこでもビルド可能。

**圧倒的に人気な理由:**

- CPU だけで 4 ビット量子化モデルが動く。M2/M3/M4 Mac、Raspberry Pi、Android、iOS、WASM でも。

- **GGUF 形式** — メタデータ、重み、トークナイザ、チャットテンプレートを 1 ファイルに詰める。2026 年のデファクト標準。

- バックエンド: CPU (AVX2、AVX-512、NEON)、CUDA、Metal (Apple)、Vulkan、SYCL (Intel GPU)、HIP (AMD)、Kompute。

- 量子化: Q2_K 〜 Q8_0、importance-aware の IQ1_S 〜 IQ4_XS、K-quants。

- **ggml** — バックエンドのテンソルライブラリ、llama.cpp の心臓。

**限界:** 単一 GPU の Prefill は vLLM より遅く、Continuous Batching は後発実装 (`-cb`)。それでも **ローカル推論 = llama.cpp** という式は揺るがない。

`Ollama`、`LM Studio`、`Jan`、`GPT4All`、`Kobold.cpp`、`text-generation-webui` の大半が裏で llama.cpp を使う。

8 章 · MLX と MLX-LM — Apple Silicon の答え

[MLX](https://github.com/ml-explore/mlx) は Apple 純正の PyTorch 代替。**ユニファイドメモリ** を一級市民として扱う — CPU と GPU が同じメモリを見る。

**MLX の特徴:**

- 遅延評価 + 動的グラフ。

- M シリーズの Neural Engine、Metal、CPU を自動ルーティング。

- NumPy 互換 API、PyTorch 風 `nn.Module`。

**MLX-LM:** [mlx-lm](https://github.com/ml-explore/mlx-lm) は Hugging Face Transformers 風インターフェースで LLM を動かし、学習・ファインチューニングまでサポート。

**重要性:** M3 Ultra Mac Studio 512GB なら Llama 3.1 405B を 4 ビットで動かせる。1 台で。H100 8 枚必要なモデルがデスクトップ 1 台に。スループットは H100 の 1/5 〜 1/10 だが、**ローカル推論市場では Apple が NVIDIA の唯一の競合だ。**

比較: llama.cpp Metal vs MLX-LM

- llama.cpp Metal: 安定、量子化多様、GGUF。

- MLX-LM: Prefill 速い、学習可、MLX 量子化 (4・8 ビット)。

9 章 · mistral.rs — Rust で書かれたマルチモデル エンジン

[mistral.rs](https://github.com/EricLBuehler/mistral.rs) は Eric Buehler の個人プロジェクトから始まり、2026 年には真面目な選択肢になった。

**特徴:**

- 純 Rust、candle / burn ベース。

- 量子化: GGUF、GGML、ISQ (in-situ quantization、ロード時量子化)。

- 複数モデルの同時サーブ (マルチアダプタ)。

- 視覚モデル対応 (LLaVA、Phi Vision、Llama 3.2 Vision、Pixtral、Qwen2-VL)。

- OpenAI API 互換。

- CUDA、Metal、Accelerate、MKL バックエンド。

**なぜ Rust か:** メモリ安全性、GC 無し、コンテナイメージが小さい (数十 MB)、コールドスタート高速。**サーバレス推論** に向く。

llama.cpp と vLLM の中間 — llama.cpp ほど軽くないが GPU 上で量子化モデルを効率良く回し、vLLM ほど重くもない。

10 章 · DeepSpeed-MII と DeepSpeed Inference — Microsoft の回答

[DeepSpeed-MII](https://github.com/deepspeedai/DeepSpeed-MII) は Microsoft DeepSpeed チームのモデル推論ライブラリ。

**主要機能:**

- **Blocked KV Cache** (vLLM の PagedAttention に類似)。

- **Continuous Batching** + Dynamic SplitFuse — 長プロンプトをトークン単位で分割しデコードとインターリーブ。

- **Tensor Parallelism** — DeepSpeed Inference の中核。

- **ZeRO-Inference** — KV と重みを CPU や NVMe へオフロード。大きいモデルを小さい GPU に押し込む。

**面白い理由:** DeepSpeed は学習フレームワークから始まったが、MII は推論特化。Microsoft 自社 (Bing、Copilot) の推論の一部に MII を使うとの報告がある。

弱点は vLLM や SGLang に比べモデル対応の幅が狭く、開発速度がやや遅いこと。

11 章 · Aphrodite Engine — 量子化フレンドリーな vLLM フォーク

[Aphrodite Engine](https://github.com/aphrodite-engine/aphrodite-engine) は PygmalionAI が vLLM をフォークし、量子化に寄せて改造したエンジン。

**Aphrodite と vLLM の違い:**

- **全量子化フォーマット対応**: GPTQ、AWQ、EXL2、GGUF、SqueezeLLM、Marlin、FP8、FP6、FP5、FP4、AQLM、HQQ。

- 旧 GPU 対応がより良い (Turing / Volta まで)。

- 量子化モデル上の LoRA。

- 追加のデコード サンプラ (DRY、Mirostat、XTC、Smoothing) — キャラチャット ワークロード向け。

**ユーザ層:** ローカルホスト コミュニティ、キャラクター AI サイト、量子化モデルを本気で配るチーム。vLLM がメインストリームなら、Aphrodite は量子化専門店。

12 章 · CTranslate2、ExLlamaV3、OpenVINO — 特殊用途エンジン

**CTranslate2** ([ctranslate2](https://github.com/OpenNMT/CTranslate2)) — OpenNMT チームの C++ エンジン。NMT (翻訳) と Transformer モデル特化。CPU で非常に速く、INT8 / INT16 量子化が強い。`faster-whisper` (高速 Whisper) は CTranslate2 上に作られている。

**ExLlamaV3** ([exllamav3](https://github.com/turboderp-org/exllamav3)) — turboderp の NVIDIA Turing 以降向け最適化エンジン。EXL3 量子化形式が EXL2 を継ぐ。4 ビット モデルを最小メモリに押し込むのが得意。text-generation-webui の既定バックエンドの一つ。

**OpenVINO** ([openvino](https://github.com/openvinotoolkit/openvino)) + **Intel Neural Compressor** — Intel CPU / GPU / NPU 推論。Intel Arc や Core Ultra の NPU を活用。ONNX 変換、INT8 / INT4 量子化。データセンター Xeon や Lunar Lake ノートで LLM を回したい場合に。

**AWS Inferentia + Neuron SDK** — AWS 推論専用チップ Inf2 / Trn2。**Neuron SDK** が PyTorch モデルをコンパイルし Inferentia 上で実行。Llama 3 405B のような大モデルも Trn2 UltraServer で配れる。SageMaker 統合。AWS 環境では GPU よりコスト・消費電力で勝つ場面がある。

13 章 · Triton Inference Server — 本番ラッパー

[Triton](https://github.com/triton-inference-server/server) は NVIDIA 汎用推論サーバ。LLM 専用ではなく **あらゆるモデル (CNN、BERT、XGBoost、TensorRT-LLM、vLLM)** を 1 インターフェースで配る。

**Triton の役割:**

- **バックエンド抽象** — TensorRT-LLM、vLLM、ONNX、Python、PyTorch を同じ Triton 上で。

- **モデル アンサンブル** — トークナイザ→モデル→後処理をパイプラインで。

- **動的バッチング** — モデル単位のバッチング ポリシ。

- **メトリクス** (Prometheus、OpenTelemetry)。

- **A/B テスト、カナリア、モデル バージョニング**。

NVIDIA NIM は事実上「Triton + TensorRT-LLM + コンテナ + Helm chart」のパッケージ。

14 章 · 量子化フォーマット動物園

エンジン選定は **量子化フォーマット対応** と切り離せない。

| フォーマット | ビット | 主要エンジン | 特徴 |

| --- | --- | --- | --- |

| FP16 / BF16 | 16 | すべて | 基準、損失ほぼ無し |

| FP8 (E4M3 / E5M2) | 8 | TensorRT-LLM、vLLM | H100 / H200 ネイティブ |

| FP4 (E2M1) | 4 | TensorRT-LLM (Blackwell) | B100 / B200 ネイティブ |

| MXFP4 | 4 | TensorRT-LLM | マイクロブロック FP4 |

| GGUF | 2〜8 | llama.cpp、mistral.rs、Aphrodite | ローカル標準 |

| GPTQ | 4 | vLLM、TGI、Aphrodite | キャリブレーション基盤、速い |

| AWQ | 4 | vLLM、TGI、Aphrodite | activation-aware、正確 |

| EXL2 / EXL3 | 1.5〜8 | ExLlama | 可変ビット、NVIDIA 専用 |

| EETQ | 4 | TGI | テンソル単位 INT4 |

| BitNet 1.58 | 1.58 | bitnet.cpp | 三値 (-1, 0, 1) |

| HQQ | 2〜8 | Aphrodite、transformers | キャリブレーション不要 |

| AQLM | 2 | Aphrodite | 2 ビット極限圧縮 |

**経験則:** Llama 3 70B を 4 ビット量子化すれば約 40GB → 約 20GB。RTX 3090 (24GB) 一枚に収まる。5 ビットだと 25GB で入らない。**VRAM 上限を見て量子化を決める。**

15 章 · KV キャッシュ管理 — 二つ目のメモリ戦争

KV キャッシュは重みの次にメモリを食う。Llama 3 70B 文脈 128K で KV だけ約 40GB。

**KV 量子化技法:**

| 技法 | 説明 |

| --- | --- |

| FP8 KV | KV を FP8 で保存 — vLLM、TensorRT-LLM の既定 |

| INT8 KV | より積極的な圧縮、わずかな損失 |

| KIVI | 2 ビット非対称 KV — 学術寄り |

| Quantized KV (vLLM) | `kv_cache_dtype=fp8_e4m3` 指定 |

| Paged KV | PagedAttention による断片化除去 (2 章) |

| Prefix Cache | 共有プレフィックスの KV 再利用 |

| Sliding Window | 窓外トークンの KV 廃棄 (Mistral 他) |

| Compressed | H2O、SnapKV による重要トークン選別 |

2026 年に推論コストを本気で下げるなら **FP8 KV + Prefix Cache + Sliding Window** は実質必須。

16 章 · Speculative Decoding — デコードを 2〜3 倍に

デコード段はメモリ律速 — GPU 演算は余る。**Speculative Decoding** はこの余剰を活かす。

**発想:** 小さな「ドラフト」モデルが N トークンを高速に推測 → 大きな「ターゲット」モデルが N トークンを 1 回で検証 → 一致部分を採用、不一致は破棄。

**主要バリエーション:**

| 方式 | 説明 | 加速 |

| --- | --- | --- |

| Draft + Target | 別の小モデル (Llama 3 8B + Llama 3 70B など) | 2〜3 倍 |

| Medusa | モデルに複数の LM ヘッド | 2 倍 |

| EAGLE / EAGLE-2 / EAGLE-3 | 特徴量レベルのドラフト、採用率向上 | 3〜4 倍 |

| Lookahead | n-gram ベースの self-speculation | 1.5〜2 倍 |

| Prompt Lookup | 入力からトークン引き写し | コード・要約で強い |

| ReDrafter | NVIDIA の RNN ドラフト | 2〜3 倍 |

vLLM、SGLang、TensorRT-LLM のいずれも EAGLE-3 を 2025〜2026 でサポート。採用率 80 パーセント以上ならデコードは 3 倍近く速くなる。

17 章 · Disaggregated Inference — Prefill と Decode を分離せよ

2024〜2026 年で最大のアーキ変化。

**問題:** Prefill は compute-bound、Decode は memory-bound。同じ GPU で混ぜると両方非効率。継続バッチである程度緩和されるが P99 は揺らぐ。

**解:** **Prefill クラスタ** と **Decode クラスタ** を物理分離。Prefill GPU が KV を作り、高速ネットワーク (RDMA / NVLink / InfiniBand) で Decode GPU へ送る。Decode GPU はデコードに専念。

**代表システム:**

- **Mooncake** (Moonshot AI / Kimi) — KV キャッシュを分散キャッシュとして分離。

- **Splitwise** (Microsoft Research) — Hopper と Ampere を役割別に混在運用。

- **vLLM Disaggregated Prefill** — V1 で実験サポート。

- **NVIDIA Dynamo** (2025) — NVIDIA の disaggregated 配信フレームワーク。

**なぜ価値があるか:** Prefill GPU は H100、Decode GPU は安価な L40S / A10 を使える。**ワークロードに合わせて GPU 種別を混ぜられる。** 大規模運用で 30〜50 パーセントのコスト削減が報告される。

18 章 · NVIDIA NIM、Triton、Dynamo — エンタープライズ スタック

**NIM (NVIDIA Inference Microservices)**: 事実上「TensorRT-LLM + Triton + モデル重み」を 1 コンテナにパッケージ。1 行の `docker run` で OpenAI 互換サーバが立つ。NVIDIA AI Enterprise ライセンス必要。Azure、AWS、GCP マーケットプレイスに掲載。

**NVIDIA Dynamo (2025)**: Triton の次世代。Disaggregated inference、KV キャッシュ ルーティング、GPU プール管理を一級市民に。Apache 2.0 のオープンソース。

**重要性:** エンタープライズ顧客が「Llama 4 を当社の H100 クラスタへ」と言えば、回答はたいてい NIM。素の vLLM 運用を望まないケースが多い。

19 章 · Ollama、LM Studio、Jan — デスクトップ推論

**Ollama** ([ollama](https://github.com/ollama/ollama)) — Go 製の llama.cpp ラッパ。`ollama run llama4` 一行でダウンロード + 実行。macOS、Linux、Windows のデスクトップで最大級の人気。モデル レジストリは `ollama.com`。

**LM Studio** — Electron GUI、llama.cpp + MLX バックエンド。一般ユーザ向け、OpenAI 互換サーバ内蔵。

**Jan** — 完全オープンソースの ChatGPT 代替、llama.cpp / Tabby / リモート API バックエンド。プライバシ重視。

**GPT4All、Kobold.cpp、text-generation-webui** — それぞれカテゴリ (個人、キャラ、研究) を持つ。

**共通項:** ほぼ全て裏で llama.cpp か MLX。差別化は GUI、モデル管理、チャット UI。

20 章 · 代替ハード — Groq、Cerebras、SambaNova

NVIDIA 独占を破ろうとする面々。2026 年に意味あるスループットを出している:

**Groq LPU** ([groq.com](https://groq.com)) — Language Processing Unit。14MB SRAM がチップ内部、HBM 無し。結果: **Llama 3 70B 単一ストリーム デコードで約 500 tok/s。** NVIDIA の 5〜10 倍。弱点は文脈長制限とモデルプールの狭さ。

**Cerebras CS-3** ([cerebras.ai](https://cerebras.ai)) — ウエハ 1 枚がチップ 1 個。85 万 AI コア。Llama 3 70B で約 450 tok/s。API 専用アクセス。

**SambaNova SN40L** ([sambanova.ai](https://sambanova.ai)) — Reconfigurable Dataflow Unit。Llama 3.1 405B を単一ノードで配信可能。API とオンプレ アプライアンス。

これらは **速度が絶対価値であるワークロード** (リアルタイム音声、コード補完、多段エージェント) で NVIDIA に勝つ。単位スループット当たりコストは依然 NVIDIA 優位。

21 章 · 推論 API 価格 — セルフホスト判断ライン

セルフホスト vs API の分岐点で価格が決め手。2026 年 5 月のおおよその単価 (USD per million tokens、出力基準):

| 提供者 | モデル | 価格帯 |

| --- | --- | --- |

| Together.ai | Llama 3.1 70B | 約 0.88/M |

| Fireworks | Llama 3.1 70B | 約 0.90/M |

| DeepInfra | Llama 3.1 70B | 約 0.60/M |

| Replicate | Llama 3.1 70B | 約 2.75/M |

| Anyscale | Llama 3.1 70B | 約 1.00/M |

| Groq | Llama 3 70B | 約 0.79/M (速度プレミアム) |

| SambaNova | Llama 3.1 405B | 約 5/M |

| AWS Bedrock | Claude 3.5 Sonnet | 約 15/M (参考) |

(価格表記は MDX の LaTeX 解釈との衝突を避けるため、ドル記号と数字のペアを避けて「約 0.88/M」と書いている。)

**セルフホストが安くなる条件:** 日平均負荷が GPU 容量の 30 パーセント以上かつ 24/7 稼働。それ未満なら API がほぼ常に安い。

22 章 · セルフホスト ROI — H100 と H200

おおよその数値 (北米相場、2026 年 5 月):

- H100 80GB 年契約: 約 25,000〜32,000 / 年 (ボリューム前)。

- H200 141GB 年契約: 約 35,000〜45,000 / 年。

- B200: 約 60,000〜80,000 / 年 (供給細い)。

**Llama 3.1 70B FP8 を H100 × 4 で vLLM 配信と仮定:**

- スループット: 持続約 9,000 tok/s。

- 日量トークン: 約 7.8 億 tok。

- 月量トークン: 約 230 億 tok = 23,000M。

- 月コスト (4 × H100 × 730h × 約 3.5/h): 約 10,000。

- トークン単価: 約 0.43/M。

同じワークロードを API で買えば (Llama 3.1 70B at 約 0.88/M): 23,000M × 約 0.88 = 約 20,000 / 月。**セルフホストは半額。**

ただしこの計算は GPU が 24/7 フル稼働の前提。稼働率 50 パーセントなら優位は消える。

**H200 / B200 の効果:** HBM が 96GB → 141GB → 192GB と増えることで、より大きいモデルをより少ないノードで配信。KV も多く乗りスループットは 1.3〜1.8 倍。単価はさらに下がる。

23 章 · 韓国の推論インフラ

**Naver Cloud HyperCLOVA X Inference** — 自社モデル HyperCLOVA X の社内外推論。自社データセンター (春川、世宗) で H100 / H200 クラスタを運用。2025 年から外部 API 公開 (Naver Cloud Platform)。

**Kakao i Cloud** — Kakao の LLM インフラ。韓国語特化 LLM 推論とマルチモーダル (KoCLIP、KaLM)。

**Upstage** ([upstage.ai](https://www.upstage.ai)) — Solar モデル シリーズ、**Predibase** 提携でファインチューニング + 配信、**AWS Foundry** 認定の韓国企業。Document AI ワークフローに強い。

**Lablup Backend.AI** ([lablup.com](https://www.lablup.com)) — GPU クラスタ管理 + 推論配信プラットフォーム。vLLM / TGI / Triton を GUI で運用。政府・大企業のオンプレ GPU クラスタに多数導入。

**KT Cloud GPU Farm** — 5G + AI 統合、NVIDIA H100 クラスタ。

**SK Telecom AI Pyramid** — 自社 LLM「A.X」推論、日本の楽天など海外と提携。

**42dot** — 現代自動車グループの自動運転 + LLM、自前 GPU インフラ。

24 章 · 日本の推論インフラ

**Sakana AI** ([sakana.ai](https://sakana.ai)) — 東京拠点の AI スタートアップ。Evolutionary Model Merging で小モデル群を結合。自社推論サービスを提供。

**Preferred Networks (PFN)** ([preferred.jp](https://www.preferred.jp)) — MN-Core アクセラレータを自社開発、PLaMo 日本語 LLM シリーズ、自社データセンターで推論。

**SoftBank** — Stargate Japan データセンターに NVIDIA GPU を大量投資、Cristal Intelligence (OpenAI 提携) の推論ワークロード。

**Rakuten** — Rakuten AI 2.0 (Mixtral ベース)、Mistral と提携、AWS Inferentia / Trainium を活用。

**LINE Yahoo** — 日本最大級のメッセンジャ、Yahoo 検索 + AI で自社 LLM 推論 (Llama ベース + 自社学習) を運用。

**NTT** — tsuzumi モデル (1B〜10B、日本語効率) を自社クラウドで推論提供。

25 章 · ワークロード別エンジン選定ガイド

| ワークロード | 推奨エンジン | 理由 |

| --- | --- | --- |

| 一般チャットボット (OSS 70B) | vLLM | 標準、確実に動く |

| エージェント・RAG (長 prefix) | SGLang | RadixAttention ツリーキャッシュ |

| 最低 TTFT (音声・リアルタイム) | TensorRT-LLM か Groq | コンパイル最適化 |

| Mac で開発 | MLX-LM か llama.cpp | ユニファイドメモリ |

| ローカル サーバ (RTX 3090 一枚) | llama.cpp か Aphrodite | 4 ビット量子化 |

| 大モデル + 少 GPU | DeepSpeed-MII + ZeRO Inference | NVMe オフロード |

| HF エコシステム統合 | TGI | Inference Endpoints と同等 |

| マルチモデル + A/B テスト | Triton + vLLM | アンサンブル・バージョニング |

| Apple Silicon (個人) | Ollama (llama.cpp) | 一番簡単 |

| 量子化多様性 | Aphrodite | 全フォーマット |

| クラウド サーバレス | Together.ai か Fireworks | API |

| AWS 環境 | Bedrock か Inferentia | Neuron SDK |

| 絶対速度 | Groq か Cerebras | 専用ハード |

| 日本語 | NTT tsuzumi か PLaMo | トークナイザ |

| 韓国語 | HyperCLOVA X か Solar | トークナイザ |

26 章 · 結論 — エンジンはワークロードが決める

2026 年 5 月の結論は明快だ:

1. **唯一の正解エンジンは無い。** ワークロードがエンジンを選ぶ。

2. **vLLM は安全な既定値。** どこでも動き、最大のコミュニティ。SGLang は prefix が多い時、TensorRT-LLM は絶対スループットが要る時。

3. **ローカル = llama.cpp か MLX。** 他に選択肢は無い。

4. **量子化は必須。** FP16 で 70B を配る時代は終わった。

5. **KV 管理・Speculative Decoding・Disaggregation** がコストを決める。モデル選び以上に。

6. **セルフホスト ROI は稼働率次第。** 30 パーセント未満なら API が答え。

7. **非 NVIDIA の代替** (Groq、Cerebras、AWS Inferentia、Apple Silicon) がやっと意味あるシェアを持ち始めた。

次の一手: ワークロード計測 → 候補エンジン 3 つベンチ → P99 とコストを SLA 内に → 運用開始。推測でなく計測。

27 章 · 参考資料

- vLLM: https://github.com/vllm-project/vllm

- vLLM 論文 (PagedAttention, SOSP 2023): https://arxiv.org/abs/2309.06180

- SGLang: https://github.com/sgl-project/sglang

- SGLang ブログ (RadixAttention): https://lmsys.org/blog/2024-01-17-sglang/

- TensorRT-LLM: https://github.com/NVIDIA/TensorRT-LLM

- Hugging Face TGI: https://github.com/huggingface/text-generation-inference

- TGI 3.0 長文脈ブログ: https://huggingface.co/blog/tgi-v3-overview

- llama.cpp: https://github.com/ggml-org/llama.cpp

- ggml: https://github.com/ggml-org/ggml

- MLX: https://github.com/ml-explore/mlx

- MLX-LM: https://github.com/ml-explore/mlx-lm

- mistral.rs: https://github.com/EricLBuehler/mistral.rs

- DeepSpeed-MII: https://github.com/deepspeedai/DeepSpeed-MII

- Aphrodite Engine: https://github.com/aphrodite-engine/aphrodite-engine

- CTranslate2: https://github.com/OpenNMT/CTranslate2

- ExLlamaV3: https://github.com/turboderp-org/exllamav3

- OpenVINO: https://github.com/openvinotoolkit/openvino

- AWS Neuron SDK: https://github.com/aws-neuron/aws-neuron-sdk

- Triton Inference Server: https://github.com/triton-inference-server/server

- NVIDIA Dynamo: https://github.com/ai-dynamo/dynamo

- Mooncake 論文: https://arxiv.org/abs/2407.00079

- Splitwise 論文: https://arxiv.org/abs/2311.18677

- EAGLE-3 論文: https://arxiv.org/abs/2503.01840

- BitNet b1.58 論文: https://arxiv.org/abs/2402.17764

- Orca (continuous batching): https://www.usenix.org/conference/osdi22/presentation/yu

- Ollama: https://github.com/ollama/ollama

- LM Studio: https://lmstudio.ai

- Jan: https://github.com/janhq/jan

- Groq: https://groq.com

- Cerebras: https://cerebras.ai

- SambaNova: https://sambanova.ai

- Sakana AI: https://sakana.ai

- Preferred Networks: https://www.preferred.jp

- Upstage: https://www.upstage.ai

- Lablup Backend.AI: https://www.lablup.com