ローカルLLMを試してみようとなって調べはじめると、Ollama、vLLM、Open WebUI、MCP、RAG……と、似たような場面で出てくる言葉がたくさんあります。わたしは最初、「Ollama ＝ LLM」だと思い込んでいて、そのせいで MCP や RAG の説明がまったく頭に入ってきませんでした。
この連載では、ローカルLLMのまわりの仕組みを、層（役割）ごとに分けて整理していきます。1 回目のこの記事では、いちばん土台になる「LLM」「実行環境」「ホスト」の 3 つを分けます。
連載の記事は次のとおりです。
- Ollama は LLM ではない？ LLM・実行環境・ホストの役割を分ける（この記事）
- LLM は道具を「頼む」だけ：tool calling と MCP の関係
- RAG と MCP の境目はどこにあるのか
- MCP サーバーはどこに置き、どう作るのか
- MCP の道具は REST API とは違う：「どんな単位で作るか」が大事
先に結論
| 層 | 例 | していること |
|---|---|---|
| LLM（モデル） | Qwen3、Llama、Mistral など | 渡された文章を読んで、続きの文章を出力するだけ |
| 実行環境 | Ollama、vLLM、LM Studio | モデルを GPU に読み込んで動かし、API として公開する |
| ホスト（司令塔） | Open WebUI、Dify、自作アプリ | 画面を出す、会話を管理する、LLM を呼ぶ、道具（MCP）をつなぐ |
Ollama は「LLM を動かすソフト」で、LLM そのものではありません。 そして、利用者が触るチャット画面を受け持つのは「ホスト」という、また別の層です。
LLM（モデル）とは
LLM は、大量の文章で学習した「大きな言語モデル」です。実体は、学習済みの数値（重み・パラメータ）が入った大きなファイルです。
ollama pull qwen3:8b を実行すると数 GB のファイルがダウンロードされますが、このファイルが LLM です。
なお、「LLM と名乗るための規格」のようなものはありません。LLM はあくまで呼び名で、満たすべき仕様が決まっているわけではありません。
実行環境とは
実行環境は、モデルのファイルを読み込んで動かすソフトです。たとえるなら、動画プレーヤーと動画ファイル、あるいは JVM と JAR の関係です。
| たとえ | 実体 | |
|---|---|---|
| 実行環境（Ollama など） | 動画プレーヤー／JVM | モデルを読み込んで動かし、API で公開するソフト |
| LLM（モデル） | 動画ファイル／JAR | 学習済みの数値が入った大きなファイル |
Ollama がしていることは、主に次の 3 つです。
- モデルのファイルを GPU（またはメモリ）に読み込んで動かす
- モデルごとに違う書式の違いを吸収する（次の記事で出てきます）
- OpenAI 互換 API として外に公開する（ホストはここにつなぐ）
同じ役割のほかのソフト
| ソフト | 向いている使い方 |
|---|---|
| Ollama | 手軽。個人や少人数向け |
| LM Studio | 画面で操作できる。個人の PC 向け |
| vLLM | 大勢が同時に使うときに強い。サーバー向け |
| llama.cpp | Ollama の中でも使われている土台の部品 |
「vLLM は大勢で使うときに強い」の意味
ここで疑問に思ったのが、「結局はモデルの大きさで速さが決まるのでは？ 同じモデルなら vLLM でもサクサク動くわけではないよね？」ということでした。
答えは、半分そのとおりです。
| 決めるもの | 何で決まるか |
|---|---|
| 1 人で使ったときの速さ・必要なメモリ | モデル（大きさ、量子化） |
| 大勢で使ったときに GPU をどれだけ無駄なく分け合えるか | 実行環境（Ollama か vLLM か） |
vLLM にしても、1 人で使うときの速さはほとんど変わりません。強いのは「同時に使ったときに、速さの落ち方が小さい」ところです。
なぜ同時に使うと差が出るのか
LLM は文字（トークン）を 1 つ出すたびに、モデルの重みを GPU のメモリから全部読み出します。実は遅さの主な原因はこの「読み出し」で、計算そのものは GPU に余裕があります。
- まとめて処理しない場合：A さんの 1 文字のために重みを全部読み、B さんの 1 文字のためにまた全部読む……
- vLLM の場合：1 回読み出すたびに、A さん・B さん・C さん……の次の 1 文字をまとめて計算する（continuous batching）
読み出しの回数は 1 人のときとほぼ同じなので、人数が増えても全体の処理量がほぼ人数分伸びます。
それでも限界はある：メモリの取り合い
同時に何人まで使えるかは、結局 GPU のメモリで決まります。
GPU のメモリ ＝ モデルの重み ＋ 会話ごとの作業メモリ（KV キャッシュ）× 同時人数
- 会話ごとの作業メモリは、会話や渡す文書が長いほど大きくなります（RAG で文書をたくさん入れると効いてきます）
- モデルが大きいほど重みがメモリを占め、作業メモリに回せる分が減ります。つまり、同時に使える人数も減ります
vLLM は、この作業メモリを細かく区切って無駄なく割り当てます（PagedAttention）。それでも、メモリが足りなければどうにもなりません。
まず GPU に合わせてモデルを選び、大勢で使うなら vLLM でその GPU を使い切る、という順番で考えるのがよさそうです。
ホスト（司令塔）とは
3 つ目の層がホストです。利用者が実際に触るチャット画面のアプリで、RAGって何？ の記事で「司令塔（オーケストレータ）」と呼んだものと同じです。
ホストがしていることは次のとおりです。
- 画面を出す
- 会話の履歴を管理する
- LLM（実行環境の API）を呼ぶ
- 道具（MCP サーバー）につなぐ
LLM は会話のことを何も覚えていません（ステートレス）。会話の履歴も、使える道具の一覧も、ホストが毎回まとめて送り直しています。
まぎらわしい例
- LM Studio は、チャット画面（ホスト）とモデルの実行環境を、1 つのアプリで両方持っています
- Ollama にも簡単なチャット画面が付いています
わたしが「Ollama ＝ ホスト」「Ollama ＝ LLM」と取り違えたのは、このように 1 つの製品が層をまたいでいるからだと思います。製品の名前ではなく、中で何の役をしているかで見ると整理しやすくなります。
社内で組むならこうなる
たとえば社内ナレッジに答えるチャットを組むなら、次のような形になります。
| 層 | 例 |
|---|---|
| ホスト | Open WebUI（社内サーバーで動かし、ブラウザで使う） |
| 実行環境 | Ollama で試してから、人数が増えたら vLLM（GPU サーバー） |
| LLM | 実行環境の上で動かすモデル（Qwen3 など） |
| 道具 | 社内ナレッジを検索する MCP サーバー |
実行環境を Ollama から vLLM に替えても、モデルは同じものが使えますし、API も OpenAI 互換なので、ホスト側はほとんど変えずに移せます。
ただし、Ollama と vLLM では、ふつう使うモデルファイルの形式（量子化の方式）が違います。同じ「Qwen3 8B」でも、精度やメモリの使用量が少し変わることがあるので、比べるときはそこもそろえる必要があります。
まとめ
- LLM はモデルのファイル。文章を読んで続きを出すだけ
- 実行環境（Ollama、vLLM）は、そのモデルを動かして API にするソフト
- ホスト（Open WebUI など）は、画面と会話を受け持ち、LLM と道具をつなぐ司令塔
次の記事では、ホストと LLM の間で「道具」がどうやりとりされているのか、tool calling と MCP の関係を見ていきます。
