Decide what you are optimising for first
Choosing local or cloud is a trade-off across privacy, capability, cost and operations. There is no universally best answer, only one matched to your scenario.
| Dimension | Local model | Cloud API |
|---|---|---|
| Data privacy | Data never leaves the machine or network | Depends on the provider's retention and compliance |
| Capability ceiling | Bounded by VRAM; usually small to mid models | Direct access to the strongest models |
| Cost shape | Hardware + power + ops; cheaper at volume | Pay per use; cheaper at low volume |
| Latency and stability | No network jitter; speed depends on hardware | Network dependent; queues at peak |
| Ops burden | You deploy, update and monitor | Almost none |
When local is the right call
- Inputs are content you cannot send out: contracts, medical records, source code, unreleased product data;
- Volume is large and steady (batch summarisation, log classification, offline labelling) where long-run cost beats per-token pricing;
- You need offline operation: internal networks, restricted environments, weak connectivity.
When a cloud API is the right call
- Capability first: hard reasoning, very long documents, multimodal input;
- Volume is spiky, or you are still validating the idea, pay as you go while experimenting;
- You have no capacity to run an inference service and track model updates.
The hybrid path most teams actually take
- Route by sensitivity: sensitive content locally, public content to the cloud;
- Redact locally first: extract and scrub on your own machine, then send only scrubbed fragments for heavy reasoning;
- Cloud as overflow: baseline load locally, peaks and hard tasks to the cloud.
Practical notes
- VRAM sets the model size: quantisation (4-bit and similar) lowers the bar a lot, but measure the quality loss;
- Evaluate on your own data: public leaderboards do not predict your scenario;
- Log every call: cost tracing, debugging and audit all depend on it;
- Keep a switch: wrap local and cloud behind one abstraction so you can swap without touching business code.
Common questions
Is local always safer? Keeping data off the network is a real gain, but a compromised host or a tampered model file is still a risk, normal hardening applies. Can every open model be used commercially? It depends on the licence (Apache 2.0, MIT, various community licences); check the terms before shipping. How do I estimate cost? Put hardware depreciation, power, ops hours and cloud unit prices in one table and compute monthly cost at your real call volume, do not compare headline rates alone.
Five questions before you choose
- Is there any input that must never leave? If yes, that part runs locally;
- How high is the capability bar? Hard reasoning or very long documents tilt towards the cloud;
- What is the monthly call volume? Steady and high volume makes local pay back;
- Do you have anyone to run an inference service? If not, do not self-host yet;
- Do you need offline capability? If so, local is a hard requirement.
Write those five answers down and the decision is usually obvious. If it still is not, validate the business value with a cloud API first, then decide whether to move the steady load to local.
Try it: file hash checker, verify a downloaded model against the published hash
Re-weighing cost and compliance
- The cost crossover: local inference front-loads hardware and operations, so it wins at high volume; for low usage an API is usually cheaper;
- Compliance value: data never leaving the network is the main reason regulated industries choose local, often ahead of performance;
- Capability gap: smaller models still trail cloud models on long context, tool calling and multilingual work, so route by task;
- Hybrid pattern: handle sensitive data locally, send only complex reasoning to the cloud, and mask before it leaves.
Decision checklist
- May the data leave your network? If not, go local or private;
- Is the volume enough to amortise hardware? If not, use an API;
- Does the task need long context and tool calling? Then prefer the cloud;
- Do you have observability and a fallback? If not, keep it out of production.