ガイド

著者 Matt Connor 2026-10-11

Ollama Cloudと自前サーバーの違いとは

Q: モデルがクラウドで実行されるのに、アプリはなぜ localhost を参照し続けるのですか？

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行してから、名前が -cloud または :cloud で終わるクラウドモデルを要求すると、デーモンはその要求を ollama.com に転送し、ポート 11434 経由で結果をストリーミングして返します。アプリケーションの URL が変わらないことが、この仕組みの利点です。コードを変更する必要はありません。ただし、localhost アドレスから推論が実行された場所を判断することはできません。URL ではなくモデル名を確認してください。モデル名に cloud タグが付いている場合、プロンプトはインターネットを経由しています。

Q: クラウドに接続できない場合、ローカルモデルへ自動的にフォールバックできますか？

はい。両方の経路が同じ API を使用するため、数行で実装できます。Client オブジェクトを 2 つ作成します。1 つは host 引数なしでローカルデーモンを使用し、もう 1 つは host="https://ollama.com" と Authorization: Bearer ヘッダーを使用します。最初の呼び出しを httpx.ConnectError と ollama.ResponseError で囲んで、エラーを捕捉します。どちらを優先するかは意図的に決めてください。ローカルを優先してクラウドへフォールバックすると、非公開にするつもりだったプロンプトが、デーモンの通常の再起動中にマシンの外部へ送信される可能性があります。そのため、フォールバックをすべてログに記録し、機密性の高いワークロードではフォールバックせずにエラーを返してください。

Ollama Cloudと自前のOllamaは同じCLIとREST APIを使えますが、変わるのはモデル名と認証情報の保存場所です。どのデータが端末外へ送信されるかも確認できます。

Ollama Cloud で変わることと、変わらないこと

Ollama Cloud では、モデルを自分のハードウェアではなく ollama.com 上で実行します。ただし、これまで使用してきた同じ ollama コマンドと同じ REST API はそのまま利用できます。変わるのは、指定するモデル名と、認証情報の保存場所の2点です。アプリケーションのその他の部分は、まったく変更する必要がありません。

この利便性にはリスクもあります。クラウドモデルへのリクエストは、ローカルモデルへのリクエストとコード上で同じように見えます。そのため、どのプロンプトが自分で管理するマシン上で実行され、どのプロンプトが自分の管理下にない企業へ送信されるのかを見失いやすくなります。このガイドでは、その境界を明確にしたうえで、ローカルモデルをフォールバックとして維持する方法を説明します。どちらを使用するかは、1つの設定値だけで切り替えられます。

まだローカル側を構築していない場合は、まず自分の VPS で Ollama を実行する手順から始めてください。以下では、Linux マシン上で動作する ollama があることを前提とします。

Ollama Cloud に接続する 2 つの方法

ホストされたモデルに接続する方法は 2 つあり、相互に置き換えることはできません。どちらを選ぶかによって、認証情報の保存場所、記述するモデル名、サーバー上でパケットキャプチャに現れる内容が決まります。

方法 1: ローカルデーモンでリクエストを転送する。 1 回サインインしてから、名前が -cloud で終わるモデルを指定します。

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

一部のクラウドモデルは、代わりに cloud だけのタグを持ちます。たとえば gemma4:cloud です。現在の Ollama のクラウドドキュメントでは、アプリと CLI にこの形式が示されています。-cloud または :cloud のどちらで終わっていても、クラウドモデルとして扱ってください。

ollama signin は、このマシンを ollama.com アカウントに関連付けます。ollama signout は関連付けを解除します。サインイン後も、アプリケーションはこれまで使用していたローカルポートに接続します。

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

この URL をもう一度確認してください。localhost と記載されていますが、推論はそこで実行されていません。ローカルデーモンは -cloud のサフィックスを認識し、リクエストを ollama.com に転送して、応答をストリームで返します。これが方法 1 の目的です。ポート 11434 の Ollama API を参照する既存のアプリケーションでは、コードを一切変更せず、モデル文字列を変更するだけで済みます。

方法 2: クライアントから ollama.com を直接呼び出す。 この場合、ローカルデーモンはまったく関与しません。https://ollama.com/settings/keys でキーを作成し、bearer token として送信します。

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

モデル名を確認してください。方法 2 では gpt-oss:120b であり、-cloud のサフィックスは付きません。このサフィックスは、ローカルデーモンにリクエストを上流へ転送させるためのものです。そのため、方法 1 でのみ使用します。https://ollama.com を呼び出す時点で、すでにそこへ接続しています。したがって、通常の名前を記述します。これらの名前の正式な一覧は、ホスト自体から取得できます。

curl https://ollama.com/api/tags

この記事を含め、記事に記載されたモデル一覧を信頼する代わりに、これを実行してください。カタログは変更されますが、api/tags は常に最新です。

どのクライアント呼び出しが変わり、どれが変わらないか

公式の Python および JavaScript ライブラリでは、クライアントの構築時にホストとヘッダーを指定します。その行以降に違いはありません。パス 1 では、デフォルトがローカルデーモンであるため、コンストラクターは空です。

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

パス 2 では、コンストラクターにホストとトークンを指定します。

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

client.chat() の呼び出し、ストリーミングループ、メッセージリスト、レスポンスの形式は、どちらも同一です。そのため、ホステッド環境とセルフホスト環境の移行は、書き直しではなく設定変更で済みます。OpenAI 互換のインターフェースもローカルで同じように動作します。OpenAI SDK の接続先を http://localhost:11434/v1/ に設定し、api_key='ollama' を指定します。これは SDK が必須とするプレースホルダーであり、ローカルサーバーは無視します。

資格情報の保存場所と、その利用者

方法2では、資格情報は環境内の OLLAMA_API_KEY にあります。シェル履歴やリポジトリに残さないでください。systemd サービスでは、Environment= 行に設定するか、root が所有し、mode 600 の環境ファイルに保存します。

方法1は、意外に感じる人が多い方法です。サインインはあなたではなく、デーモンに紐づきます。Ollama FAQ では、Linux 上のサービス ID は /usr/share/ollama/.ollama/id_ed25519.pub にあり、ollama サービスユーザーが所有すると説明されています。ローカル API にはリクエスト単位の認証がないため、port 11434 に到達できるすべての呼び出し元が、あなたのアカウントと quota を引き継いで使用できます。デーモンが loopback で待ち受けている間は問題ありません。OLLAMA_HOST=0.0.0.0:11434 を設定して別のマシンから到達できるようにした瞬間、公開された port が課金関係の公開につながります。そのため、bind address を広げる前に、Ollama endpoint の前段に認証を設定する方法を確認してください。

ローカルでは同じモデルのコンテキストが短くなる理由

モデルがどちらの経路でも同じように動作すると考えると、ここで違いに気付きます。実際には同じではありません。原因はメモリです。

Ollama は、ホスト上で検出したビデオメモリ容量から、ローカルのデフォルトのコンテキスト長を決定します。

グラフOllama documented default context length by local VRAM, October 2026

label

default_context_tokens

Under 24 GiB VRAM

4,096

24 to 48 GiB VRAM

32,768

48 GiB VRAM or more

262,144

このグラフのデータ

[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

GPU を搭載しない VPS は最下位の区分に入るため、ローカルモデルは 4,096 トークンのコンテキストから開始します。一方、大容量のカードを搭載したマシンでは 262,144 から開始します。クラウドモデルはこの区分を使用しません。Ollama のドキュメントでは、クラウドモデルはデフォルトで最大コンテキスト長に設定されています。コンテキストを保持するメモリが自分のマシン上にないためです。

そのため、gpt-oss:120b-cloud に対して動作する同じプロンプトでも、容量の小さいホスト上のローカルモデルでは、気付かないうちに切り詰められることがあります。ローカルの上限を明示的に引き上げます。

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

systemd では、systemctl edit ollama.service を使って Environment="OLLAMA_CONTEXT_LENGTH=32768" として設定し、その後 systemctl daemon-reload && systemctl restart ollama を実行します。ただし、何を増やすことになるのかを理解しておく必要があります。コンテキストを長くすると key-value cache が大きくなり、モデルの重みに加えて、そのキャッシュ用の RAM も必要になります。設定を上げすぎると生成が遅くなったり、モデルを読み込めなくなったりします。num_ctx と OLLAMA_CONTEXT_LENGTH を正しく設定する方法では計算方法を、実際に使用できるメモリに収まるモデルでは重みの観点を説明しています。

実際にマシンの外へ出るもの

ここは正確に理解してください。多くの読者が self-host を選ぶ理由そのものだからです。

ローカルで実行する場合、何も外へ出ません。 Ollama のプライバシーポリシーには、ローカル利用について「ローカルで処理するプロンプト、応答、モデルとのやり取り、その他のコンテンツを収集、保存、送信したり、アクセスしたりすることはありません」と明記されています。1 つ注意点があります。モデルの取得は ollama.com からのダウンロードです。ポリシーには、収集する情報として「モデルのダウンロードメタデータ」と IP アドレスも挙げられています。レジストリは、どのモデルを取得したかを把握します。何を質問したかは把握しません。

クラウド経由で実行する場合、プロンプト全体と生成結果全体が第三者に送られます。 これに部分的な例外はありません。送信するすべてのトークンと受信するすべてのトークンが ollama.com で処理されます。ポリシーでは、サービス提供のために「プロンプトと応答を一時的に処理する」と説明し、「入力や出力を AI モデルの学習には使用しない」としています。また、「プロンプトと応答の内容を保持しないよう設計された技術的対策」についても説明しています。これは妥当な取り組みです。ただし、これは自分のマシンの性質ではなく、引き渡したデータについて他者が示す取り組みです。ほかのベンダーの約束と同じように評価し、自分のインフラストラクチャーに保持することが契約上または法的に義務付けられている情報を送る前に、もう一度確認してください。

落とし穴は path one です。コードには http://localhost:11434 と書かれ、ファイアウォールのルールも変わっていないのに、プロンプトはインターネットを経由します。モデル名の -cloud suffix がルーティングを担っているためです。localhost URL からは、推論がどこで実行されたかは分かりません。判断材料になるのはモデル名です。これは、非公開に保つために self-host しているデータをプロンプトに含める場合に特に重要です。たとえば、移動履歴を第三者に送らないために self-hosted の位置情報トラッカーを運用していても、その1週間分を -cloud model に要約させると、履歴は結局 ollama.com に送られます。

プロンプトを決して転送してはならないサーバーでは、この選択肢自体をなくしてください。Ollama には local-only mode が用意されています。サービス環境で OLLAMA_NO_CLOUD=1 を設定するか、~/.ollama/server.json の "disable_ollama_cloud": true に設定してから再起動します。daemon は cloud models と web search にアクセスできなくなるため、誤って cloud model name を指定しても情報が漏れることはありません。

ローカルモデルをフォールバックとして維持する

両方の経路が同じ API を使用するため、コードを分岐させず、実行時の設定として選択できます。

最も単純な方法では、コードを変更する必要がありません。アプリケーションはローカルデーモンを参照したままにし、モデル名を設定に記述します。llama3.2 に設定すると、自分のマシン上で実行されます。gpt-oss:120b-cloud に設定すると、同じデーモンが ollama.com に転送します。環境変数 1 つで切り替えられ、再デプロイは不要です。

ローカルモデルをデフォルトにし、処理があふれた場合だけクラウドへ切り替えるには、両方のクライアントを構築し、リクエストごとに選択します。

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx は ollama パッケージの依存関係として追加されるため、別途インストールするものはありません。ConnectError はデーモンが停止している場合に対応します。ResponseError はデーモンが起動していても要求を拒否する場合に対応します。たとえば、ローカルモデルをまだ取得していない場合です。

この print の行は飾りではありません。フォールバックを黙って実行すると、自分のハードウェア内に保持するつもりだったプロンプトが、アップグレード中にデーモンが再起動した最初の時点で、気付かないうちに第三者へ送信されます。フォールバックはすべてログに記録し、機密性の高い処理ではフォールバックせずにエラーを発生させてください。プライバシーを重視するデプロイでは、エラーを明示的に発生させるポリシーが最も安全です。

ローカル側を信頼できるデフォルトにするには、モデルをメモリ上に常駐させることも重要です。CPU のみの VPS では、初回ロードに数十秒かかることがあります。この遅延が、そもそもクラウド経路へ切り替える原因になります。keep_alive でモデルをメモリに保持すると、初回リクエスト時の遅延をなくせます。

コミット前に比較する項目

価格だけで比較しないでください。この記事を含め、記事で読んだ価格は掲載日も含めて信用しないでください。次の4項目を比較し、それぞれをベンダーの公式ページで確認します。

モデルの提供状況。 現在のホスト型カタログを curl https://ollama.com/api/tags で確認します。ローカルで実行できるモデルは、代わりに RAM と VRAM の容量で制限されます。
コンテキスト上限。 ホスト型モデルはデフォルトで最大値を使用します。ローカルモデルは、前述の VRAM の区分に応じた値がデフォルトです。処理対象が長文書であれば、これだけで選択が決まります。
レート制限。 ホスト型推論には使用量の計測があります。制限を超えると、API は 429 Too Many Requests を返します。自分のサーバーにはレート制限がなく、代わりに同時実行数の厳しい上限があります。これは別の障害であり、多くの場合はこちらのほうが深刻です。
保持ポリシー。 実際のポリシー本文を読み、読んだ日付を記録します。更新前にもう一度確認してください。

費用については、ここで計算をやり直す必要はありません。GPU VPS がトークン単位の課金を上回る時点では、損益分岐点を正しく計算しています。多くの人が見落とす点も含まれています。アイドル状態の GPU サーバーにも、稼働中のサーバーと同じ料金が発生します。ノーコードで使えるプライベート AI サーバーを見積もりで契約する選択肢も比べたい場合は、Zanus AI と自作サーバーの費用比較で、同等の構成をレンタル GPU で自作する費用と、運用に必要な担当者の負担を確認できます。

複数のプロバイダーの前段にルーターを置く場合はどうでしょうか？

3 つ目の選択肢はルーターです。ルーターは、アプリケーションとは 1 つの API で通信し、リクエストを複数のバックエンドへ振り分けるプロキシです。自分でホストする LiteLLM proxy や、OpenRouter などのホスト型サービスがこの役割を担います。利点は明確です。クライアント側の設定を 1 つにまとめながら、複数のモデルを利用できます。また、プロバイダーの調子が一時的に悪い場合はフェイルオーバーできます。これは、前述のフォールバックパターンを 2 つのバックエンドに限らず拡張したものです。

ただし、コストを明確に把握してください。ホスト型ルーターは、プロンプトを閲覧できる別の運用事業者です。そのため、1 社のベンダーに確認していた保持期間の問題を、2 社に確認する必要があります。自分でホストするルーターなら、その通信経路を自分のマシン内に置けます。一方で、運用、パッチ適用、監視が必要なサービスが 1 つ増えます。ルーターが解決するのは、モデルの選択と可用性です。プライバシーの問題は解決しません。プロンプトは、ルーターが選択した送信先に到達するためです。

実際に表示されるエラー

API にはステータスコードが定義されており、それぞれが異なる問題を示します。429 Too Many Requests はレート制限に達したことを示すため、ループで再接続するのではなく、待機してから再試行します。502 Bad Gateway は今回のテーマに固有のコードです。クラウドモデルに到達できない場合に返されるため、パス 1 ではデーモンは正常で、上流側に問題があることを意味します。モデル名に対する 404 Not Found は、指定したホストにそのモデルが存在しないことを示します。通常は、-cloud の名前をそのまま https://ollama.com に送信した場合か、ローカルモデルをまだ pull していない場合に発生します。ローカルモデルでは、ローカル API に認証が必要ないため、サインインは関係ありません。エラーは JSON で返されます。ストリーム中は、NDJSON レスポンス内に {"error":"an error was encountered while running the model"} のような行として現れます。そのため、単純なストリーミングクライアントでは回答の一部を表示した後、説明なしに停止することがあります。ストリームの各行を解析し、error キーを確認してください。

ローカル側で典型的なのは、port 11434 への connection refused です。これは、そのポートで何も listen していないことを意味します。systemctl status ollama を確認し、デーモンが実行中であれば、OLLAMA_HOST によって別のポートへ変更されていないかを確認します。もう 1 つの典型例は、shell からは動作するリクエストが container からは失敗するケースです。これは、container の localhost がホストのものではないためです。

エラーメッセージがまったく表示されない失敗もあります。インターネット接続がない場合です。cloud パスは完全に停止しますが、local パスには影響がありません。マシンを外部へ持ち出した場合や、provider で routing 障害が発生した場合、この違いが製品全体の動作を左右します。

各選択肢が適している場合

処理量が断続的に増減する場合、モデルが VPS に収まらない場合、またはそのモデルを基盤として採用する価値をまだ判断している段階では、Ollama Cloud を使用します。1 日 20 分しか稼働しない GPU に料金を払い続けるより、リクエスト単位で支払うほうが合理的です。また、120-billion-parameter のモデルは、昼食代ほどの料金で借りるサーバーには収まりません。

プロンプトをインフラの外部に出せない場合、マシンをオフラインで動作させる必要がある場合、または負荷が安定していてレンタルした GPU を継続的に稼働させられる場合は、自分で実行します。判断の基準になるのは安定した負荷です。メータリング方式の推論が高コストになるのは、常時実行する場合だからです。そこまで負荷が増え、Ollama の単一リクエストのスループットがボトルネックになった場合は、vLLM のほうが Ollama より同時負荷を適切に処理できます。これはホストを変更するのではなく、エンジンを変更する対応です。自分で構築するより、そのプライベート環境を購入したい場合は、見積もりのみで提供されるプライベート AI サーバーと、レンタル GPU 上で自分で構築する方法を比較することで、実際の構築内容と、通常の API を購入したほうがよい場合を確認できます。

実際のデプロイでは、最終的に両方を使うことが多く、それ自体に問題はありません。ただし、使い分けを明確に決めておく必要があります。モデル名を設定に記述し、すべてのフォールバックをログに記録してください。そうすれば、ここで重要な唯一の問い、つまり「これらのプロンプトのうち、どれが環境の外部に送信されたのか」に常に答えられます。

FAQ

Ollama Cloud はプロンプトを確認しますか？

はい。ホスティング経由では、完全なプロンプトと完全な生成結果が ollama.com に送信され、そこで処理されます。Ollama のプライバシーポリシーでは、「サービスを提供するため、ユーザーのプロンプトと応答を一時的に処理する」とし、「入力または出力を AI モデルの学習には使用しない」と説明しています。また、保持期間を最小限にするための対策についても記載しています。これは、すでに送信したデータに対するベンダーの方針です。ローカルモデルについては、同じポリシーで、ローカルで処理するプロンプト、応答、モデルとのやり取り、その他のコンテンツを「収集、保存、送信せず、アクセスもしない」と説明しています。コンテンツを自分のインフラストラクチャの外部へ一切出せないことが要件であれば、要件を満たすのはローカル経由だけです。

モデルがクラウドで実行されるのに、アプリはなぜ localhost を参照し続けるのですか？

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行してから、名前が -cloud または :cloud で終わるクラウドモデルを要求すると、デーモンはその要求を ollama.com に転送し、ポート 11434 経由で結果をストリーミングして返します。アプリケーションの URL が変わらないことが、この仕組みの利点です。コードを変更する必要はありません。ただし、localhost アドレスから推論が実行された場所を判断することはできません。URL ではなくモデル名を確認してください。モデル名に cloud タグが付いている場合、プロンプトはインターネットを経由しています。

同じモデルなのに、ローカルではコンテキストが大幅に短くなるのはなぜですか？

Ollama は、利用可能なビデオメモリに基づいてローカルのデフォルト値を選択します。VRAM が 24 GiB 未満の場合は約 4k tokens、24 GiB 以上 48 GiB 未満の場合は 32k、48 GiB 以上の場合は 256k です。GPU のない VPS は最下位の範囲に該当します。クラウドモデルでは、コンテキストを保持するメモリがプロバイダー側にあるため、デフォルトで最大コンテキスト長に設定されます。ローカルの値は OLLAMA_CONTEXT_LENGTH で増やせます。OLLAMA_CONTEXT_LENGTH=32768 ollama serve として指定するか、systemctl edit ollama.service の下に Environment= 行を追加します。コンテキストを長くすると、RAM 上の key-value cache も大きくなる点に注意してください。小規模なサーバーで値を増やすと、生成が遅くなったり、モデルを読み込めなくなったりすることがあります。

クラウドに接続できない場合、ローカルモデルへ自動的にフォールバックできますか？

はい。両方の経路が同じ API を使用するため、数行で実装できます。Client オブジェクトを 2 つ作成します。1 つは host 引数なしでローカルデーモンを使用し、もう 1 つは host="https://ollama.com" と Authorization: Bearer ヘッダーを使用します。最初の呼び出しを httpx.ConnectError と ollama.ResponseError で囲んで、エラーを捕捉します。どちらを優先するかは意図的に決めてください。ローカルを優先してクラウドへフォールバックすると、非公開にするつもりだったプロンプトが、デーモンの通常の再起動中にマシンの外部へ送信される可能性があります。そのため、フォールバックをすべてログに記録し、機密性の高いワークロードではフォールバックせずにエラーを返してください。

#ollama #self-hosting #llm #privacy #gpu