推論エンジン比較

エンジンは重みをトークンに変えるプログラム。ファイルをロードし、transformerのフォワードパスを実行し、たいていその上でHTTPを話す。良い知らせは、ほぼすべてのエンジンが同じハードウェアで同じモデルをほぼ同じ速度で動かすこと——エンジン選択の軸はワークフロー、フォーマット対応、同時実行であって、生のtok/sではない。悪い知らせも同じ。エンジン間のベンチマーク物色は大抵無駄な努力。

主な顔ぶれ

エンジン	正体	フォーマット	対応ハードウェア	目的
llama.cpp	内蔵サーバ付きのC/C++推論コア	GGUF	CPU、CUDA、ROCm、Metal、Vulkan——最広	基盤。ほぼどこでも動く
Ollama	llama.cppをモデルライブラリ、CLI、RESTで包んだもの	GGUF	llama.cppが対応するすべて	ゼロ摩擦のデスクトップ利用
LM Studio	洗練されたGUI+OpenAI互換サーバ	GGUF(MacではMLXも)	Windows/macOS/Linux GUI	フラグでなくボタンが欲しい人
vLLM	Pythonサービングエンジン。ページドアテンション、コティニュアスバッチング	safetensors	CUDA(一部ROCm/TPU対応)	データセンター級の同時サービング
SGLang	RadixAttentionプレフィックスキャッシュ搭載サービングエンジン	safetensors	CUDA	高速な構造化出力。プレフィックス共有エージェント
exllamav2	デコード速度に特化したGPU専用ローダ	EXL2、GPTQ	CUDAのみ	1枚のコンシューマNVIDIA GPUでの最大単一ユーザーtok/s
MLX	Appleの配列フレームワーク。`mlx-lm`がその上でモデルを動かす	MLX	Apple Silicon	最近のMacでの速い実用経路
transformers(HF)	すべての移植元のリファレンス実装	safetensors	CPU、CUDA	正当性確認、実験、学習の配管

系統の注記が1つ。OllamaとLM Studioはどちらも内部でllama.cppを動かす。llama.cppとの比較は推論ではなくパッケージングの比較。

知っておく価値があるもう1つ。llama.cppはサーバ以上のものを同梱する——量子化・変換ツール、ベンチマークハーネス、十数言語のバインディング。

深掘り

vLLMはページドアテンションの洞察から生まれた(同時実行を参照)。GPUメモリをOSがRAMを扱うように扱えば、はるかに多くのリクエストが収まる。「GPUサーバと本物のトラフィックがある」へのデフォルトの答え。

SGLangはリクエストをまたいでプレフィックスをキャッシュする(RadixAttention)。40のエージェントが同じ2ページのシステムプロンプトを共有すれば、プロンプトは40回ではなく1回処理される。高速な制約付きデコーディングでも知られる——構造化出力を参照。

exllamav2は、1つのニッチだけのための鋭い刃。1枚のNVIDIA GPUの上の1人のユーザーが、量子化ビットあたり最大のtok/sを求める局面。サーバの物語とハードウェアの幅は薄いが、ニッチは本物。

MLXはユニファイドメモリのために作られたAppleのMLフレームワーク。執筆時点でmlx-lmは大きいモデルでllama.cppのMetal経路にしばしば勝つ——Macでは両方試す価値がある程度の接戦(Apple Siliconで詳しく)。

transformersは遅くて忠実なリファレンス。量子化エンジンが奇妙なことをしたら、同じモデルをこれで動かせば「エンジンのせいかモデルのせいか」に答えられる。ファインチューニングツールの下の配管でもある(ファインチューニングを参照)。

必要で選ぶ

あなたは…	最初に
自分の机でチャット	OllamaまたはLM Studio
シェルからスクリプト(パイプ、cron、小道具)	OllamaのREST APIか`llama-server`
軽トラフィックのアプリバックエンド構築	`llama-server`——1プロセス、運用ゼロ
多数の同時ユーザーをサーブ	vLLMまたはSGLang
長いシステムプロンプトを共有するエージェント艦隊	SGLangまたはvLLM。エージェントを参照
全員Macの世帯	まずOllama/LM Studio。速度が欲しければMLX

表について2つの注記。

「最初に」は「満足せよ」ではない——すべてのデスクトップエンジンが同じGGUFを読むので、2つ目を試すコストは移行ではなく5分。
比較するときはすべてを固定すること。同じモデル、同じ量子化、同じプロンプト、モデルはウォーム済み。

フォーマットの分裂はデスクトップ/サーバの分裂の鏡像

GGUF対safetensors(モデルフォーマットを参照)は単なるコンテナの好みではなく、エンジンを決める。GGUFは単一ファイルで事前量子化済み、どこでも動くフォーマットで、デスクトップエコシステム全体(llama.cpp、Ollama、LM Studio)がその上に建つ。safetensorsはHugging Faceエコシステムのシャード化テンソルフォーマットで、高スループットのサーバエンジン(vLLM、SGLang、transformers)が消費する。たいていは事前パッキングではなく、その場で量子化(AWQ/GPTQ派生)。

つまり本当の決定木は短い。デスクトップと単一ユーザー → GGUFエンジン。サーバと同時実行 → safetensorsエンジン。残りはすべて詳細。

何かが「動かない」とき、最初にフォーマットを確認する——「エンジンXはモデルYを動かせない」の半分はGGUF/safetensorsの不一致であって、能力の差ではない。

オーバーヘッドは主役ではない

同じハードウェアで同じ量子化なら、エンジンは単一ストリームデコードでお互いの概ね10〜20%以内に収まる——しばしばバックエンドを共有するから。体験速度をパーセントでなく倍率で動かすのは次のもの。

モデルがすでにロード済みか——コールドロードは数秒〜1分。
会話全体が毎ターン再送されるか——コンテキストのコスト。トークンを参照。
リクエストが互いに並んで待つか——同時実行を参照。
レイヤーがGPUに載っているか——エンジンノブを参照。

同じGPU、同じ8B Q4_K_M、単一ストリーム(参考値、スペックではない):
llama.cpp / Ollama / LM Studio    ~130–145 tok/s   (下は同じエンジン)
exllamav2 EXL2 ~4bpw              ~160–180 tok/s   (デコード特化ローダ)

同じGPU、8つの同時チャットストリーム:
llama-server serial queue         各ストリームが待つ。合計スループットは横ばい
vLLM                              全ストリームが単一ストリーム速度に近い

ワークフローに合うエンジンを選び、エネルギーはエンジンベンチマークではなくI/Oパターンに注ぐこと。

1つのファイル、多くのエンジン

Ollama用にダウンロードしたGGUFは、llama.cpp直接でもLM Studioでも動く。エンジンは変換も再ダウンロードもせず、同じファイルを指せばいい(Ollamaは1行のModelfileでローカルパスをインポートできる)。サーバ側のvLLMとSGLangの間のsafetensorsも同様。実用的な帰結:ファイルレベルのベンダーロックインは存在せず、エンジンを間違えてもコストは数分。

だからこのページはベンチマークよりワークフローを押し続ける。ニーズが変わっても、ダウンロード済みのモデルはあなたと一緒に引っ越す。

Ollamaを卒業するタイミング

Ollamaのデフォルトは、そうでなくなるまで優れている。サービングエンジンへ移行するのは次のとき。

数ストリームを超える持続的な同時実行が必要(同時実行を参照)。
システムプロンプトを共有する多数のエージェントをまたぐプレフィックスキャッシュが欲しい(SGLang)。
HFエコシステムのAWQ/GPTQ safetensors量子化を直接サーブする必要がある。
出荷前のプロダクト機能をロードテストしている。
1つの大きいモデルをカードにまたげるマルチGPUテンソル並列が必要。

どれかが真になるまで、利便性はスループットより価値がある。