推論エンジンは「何台で、誰が使うか」で選ぶ：llama.cpp・vLLM・MLX・TensorRT-LLM・Ollamaの守備範囲を、公式資料で確かめる

3行でいうと

OllamaのREADMEは、対応するバックエンド（中で動くエンジン）としてllama.cppを挙げています。
vLLMは多人数向けの配信、MLXはApple Silicon、TensorRT-LLMはNVIDIA GPUが前提です。
llama.cppのサーバーは、複数の利用者を「スロット」で同時に扱い、連続バッチ処理が標準で有効です。
OllamaのFAQでは、同時リクエスト数（OLLAMA_NUM_PARALLEL）の既定値は1です。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書やREADMEを読んでまとめたものです。

先に結論

見立てです。5つは、同じ土俵で競う「優劣」ではなく、置かれる場所が違います。

1人で、手元のPCやMacで動かす：Ollama（手軽）か、llama.cpp（細かく調整できる）。
Macの性能を引き出す：MLX（Appleの機械学習研究グループが開発）。
チームや社内向けに、多人数へ配る：vLLM（NVIDIA・AMDのGPUが中心）。
NVIDIA GPUで性能を絞り出す：TensorRT-LLM。

迷ったら、「同時に使う人数」と「持っているGPU（またはMac）」の二つで絞るのが早いと思います。

前提：推論エンジンの役割

推論は、学習済みのモデルに質問を入れて、答えを出す計算のことです。
推論エンジンは、モデルのファイルを読み込み、GPUやCPUで推論を回すソフトです。メモリの管理、複数のリクエストをまとめて処理する工夫（バッチ処理）、外から呼べる窓口（API）などを担当します。
KVキャッシュは、AIが文章を書くとき、すでに読んだ部分の計算結果を取っておく領域です。会話が長いほど大きくなり、GPUのメモリを食います。
OpenAI互換APIは、OpenAIのAPIと同じ形のリクエストで呼べるようにした窓口です。既存のアプリを、つなぎ先の変更だけで試せます。

5つの守備範囲（早見表）

エンジン	開発元・性格	得意な場面	読んだ範囲で分かった前提・制約
llama.cpp	C/C++製。ggmlライブラリが土台	少ない準備で、幅広いハードで動かす	幅広い対応先（CPU、Metal、CUDA、HIP、Vulkan、SYCLなど）
vLLM	UCバークレーのSky Computing Labが発端	多人数への配信（サービング）	NVIDIA・AMD GPUとCPUが中心。Apple Siliconはプラグイン（vLLM-Metal）
MLX（mlx-lm）	Appleの機械学習研究グループ	Macでの推論と微調整	Apple silicon向け。大きなモデルの高速化にはmacOS 15以上が必要
TensorRT-LLM	NVIDIA。Apache 2ライセンス	NVIDIA GPUでの高性能化	LinuxとNVIDIA GPU（Ampere以降が対象）。FP8はH100以降
Ollama	手軽に使えるコマンドとREST API	手元で最初に試す	バックエンドとしてllama.cppを挙げている

各エンジンの中身

llama.cpp

READMEは、目的を「最小限の準備で、最先端の性能で、幅広いハードウェア上で推論する」ことと述べています。C/C++だけで書かれ、外部の依存がありません。

対応先：Apple SiliconはARM NEON・Accelerate・Metal、x86はAVX・AVX2・AVX512・AMX。GPUはCUDA（NVIDIA）、HIP（AMD）、Vulkan、SYCL（Intel）。ほかにNPUや各社のGPU向けも並んでいました。
量子化：1.5ビットから8ビットまでの整数量子化。量子化の形式の違いは「量子化の形式を比べる」の記事に書きました。
ハイブリッド推論：CPUとGPUを併用し、GPUのメモリ（VRAM）に収まらない大きさのモデルも、一部を高速化して動かせる、とあります。
llama-server：OpenAI互換のAPIサーバーです。チャット、埋め込み（文章を数の列にする処理）、/v1/modelsなどに対応し、Anthropic互換の/v1/messagesもあります。

vLLM

vLLMの文書は「LLMの推論と配信のための、速くて使いやすいライブラリ」と自己紹介しています。

PagedAttention：KVキャッシュを、OSのメモリ管理（ページング）になぞらえて小分けに管理する方法です。論文（Kwonら、2023年9月、arXiv:2309.06180）は、FasterTransformerやOrcaといった当時の方式より、同じ遅延で2〜4倍のスループットが出たと報告しています。論文の条件での数字です。
連続バッチ処理：届いたリクエストを、待たせずに順次まとめて処理する方式です。チャンク化したプリフィル（最初の入力を読み込む処理）やプレフィックスキャッシュ（共通の書き出しを再利用する仕組み）も挙がっています。
量子化：FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUFなど。
投機的デコーディング：小さな予測役が先読みして、本体が確認する方式。n-gram、suffix、EAGLE、DFlashが挙がっています。
窓口：OpenAI互換のAPIサーバーに加え、Anthropic Messages APIとgRPCにも対応とあります。
ハード：NVIDIA GPU、AMD GPU、x86/ARM/PowerPCのCPU。Google TPU、Intel Gaudi、Apple Siliconなどはプラグイン経由です。

MLX（mlx-lm）

MLXは「Apple siliconで効率的に機械学習をするための、NumPyに似た配列フレームワーク」で、Appleの機械学習研究グループが開発しています。特徴として、統一メモリ（CPUとGPUが同じメモリを共有するので、データのコピーが要りません）と、遅延評価（値が必要になるまで計算しない）が挙がっています。詳しい位置づけは、別の記事で扱います。

その上のmlx-lmは、MLXでテキスト生成とLLMの微調整をするPythonパッケージです。READMEによると、Hugging Face Hubのモデルを1コマンドで動かし、量子化し、アップロードできます。微調整は低ランク（LoRA）と全体の両方で、量子化したモデルにも使えるとあります。

TensorRT-LLM

NVIDIAのオープンソースのライブラリで、PyTorchの上に作られています。概要ページには、次のことが書かれています。

実行中にリクエストを出し入れするバッチ処理（in-flight batching）、ページ化したKVキャッシュ、投機的デコーディング（EAGLE、MTP、NGram）。
H100以降のGPUでFP8に対応し、16ビットの浮動小数点と比べて、おおよそ性能が2倍、メモリが半分になりうるという記述（NVIDIAの説明）。B200ではFP4に対応。
複数GPU・複数ノードの並列化（テンソル・パイプライン・エキスパート）、LoRA、ガイド付きデコーディングなど。

サポート表のページには、OSとしてLinux（x86_64またはaarch64）、GPUとしてNVIDIAのBlackwell、Grace Hopper、Hopper、Ada、Ampereが載っていました。「載っていないGPUは、チームが開発・テストしない」とも書かれています。

Ollama

OllamaのREADMEは、コマンドラインとREST API（localhost:11434）、PythonとJavaScriptのライブラリを紹介しています。対応するバックエンドの欄には、llama.cppが一つだけ書かれていました。

公式文書のインポートの説明では、GGUFのファイルは取り込むときに量子化されません。事前にllama.cppのllama-quantizeなどで量子化しておく必要があります。

同時利用に関わる設定の値（llama-serverとOllama）

llama-server（公式READMEより）

-np, --parallel N：サーバーのスロット数。既定は-1（自動）。自動のときの数は文書に書かれていませんでした。
連続バッチ処理は既定で有効。--no-cont-batchingで無効にできます。
/slotsは既定で有効、/metrics（Prometheus用）は--metricsが必要です。

Ollama（公式FAQより）

設定	意味	既定値
OLLAMA_NUM_PARALLEL	1つのモデルへの同時リクエスト数	1
OLLAMA_MAX_LOADED_MODELS	同時に読み込むモデル数	GPU数×3（CPUのみなら3）
OLLAMA_MAX_QUEUE	待ち行列の上限（超えると503）	512
keep_alive	使い終わってから読み込みを保つ時間	5分
OLLAMA_KV_CACHE_TYPE	KVキャッシュの精度（FlashAttention有効時）	f16

FAQには、並列数を増やすと実質の文脈が増える（2Kの文脈で4並列なら8K分）、RAMはOLLAMA_NUM_PARALLEL×OLLAMA_CONTEXT_LENGTHに比例して増える、とあります。KVキャッシュのq8_0はf16の約半分のメモリ、q4_0は約4分の1で、精度の低下が大きくなりうる、との説明です。

選び方の目安

見立てです。上の資料からは、次の順で決めると整理しやすいと思います。

GPUの種類：NVIDIAだけならvLLMもTensorRT-LLMも候補。AMDならvLLM（ROCm）かllama.cpp（HIP）。Macなら、MLXかllama.cpp（Metal）か、Ollama。
同時に使う人数：1人ならOllamaやllama.cppで十分。数人以上が同時に使うなら、バッチ処理を前提に作られたvLLMやTensorRT-LLMが候補。
モデルの形式：GGUFを使うならllama.cppとOllama。MLX用に変換したモデルならmlx-lm。vLLMでもGGUFは読めますが、文書は「非常に実験的で、最適化が不十分」としています。
運用の手間：Ollamaが最も軽く、TensorRT-LLMは性能を出すぶん、NVIDIA固有の知識が要ると思います（これは僕らの推測です）。

よくあるつまずき

同時利用でOllamaが遅い：同時リクエスト数の既定値が1なので、それ以上は待ち行列に入ります（FAQの値）。
「Ollamaはllama.cppと別物」と思い込む：READMEはllama.cppをバックエンドとして挙げています。性能の差は、設定や周辺の機能で出ると思われますが、差の中身は、読んだ範囲では確認できていません。
vLLMにGGUFを入れて遅い：上記のとおり、GGUFはvLLMでは実験的な扱いです。
TensorRT-LLMに載っていないGPUを使う：サポート表のとおり、載っていないGPUは公式には開発・テストされません。
MLXで大きいモデルが遅い：READMEは、RAMに対して大きいモデルは遅くなりうると述べ、メモリの固定（wired）の設定にはsudo sysctl iogpu.wired_limit_mb=Nを示しています。macOS 15以上が必要です。

気をつけること

この記事は、実際に使って確かめた記録ではありません。速さの優劣は、この記事では扱っていません。
文書は頻繁に更新されます。vLLMの対応ハードやTensorRT-LLMの対応表は、使う直前に最新版を確認してください。
TensorRT-LLMのサポート表のページでは、NVFP4の記載を確認できませんでした。一方、概要ページにはB200でFP4に対応とあります。ページごとに更新の時期が違う可能性があります。
FP8で「性能が2倍、メモリが半分」という数字はNVIDIAの文書の記述で、条件は読んだ範囲では書かれていませんでした。
vLLMの2〜4倍は、2023年の論文の、当時の比較対象との結果です。今のバージョンの数字ではありません。
llama.cppのREADMEには、GGUFが対応形式だと文章で明記した箇所は見つけられず、例の中のモデル名に現れるだけでした。ただしGGUFの仕様書とHugging Faceの文書で、GGUFがllama.cpp系の形式であることは確認しています。
Ollamaの内部の設計（独自の部分があるかなど）は、読んだ範囲では確認できていません。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した