ガイド

著者 Matt Connor 2026-10-27 ・更新日 2026-10-28

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

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

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行し、その後、名前が -cloud または :cloud で終わるクラウドモデルをリクエストすると、デーモンはそのリクエストを ollama.com に転送し、ポート 11434 経由で応答をストリーミングして返します。アプリケーションの URL が変わらないことがこの構成の利点です。通常のチャットリクエストではコードを変更する必要がありません。ただし、構造化出力に依存する呼び出しは作り直す必要があります。現在、Ollama のクラウドは構造化出力をサポートしていないためです。つまり、localhost アドレスを見ても、推論がどこで実行されたかは分かりません。URL ではなくモデル名を確認してください。名前に cloud タグが付いている場合、プロンプトはインターネット経由で送信されています。

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

はい。両方の経路が同じ API を使用するため、数行で実装できます。Client オブジェクトを 2 つ作成します。一方はローカルデーモン用として host 引数を指定せず、もう一方は 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 を使用しているアプリケーションなら、URL とクライアントコードを変更せず、通常のチャットではモデル文字列だけを変更すれば済みます。例外は構造化出力です。Ollama のドキュメントには「Ollama のクラウドは現在、構造化出力をサポートしていません」と記載されています。そのため、format パラメーターに JSON スキーマを渡し、応答がそのスキーマに一致することを前提とするアプリケーションは、クラウドモデルへ移行する前に変更が必要です。独自のコードで検証と再試行を行うか、その呼び出しをローカルモデルで維持してください。

方法 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() の呼び出し、ストリーミングループ、メッセージリスト、レスポンスの形式は、どちらの経路でも同じです。そのため、ホスト型とセルフホスト型の切り替えは、書き直しではなく設定変更で済みます。ただし、構造化出力に依存する呼び出しは例外です。現在の Ollama の cloud は構造化出力をサポートしていません。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 のティアに応じた値がデフォルトになります。ワークロードが長文書の場合、この項目だけで判断が決まります。
レート制限。 ホスト型推論はトークン単位で計測されます。Ollama の料金ページには、「使用量は各モデルの料金に基づいてトークン単位で計測されます」と記載されています。有料プランには月間クレジットの割り当てがあり、Ollama は「まずプランに含まれるクレジットを使用し、その後に購入済みの使用クレジット残高を使用します」。同時実行数はプランごとに上限があります（2026 年 10 月 27 日時点で、$0 Pay as you go ティアと Pro は 3 件、Max と Team は 10 件）。上限を超えたリクエストはキューに入り、キューが満杯になった場合にのみ拒否されます。自分のサーバーには使用量メーターがなく、ハードウェア自体の同時実行数の上限だけがあります。これは別の障害要因であり、多くの場合はより深刻です。
保持ポリシー。 実際のポリシー本文を読み、読んだ日付を記録し、更新前に再確認してください。

費用については、ここで計算をやり直す必要はありません。GPU VPS がトークン単位の課金を上回る条件で損益分岐点を正しく計算しています。見落とされがちな点も含まれています。アイドル状態の 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 パラメーターのモデルは、昼食代程度の料金で借りるサーバーには収まりません。

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

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

FAQ

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

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

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

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行し、その後、名前が -cloud または :cloud で終わるクラウドモデルをリクエストすると、デーモンはそのリクエストを ollama.com に転送し、ポート 11434 経由で応答をストリーミングして返します。アプリケーションの URL が変わらないことがこの構成の利点です。通常のチャットリクエストではコードを変更する必要がありません。ただし、構造化出力に依存する呼び出しは作り直す必要があります。現在、Ollama のクラウドは構造化出力をサポートしていないためです。つまり、localhost アドレスを見ても、推論がどこで実行されたかは分かりません。URL ではなくモデル名を確認してください。名前に cloud タグが付いている場合、プロンプトはインターネット経由で送信されています。

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

Ollama は、利用可能なビデオメモリに基づいてローカルのデフォルト値を選択します。VRAM が 24 GiB 未満の場合は約 4k トークン、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 つ作成します。一方はローカルデーモン用として host 引数を指定せず、もう一方は host="https://ollama.com" と Authorization: Bearer ヘッダーを指定します。その後、最初の呼び出しを httpx.ConnectError と ollama.ResponseError で囲んで例外を捕捉します。切り替え方向は意図的に決めてください。ローカルを優先してクラウドへフォールバックすると、非公開にするつもりだったプロンプトが、通常のデーモン再起動中にマシンの外部へ送信される可能性があります。そのため、すべてのフォールバックをログに記録し、機密性の高いワークロードではフォールバックせずにエラーを返してください。

この記事は役に立ちましたか？

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