Ollama・LM Studio・GPT4Allの中身は全部llama.cppだった — それでも差が出る理由
RTX 4060 8GBでローカルLLMを動かすとき、フレームワーク選びにどれくらい悩むべきか。結論を先に言うと、速度差は最大11%、思ったほど出ない。
ただしVRAMオーバーヘッドの差は無視できない。0.3GBと1.5GBの違いは、8GBという制約下では「載せられるモデルが変わる」レベルのインパクトがある。
Ollama、LM Studio、GPT4All——名前は違うが中身は全部llama.cppだ。じゃあ何が違うのか。以下は同一モデル・同一ハードウェアでの推定比較だ。
比較対象と評価軸
フレームワーク一覧
frameworks = {
"llama.cpp (CLI)": {
"version": "b8233 (2026-03)",
"backend": "CUDA + Metal + CPU",
"quantization": "GGUF (Q2_K ~ FP16)",
"API": "CLI / llama-server (OpenAI互換)",
"特徴": "最小オーバーヘッド、最大制御",
},
"Ollama": {
"version": "0.6.x",
"backend": "llama.cpp (内蔵)",
"quantization": "GGUF (Ollama Hub経由)",
"API": "REST API + CLI",
"特徴": "Docker的な使いやすさ、モデル管理の簡単さ",
},
"LM Studio": {
"version": "0.3.x",
"backend": "llama.cpp (内蔵)",
"quantization": "GGUF (GUI検索)",
"API": "OpenAI互換API + GUI",
"特徴": "GUI、初心者向け、function calling対応",
},
"vLLM": {
"version": "0.7.x",
"backend": "独自CUDA kernel + PagedAttention",
"quantization": "AWQ, GPTQ, FP8, GGUF (v0.4.2+)",
"API": "OpenAI互換API",
"特徴": "バッチ処理最適化、サーバー向け",
},
"GPT4All": {
"version": "3.x",
"backend": "llama.cpp + 独自バックエンド (v3.xでVulkan/nomic移行中)",
"quantization": "GGUF",
"API": "GUI + Python SDK",
"特徴": "最も簡単、オフライン特化",
},
}
重要な事実: Ollama、LM Studio、GPT4Allはいずれもllama.cppをベースにしている（GPT4All v3.xは独自バックエンドへの移行も進行中）。違いはラッパーの設計だ。vLLMだけが独自のCUDAカーネルを持つ。
評価軸
evaluation_axes = {
"推論速度 (t/s)": "同一モデル・同一量子化での生成速度",
"VRAMオーバーヘッド": "モデル以外に消費されるVRAM (フレームワーク自体の消費)",
"初回起動時間": "モデルロード完了までの時間",
"API互換性": "OpenAI API互換の有無と品質",
"function calling": "ツール呼び出しのサポートと精度",
"セットアップ難易度": "インストールから推論開始までの手数",
}
推論速度比較
テスト条件
test_config = {
"GPU": "RTX 4060 Laptop (8GB VRAM)",
"model": "Qwen2.5-7B-Instruct Q4_K_M (4.7GB)",
"prompt": "Explain the difference between TCP and UDP in 200 words",
"max_tokens": 256,
"temperature": 0.7,
"context_length": 4096,
"measurement": "推定値 (公開ベンチマーク・公式ドキュメント・オーバーヘッド差から算出。実測ではない)",
}
結果
フレームワーク Prompt処理 生成速度 TTFT VRAMオーバーヘッド
(t/s) (t/s) (ms) (モデル以外)
────────────────────────────────────────────────────────────────
llama.cpp (CLI) ~800 32.1 120 ~0.3 GB
llama-server ~780 31.5 135 ~0.4 GB
Ollama ~750 30.2 180 ~0.5 GB
LM Studio ~720 29.8 250 ~0.6 GB
GPT4All ~680 28.5 300 ~0.7 GB
vLLM N/A* N/A* N/A* ~1.5 GB+
* vLLM はデフォルト設定で8GB VRAMでのOOMが発生
(PagedAttentionのKVキャッシュ事前確保が追加VRAMを消費するため)
分析
speed_analysis = {
"llama.cpp vs Ollama": {
"差": "32.1 vs 30.2 = 5.9%",
"原因": "OllamaのREST APIレイヤー + モデル管理デーモンのオーバーヘッド",
"実用的影響": "ほぼ無視できる。利便性で相殺",
},
"llama.cpp vs LM Studio": {
"差": "32.1 vs 29.8 = 7.2%",
"原因": "GUI + 追加のAPI抽象化レイヤー",
"実用的影響": "GUIの恩恵が速度差を上回る用途が多い",
},
"llama.cpp vs GPT4All": {
"差": "32.1 vs 28.5 = 11.2%",
"原因": "Python SDKのオーバーヘッド + 非最適化なデフォルト設定",
"実用的影響": "初心者には許容範囲だが、最適化余地あり",
},
"vLLM": {
"問題": "8GB VRAMで7Bモデルが動かない",
"原因": "PagedAttention のメモリ管理が追加VRAMを消費",
"用途": "16GB+ のサーバー用途に限定",
},
}
# 結論: llama.cppが最速だが、差は6-11%
# 8GB VRAMでの最大の違いはオーバーヘッド (0.3GB vs 1.5GB)
# オーバーヘッドの差でモデルサイズの上限が変わる
VRAMオーバーヘッドが8GBで致命的になるケース
8GB VRAMでは、フレームワークのオーバーヘッドが直接的にモデルサイズの上限を決める。
# 各フレームワークで載せられる最大モデルサイズ
max_model_size = {
"llama.cpp": {
"overhead": 0.3,
"cuda_context": 0.3,
"available_for_model": 8.0 - 0.3 - 0.3, # 7.4 GB
"max_model": "Qwen2.5-32B Q4_K_M (18GB) → 7.4GB on GPU + 10.6GB CPU offload",
"max_full_gpu": "Mistral-Nemo-12B Q4_K_M (7.2GB) → ぎりぎり",
},
"Ollama": {
"overhead": 0.5,
"cuda_context": 0.3,
"available_for_model": 8.0 - 0.5 - 0.3, # 7.2 GB
"max_full_gpu": "7B Q4_K_M (4.7GB) → 余裕あり、12B → やや厳しい",
},
"LM Studio": {
"overhead": 0.6,
"cuda_context": 0.3,
"available_for_model": 8.0 - 0.6 - 0.3, # 7.1 GB
"max_full_gpu": "7B Q4_K_M (4.7GB) → 余裕あり、12B → 厳しい",
},
"vLLM": {
"overhead": 1.5,
"cuda_context": 0.3,
"available_for_model": 8.0 - 1.5 - 0.3, # 6.2 GB
"max_full_gpu": "7B モデルでも余裕がない",
"note": "8GBでの使用は非推奨",
},
}
llama.cppとvLLMのオーバーヘッド差は1.2GB。この1.2GBがあれば:
- KVキャッシュの割り当てを増やしてコンテキスト長を拡張
- BGE-M3 Embeddingモデルを同居させる余地
- モデルのGPUオフロード比率を上げて推論を高速化
8GB VRAMでは、フレームワークの選択は「好み」ではなく「アーキテクチャ上の意思決定」だ。
function calling対応状況
function calling記事（別記事）で示したように、ツール呼び出しはローカルLLMのキラー機能だ。各フレームワークの対応状況:
function_calling_support = {
"llama.cpp (llama-server)": {
"対応": True,
"方式": "OpenAI互換 tools パラメータ",
"GBNF grammar": True, # JSON出力を文法的に強制
"品質": "モデル依存。Qwen2.5-7B-Instruct + GBNF grammarで高精度",
"制約": "手動でサーバー起動が必要",
},
"Ollama": {
"対応": True,
"方式": "OpenAI互換 tools パラメータ (v0.4+)",
"GBNF grammar": False, # GBNF直接指定は不可、formatパラメータでJSON Schema指定は可能
"品質": "llama.cppベースのため同等水準",
"制約": "GBNF grammarは非対応。ただしformat指定でJSON Schema準拠の構造化出力は可能",
},
"LM Studio": {
"対応": True,
"方式": "OpenAI互換 tools パラメータ",
"GBNF grammar": True, # JSON Schema enforcement
"品質": "GUI上でテスト可能なのが利点",
"制約": "バックエンドはllama.cppと同等",
},
"vLLM": {
"対応": True,
"方式": "OpenAI互換 tools + Guided Decoding",
"品質": "Guided Decodingで高精度",
"制約": "8GBではgpu_memory_utilization調整が必要、実用的には16GB+推奨",
},
"GPT4All": {
"対応": False,
"note": "function calling非対応。チャットのみ",
},
}
GPT4Allはfunction calling非対応。エージェント用途には使えない。vLLMのGuided Decodingは強力だが8GBでは実用的に厳しい。結局、8GBでfunction callingを使うならllama.cpp系（直接 or Ollama or LM Studio）一択。
用途別の推奨
recommendations = {
"最大性能が欲しい (開発者)": {
"推奨": "llama.cpp (CLI / llama-server)",
"理由": [
"最小オーバーヘッド (0.3GB)",
"GBNF grammarで構造化出力を強制可能",
"全パラメータを直接制御",
"GPU/CPUオフロードの細粒度制御",
],
"欠点": "セットアップに知識が必要、GUIなし",
},
"手軽に使いたい (日常利用)": {
"推奨": "Ollama",
"理由": [
"docker pull 的な簡単さ (ollama pull model)",
"バックグラウンドデーモンで常駐",
"OpenAI互換APIで既存コードから差し替え可能",
"速度差はllama.cppと6%以内",
],
"欠点": "GBNF grammar非対応（JSON Schema指定は可能）、オーバーヘッドやや大きい",
},
"GUIで試行錯誤したい": {
"推奨": "LM Studio",
"理由": [
"モデル検索・ダウンロードがGUIで完結",
"チャットUIでリアルタイムテスト",
"function callingのテストがGUI上で可能",
],
"欠点": "GUIレイヤーのぶんメモリ消費がやや多い",
},
"とにかく簡単に始めたい (非エンジニア)": {
"推奨": "GPT4All",
"理由": [
"インストール→起動→会話 が最速",
"オフラインで完結",
"余計な設定項目がない",
],
"欠点": "function calling非対応、速度が最も遅い、カスタマイズ性低い",
},
"プロダクション・サーバー用途": {
"推奨": "vLLM (16GB+ GPU推奨) or llama-server",
"理由": [
"vLLM: PagedAttentionでバッチ処理が効率的",
"llama-server: 8GBでも動く軽量サーバー",
],
"欠点": "vLLMは8GBでは動かない",
},
}
8GBでの結論
問い: 8GB VRAMで最適なフレームワークは？
答え: 用途による。だが、技術的に最適なのはllama.cpp直接実行。
理由:
1. オーバーヘッドが最小 (0.3GB) → 使えるVRAMが最大
2. 速度が最速 (他フレームワーク比 +6-11%)
3. GBNF grammarで構造化出力を強制 → function callingの信頼性が最高
4. GPU/CPUオフロード比率を1レイヤー単位で制御可能
ただし:
- 日常利用ならOllamaの利便性が速度差を上回る
- GUIが必要ならLM Studio一択
- vLLMは8GBでは使えない (16GB以上推奨)
- GPT4Allはエージェント用途に不向き (function calling非対応)
全フレームワークの速度差は11%以内。
フレームワーク選択よりモデル選択の方がはるかに重要。
Qwen2.5-3B (2.0GB) → Qwen2.5-7B (4.7GB) の差の方が、
llama.cpp → GPT4All の差より遥かに大きい。
速度差11%のために最適化に時間をかけるか、その時間でモデルの選定を詰めるか。8GBでは後者の方がリターンが大きい。ただしVRAMオーバーヘッドの差だけは、モデルサイズの上限を物理的に変えるので無視できない。
参考文献
- llama.cpp — github.com/ggerganov/llama.cpp
- Ollama — ollama.ai
- LM Studio — lmstudio.ai
- vLLM — vllm.ai
- GPT4All — gpt4all.io
- "Efficient Memory Management for Large Language Model Serving with PagedAttention" (2023) arXiv:2309.06180