LLM推論エンジン完全ガイド2026：ハードウェア別最適エンジン選択マップ
LLM推論エンジン完全ガイド2026：ハードウェア別最適エンジン選択マップ
出典: note.com / 2026-05-21
エンジンとは何か
LLM推論エンジンとは、学習済みモデルの重みを読み込み、プロンプトに対してトークンを生成するランタイムである。一見すると単なる「モデル実行プログラム」だが、その選択が実運用のすべてを決める。
同じモデル、同じハードウェアでも、エンジンが違えばスループットは10倍変わる。VRAM使用量は半分になる。レイテンシは1/5になる。
そして2026年、エンジン戦争はほぼ決着しつつある。各ハードウェアに対して「これを使え」という答えが出ている。
ワンページ判断ガイド
迷ったらこれを見ろ。
ハードウェア最適エンジン理由-------------------------------Apple Silicon (M1-M4)llama.cpp (GGUF)Metal対応、4-8bit量子化、CPU/GPU統合メモリ最適化NVIDIA A100/H100 単体vLLMPagedAttention、連続バッチ、P99レイテンシ最小NVIDIA A100/H100 複数枚TensorRT-LLMFP8/INT4量子化、in-flight batching、マルチGPU最適NVIDIA RTX 3090/4090ExLlamaV2 または llama.cpp CUDA24GB VRAMで70Bモデルの4bit量子化が現実的CPU専用 (x86)llama.cppAVX2/AVX512、4-8bit量子化で実用的な速度CPU専用 (ARM/RISC-V)llama.cppNEON/RVV対応、Raspberry Pi 5でも1-2 tok/sAMD GPU (ROCm)vLLM ROCm版PagedAttentionがROCm対応したIntel Arc GPUllama.cpp SYCL版Intel公式のIPEX-LLMもあるが成熟度はllama.cppが上Google TPUJetStream (MaxText)Google純正、TPU v5pでGemma2 27Bが最速AWS Inferentia/TrainiumNeuron SDK + vLLMAWS純正、コスト/トークン最小Apple Neural EngineMLX (CoreML経由)ANEはまだLLMに弱い。MPS優先
推論エンジンが実際にやること
表面的には「プロンプト→モデル→トークン」だが、内部では以下の最適化が走っている。
KVキャッシュ管理 生成中の各トークンのKey/Valueをキャッシュし、次のトークン生成で再計算を防ぐ。連続バッチで複数リクエストのKVキャッシュをメモリ上で共存させるかどうかで、スループットが決まる。
量子化 FP16（16bit）の重みを4bit、3bit、2bitに圧縮。精度はほぼ落ちないが、VRAM使用量は1/4〜1/8になる。GPTQ、AWQ、GGUF、EXL2、NF4など方式が乱立しているが、2026年時点で勝ち残ったのはGGUF（ローカル推論）とAWQ（サーバー推論）の二大陣営。
テンソル並列 複数GPUにモデルを分割。パイプライン並列（層ごとにGPU分割）とテンソル並列（各層の行列計算をGPU間で分割）の二段構え。vLLMとTensorRT-LLMはこれを自動でやってくれる。
投機的デコーディング 小さな「ドラフトモデル」で次のトークンを予測生成し、本命モデルで一括検証。理論上2-3倍の高速化。llama.cppとvLLMで実装済み。
コンティニュアスバッチ リクエストが来るたびにバッチを組み直す。従来のスタティックバッチ（全リクエストが終わるまで次のバッチを待つ）と違い、先に終わったリクエストのスロットに次のリクエストを即座に詰め込む。vLLMとTensorRT-LLMの最大の武器。
本当のボトルネック
速いエンジンを選んでも、別の場所で詰まる。
メモリ帯域 GPUの演算速度（FLOPS）ではなく、VRAM⇔演算器の帯域幅で決まる。H100は3.35TB/s。M2 Ultraは800GB/s。つまり、同じモデルならH100が約4倍速い。逆に言えば、M4 Max（546GB/s）でも4bit量子化すれば実用的。
プロンプト処理（Prefill） 長いプロンプトの最初のトークン生成は、プロンプト全体のAttention計算が必要で、生成の数倍の計算量。Prefill最適化（FlashAttention、PagedAttention、RadixAttention）が効くかどうかで、初動レイテンシが決まる。
トークナイザのオーバーヘッド 日本語、中国語、韓国語のマルチバイト文字はトークン効率が悪い。同じ意味の文章が英語の3-5倍のトークン数になる。2026年、これを解決する多言語トークナイザがようやく出始めた（Qwen2.5、Llama 4、Gemma 3）。
エンジンファミリー
llama.cpp ファミリー - llama.cpp: C/C++実装。CPU/Apple Siliconで最速。GGUF量子化の発明者 - Ollama: llama.cppをラップしたCLI+API。初心者向けだが中身はllama.cpp - LM Studio: GUI版。同上 - MLX-LM: Apple純正。MシリーズGPUのMetalを直叩き。llama.cppより10-20%速い
vLLM ファミリー - vLLM: UC Berkeley発。PagedAttentionでサーバー推論の標準になった - SGLang: vLLM互換の独自ランタイム。RadixAttentionでPrefill高速化。構造化出力に強い - Aphrodite Engine: vLLMフォーク。Patreon課金のローカル推論向け機能追加版
NVIDIA ファミリー - TensorRT-LLM: NVIDIA純正。FP8、INT4、in-flight batching、マルチノード。エンタープライズ標準 - Triton Inference Server: TensorRT-LLMのフロントエンド。REST/gRPC APIを提供
軽量/特化ファミリー - ExLlamaV2: RTX 3090/4090の24GBで70Bを動かすための最適化。EXL2量子化 - CTranslate2: OpenNMTチーム発。CPU推論に特化。INT8量子化が高速 - mistral.rs: Rust実装。Apple SiliconでISQ（In-Situ Quantization）が強い - llama-cpp-python: llama.cppのPythonバインディング。LangChainとの統合に便利
各エンジンの評決
エンジン長所短所適した場面--------------------------------llama.cppどこでも動く、誰でも使える、GGUFエコシステムサーバー向け機能が弱い（連続バッチ非対応）ローカルLLM、Apple Silicon、CPUOllamaインストール一発、Modelfileでカスタマイズ、API完備中身はllama.cppと変わらない。CUDA最適化は弱い個人開発、プロトタイピングvLLMPagedAttention最強、スループット最大、エコシステム成熟メモリ消費が大きい、設定項目が多すぎる本番APIサーバー、NVIDIA GPUTensorRT-LLMNVIDIA GPUで絶対最速、FP8/INT4が圧倒的NVIDIA以外で動かない、ビルドが面倒、モデルごとにエンジン再構築NVIDIAエンタープライズ、低レイテンシ必須SGLangPrefill速い、構造化出力（JSONモード）が爆速、vLLMより新しいまだ若い、ドキュメント不足、vLLMほどの検証実績がない構造化出力API、高スループットExLlamaV224GBで70B動く、EXL2量子化の品質が高いシングルGPU限定、バッチ処理弱いRTX 3090/4090ユーザーMLXApple Siliconで最速、APIが綺麗、LoRAが簡単Mac専用、モデル互換性がllama.cppより狭いMacでLLM開発する人CTranslate2CPUで爆速、消費電力最小、ONNX変換でポータブルGPU最適化がない、新しいアーキテクチャへの追従が遅いCPU専用APIサーバー
ハードウェア戦略レシピ
レシピA：M4 Mac mini 64GB（0円運用） エンジン: llama.cpp (GGUF) モデル: Qwen3.5-32B-Q4_K_M (22GB VRAM消費) 量子化: Q4_K_M (品質重視) または IQ4_XS (速度重視) 速度: 20-35 tok/s (MPS) プロジェクト: 個人開発、ローカルエージェント、オフライン翻訳
レシピB：RTX 4090 24GB（20万円） エンジン: ExLlamaV2 (EXL2) モデル: Llama-4-Maverick-17B-4.0bpw (16GB VRAM消費) 量子化: EXL2 4.0bpw (品質/速度のバランス) 速度: 80-120 tok/s プロジェクト: ローカルGPT-4代替、コーディングアシスタント
レシピC：A100 80GB（クラウド $1-2/hr） エンジン: vLLM モデル: Qwen3.5-72B-AWQ (40GB VRAM消費) 量子化: AWQ 4bit 速度: 2000-3000 tok/s (連続バッチ時) プロジェクト: 本番APIサーバー、マルチテナントSaaS
レシピD：H100 x8 ノード（$50-100/hr） エンジン: TensorRT-LLM モデル: DeepSeek-V3-FP8 (分散) 量子化: FP8 速度: 20000+ tok/s (全ユーザー合計) プロジェクト: 大規模API、カスタマーサポートAI
最終原則
一にメモリ帯域、二に量子化、三にバッチング
エンジン選びで迷ったら、ハードウェアのメモリ帯域を最初に見ろ。帯域が決まれば、量子化で収まる最大モデルサイズが決まる。モデルが決まれば、あとは連続バッチの有無でスループットが決まる。
2026年、選択肢は収束した
2年前は20以上のエンジンが乱立していた。今はllama.cpp（ローカル）、vLLM（サーバー）、TensorRT-LLM（NVIDIAエンタープライズ）の三強に集約されつつある。
Apple Silicon原理主義者のススメ
M4 Max 128GB + llama.cpp + Qwen3.5-72B-Q4_K_M。月額0円。電気代だけ。遅い？ 30 tok/sあれば読む速度より速い。エンタープライズSLAが必要ないなら、これで十分。
それでも迷ったら
llama.cppを入れろ。すべてのハードウェアで動き、すべての量子化方式をサポートし、コミュニティが最も巨大で、ドキュメントが最も充実している。「遅すぎる」と感じたら、初めてvLLMやTensorRT-LLMを検討しろ。
普遍の真理：動くものが最強。
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/n98b24e1d387a