Ollamaのコマンドは、覚えることがほとんどありません。pull して run するだけです。

詰まるのはコマンドではなく、その裏側です。 pullが何分かかるのか。1回目の応答だけ異常に遅いのはなぜか。使い終わったメモリはいつ返ってくるのか。このあたりは、動かしてみるまで分かりません。

さくらのVPS 2Gプラン（Ubuntu 24.04・GPUなし・CPUのみ）で測った数字と、公式ドキュメントの記載を突き合わせました。

確認できたこと

  • pull は 0.5Bで38.6秒、1Bで2分4秒、3Bで2分56秒。ディスクはそれぞれ +380MB / +1,260MB / +1,840MB 増えた
  • 1回目の応答が遅いのはモデルのロード時間。0.5Bで3.18秒、1Bでは43.6秒かかった
  • モデルは既定で5分間メモリに保持され、そのあとアンロードされる（公式ドキュメントの記載）
  • つまり5分以上間を空けると、あのロード時間がもう一度発生する
  • ollama ps の Processor 列を見れば、CPUで動いているかGPUで動いているかが分かる（公式の記載。100% CPU のように出る）
  • Ollama本体は常駐36MB。ディスクは2.1GB。モデルを3つ入れた時点で合計3.4GBだった

実測値は「実測」、公式ドキュメントの記載は「公式」と書き分けます。

基本のコマンドと、実際にかかった時間

コマンド何をするかこのサーバーでの実測
ollama pull <model>モデルを取得する0.5B: 38.6秒 / 1B: 2分4秒 / 3B: 2分56秒
ollama run <model> "..."1回だけ実行する初回はロード時間が乗る（後述）
ollama list入っているモデルを見る即時
ollama psいま動いているモデルを見る即時。Processor列が重要
ollama rm <model>モデルを消す未測定
ollama serveサーバーとして起動するsystemdに任せている

覚えるのはこれで足りました。 以下は、この表に書ききれない裏側です。

pull：待ち時間はモデルのサイズにほぼ比例する

3つのモデルを入れたときの実測です。

モデル所要時間ディスクの実増
qwen2.5:0.5b38.6秒+380MB
llama3.2:1b2分4秒+1,260MB
qwen2.5:3b2分56秒+1,840MB

ディスクは、Ollama本体の2.1GBが先に乗っています。 3つ入れた時点で合計3.4GBでした。

ollama list に出るサイズと df で見た増加がずれることがありますが、これはOllamaが10進のMB、du や df が2進のMiBで表示しているためです。同じ値です。

run：1回目だけ遅いのはロード時間

ここが、いちばん誤解されやすい場所です。

モデルロード時間生成速度
qwen2.5:0.5b3.18秒15.36 tok/s
llama3.2:1b43.6秒0.07 tok/s

0.5Bなら3秒で、体感としては「少し待つ」程度です。1Bでは43.6秒かかりました。このロード時間は、生成が始まる前に発生します。 プロンプトを投げて40秒間なにも起きないので、固まったように見えます。

1Bのほうは生成そのものも 0.07 tok/s まで落ちていて、9トークンの返事に合計3分かかりました。なぜここで崖が来るのかは2GBのVPSでローカルLLMは動くのかに書いています。

メモリは5分で返る。そしてまたロードし直す

公式ドキュメントに、はっきり書かれています。

How do I keep a model loaded in memory or make it unload immediately? By default models are kept in memory for 5 minutes before being unloaded.

既定では5分です。 そして keep_alive で変えられます。公式の記載では、負の数（-1 や "-1m"）を渡すとメモリに保持し続け、0 を渡すと応答を返した直後にアンロードします。

この5分という数字は、上のロード時間と組み合わせると意味が変わります。

  • 5分以内に続けて使うなら、ロード時間は最初の1回だけ
  • 5分以上空けると、43.6秒をもう一度払う

つまり、たまにしか呼ばない使い方がいちばん割に合いません。 1日に数回、思い出したように呼ぶ用途だと、毎回ロード待ちが発生します。逆に、まとめて処理を回すなら最初の1回で済みます。

メモリを常に空けておきたいなら keep_alive: 0、応答を速くしたいなら負の数、という選び方になります。私が使っているのは既定の5分のままです。 同居しているサービスがあるので、使っていないメモリは返してほしいためです。

公式には、空のリクエストを送ってモデルを先に読み込ませておく方法も書かれています（プリロード）。応答時間を短くしたい場合の手です。

ollama ps で、CPUで動いているのかが分かる

公式ドキュメントの該当項目は「モデルがGPUに載ったかどうかを確かめる方法」です。

How can I tell if my model was loaded onto the GPU? ollama ps command to see what models are currently loaded into memory.

出力の Processor 列に、100% GPU / 100% CPU / 48%/52% CPU/GPU のような値が出ます。

GPUのないサーバーなら 100% CPU になります。 ここを確認しておくと、「GPUがあるつもりだったのに使われていなかった」という取り違えを避けられます。GPUなしの環境で何がどこまで動くかはGPUなしでローカルLLMは使えるのかにまとめました。

モデルはどこに置かれるか

公式ドキュメントの記載です。

OS保存場所
Linux/usr/share/ollama/.ollama/models
macOS~/.ollama/models
WindowsC:\Users\%username%\.ollama\models

Linuxの保存先が ollama ユーザーのホーム配下にある点は、覚えておく価値があります。ディスクの使用量を調べるときに、ここを見ずに ~/.ollama を探すと何も出てきません。

モデルを消したとき、ディスクは戻るのか

測っていません。

ollama rm を実行していないので、pullで増えた分と同じだけ戻るのかを確認していません。「戻るはずです」とは書きません。

ただし、この種の「消したのに戻らない」は実際に踏んでいます。 同じサーバーでDockerを掃除したとき、docker system prune で消えたのは13GBのうち79.75MBだけでした。イメージには一切触らず、ボリュームも容量の99.1%が既定のprune では残ります。詳細はdocker system prune では13GBが1バイトも消えなかったに書きました。

ディスクの回収は、コマンドを打った結果を df で確かめるまで信用しないほうがいいというのが、そこから得た教訓です。Ollamaでも同じ姿勢で確認することをすすめます。

使えるモデルの一覧はどこで見るか

ollama list で見えるのはすでに入れたモデルだけです。これから入れられるモデルの一覧は、Ollamaの公式ライブラリにあります。

見るべきなのはダウンロードサイズです。GPUのない環境では、必要メモリがそこからほぼ決まります。

必要メモリの目安 ≒ モデルファイルのサイズ × 2.4

この2.4倍は実測から出した値です（0.5Bのファイル380MBに対し、メモリのピークが実測930MB）。公式ライブラリのサイズから逆算した早見表はGPUなしでローカルLLMは使えるのかにあります。

ライセンスもモデルごとに違います。 同じQwen2.5でも、公式ライブラリには「3Bと72B以外はApache 2.0、3Bと72BはQwenライセンス」と書かれています。商用で使うなら、サイズ単位で確認してください。

この記事が書けなかったこと

  • ollama rm の実測をしていません。 ディスクが戻るかどうかを確認していません
  • keep_alive を変えたときの挙動を測っていません。 公式の記載を引用しただけです
  • プリロードも試していません
  • すべてGPUなし・CPUのみの数字です。 GPUがある環境では、ロード時間も生成速度も別物になります
  • Ollama 0.33.3 の時点の話です

出典

  • Ollama Docs FAQ（keep_alive と5分の既定値、モデルの保存場所、ollama ps の Processor 列、プリロード／2026年9月17日確認）
  • Ollama公式ライブラリ（モデルのサイズとライセンス記載）
  • 実測値は当サイトの測定による（さくらのVPS 2Gプラン / Ubuntu 24.04 LTS / GPUなし / Ollama 0.33.3）

関連記事