ローカルLLMは、結局どれで始める？ llama.cpp / Ollama / LM Studio の関係を整理してみた
ローカルLLMを使おうと検索すると、だいたい同じ3つのツールの名前にたどり着きます。それはllama.cpp、Ollama、LM Studioです。
それぞれの紹介記事はたくさんあるんですが、「この3つがどういう違いがあるのか、自分はどれを使えばいいのか」を教えてくれる記事は意外と少ない。全部同じもの？ 競合？ どれが一番いいの？ …と、この時点で手が止まってしまう方もけっこう多いのではないでしょうか。
自分もWindows、Mac、Linuxと雑多な環境でローカルLLMをあれこれ触ってきましたが、最初のころは同じように引っかかっていました。それがあるとき、「この3つは競合しているのではなくレイヤー（層）が異なるのでは？」と考えてみると、意外とスッキリしました🤗
この記事では、これら3つのツールの関係をレイヤー構造を使ってで整理し、
それぞれのツールの素顔と得意分野
「チャットを始めるまで」の流れの違い
結局どれから始めればいいのかの早見フローチャート
についてまとめてみました。
⚠️「どのモデルを選ぶか」（QwenなのかLlamaなのかGemmaなのか）には今回は触れません。これについては沼が深いですし。
⚠️また、 この分野はツールの進化がとても速いです。最新の対応状況（特にOllamaのLinux GUI対応やLM Studioのサーバー機能あたり）は各公式サイトも合わせて確認してください。
3つの関係は「レイヤー」で見るとすっきりする
先に結論の図を出してしまいます。
LM Studio … 一番上の層。GUIアプリとして「探して試す」体験に全振り
Ollama … 真ん中の層。モデル管理とローカルAPIを整えた、開発者向けの層
llama.cpp … 一番下の層。推論エンジンそのもの。すべての土台。
大事なのは、図の左側にある矢印で、下のレイヤーほど自由度が高く、上のレイヤーほど手間が減るということです。
こうやって整理すると「どれが一番優れているか」という問いが、あまり意味を持たないと分かります。どちらかというと用途によって必要な層が違うという話になります。
ちなみにOllamaもLM Studioも、もともとはllama.cppを土台にして作られています。ただ、最近はOllamaが独自エンジン化を進めていたり、LM StudioがApple Silicon向けにMLXという別エンジンを積んでいたりと、「単なるllama.cppのラッパー」とは言いにくくなってきているんですが、レイヤーという関係性は大きくは変わっていません。
それぞれの素顔を考えてみる
各ツールについて順番に見ていこうと思います。
llama.cpp … すべての土台となる推論エンジン
C/C++で書かれた推論エンジンで、ローカルLLM界の土台中の土台です。GGUFという形式のモデルファイルをHugging Faceなどから自分でダウンロードしてきて、直接指定して動かします。
llama.cppには最初からWebUIが付いています。llama-serverというアプリ を起動するだけで、ブラウザからチャットできる画面が立ち上がります。最近のこのWebUI、会話履歴の管理からパラメータ調整までできて、普通に実用的なレベルになっています。
モデル管理は完全に手動、ビルドや量子化のオプションは無数。手間はかかりますが、そのぶんすべてを自分で制御できます。
Ollama … モデル管理とAPIを整えた層
llama.cppの「モデル管理が手動」という部分を解決したのがOllamaとなります。ollama pull qwen2.5:7b と打てばモデルが落ちてきて、ollama run ですぐチャットができる。複数モデルの切り替えも一瞬で行えます。
もうひとつの顔が、localhost:11434で待ち受けるREST APIです。これが事実上の標準になっていて、Open WebUI、LangChain、各種エディタ拡張と、世の中の多くのツールが「Ollamaがいる前提」で作られています。
⚠️2025年にOllamaにも公式のGUIアプリが登場したんですが、対応はmacOSとWindowsのみ。Linuxでは今もCLI＋サーバーだけなんです。Ubuntu機にインストールをした後に、「あれ、画面は…？」と探してしまいました😅 Linuxで画面が欲しい場合は、Open WebUIなどを別途立てることになります。
LM Studio … モデル探索体験に全振りしたGUIアプリ
LM Studioは終始GUIで完結します。アプリを起動すると、いきなりモデル検索画面。量子化バリエーションを見比べられて、「このモデルは自分のマシンのメモリに収まるか」を事前に教えてくれて、ワンクリックでダウンロード、そのままチャット。
この「探す→比べる→試す」の体験は、3つの中で頭ひとつ抜けているといえるでしょう。新しいモデルが出たときにとりあえず触ってみる用途なら、これが一番速いんですよね。
エンジンとしてはllama.cppに加えて、MLXを積んでいるので、Apple SiliconのMacではむしろ本命だったりします。クラウド機能を一切持たない純ローカル設計なのも、扱う情報に気を使う場面では安心材料です。
同じことをするのに、通る道がぜんぜん違う
3つのツールの性格がわかったところで、「チャットを始めるまで」のフローを並べてみます。
ステップ数を見ると、LM Studioが3〜4ステップ、Ollamaが5ステップ、llama.cppが5〜6ステップ。数字の差は小さく見えるんですが、体感はかなり違うようにみえます。llama.cppの「環境準備」や「モデル配置」は、初めてだと大きな苦労がある手順を含みます。一方でLM Studioは、アプリを入れた瞬間からゴールが見えている状態です。
ワークフロー全体を並べるとこうなります。
こうして見ると、3つとも「ローカルでLLMを動かす」というゴールは同じなのに、通る課程と道具の便利さが大きく違うのがわかります。llama.cppはターミナルとファイルの世界、OllamaはコマンドとAPIの世界、LM Studioは画面の世界を扱っています。
Linuxで起きている、ちょっと面白い逆転現象
先ほどのLinuxの話をここで思い出してほしいんですが、実はちょっと面白い逆転現象があります。
「Linuxで、追加ツールなしにWebUIまで欲しい」場合、一番手っ取り早いのは素のllama.cppだったりするんです。Ollamaを入れてもLinuxでは画面が付いてこないので、llama-serverを1本立てるほうが早い。
土台のほうが手軽、という場面が実在してしまっています。便利にするために作られたレイヤーが、環境によっては逆に遠回りになるという逆転現象。ローカルLLM界隈のこういうところ、個人的にはけっこう好きです🤗
で、どれから始めればいいのか
ここまでの話を早見フローチャートにまとめました。
コードやAPIから使いたい、他のアプリと連携したい → Ollama
WindowsかMac（特にApple Silicon）で、まず試したい → LM Studio
Linuxで手軽に始めたい → llama.cpp（llama-serverでWebUIまで付いてくる）
そして迷ったら、上位のレイヤーから入って、物足りなくなったら下位のレイヤーの検討を行う。これが失敗しないルートかなと思っています。LM Studioで始めて、連携したくなったらOllamaへ、細部を制御したくなったらllama.cppへ。下位に移行する過程で、ローカルLLMの仕組みそのものへの理解も自然と深まっていくと思います。
とはいえ、どのツールを選んでも、動かせるモデル自体は同じなので、このの選択では失敗はしないですけどね🤣
おわりに
llama.cpp、Ollama、LM Studioと3つのツールのどれがいいか、レイヤーの仕組みを理解することで選び方自ずと決まります。
上位の層ほど手軽、下位の層ほど自由。自分の用途を考えてレイヤーを選ぶ
LinuxではWebUI事情に逆転現象あり。素のllama.cppが意外と快適
迷ったら上位の層から入って、必要になったら下位の層に降りる
基本無料ですし、手元の機材だけで完結します。まずは一番ハードルの低そうな入り口から、気軽に試すのがよさそうです😊
