Ollama: パーソナルコンピューターおよび小規模サービス向けのローカル LLM 推論

Ollama は、モデルの取得、ローカル推論、コマンドラインインターフェース、デスクトップアプリケーション、HTTP API を 1 つのツールにまとめます。Python 環境、推論エンジン、トークナイザー、プロンプトテンプレート、GPU ランタイムを最初に組み立てなくても、オープンウェイトモデルをダウンロードし、開発者のワークステーションで実行できる最も簡単な方法の 1 つです。

最小構成のセッションは次のとおりです。

ollama pull qwen3:8b
ollama run qwen3:8b

Ollama は適切なローカルランナーを選択し、モデルを保存し、必要に応じて起動し、モデルのチャットテンプレートを適用します。この利便性により、Ollama はパーソナルコンピューター、アプリケーション開発、デモ、小規模な内部サービスに適しています。ただし、ノートパソコンが高スループットまたは高可用性の本番推論クラスターになるわけではありません。

Ollama でできること #

Ollama は次のことができます。

• モデルのダウンロード、一覧表示、検査、実行、コピー、削除
• 対話型のテキストチャットおよびテキスト生成の提供
• 対応する視覚言語、埋め込み、ツール呼び出し、推論モデルの実行
• 対応モデルの出力を構造化 JSON に制約
• 対応するモデルウェイトまたは GGUF ファイルのインポート、および Modelfile によるモデル動作のカスタマイズ
• ネイティブ REST API によるローカルモデルの提供
• OpenAI API との部分的な互換性の提供
• 利用可能な RAM または VRAM の範囲内で、1 つ以上のモデルをメモリに常駐させ、同時リクエストを処理
• オプションで、ローカルハードウェアの代わりに Ollama ホストのクラウドモデルを使用

これらはランタイムの機能であり、すべてのモデルが備える能力ではありません。テキスト専用モデルは、リクエストが視覚エンドポイントの形式であっても画像を理解できません。また、ツール使用向けに学習されていないモデルは、質の低いツール呼び出しを生成する可能性があります。利用する前に、Ollama model library のモデルカード、ライセンス、コンテキスト制限、タグを確認してください。

ローカルサーバーは通常、http://127.0.0.1:11434 で待ち受けます。CLI、デスクトップアプリ、API クライアント、エディター拡張機能、サードパーティーのチャットインターフェースは、すべてこのサービスのクライアントです。

Ollama ではないもの #

Ollama は次のものではありません。

• それ自体が LLM またはモデルウェイトの提供元
• モデル学習または完全なファインチューニングのフレームワーク
• モデルが正確、安全、公平であること、または特定用途にライセンスされていることの保証
• 検索拡張生成システム、ベクトルデータベース、エージェントフレームワーク、ツールサンドボックス
• すべての OpenAI API エンドポイントおよびオプションを完全に実装したもの
• ローカル API の認証、認可、クォータ、課金ゲートウェイ
• 自動フェイルオーバーを備えたマルチノードスケジューラー
• キャパシティプランニング、監視、バックアップ、管理されたアップグレードの代替

Ollama は RAG またはエージェントアプリケーションの 1 コンポーネントにはなれますが、アプリケーション側でドキュメント取り込み、検索、会話状態、ツール実行、アクセス制御、エラー処理を管理する必要があります。特に重要なのがツール呼び出しです。モデルは呼び出しを提案しますが、信頼できるアプリケーションコードが検証して実行しなければなりません。

モデルをローカルで実行しても、すべての処理がオフラインになるわけではありません。モデルの取得にはネットワークアクセスが必要であり、クラウドモデルまたはウェブ検索機能はリモートサービスにリクエストを送信します。ローカル限定の運用が必要な場合は、OLLAMA_NO_CLOUD=1 または ~/.ollama/server.json の disable_ollama_cloud を設定してください。

Ollama と vLLM の比較 #

vLLM も推論エンジンおよびサーバーですが、最適化の中心が異なります。PagedAttention、continuous batching、プレフィックスキャッシュ、並列化、分散サービング機能により、多数のリクエストを効率的に共有処理することを目指しています。Ollama は、ランタイムがない状態から 1 台のマシンでモデルを実行するまでの経路を最適化します。

比較は単純な「開発対本番」ではありません。1 台のマシン上で限定された内部ワークロードを処理し、周辺システムが認証、TLS、監視、復旧を提供する場合、Ollama サービスは本番に適する可能性があります。同様に、vLLM も 1 台の開発サーバーで実行できます。判断要因はワークロードです。

• Ollama は、パーソナルアシスタント、プライベートな実験、ローカルアプリケーション開発、オフライン対応ワークフロー、授業での利用、軽く共有する単一ホストサービスに適しています。
• vLLM は、同時利用者数、アクセラレーターあたりの 1 秒当たりトークン数、予測可能なキューイング、Prometheus メトリクス、分散 GPU、Kubernetes ベースのスケーリングによって追加の運用複雑性が正当化される場合に選択します。
• これらの中間に位置する場合は、両方をベンチマークしてください。最初のトークンまでの時間、1 秒当たりの出力トークン数、テールレイテンシ、メモリ使用量、想定する同時実行数およびコンテキスト長での挙動を測定します。

Ollama の利点は、運用上の摩擦が少なく、ワークステーションを幅広くサポートすることです。欠点は、専用のフリートサービングエンジンに期待される多くの制御機能と最適化を失うことです。vLLM の利点は、アクセラレーターの利用効率とサービング規模です。欠点は、セットアップの難易度が高く、ハードウェアへの依存が大きく、コンシューマー向けデスクトップ体験がないことです。

デプロイ #

デプロイ方式の選択 #

最も短く信頼できる原則は次のとおりです。

Ollama は、ローカル推論を通常の作業にすることで機能します。1 つのアプリケーションをインストールし、1 つのモデルを取得し、チャットウィンドウ、ターミナル、エディター、プログラムから同じランタイムを利用できます。この単純さが主な機能です。ただし境界を明確にしてください。Ollama はモデルを実行しますが、信頼できる製品には、その周囲のセキュリティ、状態管理、評価、可観測性、運用制御が必要です。

Docker を使用した Linux ホストへのインストール #

Docker は Linux 推論ホストで自然なデプロイ方法です。コンテナーから Linux の GPU デバイスインターフェースにアクセスできるためです。まず、ホストに動作する GPU ドライバーをインストールします。NVIDIA GPU の場合は、NVIDIA Container Toolkit もインストールして設定します。

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

永続的なモデルボリュームを使用して Ollama を起動します。公開ポートをループバックにバインドすると、認証のない API を意図せず公開することを防げます。

docker run --detach \
  --name ollama \
  --restart unless-stopped \
  --gpus all \
  --publish 127.0.0.1:11434:11434 \
  --volume ollama:/root/.ollama \
  ollama/ollama

モデルを取得し、推論が機能することを確認します。

docker exec ollama ollama pull qwen3:8b
docker exec -it ollama ollama run qwen3:8b
curl http://127.0.0.1:11434/api/version
docker exec ollama ollama ps

ollama ps は、ロード済みモデルが CPU、GPU、またはその両方に分割されているかを報告します。GPU が存在するからといって、モデルが GPU を使用しているとは限りません。

CPU のみで推論する場合は、--gpus all を省略します。これは小規模モデル、機能テスト、対応アクセラレーターのないマシンに有用です。

docker run --detach \
  --name ollama \
  --restart unless-stopped \
  --publish 127.0.0.1:11434:11434 \
  --volume ollama:/root/.ollama \
  ollama/ollama

対応する AMD GPU では、ROCm イメージを使用し、GPU デバイスを渡します。

docker run --detach \
  --name ollama \
  --restart unless-stopped \
  --device /dev/kfd \
  --device /dev/dri \
  --publish 127.0.0.1:11434:11434 \
  --volume ollama:/root/.ollama \
  ollama/ollama:rocm

ホストを選択する前に、Ollama の最新の Docker および GPU 互換性ページを確認してください。GPU ファミリー、ドライバー、コンテナーランタイム、イメージは一致していなければなりません。管理されたデプロイでは、latest による暗黙的なアップグレードを避け、テスト済みの Ollama リリースタグまたはイメージダイジェストを固定してください。

別のマシンからサービスにアクセスする必要がある場合、公開アドレスを 0.0.0.0 に変更してファイアウォールを開くだけにしないでください。TLS、リクエストサイズ制限、タイムアウト、レート制限、監査ログを提供する認証済みリバースプロキシまたは API ゲートウェイの背後に Ollama を配置します。

macOS へのネイティブインストール #

Mac ではネイティブインストールが正しい方法です。

1. 公式の macOS installation page から ollama.dmg をダウンロードします。
2. Ollama を Applications にドラッグし、起動します。
3. プロンプトが表示されたら、アプリによる ollama CLI リンクの /usr/local/bin への配置を許可します。
4. モデルを取得して実行します。

ollama pull qwen3:8b
ollama run qwen3:8b

現在のリリースには macOS Sonoma 14 以降が必要です。Apple M シリーズのシステムはネイティブランタイムを通じて CPU と GPU の両方を使用できます。Intel Mac は CPU 推論を使用します。モデルと設定は ~/.ollama 以下に保存され、モデルが数十または数百 GB を消費する場合があります。

デスクトップアプリケーションは通常、バックグラウンドサーバーを管理します。フォアグラウンドサービスを使用する場合は、ターミナルで ollama serve を実行してサーバーを明示的に起動できます。

macOS と Docker の組み合わせが不適切な理由 #

Docker Desktop for macOS 上の Linux コンテナーは、macOS カーネル上で直接実行されません。Linux 仮想マシン内で実行されます。

Apple の Metal GPU インターフェースはネイティブ macOS アプリケーションから利用できますが、Docker Desktop はその GPU をパススルーせず、Ollama コンテナー向けにサポートされた Linux アクセラレーターとしてエミュレートもしません。したがって、Ollama は macOS 上の Docker Desktop で GPU アクセラレーションを利用できません。

コンテナーは技術的には CPU のみで実行できます。そのため「Mac では Ollama を Docker で実行できない」という表現は広すぎます。実際の問題は、Linux VM がオーバーヘッドを追加しながら、Mac の主な推論上の利点である GPU とユニファイドメモリを失わせることです。ネイティブ Ollama は Metal を使用でき、ファイルシステムとネットワークの経路が単純で、デスクトップアプリも提供します。推論には macOS とネイティブ Ollama を使用し、Linux コンテナーは Linux ホスト用に限定してください。別のウェブ UI をコンテナーで実行し、ネイティブ Ollama サーバーを呼び出すことはできます。

Ollama 管理 CLI #

管理 CLI は、Ollama サーバー、モデル、アカウントセッションを管理します。通常、デスクトップアプリまたはシステムサービスがサーバーを起動します。手動で実行する場合にのみ ollama serve を使用します。

# Show available commands and global options.
ollama --help

# Show the installed Ollama version.
ollama --version

# Show options for a particular command.
ollama run --help

# Start the Ollama server in the foreground.
ollama serve

# Download a model, or update the local copy of an existing tag.
ollama pull qwen3:8b

# List models stored on this machine.
ollama list

# Use the shorter alias for `ollama list`.
ollama ls

# Show a model's metadata, parameters, template, and capabilities.
ollama show qwen3:8b

# List models currently loaded into memory and their CPU/GPU placement.
ollama ps

# Unload a model and release its memory.
ollama stop qwen3:8b

# Create a custom model from a Modelfile.
ollama create my-model --file ./Modelfile

# Copy a model to another local name or tag.
ollama cp qwen3:8b qwen3:project

# Delete a local model.
ollama rm qwen3:project

# Publish a namespaced model after authenticating with ollama.com.
ollama push account/my-model

# Sign in to ollama.com for cloud models and model publishing.
ollama signin

# End the ollama.com session.
ollama signout

コマンド固有のオプションは ollama <command> --help で確認できます。モデル名にはタグが含まれます。qwen3:8b と qwen3:14b は異なるアーティファクトであり、タグを省略すると通常は latest に解決されます。画像および WAV 入力には、対応するマルチモーダル機能を備えたモデルが必要です。CLI は動画、PDF、オフィス文書を直接取り込めないため、対応モデルに送信する前に文字起こし、抽出、または変換を行ってください。

Web/GUI フロントエンド #

複数の独立したフロントエンドが、実行中の Ollama サービスに接続できます。これらは Ollama のモデルランタイムを置き換えるものではなく、会話の保存、ドキュメントワークフロー、ユーザーアカウント、デスクトップインターフェースを追加します。

アプリケーションの境界に応じて選択してください。

• Chatbox は 1 人のユーザーに必要な追加インフラが最も少ないです。
• Open WebUI は、ローカルモデルを中心とした共有ブラウザーインターフェースへの直接的な経路を提供します。
• LibreChat または LobeChat は、Ollama を複数のモデルプロバイダーと組み合わせるデプロイに適しています。
• AnythingLLM は、ドキュメントコレクションと検索を中心にインターフェースを構成します。

コンテナーのネットワークでは localhost の意味が変わります。フロントエンドコンテナー内では、そのコンテナー自身を指し、Ollama ホストを指しません。必要に応じて Docker ホストエイリアス、Compose サービス名、またはプライベートサーバーアドレスを使用します。ブラウザーが Ollama に直接接続する場合は、OLLAMA_ORIGINS で必要なオリジンだけを設定してください。すべてのウェブオリジンを許可する * は避けます。

各フロントエンドは、Ollama とは独立して追加状態を保存します。会話データベースとアップロード済みドキュメントをバックアップし、認証を設定し、オプションのクラウド機能がプロンプトまたはファイルをリモートサービスに送信するか確認してください。フロントエンドを到達可能にするためだけに、Ollama の認証なしポートを公開しないでください。認証済みフロントエンドを公開し、Ollama は内部ネットワークに保持します。

ネイティブ API の使用 #

ネイティブ API は http://localhost:11434/api で利用できます。非ストリーミングのチャットリクエストは次のようになります。

curl http://localhost:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3:8b",
    "messages": [
      {"role": "user", "content": "Explain copy-on-write in two paragraphs."}
    ],
    "stream": false
  }'

生成とチャットではストリーミングがデフォルトで有効であり、トークンの生成に伴って改行区切りの JSON オブジェクト列が返されます。アプリケーションはストリームを逐次解析し、切断と 2xx 以外のレスポンスを処理し、独自の期限を設定する必要があります。

主なエンドポイント群は次のとおりです。

Ollama は公式の Python および JavaScript ライブラリを提供しています。Python クライアントは同じ基本データモデルを維持します。

from ollama import chat

response = chat(
    model="qwen3:8b",
    messages=[
        {"role": "user", "content": "Why does context length use memory?"}
    ],
)
print(response.message.content)

OpenAI 互換 API の使用 #

OpenAI クライアント向けに作成済みのアプリケーションは、対応する操作を http://localhost:11434/v1/ に向けることができます。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1/",
    api_key="ollama",
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
      {"role": "user", "content": "Give me three names for a backup tool."}
    ],
)
print(response.choices[0].message.content)

ローカルサーバーは API キーを無視しますが、OpenAI SDK には空でない値が必要です。対応する互換エンドポイントには Chat Completions と Responses が含まれますが、互換性は意図的に部分的です。リクエスト形式が受理されたからといって、すべてのパラメーター、イベント、usage フィールド、モデル動作、将来の OpenAI 機能がサポートされるわけではありません。アプリケーションが使用する操作を正確にテストし、Ollama 固有の制御が必要な場合は Ollama のネイティブ API を優先してください。

コンテキスト管理 #

Ollama は永続的な会話データベースを所有しないため、コンテキスト管理はクライアントとサーバーにまたがります。CLI、GUI、またはアプリケーションが各リクエストを組み立て、Ollama がそのリクエストをレンダリングしてモデルのコンテキスト制限を適用します。

したがって、同じモデルと Ollama サーバーでも、フロントエンドが異なると結果が異なる場合があります。システムプロンプト、履歴の選択、要約、検索されたドキュメント、生成パラメーターが異なる可能性があるためです。

対話型 ollama run #

ollama run MODEL は、2 種類の履歴を保持します。

1. プロンプト入力履歴 は、矢印キーで過去の入力を呼び出せるようにします。/set history と /set nohistory は、この readline 機能を制御します。プロンプト入力履歴はユーザー入力を含むだけで、完全なユーザーとアシスタントのターンを含まないため、モデルに提供される会話ではありません。
2. 会話履歴 は、実行中の CLI プロセスが保持する system、user、assistant メッセージの順序付き配列です。各レスポンスの後、CLI はアシスタントメッセージを追加します。次のターンでは、蓄積されたメッセージ配列をチャット API に送信します。

したがって、会話履歴は同じ ollama run プロセス内のプロンプト間では保持されますが、プロセス終了後に自動復元されるわけではありません。/clear はアクティブなシステムメッセージを保持したまま、現在の会話コンテキストを削除します。

/save <model-name> は、現在のメッセージ、パラメーター、システムメッセージを定義に含む新しい Ollama モデルを作成することで、明示的な永続化を提供します。後で /load <model-name> を実行すると、保存されたモデルと初期メッセージ履歴がロードされます。保存されるアーティファクトは派生モデル定義であり、検索可能なトランスクリプトデータベースではありません。埋め込まれたメッセージはモデルアーティファクトの一部となり、検査またはコピーできるため、秘密情報を保存しないでください。

すべてのターンがモデルに到達するのか #

CLI は、新しいプロンプトごとに蓄積済みのメッセージ配列全体を送信します。推論サーバーはチャットテンプレートをレンダリングし、結果を設定されたコンテキストウィンドウに収めます。レンダリング済みの履歴が num_ctx を超えると、サーバーはシステムメッセージと最新のユーザーメッセージを保持しながら、古いメッセージを先頭から削除します。したがって、次のようになります。

• API リクエストには、CLI が保持するすべてのターンを含められる
• モデルが見るのは、システムメッセージと、収まる範囲の最新のサフィックスだけ
• 古い事実は CLI のメモリ内配列から消えなくても、実効コンテキストから消えることがある
• num_ctx を増やすと保持できる履歴は増えるが、KV キャッシュのメモリ使用量が増え、同時実行性が低下する可能性がある

セッションコンテキストの設定と検査には、次を使用します。

# Change the context window for the current interactive session.
/set parameter num_ctx 16384

# Clear accumulated conversation messages.
/clear

# Persist the conversation as a derived model.
/save project-session

# Load a saved session or another model.
/load project-session

この動作は切り詰めであり、永続メモリや意味的想起ではありません。CLI は、古い会話をターンの破棄前に要約しません。永続的な会話状態が必要なアプリケーションは、メッセージを独自に保存し、明示的な要約ポリシーを適用し、選択した履歴をチャット API に送信する必要があります。

フロントエンドと API クライアントの戦略 #

Ollama のチャット API は、現在のリクエスト内の messages 配列を処理します。会話 ID によって以前の会話を取得することはありません。API クライアントは、完了したターンを保存し、継続性に必要な履歴を再送する必要があります。

フロントエンドは ollama run より高度なポリシーを実装できます。

• 完全なトランスクリプトを独自のデータベースに保持する
• リクエストがコンテキスト制限に近づくまで全メッセージを送信する
• 最初のシステムメッセージと最新のターンを保持する
• 古いターンを生成された要約に置き換える
• ユーザー設定、決定事項、ツール状態について個別の要約を保持する
• 埋め込みの類似度によって関連する過去のメッセージを検索する
• RAG パイプラインが選択したドキュメントチャンクを注入する

フロントエンドの設定は、num_ctx を送信することで Ollama の実効コンテキスト長を変更することもできます。値を大きくしても、フロントエンドがより多くの履歴を送信することにはなりません。組み立てられたリクエストにより多くの余地を与えるだけです。反対に、フロントエンドは Ollama がその制限に達するよりかなり前に履歴を破棄または要約できます。

正確な挙動が重要な場合は、フロントエンドのドキュメントまたは送信されるリクエストを確認してください。GUI に表示される会話履歴は、表示されたすべてのメッセージがモデルに送信された証拠ではありません。Open WebUI、LibreChat、AnythingLLM、LobeChat、Chatbox は Ollama とは独立して会話と検索のポリシーを管理しており、これらのポリシーはリリース間で変更される可能性があります。

背景ドキュメントと RAG #

Ollama サーバーには、ドキュメントコレクション、チャンク分割器、ベクトルインデックス、検索ポリシーは含まれていません。したがって、完全な RAG システムは提供しません。統合レベルには次の選択肢があります。

1. 直接コンテキスト: ドキュメントテキストをプロンプトに貼り付けるか、抽出したテキストを ollama run にパイプします。モデルがテキストを利用できるのは、コンテキストウィンドウ内に存在する間だけです。画像および音声パスには対応するマルチモーダル機能を備えたモデルが必要です。PDF とオフィス文書は、最初にテキストまたは画像へ変換する必要があります。
2. 静的モデルコンテキスト: 短く安定した指示または事実を Modelfile の SYSTEM または MESSAGE エントリに配置します。これらのエントリはインデックス化されずにプロンプトに含まれるため、コンテキストを消費し、ドキュメントコーパスには拡張できません。
3. アプリケーション管理 RAG: Ollama の埋め込み API を使用してドキュメントチャンクを埋め込み、ベクトルとソースメタデータをベクトルデータベースに保存し、各質問に関連するチャンクを取得して、チャットリクエストに含めます。Ollama は埋め込みモデルと生成モデルを提供しますが、取り込み、検索、引用、アクセス制御、会話の永続化はアプリケーションコードが担います。
4. サードパーティーインターフェース: Ollama にモデルランタイムとして接続する、Open WebUI などのクライアントを使用します。ナレッジベースまたは RAG ワークフローの検索動作、保存、権限、バックアップは Ollama とは別です。

最小限の RAG リクエスト経路は次のとおりです。

コーパス全体を直接貼り付けるのは、関連する証拠を選択する検索手順がないため、RAG ではなくプロンプト詰め込みです。適切な RAG では、チャンクとともにソース識別子も保持し、アプリケーションが引用を表示し、コンテンツがモデルに到達する前にドキュメント単位の認可を適用できるようにします。

モデルの選択とマシンのサイジング #

モデルの選択は、Ollama のインストールよりも体験に大きな影響を与えます。次を考慮してください。

• タスク: 一般的なチャット、コード、埋め込み、視覚、ツール、またはドメイン固有の作業
• ライセンス: 商用利用、再配布、生成物に対する許可
• パラメーター数と量子化: 小さいモデルまたはより強く量子化されたモデルはメモリ使用量が少ない一方、品質が低下する可能性がある
• コンテキスト長: 長いプロンプトと KV キャッシュは、より多くのメモリを消費する
• 言語カバレッジ: ユーザーが必要とする言語と用語をベンチマークする
• プロンプトテンプレートと能力: 2 つのバリアントが互換だと想定せず、正しい Ollama モデルタグを使用する

モデルのディスク上のサイズだけでは、メモリの十分な見積もりになりません。推論にはランタイムバッファーと、コンテキスト長、同時実行数、モデルアーキテクチャ、精度に応じて増加する KV キャッシュも必要です。Apple Silicon では CPU と GPU がユニファイドメモリを共有しますが、macOS と他のアプリケーションにもメモリが必要です。ディスクリート GPU ホストでは、システム RAM にあふれたウェイトは一般に大幅に遅くなります。

Ollama のデフォルトのコンテキストポリシーはリリース間で変更されており、利用可能な VRAM に依存する場合があります。必要なコンテキストを明示的に設定し、ollama ps で割り当てられたコンテキストと CPU/GPU 配置を確認してください。

OLLAMA_CONTEXT_LENGTH=16384 ollama serve
ollama ps

大きければ自動的に良いとは限りません。メモリ負荷が増え、同時実行性が低下したり、CPU オフロードが発生したりする可能性があります。品質もテストしてください。モデルが宣伝する最大コンテキスト長は、そのウィンドウ全体で同等に良好な注意機構を保証しません。

本番運用とセキュリティチェックリスト #

Ollama を共有サービスとして扱う前に、次を確認してください。

1. API を保護する。 ローカル API には認証がありません。ループバックまたはプライベートネットワークに保持するか、認証済み TLS プロキシを前段に配置します。セキュリティのためにダミーの OpenAI API キーへ依存しないでください。
2. ランタイムとモデルを固定する。 Ollama のバージョン、正確なモデルタグまたはダイジェスト、Modelfile、プロンプトテンプレート、コンテキスト、生成パラメーターを記録します。可変タグまたはランタイムのアップグレードによって出力が変化する可能性があります。
3. ストレージを計画する。 コンテナー交換後もモデルボリュームを保持します。モデルデータを別ディスクに置く場合は OLLAMA_MODELS を使用します。カスタム Modelfile と設定をバックアップします。大規模なレジストリモデルは通常、再取得できます。
4. 容量制限を設定する。 OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS、OLLAMA_MAX_QUEUE、コンテキスト長、keep_alive は、メモリとレイテンシーに影響します。過負荷のサーバーは HTTP 503 でリクエストを拒否する可能性があります。
5. 重要なモデルをウォームアップする。 最初のリクエストにはモデルロードのレイテンシーが含まれる場合があります。空の generate または chat リクエストでモデルを事前ロードでき、keep_alive は常駐時間を制御します。
6. サービスを監視する。 コンテナーまたはサービスのログ、リクエストレイテンシー、キュー失敗、ディスク使用量、メモリ、アクセラレーター使用率、アプリケーションのエラー率を収集します。Ollama の基本的な検査コマンドは、完全な監視システムではありません。
7. リクエストと出力に上限を設ける。 ボディサイズ制限、期限、出力制限、同時実行制限、キャンセルを適用します。生成テキストと、モデルが提案するツール引数を信頼できない入力として扱います。
8. 障害と復旧をテストする。 メモリ不足エラー、破損または満杯のディスク、中断されたモデル取得、プロセス再起動、クライアント切断後の挙動を確認します。停止が許容できない場合は、2 台目のホストまたはフォールバックサービスが必要です。
9. 外向き通信を制御する。 モデル取得、クラウドモデル、ウェブ検索、プロキシ、サードパーティー UI を許可するか決定します。ローカル推論がプロンプトを保護するのは、リクエスト経路全体がローカルに留まる場合だけです。
10. 両方のライセンスを確認する。 Ollama のライセンスとモデルのライセンスは別です。ランタイムをデプロイしても、ライブラリ内のすべてのモデルを使用する権利が付与されるわけではありません。

参考資料 #

• Ollama documentation
• Ollama Docker installation
• Ollama macOS installation
• Ollama API reference
• Ollama OpenAI compatibility
• Ollama CLI reference
• Ollama context length
• Ollama embeddings
• Ollama Modelfile reference
• Ollama FAQ
• Ollama interactive CLI source
• Ollama chat-prompt truncation source
• vLLM documentation
• vLLM project repository