ローカルLLM推論エンジン比較 — llama.cpp/Ollama/vLLM/MLX等【2026年版】

結論から言うと、単機・個人利用で手軽に動かすなら Ollama か llama.cpp、Apple Silicon 環境なら MLX、同時多数リクエストを捌くサーバ用途なら vLLM、NVIDIA GPUでの本番最適化を突き詰めるなら TensorRT-LLM、GUIで気軽に試したいなら LM Studio が向く傾向がある。どれも無料・OSSで使えるツールで、目的が異なれば正解も変わるため、まずは自分のユースケースがどれに近いかを見極めることが選定の近道になる。この記事では、各エンジンの立ち位置・対応フォーマット・比較表・スループットの考え方・メモリの扱い・用途別の選び方・乗り換え時の注意点・トラブルの切り分けを順に整理する。

個々のツールの詳しい使い方はOllama と LM Studio の比較、量子化フォーマットの選び方はGGUF量子化ガイド（Q4/Q5/Q8）、必要メモリの見積もりは必要VRAMの目安も参照してほしい。本記事はそれらの一段上、「そもそもどのエンジンを使うべきか」という層を扱う。

6つのツールは同列に並べて比べられがちだが、実際には階層が異なる。まず整理しておくと理解しやすい。

- llama.cpp: C/C++で書かれた推論エンジン本体。GGUF形式のモデルを読み込み、CPU・GPU（CUDA/Metal/Vulkan等）を横断して動かせる、最も汎用性の高い基盤レイヤ
- Ollama: llama.cpp系のバックエンドをラップし、モデルの取得・実行・OpenAI互換APIの提供までをコマンド一つで済ませる運用レイヤ。裏側の詳細を意識せず使えるのが利点
- LM Studio: 同じくllama.cpp系（および後述のMLX）をバックエンドに持つデスクトップGUIアプリ。モデル検索・ダウンロード・パラメータ調整を画面操作で完結できる
- MLX: Appleが開発する、Apple Silicon（M1〜）の統合メモリ・Neural Engineに最適化された機械学習フレームワーク。MLX対応のモデル形式でのみ動作し、他OSでは使えない
- vLLM: PagedAttentionという独自のメモリ管理方式を核に、同時多数リクエストの連続バッチ処理に最適化された推論サーバ。safetensors形式のモデルを主に扱う
- TensorRT-LLM: NVIDIAが提供する、自社GPU向けに推論グラフをコンパイル・最適化するライブラリ。NVIDIA GPU専用だが、その分チューニングの幅が広い

つまり Ollama と LM Studio は「エンジンそのもの」というより「llama.cpp系バックエンドの使いやすいラッパ」であり、MLX は Apple Silicon専用の別系統、vLLM と TensorRT-LLM はサーバ向けの高スループット指向という整理になる。

エンジンによって主に扱うモデルファイルの形式と、量子化の考え方が異なる。ここを揃えないと「動かない」「変換が必要」といったつまずきが起きやすい。

- GGUF: llama.cpp系（llama.cpp本体・Ollama・LM Studio）の標準形式。量子化はQ4_K_M等のK-quantやIQ系（imatrix）が中心
- safetensors: Hugging Face発の重み保存形式で、vLLMやTensorRT-LLMが主に読み込む。量子化なし（FP16/BF16）のほか、AWQ・GPTQ・FP8等の量子化済みsafetensorsにも対応する場合がある
- AWQ / GPTQ: いずれもGPU推論向けの量子化手法。GGUFのK-quantとは別系統で、vLLM等のサーバ系エンジンで使われることが多い
- FP8: 8bit浮動小数点による量子化。NVIDIAの新しい世代のGPUで対応が進んでおり、TensorRT-LLMやvLLMで扱われる
- MLX形式: MLX専用に変換された重み。Hugging Face上にMLX版として配布されているモデルを使うか、自分で変換する

同じ「4bit量子化」でも、GGUFのQ4_K_MとGPU向けのAWQ/GPTQでは仕組みも得意分野も異なる点には注意したい。エンジンを乗り換える際は、量子化方式ごと変換し直す必要がある場合が多い。

表の数値・対応範囲はバージョンやOS・ドライバの状況によって変わりうるため、導入前に各プロジェクトの公式ドキュメントで最新の対応状況を確認することを勧める。

具体的なtok/s（トークン毎秒）の数値は、GPU・モデルサイズ・量子化・プロンプト長・ドライバのバージョンなどで大きく変わるため、この記事では断定しない。その代わり、性能特性の「傾向」を押さえておくと選定に役立つ。Ollama・llama.cpp・LM Studioは、1人（または少数）のユーザーが順番にリクエストを送る「単発レイテンシ重視」の使い方に最適化されている。1リクエストへの応答は速いが、同時に多くのリクエストが来ると、後続は待たされやすい構造になりやすい。

一方 vLLM は、PagedAttentionによってKVキャッシュをページ単位で効率管理し、複数リクエストのバッチを継続的に処理する「連続バッチ処理（continuous batching）」を得意とする。同時接続数が増えるほど、単発レイテンシ重視のエンジンとの合計スループットの差が開きやすい傾向がある。TensorRT-LLMも連続バッチ処理に対応し、NVIDIA GPU向けにグラフレベルで最適化を行うことで、さらに高いスループットを狙える構成が組める。「個人の対話用途」か「多数ユーザーへのサービング」かという用途の違いが、そのままエンジン選びの分岐点になると考えるとわかりやすい。

必要メモリは「モデルの重み」と「KVキャッシュ」の2つで構成される。重みのサイズは量子化で決まる。KVキャッシュは会話やプロンプトが長くなるほど、また同時に処理するリクエストが増えるほど大きくなる点に注意したい。

- llama.cpp/Ollama/LM Studio: 単一ユーザー前提であればKVキャッシュの増加は緩やかだが、長いコンテキストを扱う場合はモデル重み以上にKVキャッシュがVRAMを圧迫することがある
- MLX: Apple Siliconの統合メモリを使うため、GPU専用VRAMのような明確な上限がなく、システムメモリと共有される。ただし空きメモリを使い切ると動作が重くなる
- vLLM: PagedAttentionにより、複数リクエスト分のKVキャッシュをメモリ上で無駄なく再配置できるため、同時接続数を増やしてもメモリ効率が保たれやすい設計になっている
- TensorRT-LLM: KVキャッシュの量子化（INT8等）にも対応する場合があり、同じVRAMでより長いコンテキストや多くの同時リクエストを扱える構成が可能

「モデルは載ったのにコンテキストを伸ばしたら落ちた」という症状の多くはKVキャッシュ不足が原因であり、量子化を下げる・コンテキスト長の上限を下げる・同時実行数を減らす、のいずれかで対処することになる。

- 自分のPC・Macで個人的に試したい／プログラミングツールから呼び出したい → まず Ollama。CLIとAPIが手軽で、多くの周辺ツールが標準で対応している
- コマンドを打つより画面で操作したい／初めてローカルLLMを触る → LM Studio。モデル探し・設定調整がGUIで完結する
- 細かいビルドオプションまで自分で制御したい／最新のGGUF機能を試したい → llama.cpp本体を直接使う
- Macbook等のApple Silicon機で、統合メモリを活かして大きめのモデルを動かしたい → MLX（対応モデルがあれば）
- 社内・チームで複数人が同時にAPIを叩く、あるいは製品としてLLMをサービングする → vLLM。連続バッチ処理でスループットを稼げる
- NVIDIA GPUのクラスタで本番運用し、レイテンシ・スループットを限界まで詰めたい → TensorRT-LLM。導入・チューニングの手間はかかるが最適化の余地が最も広い

迷ったら、まず Ollama か LM Studio で動作確認をしてから、必要になった時点で vLLM や TensorRT-LLM への移行を検討する、という順番が現実的である。

- プロンプトテンプレートの差: モデルごとに定められたチャットテンプレート（システムプロンプトの書式や区切りトークン）をエンジンが自動適用する場合と、手動で指定が必要な場合がある。乗り換え後に出力が崩れたら、まずテンプレートの適用状況を疑う
- 停止トークン（stop token）の差: エンジンやサーバ設定によってデフォルトの停止トークンが異なることがあり、生成が止まらない・途中で切れるといった症状につながる
- 量子化方式の違いによる出力変化: GGUFのK-quantとAWQ/GPTQ/FP8では量子化の仕組みが異なるため、同じ「4bit」でも出力の傾向が変わることがある。品質を比較する際は同一プロンプト・同一パラメータで確認する
- モデルファイルの再取得が必要: GGUF系からsafetensors系（またはその逆）へ乗り換える場合、同じ重みでもフォーマット変換または再ダウンロードが必要になることが多い
- APIの微妙な非互換: いずれもOpenAI互換を謳うが、パラメータの対応範囲やデフォルト値には差があるため、乗り換え後は主要なリクエストパターンで動作確認をしておきたい

- VRAM不足でモデルが読み込めない・落ちる: エラーメッセージにメモリ関連の記述がないか確認し、より軽い量子化（例: Q5_K_M→Q4_K_M）に変更するか、コンテキスト長の上限を下げてみる
- モデルが読み込めない（フォーマットエラー）: 使っているエンジンが対応する形式か確認する（GGUF専用のエンジンにsafetensorsを渡そうとしていないか等）。バージョンが古く新しいモデルアーキテクチャに未対応、というケースもある
- 動くが遅い: GPUオフロードが有効になっているか（CPUのみで動いていないか）を確認する。次に、量子化レベルとコンテキスト長、同時実行数を見直す。単発利用でvLLM/TensorRT-LLMのような連続バッチ処理系を使っても速くなるとは限らない点にも注意したい
- 同時アクセスで急に遅くなる: 単発レイテンシ重視のエンジン（Ollama/llama.cpp/LM Studio）を複数人・複数アプリから同時に叩いていないか確認する。恒常的に同時アクセスがあるなら、vLLM等への切り替えを検討する時期といえる