So sánh Ollama Cloud và tự host Ollama trên server

Ollama Cloud thay đổi gì và không thay đổi gì

Ollama Cloud chạy model trên ollama.com thay vì trên phần cứng của bạn, đồng thời vẫn giữ nguyên lệnh ollama và REST API mà bạn đang gọi. Có 2 điểm thay đổi: tên model bạn yêu cầu và nơi lưu credential. Phần còn lại của ứng dụng vẫn giữ nguyên, ngoại trừ một trường hợp đã được tài liệu hóa ở bên dưới: structured outputs.

Sự tiện lợi này cũng đi kèm rủi ro. Trong code, request đến cloud model trông giống hệt request đến model local, nên bạn rất dễ mất dấu prompt nào chạy trên máy do bạn kiểm soát và prompt nào được gửi đến một công ty mà bạn không kiểm soát. Hướng dẫn này làm rõ ranh giới đó, sau đó chỉ cách giữ một model local làm fallback để chỉ một giá trị cấu hình quyết định request chạy ở phía nào.

Nếu bạn chưa thiết lập phần local, trước tiên hãy xem chạy Ollama trên VPS của bạn. Phần bên dưới giả định bạn đã có ollama hoạt động trên một máy Linux.

Hai cách truy cập Ollama Cloud

Có hai cách truy cập các model được host, và chúng không thể thay thế cho nhau. Cách bạn chọn quyết định credential được lưu ở đâu, tên model bạn ghi là gì và packet capture trên server sẽ hiển thị những gì.

Cách một: daemon cục bộ chuyển tiếp request. Bạn đăng nhập một lần, sau đó yêu cầu một model có tên kết thúc bằng -cloud.

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

Một số cloud model chỉ có tag cloud, chẳng hạn gemma4:cloud. Đây cũng là dạng mà tài liệu cloud hiện tại của Ollama dùng cho app và CLI. Hãy xem cả hai hậu tố, -cloud hoặc :cloud, đều là cloud model.

ollama signin liên kết máy này với tài khoản ollama.com của bạn. ollama signout hủy liên kết. Sau khi đăng nhập, ứng dụng của bạn vẫn gửi request đến local port mà nó luôn sử dụng:

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

Đọc lại URL đó. URL ghi là localhost, nhưng inference không diễn ra ở đó. Daemon cục bộ nhận ra hậu tố -cloud, chuyển tiếp request đến ollama.com rồi stream câu trả lời về cho bạn. Đây là mục đích của cách một: ứng dụng đã trỏ đến Ollama API trên port 11434 vẫn giữ nguyên URL và client code, và với chat thông thường, ứng dụng chỉ cần dùng một model string khác. Ngoại lệ là structured outputs. Tài liệu của Ollama nêu rằng “Ollama's cloud hiện chưa hỗ trợ structured outputs”. Vì vậy, ứng dụng truyền JSON schema trong parameter format và yêu cầu câu trả lời khớp với schema đó phải thay đổi trước khi chuyển sang cloud model: tự validate rồi retry trong code của bạn, hoặc giữ request đó trên local model.

Cách hai: client của bạn gọi trực tiếp ollama.com. Ở cách này, daemon cục bộ hoàn toàn không tham gia. Tạo key tại https://ollama.com/settings/keys, sau đó gửi key dưới dạng 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
  }'

Hãy chú ý đến tên model. Ở cách hai, tên là gpt-oss:120b và không có hậu tố -cloud. Hậu tố này dùng để báo cho local daemon chuyển tiếp request lên upstream, nên chỉ thuộc về cách một. Khi gọi https://ollama.com, bạn đã gọi trực tiếp đến đó và phải ghi tên không có hậu tố. Danh sách tên chính thức được lấy trực tiếp từ host:

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

Hãy chạy lệnh đó thay vì tin vào bất kỳ danh sách model nào được in trong một bài viết, kể cả bài viết này. Catalogue thay đổi, còn api/tags luôn là phiên bản hiện tại.

Thay đổi nào ở client, và thay đổi nào không

Các thư viện Python và JavaScript chính thức nhận host và headers khi bạn khởi tạo client. Sau dòng đó, mọi thứ đều giống nhau. Ở phương án một, constructor để trống vì mặc định là local 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)

Ở phương án hai, constructor chứa host và 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)

Lệnh gọi client.chat(), vòng lặp streaming, danh sách message và cấu trúc response đều giống hệt nhau trong cả hai phương án. Vì vậy, chuyển đổi giữa dịch vụ hosted và self-hosted chỉ là thay đổi cấu hình, không phải viết lại code, trừ khi lệnh gọi phụ thuộc vào structured outputs, tính năng hiện chưa được Ollama cloud hỗ trợ. Giao diện tương thích với OpenAI cũng hoạt động tương tự ở local: trỏ OpenAI SDK đến http://localhost:11434/v1/ với api_key='ollama', một giá trị placeholder mà SDK bắt buộc phải có còn local server thì bỏ qua.

Nơi lưu trữ credential và quyền sử dụng

Ở phương án hai, credential nằm trong OLLAMA_API_KEY của môi trường bạn. Hãy giữ nó khỏi lịch sử shell và không đưa vào repository. Trên một service systemd, hãy đặt nó trong dòng Environment= hoặc một file môi trường do root sở hữu với mode 600.

Phương án một là điều gây bất ngờ cho nhiều người. Việc đăng nhập thuộc về daemon, không phải bạn. FAQ của Ollama ghi lại danh tính service trên Linux tại /usr/share/ollama/.ollama/id_ed25519.pub, do user service ollama sở hữu. Không có xác thực cho từng request trên API cục bộ, vì vậy mọi caller có thể truy cập cổng 11434 đều kế thừa tài khoản của bạn và tiêu tốn quota của bạn. Điều này ổn khi daemon lắng nghe trên loopback. Ngay khi bạn thiết lập OLLAMA_HOST=0.0.0.0:11434 để truy cập nó từ máy khác, một cổng mở sẽ trở thành một mối quan hệ thanh toán mở, đó là lý do tại sao bạn nên đọc cách đặt xác thực phía trước một endpoint Ollama trước khi mở rộng bind address.

Vì sao cùng một model nhưng local lại có context ngắn hơn

Đây là điểm thường gây nhầm lẫn khi bạn cho rằng model hoạt động giống hệt nhau trên cả hai cách chạy. Thực tế không phải vậy. Nguyên nhân là bộ nhớ.

Ollama chọn context length mặc định cho local dựa trên video memory mà nó tìm thấy trên máy.

[
  {
    "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"
  }
]

VPS không có GPU thuộc tier thấp nhất. Vì vậy, local model bắt đầu với context gồm 4,096 token, trong khi máy có card lớn bắt đầu với 262,144 token. Cloud model không áp dụng các tier này. Theo tài liệu của Ollama, chúng mặc định dùng context length tối đa vì phần bộ nhớ chứa context đó không thuộc về bạn.

Vì vậy, cùng một prompt chạy được với gpt-oss:120b-cloud có thể bị cắt ngầm khi chạy với local model trên máy có ít tài nguyên. Hãy đặt rõ giới hạn local:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Với systemd, đặt giá trị này bằng Environment="OLLAMA_CONTEXT_LENGTH=32768" với systemctl edit ollama.service, sau đó systemctl daemon-reload && systemctl restart ollama. Bạn cần hiểu tác động của việc này: context dài hơn đồng nghĩa với key-value cache lớn hơn, và cache này cần thêm RAM ngoài phần RAM dành cho weights của model. Nếu đặt quá cao, tốc độ generation sẽ giảm hoặc model không thể load. Đặt num_ctx và OLLAMA_CONTEXT_LENGTH đúng cách trình bày phần tính toán, còn model nào phù hợp với dung lượng memory bạn thực sự có trình bày phần weights.

Điều gì thực sự rời khỏi máy của bạn

Hãy nêu chính xác điểm này, vì đây là lý do ban đầu khiến hầu hết độc giả tự host.

Chạy local thì không có dữ liệu nào rời khỏi máy. Chính sách quyền riêng tư của Ollama nêu rõ rằng khi sử dụng local: “Chúng tôi không thu thập, lưu trữ, truyền hoặc truy cập prompt, response, tương tác với model hay nội dung khác mà bạn xử lý local.” Có một ngoại lệ cần lưu ý: việc pull một model vẫn là hoạt động download từ ollama.com, và chính sách liệt kê “metadata của việc download model” cùng địa chỉ IP của bạn trong số các dữ liệu được thu thập. Registry biết bạn đã fetch những model nào. Registry không biết bạn đã hỏi model những gì.

Chạy qua cloud path thì toàn bộ prompt và toàn bộ completion được gửi cho bên thứ ba. Không có phiên bản nào chỉ gửi một phần. Mọi token bạn gửi và mọi token bạn nhận đều được xử lý trên ollama.com. Chính sách cho biết công ty xử lý “prompt và response của bạn trong thời gian ngắn để cung cấp dịch vụ”, “không sử dụng input hoặc output của bạn để train bất kỳ AI model nào”, đồng thời mô tả “các biện pháp kỹ thuật được thiết kế để giảm thiểu thời gian lưu giữ nội dung prompt và response”. Đây là một cam kết hợp lý. Nhưng đó vẫn là cam kết của bên khác về dữ liệu bạn đã giao cho họ, không phải thuộc tính của máy riêng của bạn. Hãy đánh giá cam kết này như mọi lời hứa của vendor khác, và đọc lại chính sách trước khi gửi bất kỳ dữ liệu nào mà theo hợp đồng hoặc pháp luật bạn phải giữ trên hạ tầng của mình.

Bẫy nằm ở path one. Code của bạn ghi http://localhost:11434, các rule của firewall không thay đổi, nhưng prompt vẫn đi qua Internet vì suffix -cloud trong tên model đang thực hiện việc định tuyến. URL localhost không cho bạn biết inference diễn ra ở đâu. Tên model mới cho biết điều đó. Điểm này đặc biệt quan trọng khi prompt chứa dữ liệu bạn tự host chính vì muốn giữ riêng tư: nếu bạn chạy một ứng dụng theo dõi vị trí tự host để lịch sử di chuyển của mình không bao giờ đến tay bên thứ ba, rồi yêu cầu một model -cloud tóm tắt dữ liệu của một tuần, lịch sử đó vẫn được gửi đến ollama.com.

Trên server tuyệt đối không được forward prompt, hãy loại bỏ hoàn toàn lựa chọn này. Ollama có tài liệu về chế độ chỉ chạy local: đặt OLLAMA_NO_CLOUD=1 trong môi trường của service, hoặc đặt "disable_ollama_cloud": true trong ~/.ollama/server.json, rồi restart. Daemon sẽ mất quyền truy cập vào cloud model và web search, nên một tên cloud model bị dùng nhầm cũng không thể làm rò rỉ dữ liệu.

Duy trì model cục bộ làm phương án dự phòng

Vì cả hai đường dẫn đều sử dụng chung một API, bạn có thể biến lựa chọn này thành thiết lập runtime thay vì phải phân nhánh code.

Phiên bản đơn giản nhất không cần thay đổi code. Hãy giữ ứng dụng trỏ vào daemon cục bộ và đặt tên model trong cấu hình. Thiết lập thành llama3.2 và bạn chạy trên máy của chính mình. Thiết lập thành gpt-oss:120b-cloud và cùng daemon đó sẽ chuyển tiếp yêu cầu đến ollama.com. Chỉ cần một biến môi trường, không cần redeploy.

Khi bạn muốn model cục bộ là mặc định và cloud là phương án dự phòng khi quá tải, hãy khởi tạo cả hai client và chọn lựa theo từng request:

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 đi kèm như một dependency của gói ollama, vì vậy không cần cài đặt thêm gì cả. ConnectError xử lý trường hợp daemon bị down. ResponseError xử lý trường hợp daemon đang chạy nhưng từ chối kết nối, ví dụ khi model cục bộ chưa được pull.

Dòng print đó không phải để trang trí. Dự phòng âm thầm nghĩa là một prompt bạn dự định giữ trên phần cứng của mình sẽ lặng lẽ gửi đến bên thứ ba ngay lần đầu tiên daemon khởi động lại trong quá trình nâng cấp. Hãy log lại mọi lần dự phòng, và với bất kỳ dữ liệu nhạy cảm nào, hãy báo lỗi thay vì dự phòng. Chính sách dự phòng an toàn nhất cho triển khai ưu tiên quyền riêng tư là thất bại một cách rõ ràng.

Còn một điều nữa giúp phía cục bộ trở thành mặc định đáng tin cậy: hãy giữ model thường trú trong bộ nhớ. Một lần cold load trên VPS chỉ dùng CPU có thể mất hàng chục giây, đây chính là lý do khiến người dùng chuyển sang cloud ngay từ đầu. Giữ model trong bộ nhớ với keep_alive sẽ loại bỏ độ trễ của request đầu tiên đó.

Những điều cần so sánh trước khi quyết định

Đừng chỉ so sánh về giá và đừng tin một mức giá bạn đọc trong bài viết, kể cả ngày đăng của bài này. Hãy so sánh 4 yếu tố và kiểm tra từng yếu tố trên trang chính thức của nhà cung cấp:

• Tính khả dụng của model. Chạy curl https://ollama.com/api/tags để xem catalogue hosted hiện tại. Những model bạn có thể chạy local bị giới hạn bởi RAM và VRAM của bạn.
• Giới hạn context. Model hosted mặc định dùng mức tối đa. Model local mặc định theo tier VRAM như trên. Nếu workload của bạn là các tài liệu dài, yếu tố này tự quyết định lựa chọn.
• Rate limit. Hosted inference được tính theo token: trang pricing của Ollama ghi rằng “Mức sử dụng được đo bằng token theo rate của từng model.” Gói trả phí có credit hàng tháng, và Ollama “dùng credit có trong gói trước, sau đó mới trừ vào số dư usage credit đã mua.” Số request chạy đồng thời bị giới hạn theo từng gói (3 request đồng thời ở tier $0 Pay as you go và gói Pro, 10 ở gói Max và Team, tính đến ngày 27 tháng 10 năm 2026), còn request vượt giới hạn sẽ được xếp hàng và chỉ bị từ chối khi queue đầy. Server của bạn không có usage meter, chỉ có giới hạn concurrency do phần cứng quyết định. Đây là một kiểu lỗi khác và thường nghiêm trọng hơn.
• Chính sách lưu giữ dữ liệu. Đọc nội dung chính sách thực tế, ghi lại ngày bạn đọc, rồi kiểm tra lại trước mỗi lần gia hạn.

Về chi phí, đừng tính lại phép toán ở đây. Khi GPU VPS vượt qua cách tính phí theo token phân tích đúng điểm hòa vốn, bao gồm cả điều nhiều người quên: GPU server không hoạt động vẫn bị tính phí như khi đang bận.

Còn router đặt trước nhiều nhà cung cấp thì sao?

Lựa chọn thứ ba là router, một proxy giao tiếp bằng một API duy nhất với ứng dụng của bạn và phân phối các request đến nhiều backend khác nhau. LiteLLM proxy tự host hoặc một dịch vụ như OpenRouter đều thực hiện việc này. Lợi ích rất rõ ràng: chỉ cần một cấu hình client, sử dụng được nhiều model, và có cơ chế failover khi một nhà cung cấp gặp sự cố. Đây là bước phát triển tự nhiên của mô hình fallback nêu trên, được mở rộng vượt ra ngoài phạm vi hai backend. Tuy nhiên, hãy cân nhắc kỹ về chi phí. Một router dạng dịch vụ đồng nghĩa với việc có thêm một đơn vị vận hành khác nhìn thấy các prompt của bạn, vì vậy câu hỏi về lưu trữ dữ liệu mà bạn từng đặt ra cho một nhà cung cấp giờ đây phải áp dụng cho cả hai. Một router tự host giúp giữ bước trung gian này trên máy chủ của bạn, nhưng bạn sẽ phải quản lý thêm một dịch vụ để chạy, cập nhật và monitor. Router giải quyết được vấn đề lựa chọn model và tính sẵn sàng. Chúng không giải quyết được vấn đề quyền riêng tư, vì prompt vẫn sẽ được gửi đến đích cuối cùng mà router chỉ định.

Các lỗi bạn thực sự sẽ gặp

API mô tả các status code, và mỗi mã trỏ đến một vấn đề khác nhau. 429 Too Many Requests nghĩa là bạn đã chạm rate limit, vì vậy hãy giảm tốc độ và retry thay vì reconnect liên tục. 502 Bad Gateway là mã cụ thể của chủ đề này: nó được trả về khi không thể kết nối đến cloud model, nên trên path một, điều đó nghĩa là daemon của bạn vẫn hoạt động còn upstream thì không. 404 Not Found trên tên model nghĩa là model không tồn tại trên host bạn đã chỉ định: thường là tên -cloud được gửi thẳng đến https://ollama.com, hoặc một local model mà bạn chưa pull. Việc đăng nhập không liên quan đến trường hợp này với local model, vì local API không yêu cầu authentication. Lỗi được trả về dưới dạng JSON. Trong lúc stream, lỗi xuất hiện dưới dạng một dòng như {"error":"an error was encountered while running the model"} bên trong phản hồi NDJSON. Vì vậy, streaming client đơn giản có thể in ra một phần câu trả lời rồi dừng mà không giải thích. Hãy parse từng dòng được stream và kiểm tra key error.

Ở phía local, lỗi thường gặp là connection refused trên port 11434. Điều đó nghĩa là không có tiến trình nào đang listen tại đó: hãy kiểm tra systemctl status ollama. Nếu daemon đang chạy, hãy kiểm tra xem OLLAMA_HOST có chuyển daemon sang port khác hay không. Một lỗi thường gặp khác là request chạy được từ shell nhưng thất bại từ container, vì localhost của container không phải là localhost của host.

Còn một kiểu lỗi hoàn toàn không có thông báo: không có Internet. Cloud path ngừng hoạt động hoàn toàn, còn local path không nhận thấy sự cố. Nếu máy của bạn đang được mang đi nơi khác hoặc provider gặp sự cố định tuyến, khác biệt đó chính là toàn bộ giá trị của sản phẩm.

Khi nào nên chọn từng phương án

Dùng Ollama Cloud khi workload không đều, khi model quá lớn so với VPS của bạn, hoặc khi bạn vẫn đang đánh giá model đó có đáng để xây dựng hệ thống dựa trên nó hay không. Trả tiền theo token tốt hơn trả tiền cho một GPU ở trạng thái idle nhưng chỉ chạy 20 phút mỗi ngày. Một model có 120 tỷ tham số sẽ không thể chạy trên một máy chủ được thuê với mức giá chỉ tương đương một bữa ăn trưa.

Tự chạy model khi prompt không được phép rời khỏi hạ tầng của bạn, khi máy phải hoạt động offline, hoặc khi tải đủ ổn định để GPU thuê luôn được sử dụng. Tải ổn định là tín hiệu rõ nhất: inference tính phí theo mức sử dụng sẽ đắt chính xác khi nó chạy liên tục. Nếu Ollama đạt đến giới hạn throughput của một request và trở thành bottleneck, vLLM xử lý tải đồng thời tốt hơn Ollama, và đây là việc thay engine chứ không phải thay host. Nếu bạn muốn mua một hệ thống private thay vì tự xây dựng, so sánh báo giá máy chủ AI private chỉ cung cấp theo yêu cầu với việc tự xây dựng trên GPU thuê sẽ cho thấy hệ thống đó thực sự cần những gì, cũng như khi nào một API đơn giản là lựa chọn đáng mua hơn.

Hầu hết deployment thực tế đều dùng cả hai phương án. Điều này hoàn toàn ổn nếu việc phân tách được chủ động thiết kế. Đặt tên model trong configuration, log mọi lần fallback, và bạn sẽ luôn trả lời được câu hỏi duy nhất thực sự quan trọng ở đây: những prompt nào đã rời khỏi hạ tầng của bạn?

FAQ

Ollama Cloud có thấy prompt của tôi không?

Có. Với đường đi qua dịch vụ hosted, toàn bộ prompt và toàn bộ completion được gửi đến ollama.com để xử lý tại đó. Chính sách quyền riêng tư của Ollama cho biết họ xử lý “prompt và response của bạn trong thời gian tạm thời để cung cấp dịch vụ” và “không sử dụng input hoặc output của bạn để train bất kỳ model AI nào”, đồng thời mô tả các biện pháp nhằm giảm thiểu thời gian lưu trữ. Đây là cam kết của nhà cung cấp đối với dữ liệu bạn đã gửi đi. Với local model, cùng chính sách đó cho biết công ty “không thu thập, lưu trữ, truyền hoặc có quyền truy cập vào prompt, response, tương tác với model hoặc nội dung khác mà bạn xử lý cục bộ”. Nếu yêu cầu là nội dung không bao giờ được rời khỏi hạ tầng của bạn, chỉ đường đi local mới đáp ứng được.

Vì sao app của tôi vẫn trỏ đến localhost khi model chạy trên cloud?

Vì local daemon đang hoạt động như một proxy. Khi bạn chạy ollama signin rồi request một cloud model có tên kết thúc bằng -cloud hoặc :cloud, daemon sẽ forward request đó đến ollama.com và stream câu trả lời ngược về qua port 11434. URL của ứng dụng không thay đổi. Đây chính là mục đích của cơ chế này: với các request chat thông thường, bạn không cần sửa code, nhưng các call dựa vào structured output cần được làm lại vì cloud của Ollama hiện chưa hỗ trợ chúng. Điều này cũng có nghĩa là địa chỉ localhost không cho biết inference đã diễn ra ở đâu. Hãy kiểm tra tên model, không phải URL. Tag cloud trong tên cho biết prompt đã đi qua Internet.

Vì sao cùng một model lại cho tôi context ngắn hơn nhiều khi chạy local?

Ollama chọn giá trị mặc định cho local dựa trên video memory hiện có: khoảng 4k token khi VRAM dưới 24 GiB, 32k khi ở mức từ 24 đến 48 GiB, và 256k khi đạt 48 GiB trở lên. VPS không có GPU thuộc tier thấp nhất. Cloud model mặc định được đặt ở context length tối đa vì phần memory dùng để chứa context thuộc về nhà cung cấp. Tăng giá trị local bằng OLLAMA_CONTEXT_LENGTH, ở dạng OLLAMA_CONTEXT_LENGTH=32768 ollama serve hoặc dưới dạng một dòng Environment= trong systemctl edit ollama.service. Hãy nhớ rằng context dài hơn cần key-value cache lớn hơn trong RAM. Vì vậy, tăng giá trị này trên server nhỏ có thể làm chậm quá trình generation hoặc khiến model không load được.

Tôi có thể tự động chuyển về local model khi cloud không truy cập được không?

Có, và chỉ cần vài dòng vì cả hai đường đi đều dùng cùng một API. Tạo hai object Client: một object không có tham số host cho local daemon và một object có host="https://ollama.com" cùng header Authorization: Bearer. Sau đó bắt httpx.ConnectError và ollama.ResponseError quanh lần call đầu tiên. Hãy chủ động quyết định hướng chuyển đổi. Ưu tiên local với cloud fallback có nghĩa là prompt vốn cần được giữ riêng tư có thể rời khỏi máy trong lúc daemon restart thông thường. Vì vậy, hãy log mọi lần fallback và với workload nhạy cảm, hãy trả về error thay vì fallback.