ガイド

著者 Matt Connor 2026-08-29 ・更新日 2026-09-13

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

Q: モデルがクラウドで実行されているのに、アプリはなぜ localhost を指したままなのですか？

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行し、名前が -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

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' を設定します。ローカルサーバーはこれを必須としますが、値自体は使用しません。

認証情報の保存場所と、誰がそれを使用できるか

方法 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 は、ホスト上で検出したビデオメモリに基づいて、ローカルのデフォルトコンテキスト長を決めます。

ChartOllama documented default context length by local VRAM, August 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

The data behind this chart

[
  {
    "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 キャッシュが大きくなり、モデルの重みに加えて、そのキャッシュ分の RAM が必要になります。設定を大きくしすぎると、生成が遅くなったり、モデルの読み込みに失敗したりします。num_ctx と OLLAMA_CONTEXT_LENGTH を正しく設定するでは計算方法を説明し、実際に利用できるメモリに収まるモデルでは重みの要件を説明しています。

実際にマシンから外部へ送信されるもの

この点は正確に理解してください。多くの読者がセルフホストを選ぶ理由だからです。

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

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

落とし穴は path one です。コードには http://localhost:11434 と記述され、ファイアウォールルールも変わっていません。それでもプロンプトがインターネットを通過するのは、モデル名の末尾にある -cloud がルーティングを決めているためです。localhost URL からは、推論がどこで実行されたかは分かりません。判断材料になるのはモデル名です。

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

両方の経路が同じ 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 サーバーにも、稼働中のサーバーと同じ料金が発生します。

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

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

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

実際に目にするエラー

API ではステータスコードが定義されており、それぞれが異なる問題を示します。429 Too Many Requests はレート制限に達したことを意味するため、ループで再接続するのではなく、待機して再試行します。502 Bad Gateway は今回のテーマに固有のコードです。クラウドモデルに到達できない場合に返されるため、path one では daemon は正常に動作しており、upstream 側に問題があることを意味します。モデル名に対する 404 Not Found は通常、suffix が host と一致していない、-cloud の名前を https://ollama.com に直接送信している、またはサインインしていない daemon に bare name を送信していることを示します。エラーは JSON で返されます。ストリームの途中では、NDJSON response 内の {"error":"an error was encountered while running the model"} のような行として現れます。そのため、単純な streaming client は回答の一部を出力した後、説明なしに停止することがあります。ストリームの各行を解析し、error key の有無を確認します。

local 側で典型的なのは、port 11434 への connection refused です。これは daemon が起動していないことを意味するため、systemctl status ollama を確認します。もう1つの典型例は、shell からは動作する request が container からは失敗するケースです。これは、container の localhost が host のものではないためです。

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

各選択肢が適するケース

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

プロンプトをインフラの外部へ出せない場合、マシンをオフラインで動作させる必要がある場合、または負荷が安定していてレンタルした GPU を継続的に稼働させられる場合は、自分で運用します。負荷が安定しているかどうかが重要な判断材料です。メータリング方式の推論は、常時実行すると特に高額になるためです。その段階に達し、Ollama の単一リクエスト処理性能がボトルネックになった場合は、vLLM のほうが Ollama より並行負荷を適切に処理できます。これはホストを変更するのではなく、推論エンジンを変更する対応です。

実際のデプロイでは、両方を使用する構成になることが多く、分担を意図的に設計していれば問題ありません。モデル名を設定に記述し、すべてのフォールバックをログに記録します。そうすれば、ここで重要な唯一の問い、つまり「どのプロンプトがこの環境の外部へ送信されたのか」に常に答えられます。

FAQ

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

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

モデルがクラウドで実行されているのに、アプリはなぜ localhost を指したままなのですか？

ローカルデーモンがプロキシとして動作するためです。ollama signin を実行し、名前が -cloud で終わるモデルをリクエストすると、デーモンはそのリクエストを ollama.com に転送し、応答をポート 11434 経由でストリーミングして返します。アプリケーションの URL が変わらないことが、この仕組みの目的です。コードを変更する必要はありません。ただし、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つ作成します。1つは host 引数なしでローカルデーモンを指定し、もう1つは host="https://ollama.com" と Authorization: Bearer ヘッダーを指定します。その後、最初の呼び出しを httpx.ConnectError と ollama.ResponseError で囲みます。フォールバックの方向は意図的に決めてください。ローカルを優先してクラウドへフォールバックする構成では、非公開にするつもりだったプロンプトが、通常のデーモン再起動中にマシンの外へ出る可能性があります。そのため、すべてのフォールバックをログに記録し、機密性の高いワークロードではフォールバックせずにエラーを返してください。

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