【実践】Ollama で 10 分で動かす

ここまでで、インスタンスを借りて（第 8 章）SSH で入り（第 9 章）モデルを落とす（第 11 章）までが揃いました。この章はいちばん短い道を通します。Ollama（= 1 コマンドで LLM を落として動かすためのサーバ + CLI）を入れて、会話するところまでです。

お金の目安を先に置きます。この章の作業は合計 25 分ほどで、1 枚構成の RTX 5090 なら 0.2 USD 弱（2026-08-24 時点の実測中央値 0.4037 USD/時 で計算。1 USD = 150 円として約 25 円）です（章題の「10 分」は、このうちモデルを落として会話するところ = やってみる 12-2 の所要時間です）。加えてディスク代がかかります（後述）。

Ollama は「サーバ 1 つ」で全部やっている

最初に取り違えると後の全部が分からなくなるので、構造から入ります。Ollama は 3 つの層に分かれています。

• サーバ（本体） — ollama serve で立ち上がる HTTP サーバ。既定で 127.0.0.1 の 11434 番を listen（= その番号で待ち受ける）します。モデルを VRAM（= GPU に内蔵された専用メモリ。RTX 5090 は 32 GB）に載せているのはこのプロセスです
• CLI — ollama run / pull / ps などのサブコマンド。これらは内部でサーバの REST API を叩いているだけのクライアントです
• REST API（= HTTP で命令を送る窓口） — /api/generate・/api/chat という Ollama 独自の API と、/v1/... の OpenAI 互換 API の 2 系統があります

つまり ollama run が動くのは「同じマシンでサーバが立っているから」です。手元の Mac から使うときも、GUI（Open WebUI）から使うときも、行き先は同じ 11434 番の 1 つのサーバです。

モデルの指定は モデル名:タグ の形です。タグを省略すると latest が使われます（orca-mini:3b-q8_0 や llama3:70b のようにパラメータ数や量子化がタグに入ります）。

借りるときに決めるのは「入り口」と「ディスク」の 2 つだけ

入り口は 2 通りあります。どちらでも同じ Ollama が動きます。

① は vast.ai のテンプレート一覧（cloud.vast.ai）でテンプレートを選び、play アイコンを押すと検索画面に移ります。起動後は Open ボタン → Instance Portal → Open WebUI のリンクで開き、初回に Admin のユーザー名とパスワードを作ります。モデルの取得は WebUI の中で、admin panel → settings → Models タブ → ダウンロードアイコン（Manage Models）にモデル名を入れる、という導線です。この章では ② を通します。API として使う話（第 13 章以降）に繋がるからです。

もう 1 つの決めごとがディスクです。ディスク容量はインスタンス作成時に決めたら変更できません。検索画面のストレージスライダーで確保します（テンプレート側の欄ではありません）。モデルの実体はここに落ちるので、モデルサイズ以上を取らないと pull の途中で詰まります。公式は deepseek-r1:70b の例で 50 GB を確保するよう書いています。

ディスクの月額 = 確保 GB × storage_cost（USD/GB/月）

2026-08-24 時点の実測では storage_cost の中央値が 0.200 USD/GB/月 でした。計算例: 40 GB を 1 か月確保すると 40 × 0.200 = 月 8 USD。GPU を 1 時間動かすのが 0.40 USD ですから、放置したディスクのほうが高くつくことがあります。この章の練習なら 40 GB あれば足ります。公式 FAQ も「必要だと思う量より常に多めに割り当てて、途中で詰まるのを避けよ」と書いています。

最後に、そもそも Ollama が RTX 5090 を使えるのかを確認しておきます。公式ドキュメントは compute capability 5.0 以上（= NVIDIA が GPU の世代・機能水準に振る番号）で ドライバ 550 以降の NVIDIA GPU に対応すると書き、対応表の compute capability 12.0 の欄に RTX 5060 RTX 5060 Ti RTX 5070 RTX 5070 Ti RTX 5080 RTX 5090 を並べています。vast.ai の offer 実測（2026-08-24 時点）でも 1 枚構成 5090 の compute_cap は全件 1200（= 12.0）、ドライバは 570 系〜580 系でした。要件は満たしていますので、あとは入れるだけです。

nvidia-smi
curl -fsSL https://ollama.com/install.sh | sh
ollama -v

1 コマンドで会話するところまで

公式のクイックスタートは ollama pull を挟まずに ollama run gemma4 から始まります。つまり run 1 本でも会話まで行けます。ただし初心者のうちは落とす工程と動かす工程を分けたほうが、どこで詰まったかが分かります。ダウンロードで失敗しているのか、GPU に載らなくて失敗しているのかが、画面を見ただけで切り分けられるからです。

ollama pull gemma4
ollama ls
ollama run gemma4

GPU に載ったかは ollama ps の 1 列で分かる

ここが実践で最も重要な確認です。Ollama は VRAM に収まらなければ黙って CPU に逃がします。動いてはいるが極端に遅い、という状態がこれです。別ウィンドウで ollama ps を叩きます。

ollama ps

NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
gemma4:latest    c6eb396dbd59    9.6 GB    100% GPU     131072     2 minutes from now

読む列は 3 つです。PROCESSOR が 100% GPU なら全部 GPU に載っています。48%/52% CPU/GPU のように割れていたら部分オフロード、100% CPU なら全部システムメモリです。公式の指針も「モデルを CPU にオフロード（= GPU に載りきらない分をシステムメモリ側に肩代わりさせること）するのを避け、ollama ps の PROCESSOR で分割を確認せよ」です。CONTEXT は実際に割り当てられたコンテキスト長、UNTIL はあと何分 VRAM に居座るかです。

この UNTIL が keep alive です。既定は 5 分。最後の応答から 5 分で、モデルは VRAM から自動的に降ります。

API の keep_alive は環境変数 OLLAMA_KEEP_ALIVE を上書きします。なお OLLAMA_MAX_LOADED_MODELS の既定は「GPU 数 × 3」（CPU 推論時は 3）なので、GUI から複数のモデルを触ると意図せず 2〜3 個が同時に VRAM に残ります。速度が落ちたら ollama ps で常駐を数え、要らないものを ollama stop で降ろします。

32 GB に入るモデルの決め方

RTX 5090 の VRAM は 32607 MB（2026-08-24 時点の offer 実測値、全件同一）。ここに何が入るかは、公式ドキュメントに出ている実測サイズを並べると見えてきます。

この 3 つの実測値（4.7÷7.6、2.0÷3.2、42÷70）から本書の計算として言えるのは、Q4 系の量子化なら 1B パラメータあたり約 0.6 GB ということです。ここでいう量子化（= モデルの重みを粗く丸めてファイルを小さくする加工。q4_K_M q8_0 のような型名で表され、公式が推奨として挙げているのはこの 2 つ）の水準が変われば、この係数も変わります。単純計算では 32 GB に 50B 相当の重みが入りますが、重みだけが乗るわけではありません。

重み以外に何が乗るかというと、K/V キャッシュ（= 生成の途中経過を GPU 側に置いておく作業領域。コンテキストが長いほど大きくなる）です。余白が必要な理由は、公式が明記している 2 つの性質にあります。コンテキスト長を伸ばすとメモリ消費が増えること、そして並列リクエストはコンテキストを掛け算すること（公式の例: 2K のコンテキストに 4 並列で 8K 相当のメモリ確保になる）。並列数を決める OLLAMA_NUM_PARALLEL の既定は 1 なので、自分で増やすか、Open WebUI のように複数の会話を同時に走らせたときに効いてきます。したがって実務の安全域は Q4 系で 30B〜40B クラスまで（重みで 24〜26 GB 前後）、というのが本書の目安です。70B クラスは 1 枚では入りません。

コンテキスト長の既定値は公式ドキュメントの中で食い違っています。context-length のページは VRAM 依存（24 GiB 未満で 4k、24〜48 GiB で 32k、48 GiB 以上で 256k）と書き、FAQ は「既定は 4096 トークン」と書いています。RTX 5090 の 32 GB は 24〜48 GiB の帯に入りますが、断定せずに ollama ps の CONTEXT 列で実機の値を読むのが正解です。指定したいときは次の 3 通りです。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve   # サーバ全体の既定
/set parameter num_ctx 4096                 # 対話セッション内
# API なら options に "num_ctx": 4096

公式は「web 検索・エージェント・コーディングのような大きなコンテキストを要する用途は少なくとも 64000 トークンにすべき」と書いています。VRAM が苦しくなったら、Flash Attention（= K/V キャッシュの量子化を使うための前提になる高速化機能。既定はバックエンドとデバイスが対応していれば自動で有効。OLLAMA_FLASH_ATTENTION=1 で強制的に有効化できます）が効いている状態で OLLAMA_KV_CACHE_TYPE=q8_0 にすると、K/V キャッシュが既定の f16 の約半分になります（精度低下はごく小さいと公式は書いています。さらに小さくする q4_0 もありますが、公式は「中程度の精度低下」と書いています）。ただしこれは全モデルに効くグローバル設定で、モデル単位では切り替えられません。

手元の Mac / PC から API として叩く

既定の OLLAMA_HOST は 127.0.0.1 の 11434 番、つまりインスタンスの内側からしか届きません。外から使う経路は 2 つです。

初心者に勧めるのは経路 ① です。公式も ssh -L を「公開インターフェースにポートを開けることの安全な代替。すべてのデータは SSH 接続の中を運ばれる」と書いています。ポートを 1 つも開けずに済むので、事故の起きようがありません。

ssh -p <ポート> root@<ホスト> -L 11434:localhost:11434

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{ "role": "user", "content": "自己紹介を 1 文で" }],
  "stream": false
}'

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

経路 ② を使うのは「テンプレート ① で借りて、Open WebUI と一緒に Ollama の口も外から使いたい」場合です。このテンプレートは Ollama API のポート公開まで自動でやってくれるので、自分で OLLAMA_HOST を触る必要はありません（自分で入れた Ollama を外に出す場合だけ 0.0.0.0:11434 化が要ります）。vast.ai の公式ガイドでは URL は https://INSTANCE_IP:PORT_11434 の形で、Authorization ヘッダに OPEN_BUTTON_TOKEN の値を Bearer トークン（= 合言葉の文字列をヘッダに添えて本人確認する方式）として入れる必要があります。外部ポート番号はインスタンス上部の IP ボタン（IP Port Info）のポップアップで内部 11434 に対応するものを読み、トークンはインスタンス内のターミナルで echo $OPEN_BUTTON_TOKEN と打つと出ます。vast.ai は自己署名証明書（= 公的な認証局が発行していない証明書。そのままだと curl が接続を拒否する）を使うので、curl には -k を付けます。

curl -k https://<インスタンスの IP>:<外部ポート>/v1/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer <OPEN_BUTTON_TOKEN>" \
    -d '{"model": "gemma4", "prompt": "San Francisco is a", "max_tokens": 128}'

つまずきポイント

理解度チェック

まとめ

• Ollama は 11434 番で待つ 1 つのサーバ。ollama run も Open WebUI も curl も、全部その客である
• 借りるときに決めるのは入り口（推奨テンプレート Open Webui (Ollama) か、素のインスタンス + curl -fsSL https://ollama.com/install.sh | sh）とディスク容量（作成後は変更不可、モデルサイズ以上）の 2 つ
• 動かす手順は ollama pull → ollama ls → ollama run → /bye。一覧は ollama ls であって list ではない
• 成否の判定は ollama ps の PROCESSOR が 100% GPU か。CONTEXT でコンテキスト長、UNTIL で残り常駐時間も読める
• keep alive の既定は 5 分。降りても課金は止まらない。止めるのは vast.ai 側の stop / destroy だけ
• 32 GB の目安は Q4 系で 30B〜40B クラスまで（1B ≒ 0.6 GB という本書の計算 + K/V キャッシュの余白）。70B は入らない
• 外から使うなら ssh -L 11434:localhost:11434 が既定の作法。公開ポートを開けるなら 0.0.0.0 化 + Bearer トークン + curl -k がセットで必要

ここで手を止めるなら、忘れずにインスタンスを止めてください。/bye でも ollama stop でも GPU の時間課金は動き続けます。続けて第 13 章に進まないのであれば、vast.ai 側で stop（GPU 代は止まる。ディスク代は続く）か destroy（全部止まるがデータも消える）まで行うところが「作業の終わり」です。詳しくは第 16 章で扱います。

次章では、同じモデルを vLLM で立てて OpenAI 互換 API のサーバにします。Ollama より設定は増えますが、複数リクエストを裁く力と 32 GB に収めるための細かい制御が手に入ります。

参考リンク

• Ollama — Quickstart（ollama run・モデル名とタグ・/bye）
• Ollama — Linux（インストーラ・systemd サービス・OLLAMA_MODELS の所有者）
• Ollama — CLI Reference（ls / ps / stop / serve --help）
• Ollama — GPU（対応表に RTX 5090・compute capability とドライバ要件）
• Ollama — Context length（VRAM 別の既定値・ollama ps の CONTEXT）
• Ollama — FAQ（OLLAMA_HOST・keep alive・並列とメモリ・K/V キャッシュ）
• Ollama — API（/api/chat・keep_alive・速度の計算式）
• Ollama — OpenAI compatibility（/v1/chat/completions・API キーは ollama）
• Ollama — Troubleshooting（GPU 検出失敗・ログの読み方）
• vast.ai — Open WebUI (Ollama) テンプレート（ディスクと VRAM の目安・Bearer トークン）
• vast.ai — RTX 5 series（CUDA 12.8 / PyTorch 2.7 以降・イメージを変えない）
• vast.ai — SSH（ssh -L によるポートフォワード）