Ollama Cloud 與自架伺服器有何不同？

Ollama Cloud 的變更內容與不變事項

Ollama Cloud 會將模型執行於 ollama.com，而不是您自己的硬體上，同時保留相同的 ollama 命令，以及您目前呼叫的相同 REST API。只有兩項內容會變更：您要求使用的模型名稱，以及憑證存放的位置。除此之外，應用程式維持不變；以下將說明唯一的例外：結構化輸出。

這項便利性也帶來風險。雲端模型的請求在程式碼中的形式與本機模型相同，因此很容易無法確認哪些提示詞是在您控制的機器上執行，哪些提示詞則會傳送給您無法控制的公司。本指南會先劃清這條界線，再說明如何保留本機模型作為備援，讓單一設定值決定您使用哪一側。

如果您尚未完成本機端的建置，請先從在自己的 VPS 上執行 Ollama開始。以下內容均假設 Linux 主機上已有可正常運作的 ollama。

存取 Ollama Cloud 的兩種方式

存取託管模型有兩種方式，兩者不可互換。選擇哪一種方式，會決定憑證儲存的位置、要填寫的模型名稱，以及在伺服器上擷取封包時會看到的內容。

方式一：由本機 daemon 轉送請求。 先登入一次，再要求名稱以 -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，而推論並不是在這裡執行。本機 daemon 會辨識 -cloud 尾碼，將請求轉送至 ollama.com，再把回應串流傳回給您。這就是方式一的重點：原本已指向 11434 埠上的 Ollama API 的應用程式，可以維持原本的 URL 與用戶端程式碼；一般聊天只需改用不同的模型字串。例外是結構化輸出。Ollama 文件指出「Ollama 的雲端服務目前不支援結構化輸出」，因此，若應用程式在 format 參數中傳入 JSON schema，並依賴回應符合該 schema，就必須先修改後才能改用雲端模型：在您自己的程式碼中進行驗證並重試，或讓該請求繼續使用本機模型。

方式二：由用戶端直接呼叫 ollama.com。 這裡完全不會使用本機 daemon。請在 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
  }'

查看模型名稱。方式二使用 gpt-oss:120b，不含 -cloud 尾碼。這個尾碼是用來通知本機 daemon 將請求轉送至上游，因此只適用於方式一。呼叫 https://ollama.com 時，您已直接連線至該服務，應填寫不含尾碼的名稱。這些名稱的權威清單來自主機本身：

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

請執行這個指令，不要相信文章中列出的任何模型清單，包括本文。模型目錄會變更，而 api/tags 一律是最新資料。

哪些用戶端呼叫會變更，哪些不會

官方的 Python 與 JavaScript 程式庫會在建立用戶端時取得主機與標頭。該行之後的內容都不需要變更。在路徑一中，建構函式留空，因為預設值是本機 daemon：

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)

在路徑二中，建構函式會帶入主機與 token：

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() 呼叫、串流迴圈、訊息清單與回應結構都相同。因此，除非某個呼叫依賴 structured outputs，而 Ollama 的 cloud 目前不支援該功能，否則在代管與自架環境之間切換只需變更設定，不必重寫程式。OpenAI 相容介面在本機的運作方式也相同：將 OpenAI SDK 指向 http://localhost:11434/v1/，並設定 api_key='ollama'；這是 SDK 要求的 placeholder，本機伺服器則會忽略它。

憑證存放位置，以及可使用該憑證的對象

在路徑二中，憑證位於你的環境變數 OLLAMA_API_KEY。請勿讓它出現在 shell 歷程記錄或儲存庫中。對於 systemd 服務，請將它放在 Environment= 行中，或放在由 root 擁有且權限為 600 的環境檔案中。

路徑一才是容易讓人意外的部分。登入憑證屬於 daemon，而不是屬於你。Ollama FAQ 說明，Linux 上的服務身分位於 /usr/share/ollama/.ollama/id_ed25519.pub，其擁有者是 ollama 服務使用者。local API 不會針對每個要求進行驗證，因此所有能連線到 port 11434 的呼叫端，都會繼承你的帳戶並使用你的配額。只要 daemon 監聽 loopback，這樣通常沒有問題。你一旦設定 OLLAMA_HOST=0.0.0.0:11434，讓其他機器也能連線，開放的連接埠就會變成開放的計費關係。因此，在擴大 bind address 之前，請先閱讀如何在 Ollama endpoint 前方加入驗證。

為什麼相同模型在本機提供的上下文較少

這是容易讓人誤以為模型在兩種路徑上的行為完全相同的差異。實際上並不相同，原因在於記憶體。

Ollama 會依據在該主機上找到的視訊記憶體，選擇本機的預設上下文長度。

[
  {
    "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 tokens；配備大容量顯示卡的機器則為 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，而該 cache 會在模型權重之外額外占用模型所需的 RAM。設定過高會使生成速度變慢，或導致模型無法載入。正確設定 num_ctx 與 OLLAMA_CONTEXT_LENGTH說明計算方式；哪些模型符合你實際擁有的記憶體則說明模型權重所需的記憶體。

實際離開你機器的資料

這點必須說清楚，因為這正是多數讀者採用 self-hosting 的首要原因。

在本機執行時，不會有資料離開。 Ollama 的隱私權政策明確指出，本機使用時，「我們不會蒐集、儲存、傳輸，也無法存取您在本機處理的提示、回應、模型互動或其他內容。」但有一項例外：提取模型仍是從 ollama.com 下載，而該政策將「模型下載中繼資料」及您的 IP 位址列為蒐集項目。Registry 會知道您提取了哪些模型，但不知道您向模型提出了什麼問題。

透過雲端路徑執行時，完整提示與完整完成內容都會傳送給第三方。 這不是部分傳送的情況。您送出的每個 token 和收到的每個 token，都會在 ollama.com 上處理。政策指出，公司會「暫時處理您的提示與回應以提供服務」，且「不會使用您的輸入或輸出訓練任何 AI 模型」，並說明採取了「旨在降低提示與回應內容保留程度的技術措施」。這是合理的承諾，但仍是他人對您交付資料所作的承諾，而不是您自己機器本身具備的特性。請以評估任何供應商承諾的方式評估這項政策，並在傳送任何依合約或法律規定必須留在自有基礎架構內的資料前重新閱讀。

陷阱在於路徑一。您的程式碼顯示 http://localhost:11434，防火牆規則沒有變更，而提示仍會跨越網際網路，因為模型名稱中的 -cloud 後綴負責進行路由。localhost URL 無法告訴您推論在哪裡完成；模型名稱才可以。當提示包含您特別 self-host 以維持私密性的資料時，這點尤其重要：如果您執行自架位置追蹤器，讓移動歷史不會傳給第三方，卻要求 -cloud 模型摘要其中一週的資料，這段歷史仍會傳送到 ollama.com。

如果伺服器絕對不能轉送提示，請直接移除這項選擇。Ollama 提供僅限本機模式的說明：在服務環境中設定 OLLAMA_NO_CLOUD=1，或在 ~/.ollama/server.json 中設定 "disable_ollama_cloud": true，然後重新啟動。daemon 將無法存取雲端模型與網頁搜尋，因此即使誤用雲端模型名稱，也不會洩漏任何資料。

將本機模型作為備援

由於兩條路徑使用相同的 API，您可以將選擇設為執行階段設定，而不必在程式碼中分叉。

最簡單的做法完全不需要修改程式碼。讓應用程式持續指向本機 daemon，並在設定中指定模型名稱。設為 llama3.2 時，應用程式會在自己的主機上執行。設為 gpt-oss:120b-cloud 時，同一個 daemon 會將請求轉送至 ollama.com。只需設定一個環境變數，無須重新部署。

如果您希望本機模型作為預設，並在流量超出本機處理能力時改用雲端，可以建立兩個 client，再依每個請求選擇：

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 處理 daemon 未啟動的情況。ResponseError 處理 daemon 已啟動但拒絕請求的情況，例如本機模型從未下載過。

print 這一行不是裝飾。無聲備援表示您原本打算留在自有硬體上的提示，可能會在 daemon 升級重新啟動時，首次悄悄傳送給第三方。請記錄每次備援；對於敏感內容，應直接回報錯誤，不要啟用備援。對於以隱私為優先的部署，最安全的備援政策是明確失敗。

還有一項設定能讓本機模型成為可靠的預設選項：讓模型常駐記憶體。僅使用 CPU 的 VPS 進行冷載入可能需要數十秒，這正是使用者改走雲端路徑的主要原因。使用 keep_alive 將模型保留在記憶體中可以消除第一次請求的延遲。

提交前應比較的項目

不要只比較價格，也不要相信文章中看到的價格，包括本文標示的日期。請比較以下 4 項，並逐一查閱供應商自己的頁面：

• 模型可用性。 執行 curl https://ollama.com/api/tags 取得目前的託管模型目錄。可在本機執行的模型則受 RAM 和 VRAM 限制。
• 上下文限制。 託管模型預設使用最大值。本機模型則依上述 VRAM 等級設定預設值。如果工作負載包含長篇文件，這項限制本身就能決定選擇。
• 速率限制。 託管推論依 token 計費：Ollama 的定價頁面表示：「Usage is measured in tokens at each model's rates.」付費方案包含每月額度，而 Ollama「uses included plan credits first, then draws from the purchased usage credit balance.」每個方案都有並行數上限（截至 October 27, 2026，$0 Pay as you go 方案和 Pro 為 3 個並行請求，Max 和 Team 為 10 個），超過上限的請求會排入佇列，只有佇列已滿時才會遭到拒絕。自行管理的伺服器沒有使用量計量，只有硬體本身的並行上限。這是不同類型的故障，而且通常更嚴重。
• 保留政策。 閱讀實際政策文字，記下閱讀日期，並在任何續約前重新確認。

至於費用部分，這裡不必重新計算。GPU VPS 何時會超過按 token 計費會正確計算損益平衡點，也包含人們容易忽略的一點：閒置的 GPU 伺服器與忙碌中的伺服器計費相同。

多家服務供應商前方使用路由器時如何？

第三種選項是路由器，也就是向應用程式提供單一 API，並將請求分散到多個後端的代理程式。自行託管的 LiteLLM proxy，或 OpenRouter 這類託管服務，都能執行這項工作。這種方式的優點很明顯：只需設定一個用戶端，即可使用多個模型；當某個供應商暫時發生問題時，也能進行故障轉移。這是前述 fallback 模式的自然延伸，將適用範圍從兩個後端擴展到更多後端。不過，必須清楚了解其代價。託管式路由器是另一個能看到您提示內容的營運方，因此原本向單一供應商詢問的資料保留問題，現在也必須向兩方詢問。自行託管的路由器會讓這個中繼環節留在自己的機器上，但您也需要再維護、修補及監控一項服務。路由器能解決模型選擇與可用性問題，但無法解決隱私問題，因為提示內容仍會傳送到路由所指定的位置。

實際會看到的錯誤

API 文件會說明狀態碼，而每個狀態碼都指向不同的問題。429 Too Many Requests 表示觸發速率限制，因此應先等待後重試，不要在迴圈中反覆重新連線。502 Bad Gateway 是本主題特有的狀態碼：當無法連線至雲端模型時就會回傳，因此在路徑一中，這表示你的 daemon 正常運作，問題出在上游服務。模型名稱出現 404 Not Found 時，表示你指定的主機上不存在該模型：通常是將 -cloud 名稱直接傳給 https://ollama.com，或是尚未拉取的本機模型。對本機模型而言，登入與此無關，因為本機 API 不需要驗證。

錯誤會以 JSON 傳回。在串流傳輸期間，錯誤會以類似 {"error":"an error was encountered while running the model"} 的單行內容出現在 NDJSON 回應中。因此，處理不完整的串流用戶端可能會先輸出部分回答，接著在沒有任何說明的情況下停止。請解析每一行串流內容，並檢查是否包含 error 索引鍵。

本機端最常見的問題，是對 11434 埠收到 connection refused，表示該埠沒有程序正在監聽。請檢查 systemctl status ollama；如果 daemon 正在執行，請確認 OLLAMA_HOST 是否將服務移至其他埠。另一個常見問題是請求可從 shell 成功執行，卻在容器中失敗，原因是容器中的 localhost 並不是主機的 localhost。

還有一種完全沒有錯誤訊息的失敗情況：沒有網際網路。雲端路徑會完全停止運作，但本機路徑不會受到影響。如果機器被帶到外部網路環境，或供應商發生路由事故，這項差異就是整個產品的核心。

何時適合採用各種方案

在工作負載具突發性、模型大到超出 VPS 的處理能力，或仍在評估是否值得以某個模型為基礎進行開發時，適合使用 Ollama Cloud。按 token 計費，比支付每天只執行 20 分鐘的閒置 GPU 費用更划算；擁有 120 billion 個參數的模型，也不可能容納在租金只需一頓午餐費用的主機上。

當提示內容不得離開基礎架構、機器必須在離線環境中運作，或負載穩定到足以讓租用的 GPU 持續忙碌時，適合自行執行。穩定負載才是可靠的判斷依據：計量式推論在持續執行時尤其昂貴。若 Ollama 的單一請求吞吐量成為瓶頸，vLLM 對並行負載的處理能力優於 Ollama；這是更換引擎，而不是更換主機。若你希望直接購買這種私有部署，而不是自行建置，比較僅提供報價的私有 AI 伺服器與自行在租用 GPU 上建置的方案，可了解實際建置內容，以及何時購買一般 API 會更划算。

多數實際部署最後會同時採用兩者，只要事先明確規劃分工即可。將模型名稱放在設定中，記錄每次 fallback，如此就能隨時回答這裡唯一重要的問題：哪些提示內容離開了這個環境？

FAQ

Ollama Cloud 會看到我的提示嗎？

會。在代管路徑中，完整提示與完整回應都會傳送至 ollama.com，並在該處處理。Ollama 的隱私權政策表示，該公司會「暫時處理您的提示與回應以提供服務」，且「不會使用您的輸入或輸出訓練任何 AI 模型」，並說明了旨在降低資料保留時間的措施。這是供應商對您已交付資料所作的承諾。對於本機模型，同一份政策表示該公司「不會收集、儲存、傳送或存取您在本機處理的提示、回應、模型互動或其他內容」。如果要求內容不得離開您的基礎架構，只有本機路徑符合此要求。

為什麼模型在雲端執行時，我的應用程式仍指向 localhost？

因為本機 daemon 會充當 proxy。執行 ollama signin 後，若要求使用雲端模型，也就是名稱以 -cloud 或 :cloud 結尾的模型，daemon 會將要求轉送至 ollama.com，再透過 port 11434 將回應串流傳回。應用程式 URL 不會變更，這正是其設計目的：一般聊天要求不需要修改程式碼。不過，依賴結構化輸出的呼叫需要重新處理，因為 Ollama 的雲端服務目前不支援這項功能。這也表示 localhost 位址無法告訴您推論實際在哪裡執行。請檢查模型名稱，而不是 URL。名稱中的 cloud 標籤表示提示已跨越網際網路傳送。

為什麼同一個模型在本機提供的 context 短得多？

Ollama 會依可用的 video memory 選擇本機預設值：VRAM 少於 24 GiB 時約為 4k tokens，介於 24 和 48 GiB 時為 32k，48 GiB 以上時為 256k。沒有 GPU 的 VPS 屬於最低級距。雲端模型預設會使用最大 context length，因為儲存該內容所需的記憶體由供應商提供。使用 OLLAMA_CONTEXT_LENGTH 提高本機值，可以設定為 OLLAMA_CONTEXT_LENGTH=32768 ollama serve，或在 systemctl edit ollama.service 下加入 Environment= 行。請注意，較長的 context 需要 RAM 中更大的 key-value cache，因此在小型伺服器上提高此值可能會降低生成速度，或導致模型無法載入。

雲端無法連線時，可以自動改用本機模型嗎？

可以，而且只需幾行程式碼，因為兩條路徑使用相同的 API。建立兩個 Client 物件：其中一個不帶 host 引數，連線至本機 daemon；另一個則使用 host="https://ollama.com" 加上 Authorization: Bearer header。接著在第一次呼叫外圍捕捉 httpx.ConnectError 和 ollama.ResponseError。請明確決定切換方向。本機優先、雲端備援表示例行 daemon 重新啟動期間，原本要保留私密的提示可能會離開機器。因此，請記錄每次備援；對於敏感工作負載，應直接回報錯誤，而不要切換至備援。