午前2時。ターミナルに429 Too Many Requestsが表示された。OpenAIのAPIキーがレートリミットに達し、翌朝8時のデモが迫っていた。画面を見つめながら、初めて真剣にLLMをローカルで動かすことを調べ始めた。
ラップトップとVPSの両方で数ヶ月実運用した経験から得た知見をまとめた——どのアプローチがどの状況に適しているか、そしてOllamaをゼロからAPIが動くまでセットアップする方法を解説する。
LLMローカル実行の主要3アプローチ比較
Ollamaを選ぶ前に3つのアプローチを試した。それぞれにトレードオフがあり、絶対的に優れたものはない。
llama.cpp — 純C++エンジン、最高パフォーマンス
llama.cppはGGUF形式のモデルを直接実行し、抽象化レイヤーが一切ない。非常に軽量で、CUDAやMetalでコンパイルしてGPUを最大限に活用できる。その代わり、すべて自分で行う必要がある——バイナリのコンパイル、HuggingFaceからのモデルダウンロード、REST APIが必要なら自分でラッパーを書く。
# llama.cppサーバーを起動する — フラグが多く間違えやすい
./llama-server -m models/mistral-7b-q4_K_M.gguf \
--ctx-size 4096 \
--n-gpu-layers 35 \
--host 0.0.0.0 \
--port 8080
MLリサーチや1トークン/秒単位でパフォーマンスを絞り出したい場合に適している。素早くデプロイしたい場合の選択肢ではない。
LM Studio — 美しいGUI、でもデスクトップに縛られる
LM StudioはきれいなUIを備え、HuggingFaceブラウザが統合されており、OpenAI互換のローカルAPIサーバーもある。新しいモデルを探索するのに使っていた——数クリックで起動できてとても便利だ。ただし、デスクトップアプリだ。SSHでアクセスできず、ヘッドレスVPSで動かせず、コンテナ化もできない。CIパイプラインやチーム全員のための共有サーバーに統合したい?LM Studioは行き止まりだ。
Ollama — CLI + API、どこでも動く
Ollamaは内部でllama.cppをラップしているが、Dockerに似たインターフェースを公開している:モデルのpull、run、組み込みのREST API。macOS、Linux(ヘッドレスサーバーも含む)、Windowsで動作する。重要なのは、開発ラップトップから本番サーバーまで同じワークフローが使えること——環境を移行しても変更が不要だ。
メリット・デメリット分析:どれを選ぶべきか?
- llama.cpp:最大パフォーマンスが必要な場合、MLリサーチ中、またはカスタム推論パイプラインを構築する場合に選ぶ。初心者や素早くリリースしたい場合には不向き。
- LM Studio:個人のマシンでモデルを試すだけでコードへの統合が不要な場合に選ぶ。ここで止まれ——本番アプリをこれで構築するな。
- Ollama:それ以外すべての用途に選ぶ——ローカル開発、プロトタイプ、チーム共有サーバー、オフライン環境。使いやすさと柔軟性のバランスが取れている。
実際のプロジェクトで3つすべてを使った。実用的な結論:普通の開発者の90%はOllamaで十分だ。llama.cppは推論時間を1ミリ秒単位で絞り出す必要がある場合にのみ価値がある。LM Studioは個人的な実験止まりにしておくべきだ。
Ollamaのインストール
Linux(VPSまたはサーバー)
curl -fsSL https://ollama.com/install.sh | sh
スクリプトがGPUを自動検出し、必要であればCUDAドライバをインストールし、systemdサービスを自動設定する——全体で約2〜3分かかる。インストール後の確認:
# サービスの稼働確認
systemctl status ollama
# Ollamaはポート11434で待機している
curl http://localhost:11434
# 出力: Ollama is running
macOS
# Homebrewを使う
brew install ollama
# サーバーを起動する(トレイアプリを使わない場合)
ollama serve
最初のモデルを実行する
Dockerを使ったことがあれば馴染みのある構文だ:
# Llama 3.2 3B — 軽量、強力なGPUがないマシンに適している(~2GB)
ollama run llama3.2
# Mistral 7B — 品質と速度のバランスが良い(~4GB)
ollama run mistral
# Qwen 2.5 7B — ベトナム語と日本語のサポートが優れている
ollama run qwen2.5:7b
# ダウンロード済みモデルの確認
ollama list
# 不要なモデルの削除(ディスク容量の解放)
ollama rm mistral
初回実行時にOllamaがモデルをローカルにダウンロードする。Mistral 7Bは約4GB、Llama 3.2 3Bは約2GBだ。次回以降はキャッシュから読み込まれ、ダウンロード時間はかからない。
GPUがない?問題ない。3B〜7BのモデルはCPUでも動作し、チップによって約5〜15トークン/秒の速度が出る。開発やテストには十分だ——複数ユーザーが同時アクセスする本番環境には不足するが。
RAMに応じたモデル選択
- 4GB RAM:
llama3.2:3b,phi3:mini - 8GB RAM:
mistral:7b,llama3.1:8b,qwen2.5:7b - 16GB RAM:
llama3.1:13b,codestral:22b - 32GB+ RAM:
llama3.3:70b(遅いが動作する)
REST APIを通じてOllamaをコードに統合する
最もよく使う部分だ。OllamaはOpenAI互換APIを公開しているため、既存コードはほぼ変更不要で、base_urlを変えるだけでいい:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # 任意の文字列でよい、Ollamaは検証しない
)
response = client.chat.completions.create(
model="llama3.2",
messages=[
{"role": "user", "content": "Dockerのネットワーキングを3文で説明してください"}
]
)
print(response.choices[0].message.content)
パッケージを追加したくない?curlでネイティブAPIを直接呼び出せる:
curl http://localhost:11434/api/chat -d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "ディスク使用量を確認するbashスクリプトを書いてください"}
],
"stream": false
}'
Ollamaの実践的なTips
内部ネットワーク全体に公開する
デフォルトでOllamaは127.0.0.1にバインドされており、そのマシンからしかアクセスできない。チーム全員が1台のサーバーを共有したい場合、systemdオーバーライドで環境変数を追加する:
# systemdサービスのオーバーライドを作成する
sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0"
EOF
sudo systemctl daemon-reload && sudo systemctl restart ollama
Modelfileでカスタムモデルを作成する
固定のシステムプロンプトを持つ社内テクニカルサポートチャットボットが必要?Modelfileを使おう——毎リクエストに同じプロンプトを貼り付ける代わりに、モデルに焼き込む:
# Modelfileを作成する
cat > Modelfile << 'EOF'
FROM mistral
SYSTEM """
あなたは10年の経験を持つLinuxの専門家です。
Linux、シェルスクリプト、システム管理についてのみ回答してください。
日本語を使い、簡潔に答え、実践的な例を示してください。
"""
EOF
# カスタムモデルをビルドする
ollama create linux-expert -f Modelfile
# テスト
ollama run linux-expert "ポート8080を使っているプロセスは何ですか?"
Modelfile1つで何十行ものボイラープレートコードを節約できる——特にチームの複数のメンバーが同じベースプロンプトを使う場合に効果的だ。
Ollamaを使う場面、クラウドAPIが必要な場面
Ollamaが適しているケース:
- ローカル開発——APIコストがかからず、深夜2時にレートリミットを心配しなくていい
- センシティブなデータ処理——データがマシンの外に出ない
- 共有AIサーバーが必要な小チーム——1台のVPSでOllamaを動かし、チーム全員で共有
- オフライン環境、エアギャップネットワーク
最強のモデル(GPT-4oレベル)、複雑なマルチモーダル処理、またはハードウェアでは対応できない高い本番トラフィックが必要な場合は、引き続きクラウドAPIを使うべきだ。
あの夜に戻ると——午前3時にMistral 7BでOllamaのセットアップを完了し、午前8時のデモはエラーなく完璧に動いた。それ以来、開発マシンの常設フォールバックとしてOllamaを使っており、クラウドAPIのレートリミットが仕事を台無しにする心配はなくなった。
