中級 11 分llama.cpp

llama.cppとは何か、Ollamaから乗り換えるべきか ?

端的な回答

llama.cppは、GGUF形式のモデルをCPUやNVIDIA、AMD、Intel、Apple SiliconのGPUで実行するC/C++の推論エンジンです。Ollama、LM Studio、KoboldCppはいずれもこれを基盤としています。llama-serverを通じて直接使っても、同じハードウェアでモデルが速くなるわけではありません。その代わり、GPUとCPUへの処理の振り分け、コンテキストサイズ、KVキャッシュの量子化など、上位のアプリケーションがユーザーに代わって決めている設定を自分で調整できます。

llama.cppは、CとC++で書かれた推論エンジンです。GGUF形式のモデルをCPU、NVIDIA・AMD・IntelのGPU、そしてMacで実行します。2026年9月20日時点で、ローカルLLMアプリケーションの大半は、このエンジンまたはそのライブラリであるggmlを利用しています。Ollama、LM Studio、KoboldCpp、Janなどがその例です。直接使っても、モデルの実行速度が上がるわけではありません。その代わり、通常は上位のアプリケーションがユーザーに代わって決める設定を、自分で調整できるようになります。

著者 Mohamed Meguedmi·更新 2026-09-28·macOS 14+ でテスト済み

#llama.cpp についての概要

このプロジェクトは 2023 年 3 月に Georgi Gerganov によって開始され、Python や重い依存関係なしに Meta の LLaMA モデルを MacBook で実行するというシンプルな目標を持っていました。MIT ライセンスで公開されています。3 年後、このリポジトリ（ggml-org 組織に移行）は数百のアーキテクチャをサポートし、2023 年 8 月に定義されたファイル形式 GGUF は、量子化モデルの配布における事実上の標準となりました。

この成功を説明する技術的な選択は二つあります。一つ目は量子化です。llama.cppは2〜8ビットに圧縮された重みを使ってモデルを実行できるため、80億パラメータのモデルを16 GBではなく5 GBに収められます。二つ目は、CPUとグラフィックカードで処理を分担することです。モデル全体がVRAMに収まらない場合、一部の層をRAMに残し、残りをGPUに配置します。すべてをGPUに読み込む場合より遅くなりますが、動作します。この機能を提供するエンジンは少数です。

#箱の中身

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート
ローカルAIキット →または すべてのキットを無期限で利用 — 49 € →
llama-cli
コマンドライン用のチャット。モデルや設定を数秒でテストできます。
llama-server
OpenAI互換APIと内蔵ウェブインターフェースを備え、ポート8080で動作するHTTPサーバーです。上級ユーザーの大半が常時稼働させているコンポーネントです。
llama-bench
測定ツールです。プロンプトの読み取り速度と生成速度を別々に表示するため、思い込みに惑わされずに2つの設定を比較できます。
llama-quantize
フル精度のGGUFファイルを、より軽量な量子化形式（Q4_K_M、Q5_K_M、Q8_0）に変換します。

#上位レイヤーが追加するもの、隠すもの

Ollama、LM Studio、KoboldCppは、llama.cppが提供しない機能を備えています。モデルカタログ、1コマンドでのダウンロード、インターフェース、モデルの自動読み込みと解放です。その代わり、これらのツールがデフォルト値を設定します。以下の表は性能を比較するものではなく、誰が何を決めるのかを示しています。

制御の比較、速度の比較ではない · 2026年9月20日時点
設定llama.cpp単体OllamaLM StudioKoboldCpp
コンテキストのサイズ-c オプションで自由に設定可能デフォルト値は慎重に設定されており、変数またはModelfileで変更可能です。モデルごとのスライダー起動時のオプション
量子化の選択任意の GGUF ファイルカタログタグ、デフォルトでQ4ダウンロード候補の一覧任意の GGUF ファイル
GPUに送られるレイヤー数-nglオプション、レイヤー単位自動スライダー起動時のオプション
KVキャッシュの量子化オプション -ctk および -ctvグローバル環境変数高度な設定起動時のオプション
APIllama-server、OpenAI互換シンプルなAPI＋OpenAIとの互換性OpenAIと互換性のあるサーバーシンプルなAPI＋OpenAIとの互換性
エンジンの更新その日のうちに、コミットごとにデルタを適用する場合デルタを適用する場合デルタを適用する場合

最後の行は、見た目以上に重要です。新しいモデルアーキテクチャが登場すると、まずllama.cppで対応し、その数日〜数週間後に、それを利用する上位のツールが対応します。モデルの公開された週に試したいなら、llama.cppを使うのが唯一の方法となることもよくあります。

#すべてを変える 4 つの設定

-ngl (n-gpu-layers)
VRAMに配置するモデルのレイヤー数。値99は「収まる限りすべて」を意味します。モデルがVRAMを超えている場合は、読み込みが成功するまでこの数を下げてください: CPUに残した各レイヤーは生成を遅くしますが、8トークン/秒で動作するモデルの方が、起動しないモデルより良いです。
-c (ctx-size)
割り当てるコンテキストウィンドウのサイズです。KV キャッシュはそのサイズに応じて大きくなります。8B モデルでは、8,000 トークンから 32,000 トークンに増やすと、数 GB の VRAM が追加で必要になります。モデルが公表している最大値をそのまま割り当てるのではなく、必要な分だけ割り当ててください。
-fa (flash-attn)
Flash Attentionを有効にし、メモリ使用量を減らして長いプロンプトの処理を高速化します。KVキャッシュの量子化にも必須です。
--n-cpu-moe
MoEモデルの場合、一定数の層のエクスパートをRAMに保持し、残りはGPUに配置します。これにより、16 GBのカードで300億または1200億パラメータのMoEを、実用的な速度で動作させることができます。

#変更点：--fit が -ngl を自動で設定

長い間、llama.cppのガイドでは、まず-nglを手動で設定するのが定番でした。すべてをGPUに載せるために99を指定し、読み込みに失敗したら試行錯誤しながら値を下げる方法です。今では、この手順は必須ではありません。プロジェクトには、デフォルトで有効な--fitオプションが追加されています。これは、モデルが利用可能なメモリに収まるように、未指定のパラメータ（-nglを含む）を自動調整します。性能が控えめなカードでも、起動に失敗しては-nglを手動で下げるという、よくある繰り返しを避けられます。

→
-ngl 99 は依然として有効です
もし特定の配置を強制的に指定したい場合は、-ngl は以前とまったく同じように動作します。--fit は、自分で設定していないパラメータにのみ適用されます。動作の変更はデフォルト値に関するものであり、コマンド自体には影響しません。

#あなたのGPUに適したバックエンドは？

llama.cppは、特定の計算バックエンド向けにコンパイルするか、そのバックエンド向けのビルドをダウンロードして使います。適切な選択は、お使いのハードウェアだけで決まります。この表は、当サイトの90種類の構成データベースにある構成を系統別にまとめたものです。

QuelLLMのハードウェアデータベース（GPUとチップ計90種）に基づく分類 · 2026年9月20日
あなたのハードウェア推奨されるバックエンド注記
NVIDIA GTX 10〜RTX 50、デスクトップ向けおよびノートPC向けCUDA最も高速で、最も十分にテストされた方法です。
AMD Radeon RX 7000 および RX 9000ROCm (HIP) または VulkanROCmは、動作する場合にはより高速です。VulkanはWindowsでも手間なくインストールできます。
AMD Radeon RX 6000シリーズおよびそれ以前Vulkanカードにより ROCm のサポートは部分的または全くありません。
Apple M1 から M5MetalmacOSバイナリではデフォルトで有効です。すべての統合メモリが使用可能です。
IntelまたはAMDの内蔵GPU、Intel ArcVulkanまたはSYCL小型モデルにおいてCPUのみを使用する場合と比較した実際の性能向上。
GPU なしCPU（AVX2、AVX-512、NEON）どこでも動作します。パラメータ数80億以下のモデルを選んでください。

#llama.cppでの当社の測定結果

llama.cppは、すべてのプラットフォームで同じように動作するという理由から、当サイトのベンチマーク環境の基準エンジンです。以下は、Llama 3.1 8BをQ4で使用し、コンテキスト2,048トークン、リクエスト1件、Flash Attention有効という条件で測定した生成速度です。

測定済み · QuelLLMベンチマーク、llama.cpp b4280、2026年4月18日の記録 · 完全な表はBenchmarksページを参照
マシンメモリLlama 3.1 8B Q4
RTX 509032 GB172 tok/s
RTX 409024 GB128 tok/s
RTX 407012 GB76 tok/s
Mac M3 Max64 GBのユニファイドメモリ64 tok/s
RTX 306012 GB44トークン/秒
Ryzen 7 7700、CPUのみシステムRAM7.8 tok/s

ここから2つのことが読み取れます。まず、RTX 3060とCPUのみの場合には5〜6倍の差があり、エントリークラスのカードでも使用感が変わります。次に、計算エンジンが同じなので、同じマシンでOllamaやLM Studioを使っても、これらの数値はほぼ同じになるでしょう。

#Ollamaを使い続けるか、llama.cppに移行するか

次の場合はOllamaまたはLM Studioを使い続けてください…こんな場合はllama.cppに移行…
ドキュメントを読まずにモデルと会話したいモデルがVRAM容量に収まらず、GPUとCPUへの配分を細かく調整したい場合。
モデルを頻繁に切り替え、内蔵カタログを便利に感じている。今週公開されたアーキテクチャを試したい。
お使いのツール（Open WebUI、エディターの拡張機能）がOllamaのAPIを前提としている場合。長期運用するサーバーを構築し、コンテキストからKVキャッシュまで、すべての設定を自分で制御したい場合。

#10分で開始

試すためにコンパイルする必要はありません。リリースごとにWindows、macOS、Linux向けのコンパイル済みバイナリが公開されており、残りの作業はパッケージマネージャーが行います。以下のコマンドは、Hugging Faceから小さなモデルをダウンロードし、http://localhost:8080 でウェブインターフェースを開きます。

インストール後、サーバーを起動してください
# macOS et Linux (Homebrew)
brew install llama.cpp

# Windows
winget install llama.cpp

# Télécharger un modèle et ouvrir l'interface web
llama-server -hf ggml-org/gemma-3-4b-it-GGUF -ngl 99 -c 8192

カタログからより高性能なモデルを使う場合は、好みの GGUF ファイルを取得し、-m オプションで指定してください。ソースからのコンパイルが役立つのは、特定のバックエンドを有効にする場合や、日々の開発に追随する場合だけです。

#モデル読み込み時のよくあるエラー

llama.cppでのほとんどのトラブルは三つの原因に集約されます。メモリ超過、インストールされたビルドと互換性のないGGUFファイル、または誤ったスペルで入力されたオプションです。コマンドラインに表示されるエラーメッセージは、最後まで読み取れば、ほぼ常にこの三つのうちどれであるかを示しています。閉じて再実行するのではなく、最後までお読みください。

設定を変更する前にメッセージを読む
メッセージまたは症状考えられる原因試してみる
cudaMalloc failed: out of memory指定したコンテキストを含めると、モデルに必要なメモリ量が利用可能なVRAM容量を超えます-c を減らし、--fit が -ngl を自動調整できるようにするか、または軽量な量子化を選択する
unknown model architectureGGUFファイルは、インストールされたバイナリよりも新しいアーキテクチャを採用しています。公開されている最新版に更新する。新しいアーキテクチャへの対応は、まず llama.cpp に導入されます。
最新のGPUを備えているにもかかわらず、生成が非常に遅いすべてのレイヤーが GPU に移されているわけではありません。多くの場合、VRAM の空き容量不足が原因です。読み込み時の出力（「offloaded」の行）を確認し、GPUを使用している他のアプリケーションを閉じる
error: invalid argumentコマンドでのオプションの名前変更または誤記短縮形と長い形式のエイリアスを最新の状態で一覧表示する llama-server --help と比較する

サーバー起動時に表示される読み込みログの行は、一度全文を読んでおく価値があります。実際にGPUに送られたレイヤー数、有効なコンテキストサイズ、使用されるKVキャッシュの種類が分かるためです。うまく動くまで手当たり次第にオプションを追加するより、そのほうが早いことがよくあります。インストール済みのバージョンにも注意してください。llama.cppはナイトリービルドを非常に頻繁に公開しており、お使いのグラフィックスカードやモデル向けの修正がすでに公開されていても、先週インストールしたHomebrewやwingetのパッケージにはまだ含まれていないことがあります。

#FAQ

llama.cppはOllamaよりも速いですか？+
設定が同じなら、速くはありません。Ollamaは同じ計算エンジンを使っているため、生成速度はほぼ同じです。差が生じるのは設定によるものです。llama.cppでは、GPUに載せる層の数、コンテキストのサイズ、キャッシュの量子化を細かく指定できます。そのため、Ollamaでは一部がCPU側に残るモデルでも、VRAM内に収められる場合があります。
llama.cppを使うには、コンパイルの方法を知っている必要がありますか？+
いいえ。リリースごとにWindows、macOS、Linux向けのコンパイル済みバイナリが公開され、Homebrew（macOS、Linux）とwinget（Windows）でもパッケージを入手できます。インストールコマンドを1つ実行するだけで済み、コンパイラを使う必要はありません。ソースからのコンパイルが役立つのは、公式バイナリにない特定のバックエンドを有効にする場合、ローカルの修正を適用する場合、または公開済みのリリースではなく開発ブランチの変更を日々追う場合に限られます。
llama.cpp をグラフィックスカードなしで使用することは可能ですか？+
はい、むしろそれが本来の用途です。このプロジェクトは、GPU や Python を使わず、CPU だけでモデルを動かすことを目的に設計されました。最近の CPU では、Q4 の 8B モデルは当サイトのベンチマークで毎秒約 8 トークンの速度で動作します。遅いものの、チャットや要約では無理なく読み進められる速度です。140 億パラメータを超えると、ハードウェアアクセラレーションなしでは待ち時間がつらくなります。
llama.cppとvLLMの違いは？+
llama.cppは、ハードウェアの種類を問わず、個人用マシンでGGUF形式の量子化モデルを動かすことを想定しています。vLLMは、Hugging Faceの重みを使い、多数のリクエストを並列に処理するGPUサーバーを想定しています。前者は手元のマシンで動かせるモデルの幅を最大限に広げ、後者は共有GPUのスループットを最大化します。
Mac上でllama.cppかMLXか？+
どちらもユニファイドメモリを介してAppleのGPUを利用します。Appleが自社製チップ向けに開発したライブラリであるMLXは、最近のモデルでは速度で優位に立つことがよくあります。一方、llama.cppには、量子化済みGGUFファイルの膨大なラインアップと、コンテキストやKVキャッシュをより細かく調整できるという利点があります。実際、多くのMacユーザーは両方をインストールしたままにし、使いたいモデルで利用できる形式に応じて選んでいます。
このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。