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

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 的應用程式完全不需要修改程式碼，只需改用不同的模型字串。

方式二：由用戶端直接呼叫 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() 呼叫、串流迴圈、訊息清單與回應格式都完全相同。因此，從代管環境切換至自架環境只需變更設定，不必重寫程式。本機的 OpenAI 相容介面也以相同方式運作：將 OpenAI SDK 指向 http://localhost:11434/v1/，並設定 api_key='ollama'。本機伺服器需要這項設定，但之後會忽略它。

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

在路徑二中，憑證位於你的環境變數 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 個上下文 token 開始；配備大型顯示卡的機器則從 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說明計算方式；哪些模型符合你實際擁有的記憶體則說明模型權重的需求。

實際離開您機器的資料

請務必釐清這一點，因為這正是多數讀者選擇自架服務的主要原因。

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

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

陷阱在於路徑一。您的程式碼顯示 http://localhost:11434，防火牆規則沒有變更，提示仍會穿過網際網路，因為模型名稱中的 -cloud 尾碼負責路由。localhost URL 無法告訴您推論發生在哪裡，但模型名稱可以。

將本機模型作為備援

由於兩條路徑使用相同的 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 等級設定預設值。如果工作負載是長文件，這項限制本身就能決定選擇。
• 速率限制。 託管推論會計量使用量。超過限制後，API 會回應 429 Too Many Requests。自有伺服器沒有速率限制，而是有固定的並行上限。這會造成不同類型的失敗，而且通常更嚴重。
• 資料保留政策。 閱讀實際的政策文字，記下閱讀日期，並在每次續約前重新確認。

至於費用，不要在這裡重新計算。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，或將未加前綴的名稱傳送給尚未登入的 daemon。錯誤會以 JSON 傳回。在串流中，錯誤會以類似 {"error":"an error was encountered while running the model"} 的行出現在 NDJSON 回應內。因此，未妥善處理的串流用戶端可能會先輸出部分答案，接著毫無說明地停止。請解析每一行串流內容，並檢查是否包含 error 金鑰。

在本機端，最典型的問題是連接埠 11434 被拒絕連線，這表示 daemon 未執行：請檢查 systemctl status ollama。另一個典型問題是請求可在 shell 中正常運作，卻在容器中失敗，因為容器中的 localhost 並不是主機的 localhost。

還有一種完全沒有錯誤訊息的失敗模式：沒有網際網路。雲端路徑會完全停止運作，而本機路徑不會察覺。如果機器被帶到外部網路環境，或服務提供者發生路由事故，這項差異就是整個產品的核心。

何時適合採用各種選項

在工作負載具有突發性、模型太大而無法放入 VPS，或仍在評估是否值得以某個模型為基礎進行開發時，請使用 Ollama Cloud。按請求付費，比支付閒置 GPU 每天僅執行 20 分鐘的費用更划算；而擁有 120-billion-parameter 的模型，不可能放入以一頓午餐的價格租用的主機。

當提示內容不得離開您的基礎架構、機器必須離線運作，或負載穩定到租用的 GPU 能持續忙碌時，請自行執行。穩定負載是最可靠的判斷訊號：計量式推論之所以昂貴，正是因為它會持續執行。如果 Ollama 的單一請求吞吐量成為瓶頸，vLLM 比 Ollama 更能處理並行負載；這是更換引擎，而不是更換主機。

大多數實際部署最後都會同時採用兩者。只要明確規劃分工即可。將模型名稱寫入設定，記錄每次 fallback，這樣就能隨時回答這裡唯一重要的問題：哪些提示內容離開了這棟建築？

FAQ

Ollama Cloud 會看到我的提示嗎？

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

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

因為本機 daemon 正在充當 proxy。執行 ollama signin 後，若要求模型名稱以 -cloud 結尾，您的 daemon 會將要求轉送至 ollama.com，再透過 port 11434 將答案串流傳回。應用程式 URL 不會變更，這正是其用途：不需要修改程式碼。這也表示 localhost 位址無法告訴您推論在哪裡執行。請檢查模型名稱，不要檢查 URL。-cloud 尾碼表示提示已跨越網際網路。

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

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

如果無法連線至 cloud，可以自動改用本機模型嗎？

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