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