Ollamaとllama.cppの違いは？用途別の選び方と比較

公式資料の再確認: 2026年10月11日（Asia/Tokyo）。両プロジェクトの現行公式文書と2026年9〜10月のrelease noteを照合しました。
検証区分: 机上調査です。インストール、モデル取得、推論速度、メモリ使用量、API応答は実測していません。起動オプションやbackendの対応は更新されるため、実行前に利用中のversionとhelpを確認してください。
画像: アイキャッチは共通GGUFから、扱いやすい運用と細かな制御へ分かれる考え方を表す当サイトの要点図解です。実測結果や公式画面ではありません。

Ollamaとllama.cppの違いを一表で比較

Ollamaはモデルを取得・管理して使う流れをまとめるruntime、llama.cppはGGUFと推論条件を直接指定しやすい実行ツール群です。ただし機能は重なります。OllamaはGGUFをimportでき、llama.cppもllama-serverでAPIを提供します。名前だけでなく、変更したい設定や問題の切り分け方で選びます。

「Ollamaの中身はllama.cpp」だけでは説明不足

Ollamaの公式repositoryはllama.cppをsupported backendに挙げています。一方、Ollamaのv0.34.3 release noteは、選択されたNemotron H vision modelをApple Silicon上のMLXでサポートすると記しています。これは特定モデルとversionの記述であり、全モデルがMLXを使う、または全モデルが同一のllama.cpp経路を通るという意味ではありません。

したがって、Ollamaを常に「同じ引数でllama.cppを起動するwrapper」と見なすのは不正確です。model形式、OS、Ollamaのversionによって実行経路が異なる場合があります。同じモデル名でもweightや量子化、chat template、context、backendが揃っていなければ、差をruntimeだけに帰属できません。

Ollamaがおすすめの4ケース

1. 最短でチャットを始めたい

公式CLIはモデルの実行、取得、一覧、停止を短いcommandで揃えています。

ollama pull gemma3
ollama run gemma3
ollama ps
ollama stop gemma3

GGUFの保存場所や起動引数を毎回組み立てるより、モデル名で操作したい人に向きます。ただしモデルのdownload容量とlicenseは実行前に配布ページで確認してください。

2. アプリから同じAPIを繰り返し呼びたい

Ollamaのlocal APIは通常127.0.0.1:11434で待ち受け、Python・JavaScriptの公式libraryやOpenAI互換APIの一部から呼び出せます。OpenAI互換はAPI全体の再現ではありません。local接続用clientの例ではAPI keyの引数が必要ですが、Ollama serverはその値を無視します。これは認証ではないので、ネットワーク公開時の保護には使えません。cloud model用APIはhttps://ollama.com/v1で、local serverとは接続先もデータ経路も異なります。

curl http://localhost:11434/api/chat \
  -d '{
    "model": "gemma3",
    "messages": [{"role": "user", "content": "3行で要約してください"}],
    "stream": false
  }'

3. SYSTEMやcontextをチームで再利用したい

Modelfileにはbase model、SYSTEM、TEMPLATE、PARAMETER、ADAPTER、licenseなどを記述できます。たとえばcontextとsystem messageを固定した別名modelを作れます。OllamaのFAQにある既定contextは4096 tokenですが、実際の設定はmodel、CLI、API、server設定で変わるため、呼び出し条件に合わせて明示します。

FROM gemma3
PARAMETER num_ctx 8192
SYSTEM あなたは技術文書を簡潔に要約するアシスタントです。

ollama create tech-summary -f ./Modelfile
ollama run tech-summary

設定をファイルで共有できる一方、元modelのlicenseや再配布条件まで自動的に解決されるわけではありません。

4. 複数モデルの日常運用を簡単にしたい

ollama ls、ollama ps、ollama rmでlocal modelと実行中modelを管理できます。毎回絶対pathを渡す必要がなく、アプリ側も同じbase URLでmodel名だけを切り替えられます。

llama.cppがおすすめの5ケース

1. GGUFをそのまま指定して動かしたい

llama.cppはlocal fileを直接指定できます。renameやimportを挟まず、downloadした実体と起動commandの対応を追いやすい構成です。

MODEL_GGUF="/absolute/path/to/model.gguf"

llama-cli \
  -m "$MODEL_GGUF" \
  -c 4096 \
  -n 128 \
  -cnv

GGUFの取得から始める場合はllama.cppでGGUFモデルを動かす方法を参照してください。

2. GPU offloadやKV cacheを細かく調整したい

device、GPU layer、split mode、batch／ubatch、Flash Attention、K／V cache type、contextなどをCLIで明示できます。OOMや速度低下の原因を1項目ずつ切り分けたいときに有利です。ただしoption名・既定値・backend対応はreleaseによって変わるため、手元のllama-cli --versionとllama-cli --helpを確認してください。主要引数の組み立て例はllama.cppコマンド実例集で確認できます。

3. 同一条件でbenchmarkを取りたい

llama.cppにはllama-benchが含まれます。binaryのSHA、GGUFのhash、device、context、batch、threadsを記録すれば、変更前後を比較しやすくなります。「Ollamaより速い／遅い」と先に決めず、同じweightと条件でprompt processingとtoken generationを分けて測ります。

速度が出ない場合の確認順はllama.cppが遅い原因と高速化設定にまとめています。

4. 新しいmodel architectureを早く検証したい

llama.cppの開発branchとreleaseでは、新architecture、GGUF metadata、backend対応が更新されます。公式release履歴にもCLIやMetal関連の変更が続くため、特定versionのoptionを常に現行のものとして扱わないでください。再現性が必要ならbinaryのversionまたはcommit SHAを記録し、更新時に同じ条件で再確認します。

5. 問題をruntimeとmodelに分離したい

Ollamaでmodelが失敗したとき、同じGGUFをllama.cppで直接loadすると、file自体の問題かOllama側のimport／engine経路かを切り分けられます。逆にllama.cppで複雑な引数を組んでいる場合、Ollamaの標準構成で動けばcustom設定を疑えます。GGUFが読み込めない場合の対処法と組み合わせると調査しやすくなります。

独自GGUFは両方で使える

llama.cppで直接実行する

llama-cli -m /absolute/path/to/custom-model.gguf -c 4096 -cnv

Ollamaへimportする

Ollama公式docsでは、ModelfileのFROMへGGUFの絶対pathまたは相対pathを書き、ollama createでmodelを作る手順が案内されています。

FROM /absolute/path/to/custom-model.gguf
PARAMETER num_ctx 4096

ollama create custom-local -f ./Modelfile
ollama run custom-local

import後の出力がllama.cpp直実行と違う場合、まず次を揃えます。

1. 同じGGUF fileとSHA-256か
2. 同じchat templateとsystem messageか
3. context lengthと生成上限が同じか
4. temperature、top-p、top-k、seed、stop sequenceが同じか
5. vision modelなら画像projectorを含む対応方法が一致するか
6. 実際に選ばれたbackendとoffload状態が同じか

モデル名だけを揃えても比較条件は揃いません。特に配布libraryのtagは更新される場合があるため、再現性が必要ならdigest、GGUF hash、runtime versionを記録します。

比較結果が違うときの確認順

1. 同じ実体か: 元GGUFのSHA-256、quantization、split shard一式を記録します。Ollamaへのimportは元GGUFをquantizeしないと公式docsにありますが、モデル名とtagだけでは同一fileを証明できません。
2. 同じ入力か: system message、chat template、user prompt、stop sequence、temperatureなどsampling条件を揃えます。seedを固定しても、異なるbackendや演算順で完全一致するとは限りません。
3. 同じ負荷か: context上限、生成token数、batch、同時request数を記録します。OllamaはFAQで既定contextを4096とし、同じmodelへのparallel request数に応じて必要RAMが増えると説明しています。ollama psでロード中のmodelとprocessorを確かめ、llama.cpp側では指定した-cやserver slotを記録します。 Ollamaの表示列の読み方は実行中モデルの配置と解放予定を確認する方法も参照してください。
4. 指標を分ける: prompt processingと生成token/sは別に記録します。加えて起動時間、実行中メモリ、swapやmemory pressureを観察します。片方だけを有利にする長いcontextや並列数を混ぜず、同一Macで一方ずつ測ります。

これは比較条件を揃えるための手順であり、この記事は速度や品質の実測順位を示していません。

用途別の最終判断

Macでは先にメモリ別・動かせるローカルLLM一覧でmodel規模を絞ってください。runtimeを変えても、weightとKV cacheが物理メモリへ収まる必要がある点は変わりません。

外部公開するときの注意

Ollamaは既定で127.0.0.1:11434、llama-serverは既定で127.0.0.1:9931にbindします。listen addressを変更すると別端末から到達可能になる場合があります。Ollamaのlocal OpenAI互換client例にあるAPI keyはserver側で無視されます。認証として数えないでください。llama.cpp公式server guideはpublic deployment向けにAPI keyとreverse proxyを案内しています。いずれも公開前に認証、TLS、firewall、rate limit、logの個人情報対策を設計してください。

Ollamaにはlocal modelとcloud modelの両方があります。公式FAQではlocal実行のprompt・responseはOllamaへ送られない一方、cloud modelではprompt・responseをremote serviceへ送ると説明しています。使用modelとendpointを確認し、機密dataではlocal実行の設定を確認します。

参考資料

• Ollama公式FAQ（2026年10月11日確認、既定context、ollama ps、bind、cloud/local、並列request）
• Ollama公式：OpenAI互換API（2026年10月11日確認、互換範囲とlocal clientのAPI key）
• Ollama公式：モデルのimport（2026年10月11日確認、GGUF importとquantization）
• Ollama公式GitHub README（2026年10月11日確認、supported backendとREST APIの案内）
• Ollama公式GitHub v0.34.3（2026年9月19日公開、特定のApple Silicon向けMLX対応）
• llama.cpp公式CLI Reference（2026年10月11日確認、contextとGPU layer等のoption）
• llama.cpp公式server README（2026年10月11日確認、API、既定bind・port、context、公開時の認証指針）
• llama.cpp公式GitHub v0.6.0（2026年10月5日公開、releaseごとの変更履歴）