推論エンジンを最初に選ぶべきではない。まず、ハードウェア戦略、ワークロードの形状、そしてサービングモデルを選ぶ。エンジンはそれに従う。
これが LLM 推論エンジンを考える上で最も有用な考え方だ。
シリーズノート：これは、セルフホスト LLM / ローカル AI を解説するシリーズの第 3 部です。
この 2 つは、ハードウェアの容量と帯域幅の計算を説明している。
この記事では、そのハードウェアを実用的な推論に変えるソフトウェアレイヤーについて説明する。
エンジン
これらのツールは、それぞれ異なる目的を果たし、異なるレイヤーに位置する。
- ローカルでの可搬性
- コンシューマー向け CUDA
- Apple ユニファイドメモリワークフロー
- 量子化推論
- 本番環境でのサービング
- 分散オーケストレーション
- ベンダー最適化データセンターでの実行
有用なメンタルモデル：
推論エンジンは「モデル」ではない。それは、トラフィックコップ、メモリマネージャー、カーネルディスパッチャー、スケジューラー、キャッシュアカウンタント、並列性プランナー、API サーフェス、そして時にはデプロイフレームワークでもある。
最適なエンジンは、メモリ階層、インターコネクト、量子化フォーマット、レイテンシとスループットの目標、モデルアーキテクチャ、運用の成熟度にマッチする。
ワンページ判断ガイド
- ラップトップ / エッジ / 変則的なハードウェア → llama.cpp
- Mac ファーストのワークフロー → MLX / MLX-LM
- 単一 RTX でのローカル推論 → ExLlamaV2
- 2〜4 以上の NVIDIA / CUDA GPU → ExLlamaV3
- 一般的な本番サービング → vLLM
- ロングコンテキスト / MoE / ルーティング → SGLang
- NVIDIA 最高パフォーマンス → TensorRT-LLM
- クラスターオーケストレーション → NVIDIA Dynamo
このガイドの残りの部分で、その理由を説明する。
推論エンジンが実際に行うこと
推論エンジンは、重みをロードし、入力をトークン化し、フォワードパスを実行し、トークンをサンプリングし、KV キャッシュを維持し、結果をストリーミングする。本格的なエンジンは、バッチ処理、スケジューリング、プレフィックスキャッシング、量子化、並列実行、API サービング、メトリクス、分散実行も処理する。
ワークロードには 2 つのフェーズがある：
プリフィルはプロンプトを読み取り、初期 KV キャッシュを構築する。これは計算集約的である。
デコードは一度に 1 つのトークンを生成し、重みと KV キャッシュを繰り返し読み取る。これはメモリ帯域幅に制約される。デコード速度は、ピーク計算能力よりもメモリ帯域幅に依存する。
この区別がほとんど全てを説明する：
- 短いプロンプト、長い回答：デコードが支配的 → メモリ帯域幅とバッチ処理が重要。
- 長いプロンプト、短い回答：プリフィルが支配的 → アテンションカーネルとチャンク化プリフィルが重要。
- 多数のユーザー：スケジューラーの品質が重要 → 継続的バッチ処理、キャッシュページング、公平性。
- ロングコンテキスト：KV キャッシュが支配的 → ページドアテンション、KV 量子化、オフロード。
- MoE：エキスパートルーティングが支配的 → エキスパート並列性、インターコネクト、グループ化 GEMM。
- マルチノード：インターコネクトが支配的 → NVLink、RDMA、パイプラインレベル並列性、分離。
PagedAttention は KV キャッシュの断片化に取り組んだ。FlashAttention は IO 認識型タイル処理を使用して HBM（高帯域幅メモリ）トラフィックを削減した。投機的デコードは安価なトークンを起草し、並行して検証する。繰り返し登場するテーマ：推論パフォーマンスはメモリ移動とスケジューリングである。
実際のボトルネック
- メモリ帯域幅、単なる VRAM サイズではない。VRAM は収まるかどうかを決定する。帯域幅はデコード速度を決定する。Apple の M3 Ultra は最大 819 GB/s のユニファイドメモリ帯域幅を提供する。NVIDIA の H100 SXM は 3.35 TB/s の GPU メモリ帯域幅をリストしている。ユニファイドメモリを使うと、コンシューマー VRAM に収まらないモデルを実行できる。HBM を使うと、モデルが収まる場合により高速にサービングできる。収まることと速度は同じではない。容量は帯域幅ではない。
- KV キャッシュの成長。KV キャッシュはバッチサイズとコンテキスト長に応じて成長する。ロングコンテキストのワークロードでは、重みが収まってもメモリが不足する可能性がある。PagedAttention は KV キャッシュをブロックに分割し、利用率を高め、より大きなバッチをサポートする。
- インターコネクト。モデルが GPU の境界を越える（マルチ GPU）瞬間、通信コストが発生する。テンソル並列性は頻繁な all-reduce 集合通信を必要とする。パイプラインレベル並列性はステージ境界で通信する。エキスパート並列性は MoE のための all-to-all トラフィックを必要とする。vLLM のドキュメントには、NVLink がない場合、パイプラインレベル並列性がテンソル並列性より優れる可能性があると記載されている。
- スケジューラーの品質。優れたスケジューラーは、どのリクエストをバッチに入れるか、プリフィルとデコードがどのようにアクセラレータを共有するか、長いプロンプトが短いデコードをブロックするかどうか、そしてスターベーションを回避する方法を決定する。バッチ処理をサポートすることは、本番対応のスケジューラーとして動作することとは異なる。
- ランタイムオーバーヘッド。CUDA グラフ、カーネル融合、サンプリングオーバーヘッド、トークナイザーオーバーヘッド、HTTP オーバーヘッド、LoRA 切り替え、構造化デコードは全て重要である。大規模になると、厄介な 2% のオーバーヘッドが結合し、注意を要求する（駄洒落の意図はない）。
エンジンファミリー
大きく 4 つのファミリーがある：
ポータブルローカルランタイム：llama.cpp、MLC LLM、ONNX Runtime GenAI、OpenVINO、Ollama スタイルのツール。これらは「ここで動かす」ことを重視する。
Apple / ユニファイドメモリランタイム：MLX と MLX-LM。これらは「大きな共有メモリを使い、Apple のスタックをうまく活用する」ことを重視する。
コンシューマー CUDA 量子化エンジン：ExLlamaV2 と ExLlamaV3。これらは「自分の 3090/4090/5090 ボックスを低ビット重みで最高のパフォーマンスにする」ことを重視する。
本番サービングエンジン：vLLM、SGLang、TensorRT-LLM、TGI、LMDeploy。これらは、同時ユーザー数、KV キャッシュ、バッチ処理、並列性、可観測性、トークンあたりのコストを重視する。
そして、Dynamo のようなオーケストレーションレイヤーがあり、エンジンの上に位置して、フリートの調整、分離されたプリフィル/デコード、ルーティング、オートスケーリングを実行する。
llama.cpp：移植性の王者
llama.cpp は、ハードウェアが変則的、リソースが限られている、オフライン、CPU 中心、エッジ指向、あるいは整然とした NVIDIA データセンターノードではない場合の答えである。
ARM NEON、Accelerate、Metal を介した Apple Silicon、AVX/AVX2/AVX512/AMX を介した x86、RISC-V、低ビット量子化、CUDA、HIP を介した AMD、MUSA、Vulkan、SYCL、CPU+GPU ハイブリッドオフロードをサポートする。これが、llama.cpp が「とにかく動かす」という分野を支配する理由である。
HTTP サーバーは「おもちゃのローカルランナー」以上の能力がある。llama-server は、OpenAI 互換ルート、Anthropic Messages API 互換性、リランキング、継続的バッチ処理、マルチモーダルサポート、JSON スキーマ制約、関数呼び出し、投機的デコード、そして Web UI を提供する。
重要な制限：llama.cpp は本格的なマルチノード本番サービング向けではない。その RPC バックエンドは、概念実証、脆弱、安全ではないと明示的に文書化されている。
結論：移植性、オフライン動作、GGUF、またはハイブリッドオフロードがフリート規模のサービングよりも重要な場合に、llama.cpp を使用する。
MLX と MLX-LM：Apple Silicon の武器
MLX は、Apple Silicon 向けの Apple の配列フレームワークであり、MLX-LM はその上に構築された LLM パッケージである。これは Mac ファーストの ML スタックである。
重要なハードウェアの事実は、ユニファイドメモリである。Apple Silicon は CPU と GPU に同じメモリプールへの直接アクセスを提供する。MLX 配列はユニファイドメモリ内に存在し、操作を実行する際にデバイスを選択する。つまり、配列を別々のメモリ空間間で移動する必要はない。
これにより、ローカル推論のトレードオフが変わる。個別 GPU システムでは、「VRAM に収まるか？」が問題になる。大きなユニファイドメモリを備えた M シリーズ Mac では、「メモリに収まるか、そしてメモリシステムが GPU に十分な速度でデータを供給できるか？」が問題になる。大規模な量子化モデルは、同じモデルが 24 GB のコンシューマー GPU では不可能なマシンでも実行できる。
しかし、速度は遅くなる。
MLX-LM は、Hugging Face Hub 統合、量子化、LoRA およびフルファインチューニング、分散推論、そして大規模な MLX Community モデルエコシステムを追加する。MLX はもはや Mac 専用ではない。Linux 向けに CUDA と CPU 専用パッケージを提供する。分散通信は、MPI、TCP 上の Ring、Thunderbolt 上の RDMA 用の JACCL、CUDA 用の NCCL をサポートする。
MLX-LM のサーバー自体は、基本的なセキュリティチェックのみを実装しているため、本番環境では推奨されないと警告している。
結論：Mac ファーストの ML および LLM ワークフローには MLX を使用する。高同時実行の公開サービングには、実際のサービングスタックから始めること。
ExLlamaV2 と V3：コンシューマー CUDA、チューニング済みで高速
ExLlamaV2 は、コンシューマー NVIDIA GPU で能力以上のパフォーマンスを引き出したい人向けのローカル CUDA 量子化エンジンである。ページドアテンション、動的バッチ処理、プロンプトキャッシング、KV キャッシュ重複排除、バッチ生成、ストリーミング、投機的デコードをサポートする。覚えておくべき言葉は「ローカル」である。最新の CUDA GPU、特にコンシューマーカード上で量子化モデルを高速にする。
最適な用途：1 台の RTX 3090/4090/5090 ボックス、ローカルコーディングアシスタント、ローカルチャット、EXL2 量子化モデル、プロシューマーワークステーションでの使用。
ExLlamaV3 は、その哲学をマルチ GPU と MoE ローカル推論に拡張する。QTIP に基づく EXL3 量子化フォーマット、コンシューマーハードウェア向けの柔軟なテンソル並列およびエキスパート並列推論、TabbyAPI を介した OpenAI 互換サーバー、継続的動的バッチ処理、マルチモーダルサポートを追加する。
V3 は、2〜4 台以上のコンシューマー NVIDIA GPU を持っているか、ローカル MoE を望む場合に魅力的である。注意点として、一部のモデルは ExLlamaV3 でテンソル並列またはエキスパート並列をサポートしない。
結論：ExLlamaV2 は、愛好家向けのローカル CUDA エンジンである。ExLlamaV3 は、マルチ GPU（2〜4 台）ローカルセットアップの最前線である。より優れた能力と引き換えに、より荒い部分があると予想される。
vLLM：デフォルトのオープンソース本番サーバー
vLLM は、本格的なオープンソース LLM サービングを評価する際に、ほとんどのチームが最初に検討すべきエンジンである。
PagedAttention ベースの KV メモリ管理、継続的バッチ処理、チャンク化プリフィル、プレフィックスキャッシング、CUDA/HIP グラフ、広範な量子化（FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ、GGUF）、最適化されたアテンションおよび GEMM/MoE カーネル、投機的デコード、torch.compile、分離されたプリフィル/デコード/エンコードを提供する。
また、柔軟性も高い：テンソル/パイプライン/データ/エキスパート/コンテキスト並列性、ストリーミング、構造化出力、ツール呼び出し、OpenAI 互換および Anthropic Messages API、gRPC、マルチ LoRA、NVIDIA、AMD、x86/ARM/PowerPC CPU のサポート、さらに TPU、Gaudi、Ascend、Apple Silicon などのプラグインも提供する。
vLLM のドキュメントは、マルチノードデプロイメントは通常 Ray を使用し、NVLink がない場合、パイプラインレベル並列性がテンソル並列性を凌ぐ可能性があると指摘している。落とし穴は、vLLM がシステム思考の必要性を排除すると想定することである。バッチ処理、コンテキスト長、GPU メモリ使用率、並列性レイアウト、ルーティングを調整する必要がある。vLLM は非常に優れたエンジンを提供するが、それでも適切なシステム設計が必要である。
結論：誰かが「本番環境でオープンモデルを提供する必要がある」と言った場合、vLLM がデフォルトの出発点である。
SGLang：vLLM のシステム思考のいとこ
SGLang は、サービングワークロードが厄介な場合に手を伸ばすものである：構造化出力、ロングコンテキスト、MoE、分離、ルーティング。
RadixAttention プレフィックスキャッシング、プリフィルデコード分離、投機的デコード、継続的バッチ処理、ページドアテンション、テンソル/パイプライン/エキスパート/データ並列性、構造化出力、チャンク化プリフィル、マルチ LoRA バッチ処理を提供する。NVIDIA、AMD、Intel Xeon、Google TPU、Ascend NPU などをサポートする。
SGLang の差別化要因はサービングアーキテクチャである。プリフィルデコード分離は、計算集約的なプリフィルをメモリ集約的なデコードから分離し、専用インスタンスに割り当て、KV キャッシュをそれらの間で転送する。これにより、長いプリフィルバッチがデコードを中断し、トークンレイテンシが急上昇するのを防ぐ。
結論：SGLang は、ボトルネックがもはや「モデルを実行できるか？」ではなく、「過酷なトラフィック下で、レイテンシ、メモリ、コストを犠牲にせずに実行できるか？」であるチーム向けである。
TensorRT-LLM：最大の NVIDIA パフォーマンス
TensorRT-LLM は、NVIDIA 最高パフォーマンスのスタックである。最適化され、特化され、強力であり、移植性を装わない。
最先端の最適化を備えた TensorRT エンジンを構築するための Python API と、Python および C++ ランタイムを提供する。アテンション、GEMM、MoE 用のカスタムカーネル、プリフィルデコード分離、Wide Expert Parallelism、投機的デコード、そして NVIDIA Dynamo および Triton Inference Server と統合された高レベル Python API が含まれる。
B200 GPU は、最適化されたカーネルで FP4 重みをロードできる。H100 以降は、FP8 量子化をサポートしており、16 ビットと比較してパフォーマンスを 2 倍にし、メモリ消費を最小限の精度損失で半分にできる。
最も輝く場面：H100/H200/B200/GB200/GB300 クラスのフリート、NVIDIA 専用データセンター、FP8/FP4 デプロイメント、マルチノードサービング、大規模 MoE。扱いにくい場面：AMD、Apple、または Intel への移植性、急速に変化する実験的モデル、小さなローカルセットアップ、そして「どこでも動く」ものを必要とするチーム。
結論：NVIDIA にコミットしており、絶対的なパフォーマンスを重視する場合、TensorRT-LLM は比較検討に値する。移植性と引き換えにパフォーマンスを得る。チューニングされた特化型だが、機能は少ない。
その他の分野
TGI は、トレーシング、メトリクス、テンソル並列性、継続的バッチ処理を備えた Hugging Face の本番サーバーである。HF 統合とシンプルさが重要な場合に使用する。
MLC LLM は、コンパイラファーストのユニバーサルデプロイメントエンジンであり、REST、Python、JavaScript、iOS、Android 全体で OpenAI 互換 API を提供する。「LLM をあらゆる場所に届ける」、特にブラウザ、モバイル、ネイティブアプリに最適である。
ONNX Runtime GenAI は、ONNX Runtime 上で完全な生成ループを実装し、Foundry Local、Windows ML、VS Code AI Toolkit を強化する。CPU、CUDA、DirectML、TensorRT-RTX、OpenVINO、QNN、WebGPU、AMD GPU をサポートする。アプリデプロイメントと ONNX ワークフローに最適である。
OpenVINO GenAI は、Intel 最適化されたストーリーであり、Xeon CPU、Arc GPU、Core Ultra、NPU 向けである。継続的バッチ処理とページドアテンションを備えた OpenAI 互換サービングを提供する。Intel ハードウェアに最適である。
LMDeploy は、パフォーマンス用の TurboMind とアクセシビリティ用の PyTorch を備えた CUDA フォーカスのツールキットである。vLLM/SGLang/TensorRT-LLM の代替を求める CUDA ユーザーに最も興味深い。
NVIDIA Dynamo は、vLLM、SGLang、TensorRT-LLM などのエンジンの上に位置する分散オーケストレーションレイヤーであり、分離、インテリジェントルーティング、マルチティア KV キャッシングをサポートする。単一エンジンのサービングがもはや十分でない場合に使用する。
注：Ollama は使用しないこと。
ハードウェア戦略レシピ
CPU 専用サーバー：まず llama.cpp。Intel Xeon には OpenVINO。アプリ/ONNX デプロイメントには ONNX Runtime GenAI。
MacBook / Mac Studio：Mac ネイティブワークフローには MLX / MLX-LM。GGUF 移植性には llama.cpp。
単一 RTX 3090 / 4090 / 5090：EXL2 ローカル推論には ExLlamaV2。GGUF または移植性には llama.cpp。複数ユーザーへのサービングには vLLM。
デュアルまたはクアッドコンシューマー RTX ボックス：マルチ GPU 量子化推論または MoE には ExLlamaV3。サービング動作が重要な場合は vLLM。ルーティングまたはロングコンテキストパターンをテストする場合は SGLang。
8×H100 / H200 ノード：vLLM または SGLang から開始する。NVIDIA 専用でパフォーマンスがチューニングを正当化する場合は TensorRT-LLM をベンチマーク。マルチノードオーケストレーションが必要になったら Dynamo を使用する。
B200 / GB200 / GB300 クラスインフラストラクチャ：TensorRT-LLM、SGLang、vLLM をベンチマーク。フリートレベルのオーケストレーション、KV 認識ルーティング、オートスケーリングには Dynamo を追加する。
AMD MI300 / MI325 / MI350 / MI355：ROCm 上で vLLM または SGLang から開始する。NVIDIA のベンチマークがそのまま転用できると想定しないこと。
Intel Xeon / Core Ultra / Arc：OpenVINO GenAI または OpenVINO Model Server。アプリ埋め込みが重要な場合は ONNX Runtime GenAI。
ブラウザ、モバイル、アプリネイティブ：MLC LLM / WebLLM または ONNX Runtime GenAI。
ベンチマーク：測定すべきもの
悪いベンチマーク：「180 tok/s 出た。」
良いベンチマークには以下が含まれる：
モデル：正確なモデル、アーキテクチャ、パラメータ数、アクティブ MoE パラメータ。
重み：dtype、量子化フォーマット、グループサイズ、キャリブレーション。
エンジン：バージョン、コミット、バックエンド、フラグ。
ハードウェア：GPU SKU、メモリ容量、帯域幅、インターコネクト、CPU、RAM。
ワークロード：入力/出力長の分布、同時実行数、ストリーミング、共有プレフィックス、構造化出力。
メトリクス：TTFT、TPOT、エンドツーエンドレイテンシ、p50/p95/p99、トークン/秒、リクエスト/秒、GPU メモリ使用量、KV キャッシュヒット率、プリフィルスループット、デコードスループット、100 万トークンあたりのコスト。
ベンチマークのルール：
- 単一ユーザーのトークン/秒のみを使用してエンジンを比較しない。
- 実際のプロンプトと出力分布をテストする。
- 現実的な同時実行数でテストする。
- プリフィルとデコードを分離する。
- 平均だけでなく p95 と p99 を追跡する。
- 目標のコンテキスト長でのメモリヘッドルームを測定する。
- アプリに繰り返しプレフィックスがある場合、キャッシュ再利用をテストする。
- 構造化出力は個別にベンチマークする。文法はオーバーヘッドを追加する。
- LoRA とマルチ LoRA は個別にベンチマークする。
- ドライバー、CUDA、ROCm、モデル、またはエンジンのアップグレード後に再テストする。
よくある間違い
VRAM 容量だけで選ぶこと。VRAM は収まるかどうかを決定する。帯域幅とスケジューラーが速度を決定する。大きなユニファイドメモリを搭載したマシンは巨大なモデルを実行できるが、H100 はモデルが収まる場合、はるかに高い HBM 帯域幅によりデコードが高速である。
弱いインターコネクトでテンソル並列性を使用すること。NVLink または NVSwitch がない場合、パイプラインレベル並列性をテストする。vLLM のドキュメントは、L40S のようなセットアップでこれを指摘している。
KV キャッシュを無視すること。ロングコンテキストと同時実行数により、KV キャッシュが制限要因になる可能性がある。PagedAttention、プレフィックスキャッシング、KV 量子化、分離は、大規模になるとオプションではない。
ローカルエンジンを本番サーバーとして扱うこと。llama.cpp サーバーは有能である。MLX-LM サーバーは便利である。Ollama は快適だが、使用すべきではない。
しかし、本番環境とは、セキュリティ、可観測性、バックプレッシャー、ルーティング、オートスケーリング、SLA 動作を意味する。MLX-LM 自身、そのサーバーは本番環境では推奨されないと警告している。
すべての量子化フォーマットが移植可能だと想定すること。GGUF、EXL2、EXL3、AWQ、GPTQ、FP8、FP4、MLX フォーマット、ONNX は互換性がない。適切なフォーマットとは、エンジンが最適化されたカーネルを持っているものである。
モデルアーキテクチャを無視すること。高密度モデル、MoE、ハイブリッドアテンション、マルチモーダルモデル、ロングコンテキストバリアントは、エンジンの異なる部分に負荷をかける。幅広いサポートは、すべての最適化が均等に機能することを意味しない。
ワークロード形状なしでベンチマークチャートを信頼すること。Llama 3.1 8B を 1K 入力 / 128 出力で示すチャートは、80K コンテキストで Qwen 3.6 27B / Gemma 4 26B-A4B を実行するコーディングエージェントや、500 の同時ユーザーがいる RAG サービスについてはほとんど何も語らない。
確固たる最終マップ
ローカル AI ユーザー：利便性のために LM Studio または Harbor。制御のために llama.cpp。Mac では MLX。CUDA ローカルパフォーマンスには ExLlamaV2/V3。
ローカルエージェントの構築：どれでも動作するはずだが、ほとんどの人が使用しているものを考慮すると、移植性には llama.cpp。ユーザーが Apple Silicon の場合は MLX。ローカルで本番サービングをシミュレートする場合は vLLM。
内部チームへのサービング：vLLM から始める。構造化出力、ロングコンテキスト、マルチ LoRA、MoE、またはルーティングが重要な場合は SGLang を使用する。
大規模な顧客へのサービング：vLLM、SGLang、TensorRT-LLM をベンチマークする。ルーティングと分離が重要な場合、SGLang と Dynamo が注目に値する。
NVIDIA データセンター：最大パフォーマンスには TensorRT-LLM。柔軟性には vLLM。複雑なサービングには SGLang。フリートオーケストレーションには Dynamo。
Apple Silicon：ネイティブ開発には MLX。GGUF には llama.cpp。ユニファイドメモリは容量のスーパーパワーだが、帯域幅のトレードオフがあり、HBM ではない。
エッジ、アプリ、ブラウザ、または Windows ネイティブ：スタックに応じて、llama.cpp、MLC LLM、ONNX Runtime GenAI、または OpenVINO。
最終原則
推論エンジンには結果が伴う。
以下の質問に答えた後にエンジンを選ぶ：
- 実際にどのようなハードウェアを持っているか？
- モデルは高速メモリに収まるか、それともシステム/ユニファイドメモリにのみ収まるか？
- デコードとプリフィルのどちらがボトルネックか？
- どのコンテキスト長と同時実行数が重要か？
- プレフィックスキャッシングに十分なほどプロンプトは共有されているか？
- モデルは高密度か、MoE か、マルチモーダルか、それともハイブリッドか？
- ローカルの利便性、本番サービング、それともフリートオーケストレーションが必要か？
- ターゲットエンジンでは、どの量子化フォーマットに最適化されたカーネルがあるか？
- インターコネクトは PCIe、NVLink、NVSwitch、Ethernet、RDMA、それとも Thunderbolt か？
- レイテンシ、スループット、コスト、プライバシー、移植性、それとも開発速度のどれを最適化しているか？
エンジンは、その答えに従う。
また次回まで。
- Ahmad
