Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 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 P9999 パーセンタイル応答時間テール遅延、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 は 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 DecodingDraft モデルや EAGLE-3 でデコード 2〜3 倍加速
Chunked Prefill長いプロンプトをチャンクに分けデコードとインターリーブ — P99 安定
Tensor Parallelism1 モデルを複数 GPU に分割 (NVLink 推奨)
Pipeline Parallelismレイヤを GPU 間で分割 — ノード跨ぎ可
Multi-LoRA複数 LoRA を同時にサーブ
Structured Outputxgrammar / outlines 統合
Guided DecodingJSON 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 は 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 は 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 (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 は 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 は Apple 純正の PyTorch 代替。ユニファイドメモリ を一級市民として扱う — CPU と GPU が同じメモリを見る。

MLX の特徴:

  • 遅延評価 + 動的グラフ。
  • M シリーズの Neural Engine、Metal、CPU を自動ルーティング。
  • NumPy 互換 API、PyTorch 風 nn.Module。

MLX-LM: 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 は 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 は 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 は 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) — OpenNMT チームの C++ エンジン。NMT (翻訳) と Transformer モデル特化。CPU で非常に速く、INT8 / INT16 量子化が強い。faster-whisper (高速 Whisper) は CTranslate2 上に作られている。

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

OpenVINO (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 は 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 / BF1616すべて基準、損失ほぼ無し
FP8 (E4M3 / E5M2)8TensorRT-LLM、vLLMH100 / H200 ネイティブ
FP4 (E2M1)4TensorRT-LLM (Blackwell)B100 / B200 ネイティブ
MXFP44TensorRT-LLMマイクロブロック FP4
GGUF2〜8llama.cpp、mistral.rs、Aphroditeローカル標準
GPTQ4vLLM、TGI、Aphroditeキャリブレーション基盤、速い
AWQ4vLLM、TGI、Aphroditeactivation-aware、正確
EXL2 / EXL31.5〜8ExLlama可変ビット、NVIDIA 専用
EETQ4TGIテンソル単位 INT4
BitNet 1.581.58bitnet.cpp三値 (-1, 0, 1)
HQQ2〜8Aphrodite、transformersキャリブレーション不要
AQLM2Aphrodite2 ビット極限圧縮

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

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

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

KV 量子化技法:

技法説明
FP8 KVKV を FP8 で保存 — vLLM、TensorRT-LLM の既定
INT8 KVより積極的な圧縮、わずかな損失
KIVI2 ビット非対称 KV — 学術寄り
Quantized KV (vLLM)kv_cache_dtype=fp8_e4m3 指定
Paged KVPagedAttention による断片化除去 (2 章)
Prefix Cache共有プレフィックスの KV 再利用
Sliding Window窓外トークンの KV 廃棄 (Mistral 他)
CompressedH2O、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 倍
Lookaheadn-gram ベースの self-speculation1.5〜2 倍
Prompt Lookup入力からトークン引き写しコード・要約で強い
ReDrafterNVIDIA の 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) — 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) — Language Processing Unit。14MB SRAM がチップ内部、HBM 無し。結果: Llama 3 70B 単一ストリーム デコードで約 500 tok/s。 NVIDIA の 5〜10 倍。弱点は文脈長制限とモデルプールの狭さ。

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

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

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

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

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

提供者モデル価格帯
Together.aiLlama 3.1 70B約 0.88/M
FireworksLlama 3.1 70B約 0.90/M
DeepInfraLlama 3.1 70B約 0.60/M
ReplicateLlama 3.1 70B約 2.75/M
AnyscaleLlama 3.1 70B約 1.00/M
GroqLlama 3 70B約 0.79/M (速度プレミアム)
SambaNovaLlama 3.1 405B約 5/M
AWS BedrockClaude 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) — Solar モデル シリーズ、Predibase 提携でファインチューニング + 配信、AWS Foundry 認定の韓国企業。Document AI ワークフローに強い。

Lablup Backend.AI (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) — 東京拠点の AI スタートアップ。Evolutionary Model Merging で小モデル群を結合。自社推論サービスを提供。

Preferred Networks (PFN) (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)SGLangRadixAttention ツリーキャッシュ
最低 TTFT (音声・リアルタイム)TensorRT-LLM か Groqコンパイル最適化
Mac で開発MLX-LM か llama.cppユニファイドメモリ
ローカル サーバ (RTX 3090 一枚)llama.cpp か Aphrodite4 ビット量子化
大モデル + 少 GPUDeepSpeed-MII + ZeRO InferenceNVMe オフロード
HF エコシステム統合TGIInference Endpoints と同等
マルチモデル + A/B テストTriton + vLLMアンサンブル・バージョニング
Apple Silicon (個人)Ollama (llama.cpp)一番簡単
量子化多様性Aphrodite全フォーマット
クラウド サーバレスTogether.ai か FireworksAPI
AWS 環境Bedrock か InferentiaNeuron 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 章 · 参考資料

Discuss on Twitter • View on GitHub