Bởi So sánh Ollama Cloud và tự host Ollama trên server
Ollama Cloud và tự host dùng chung CLI và API nhưng khác biệt về bảo mật dữ liệu. Xem chi tiết các thay đổi cấu hình và cách kiểm soát prompt gửi đi khỏi máy bạn.
Những thay đổi và những gì giữ nguyên khi dùng Ollama Cloud
Ollama Cloud chạy model trên ollama.com thay vì trên phần cứng của bạn, nhưng vẫn giữ nguyên lệnh ollama và REST API mà bạn đang sử dụng. Có hai thứ thay đổi: tên model bạn yêu cầu và nơi lưu trữ credential. Phần còn lại trong ứng dụng của bạn vẫn giữ nguyên hoàn toàn.
Sự tiện lợi đó cũng đi kèm với rủi ro. Một request gửi đến cloud model trông giống hệt request gửi đến model cục bộ trong code của bạn, vì vậy rất dễ nhầm lẫn giữa prompt nào chạy trên máy 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 vạch ra ranh giới đó, sau đó chỉ cho bạn cách giữ lại một model cục bộ làm phương án dự phòng, để một giá trị cấu hình duy nhất quyết định bạn đang sử dụng phía nào.
Nếu bạn chưa thiết lập phía cục bộ, hãy bắt đầu với chạy Ollama trên VPS của riêng bạn trước. Mọi nội dung bên dưới đều giả định bạn đã có ollama hoạt động trên một máy Linux.
Hai cách để kết nối với Ollama Cloud
Có hai đường dẫn để truy cập các model được host sẵn và chúng không thể thay thế cho nhau. Việc bạn chọn đường dẫn nào sẽ quyết định nơi lưu trữ credential, tên model bạn viết và nội dung gói tin mà bạn bắt được trên server.
Cách một: daemon cục bộ của bạn chuyển tiếp yêu cầu. 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-cloudollama signin liên kết máy này với tài khoản ollama.com của bạn. ollama signout dùng để hủy liên kết. Sau khi đăng nhập, ứng dụng của bạn vẫn tiếp tục giao tiếp với cổng cục bộ 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
}'Hãy đọc lại URL đó. Nó ghi là localhost, và quá trình inference không diễn ra tại đó. Daemon cục bộ nhận diện hậu tố -cloud, chuyển tiếp yêu cầu đến ollama.com và stream câu trả lời ngược lại cho bạn. Đây chính là mục đích của cách một: một ứng dụng đã trỏ đến Ollama API tại cổng 11434 không cần thay đổi bất kỳ dòng code nào, chỉ cần một chuỗi tên model khác.
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. Hãy tạo một key tại https://ollama.com/settings/keys, sau đó gửi nó 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 nhìn vào tên model. Ở cách hai, nó là gpt-oss:120b, không có hậu tố -cloud. Hậu tố này tồn tại để báo cho daemon cục bộ của bạn biết cần chuyển tiếp yêu cầu lên upstream, vì vậy nó chỉ thuộc về cách một. Khi bạn gọi https://ollama.com, bạn đã ở đó rồi và bạn chỉ cần viết tên model thông thường. Danh sách chính xác của các tên đó đến từ chính host:
curl https://ollama.com/api/tagsHãy chạy lệnh đó thay vì tin tưởng bất kỳ danh sách model nào được in trong bài viết, kể cả bài viết này. Danh mục luôn thay đổi và api/tags luôn là thông tin cập nhật nhất.
Những lời gọi client nào thay đổi, và những cá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. Không có gì khác biệt sau dòng đó. Ở đường dẫ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)Ở đường dẫ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ời gọi client.chat(), vòng lặp streaming, danh sách tin nhắn và cấu trúc phản hồi là giống hệt nhau ở cả hai trường hợp. Đó là lý do tại sao việc chuyển đổi giữa hosted và self-hosted chỉ là thay đổi cấu hình chứ không phải viết lại code. Bề mặt tương thích với OpenAI cũng hoạt động tương tự ở local: trỏ OpenAI SDK vào http://localhost:11434/v1/ với api_key='ollama', giá trị mà local server yêu cầu nhưng sau đó sẽ 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.
Tại sao cùng một model lại cho bạn ít context hơn khi chạy local
Đây là sự khác biệt khiến nhiều người lầm tưởng model sẽ hoạt động giống hệt nhau trên cả hai môi trường. Thực tế không phải vậy, và nguyên nhân nằm ở bộ nhớ.
Ollama tự chọn độ dài context mặc định dựa trên dung lượng bộ nhớ video (VRAM) mà nó tìm thấy trên máy.
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"
}
]Một VPS không có GPU sẽ nằm ở phân khúc thấp nhất, vì vậy một model local sẽ bắt đầu với 4,096 token context, trong khi một máy có card đồ họa mạnh sẽ bắt đầu với 262,144. Các model trên cloud bỏ qua những phân khúc này: tài liệu của Ollama ghi rõ chúng được thiết lập mặc định ở độ dài context tối đa, vì bộ nhớ lưu trữ context đó không phải của bạn.
Do đó, cùng một prompt hoạt động tốt trên gpt-oss:120b-cloud có thể bị cắt bớt âm thầm khi chạy local trên một máy cấu hình thấp. Hãy tăng giới hạn local một cách chủ động:
OLLAMA_CONTEXT_LENGTH=32768 ollama serveTrên systemd, hãy thiết lập nó dưới dạng Environment="OLLAMA_CONTEXT_LENGTH=32768" với systemctl edit ollama.service, sau đó systemctl daemon-reload && systemctl restart ollama. Hãy lưu ý những gì bạn đang đánh đổi: context dài hơn đồng nghĩa với cache key-value lớn hơn, và cache đó là RAM mà model cần sử dụng bên cạnh trọng số (weights) của nó. Nếu đẩy lên quá cao, tốc độ tạo văn bản sẽ chậm lại hoặc model sẽ không thể load được. Thiết lập num_ctx và OLLAMA_CONTEXT_LENGTH đúng cách giải thích các phép tính, và model nào phù hợp với bộ nhớ bạn thực sự có giải thích về khía cạnh trọng số.
Những gì thực sự rời khỏi máy của bạn
Hãy chính xác về điều này, vì đây là lý do chính khiến hầu hết người đọc chọn tự host (self-host).
Khi chạy cục bộ, không có dữ liệu nào rời khỏi máy. Chính sách bảo mật của Ollama nêu rõ rằng đối với việc sử dụng cục bộ, "Chúng tôi không thu thập, lưu trữ, truyền tải hoặc có quyền truy cập vào các prompt, phản hồi, tương tác với mô hình hoặc nội dung khác mà bạn xử lý cục bộ." Một lưu ý nhỏ: việc tải mô hình vẫn là một lượt tải xuống từ ollama.com, và chính sách này liệt kê "metadata tải xuống mô hình" và địa chỉ IP của bạn là những thứ được thu thập. Registry biết bạn đã lấy mô hình nào. Nó không biết bạn đã hỏi mô hình đó những gì.
Khi chạy trên cloud, toàn bộ prompt và toàn bộ kết quả hoàn thiện đều được gửi đến bên thứ ba. Không có phiên bản trung gian nào ở đây. 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ý "các prompt và phản hồi của bạn một cách tạm thời để cung cấp dịch vụ" và "không sử dụng dữ liệu đầu vào hoặc đầu ra của bạn để huấn luyện bất kỳ mô hình AI nào", đồng thời mô tả "các biện pháp kỹ thuật được thiết kế để giảm thiểu việc lưu giữ nội dung prompt và phản hồi." Đó là một cam kết hợp lý. Tuy nhiên, đó vẫn là cam kết của người khác về dữ liệu mà bạn đã bàn giao, thay vì là một đặc tính của chính máy chủ của bạn. Hãy đánh giá nó như cách bạn đánh giá lời hứa của bất kỳ nhà cung cấp nào, và đọc lại chính sách trước khi gửi bất kỳ nội dung nào mà bạn có nghĩa vụ theo hợp đồng hoặc pháp lý phải giữ trên hạ tầng của riêng mình.
Cái bẫy nằm ở con đường thứ nhất. Code của bạn ghi http://localhost:11434, các quy tắc firewall của bạn không thay đổi, và prompt của bạn vẫn đi qua internet, vì hậu tố -cloud trên tên mô hình đang thực hiện việc định tuyến. Một URL localhost không cho bạn biết gì về nơi thực hiện inference. Tên mô hình mới là thứ quyết định. Điều này quan trọng nhất khi prompt chứa dữ liệu mà bạn tự host với mục đích giữ riêng tư: nếu bạn chạy một trình theo dõi vị trí tự host để lịch sử di chuyển không bao giờ đến tay bên thứ ba, thì việc yêu cầu một mô hình -cloud tóm tắt lịch sử một tuần của nó vẫn sẽ gửi dữ liệu đó đến ollama.com.
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 yếu tố cần so sánh trước khi quyết định
Đừng chỉ so sánh dựa trên giá cả và đừng tin vào mức giá bạn đọc được trong một bài viết, bao gồm cả ngày tháng của bài viết này. Hãy so sánh bốn yếu tố sau và kiểm tra từng mục trên trang chủ của nhà cung cấp:
- Tính khả dụng của model. Chạy
curl https://ollama.com/api/tagsđể xem danh mục được host hiện tại. Các model bạn có thể chạy cục bộ bị giới hạn bởi RAM và VRAM của bạn thay vì danh mục này. - Giới hạn ngữ cảnh (Context limits). Các model được host mặc định ở mức tối đa. Các model cục bộ mặc định theo phân cấp VRAM như trên. Nếu khối lượng công việc của bạn là các tài liệu dài, yếu tố này sẽ tự quyết định lựa chọn của bạn.
- Giới hạn tốc độ (Rate limits). Inference được host sẽ bị tính phí theo định mức. Vượt quá giới hạn này, API sẽ trả về
429 Too Many Requests. Máy chủ của riêng bạn không có giới hạn tốc độ mà thay vào đó là giới hạn cứng về concurrency (số lượng truy vấn đồng thời), đâ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 trữ (Retention policy). Đọc văn bản chính sách thực tế, ghi chú lại ngày bạn đọc và kiểm tra lại trước mỗi lần gia hạn.
Về khía cạnh chi phí, đừng tính toán lại ở đây. Khi nào GPU VPS vượt trội hơn so với tính phí theo token sẽ phân tích kỹ điểm hòa vốn, bao gồm cả phần mà mọi người thường quên: một máy chủ GPU nhàn rỗi vẫn bị tính phí như khi đang hoạt động.
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 sẽ thực sự gặp phải
API ghi lại các mã trạng thái và mỗi mã chỉ ra một vấn đề khác nhau. 429 Too Many Requests nghĩa là bạn đã chạm ngưỡng rate limit, vì vậy hãy dừng lại và thử lại thay vì kết nối liên tục trong một vòng lặp. 502 Bad Gateway là mã cụ thể cho chủ đề này: nó được trả về khi không thể kết nối tới cloud model, vì vậy ở đường dẫn thứ nhất, điều đó có nghĩa là daemon của bạn vẫn ổn nhưng phía upstream thì không. 404 Not Found trên một tên model thường có nghĩa là hậu tố không khớp với host, một tên -cloud được gửi thẳng đến https://ollama.com, hoặc một tên trần được gửi đến một daemon mà bạn chưa từng đăng nhập. Các lỗi được trả về dưới dạng JSON, và khi đang stream chúng 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, đó là lý do tại sao một client streaming đơn giản có thể in ra một phần câu trả lời rồi dừng lại mà không có giải thích nào. Hãy phân tích cú pháp từng dòng được stream và kiểm tra khóa error.
Ở phía local, lỗi kinh điển là connection refused trên cổng 11434, nghĩa là daemon không chạy: hãy kiểm tra systemctl status ollama. Một lỗi kinh điển khác là request hoạt động từ shell của bạn nhưng lại thất bại từ container, vì localhost của container không phải là của host.
Và chế độ lỗi không có thông báo nào cả: mất internet. Đường dẫn cloud ngừng hoạt động hoàn toàn, trong khi đường dẫn local không nhận ra điều đó. Nếu máy của bạn di chuyển hoặc nhà cung cấp của bạn gặp sự cố định tuyến, sự khác biệt đó chính là toàn bộ sản phẩm.
Khi mỗi lựa chọn đều đúng
Hãy sử dụng Ollama Cloud khi khối lượng công việc không ổn định, khi model quá lớn so với VPS của bạn, hoặc khi bạn vẫn đang cân nhắc xem một model có đáng để phát triển hay không. Trả phí theo từng request sẽ tiết kiệm hơn so với việc trả tiền cho một GPU nhàn rỗi chỉ chạy 20 phút mỗi ngày, và một model 120 tỷ tham số sẽ không thể chạy trên một máy chủ có giá thuê chỉ bằng một bữa trưa.
Hãy tự chạy model khi các prompt không được phép rời khỏi hạ tầng của bạn, khi máy chủ bắt buộc phải hoạt động offline, hoặc khi tải công việc đủ ổn định để GPU thuê luôn bận rộn. Tải ổn định là tín hiệu trung thực nhất: inference tính phí theo lưu lượng sẽ trở nên đắt đỏ nếu nó chạy liên tục. Nếu bạn đạt đến ngưỡng đó và throughput của từng request trên Ollama trở thành nút thắt cổ chai, vLLM xử lý tải đồng thời tốt hơn Ollama, và đó chỉ là việc thay đổi engine chứ không phải thay đổi host.
Hầu hết các triển khai thực tế đều sử dụng kết hợp cả hai, điều này hoàn toàn ổn miễn là việc phân chia được thực hiện có chủ đích. Hãy đặt tên model vào cấu hình, ghi log mọi trường hợp fallback, và bạn sẽ luôn có thể trả lời câu hỏi quan trọng nhất ở đây: prompt nào trong số này đã được gửi ra ngoài hệ thống?
FAQ
Ollama Cloud có xem các prompt của tôi không?
Có. Với tùy chọn hosted, toàn bộ prompt và phản hồi được gửi đến ollama.com để xử lý. Chính sách bảo mật của Ollama nêu rằng họ xử lý "các prompt và phản hồi của bạn một cách tạm thời để cung cấp dịch vụ" và "không sử dụng dữ liệu đầu vào hoặc đầu ra của bạn để huấn luyện bất kỳ mô hình AI nào", đồng thời mô tả các biện pháp nhằm giảm thiểu việc lưu trữ dữ liệu. Đây là cam kết của nhà cung cấp đối với dữ liệu mà bạn đã gửi đi. Đối với các mô hình chạy cục bộ, chính sách này nêu rõ công ty "không thu thập, lưu trữ, truyền tải hoặc có quyền truy cập vào các prompt, phản hồi, tương tác mô hình hoặc bất kỳ nội dung nào khác mà bạn xử lý cục bộ". Nếu yêu cầu của bạn là nội dung không bao giờ được rời khỏi hạ tầng của mình, chỉ có cách chạy cục bộ mới đáp ứng được.
Tại sao ứng dụng của tôi vẫn trỏ về localhost khi mô hình chạy trên cloud?
Vì daemon cục bộ đang đóng vai trò là một proxy. Khi bạn chạy ollama signin và yêu cầu một mô hình có tên kết thúc bằng -cloud, daemon sẽ chuyển tiếp yêu cầu đó đến ollama.com và stream phản hồi ngược lại qua cổng 11434. URL ứng dụng của bạn không thay đổi, đó chính là mục đích: không cần sửa code. Điều này cũng có nghĩa là địa chỉ localhost không cho bạn biết suy luận (inference) đã diễn ra ở đâu. Hãy kiểm tra tên mô hình, không phải URL. Hậu tố -cloud nghĩa là prompt của bạn đã truyền qua Internet.
Tại sao cùng một mô hình lại cho tôi context ngắn hơn nhiều khi chạy cục bộ?
Ollama chọn giá trị mặc định cục bộ dựa trên VRAM khả dụng: khoảng 4k token nếu dưới 24 GiB VRAM, 32k nếu từ 24 đến 48 GiB, và 256k nếu từ 48 GiB trở lên. Một VPS không có GPU sẽ rơi vào nhóm thấp nhất. Các mô hình trên cloud được thiết lập mặc định ở độ dài context tối đa vì bộ nhớ lưu trữ nó thuộc về nhà cung cấp. Bạn có thể tăng giá trị cục bộ bằng OLLAMA_CONTEXT_LENGTH, thông qua OLLAMA_CONTEXT_LENGTH=32768 ollama serve hoặc dòng Environment= trong systemctl edit ollama.service. Lưu ý rằng context dài hơn cần cache key-value lớn hơn trong RAM, vì vậy việc tăng giá trị này trên một máy chủ nhỏ có thể làm chậm quá trình tạo phản hồi hoặc khiến mô hình không thể load.
Tôi có thể tự động chuyển sang mô hình cục bộ khi cloud không thể kết nối không?
Có, và chỉ cần vài dòng code vì cả hai đường truyền đều sử dụng chung một API. Hãy tạo hai đối tượng Client, một đối tượng không có tham số host cho daemon cục bộ và một đối tượng có host="https://ollama.com" kèm header Authorization: Bearer, sau đó bắt lỗi httpx.ConnectError và ollama.ResponseError xung quanh lệnh gọi đầu tiên. Hãy quyết định hướng xử lý một cách cẩn trọng. Ưu tiên cục bộ với dự phòng cloud nghĩa là một prompt bạn muốn giữ riêng tư có thể rời khỏi máy trong lúc daemon khởi động lại, vì vậy hãy log lại mọi lần chuyển đổi dự phòng, và đối với các tác vụ nhạy cảm, hãy trả về lỗi thay vì tự động chuyển đổi.