Use case
Local LLM
Running an open-weight model on hardware you own — a workstation, a GPU server, a laptop. The question is usually which model fits the memory you have and how many people can use it at once.
- Source
- Editorial ontology entry — no fetched document behind this page
- Evidence
- none on this page — it links to the pages that hold it
- Category
- Infrastructure
- Typical risk
- medium
- Entry
- editorial · reviewed 21 Sep 2026
01What this is
A local LLM deployment downloads open-weight models and serves them from your own machine through an inference server. Practical model choice is set by memory: weights in the chosen quantisation, plus the KV cache for the context length and the number of concurrent users.
A good deployment sizes hardware from the workload rather than the model name, picks a quantisation deliberately, pins model versions, measures tokens per second at the intended concurrency, and keeps a fallback path for peaks. Model licences are checked before commercial use — open weights are not automatically open licences.
Pitfalls: buying a GPU before measuring; a 70B model chosen for a task a 14B handles; and an inference server run as a single point of failure with no monitoring. Weights are downloaded once from a registry over the network — that is normally the only external traffic, and it is worth stating explicitly.
- Typical data
- internal documents, source code, client documents
- Solution classes it admits
- Self-hosted
02Deployment options
- ASSESSMENT
On a neutral reading of this use case, Private cloud is recommended, Self-hosted is a strong alternative, Model API is a strong alternative and Enterprise SaaS is conditional.
- ASSESSMENT
Read as a generic reading of this page, not a recommendation: no organisation, size, jurisdiction, budget or technical capability has been supplied, so wherever an option depends on one of those, it says "unknown". Ask your own question to get a verdict that accounts for them.
Private cloud
RECOMMENDEDManaged model API or private model deployment in your cloud account
- ASSESSMENT
Two patterns fit inside one account in a region you name: call a managed foundation-model API such as Amazon Bedrock, Microsoft Foundry / Azure OpenAI, or Vertex AI; or deploy an open-weight model on GPU compute you control. Your application, retrieval layer, storage, identity and logs remain in your cloud boundary in both patterns.
- ASSESSMENT
The managed-API pattern can use closed-source frontier models without buying or operating GPUs. It is usually the fastest way to build a custom workflow, but prompts and retrieved context are processed by the managed service, so model availability, retention, abuse monitoring and regional routing must be checked for the exact feature and endpoint.
- ASSESSMENT
The private-model pattern gives more control over weights, serving and network paths, and can use managed endpoints or your own containers. It also makes your team responsible for capacity, patches, model upgrades, evaluation and failover.
- ASSESSMENT
Which account you already have is a real input, not a detail: no existing cloud account was named. An organisation that already has a landing zone, an identity provider and a signed agreement with one provider is buying a feature; one that does not is buying a cloud programme, and those are different projects.
- ASSESSMENT
The cloud provider becomes a data processor in either pattern: you need a DPA, a documented region, and an answer on cross-region routing and where support staff can access the environment from.
- RECOMMENDATION
Start with the managed-API pattern when the workflow is custom but model operations are not the source of competitive advantage; move to private model serving only if evaluation, volume, portability or the data boundary justifies the extra operations. Your stated technical capability is "unknown".
- RECOMMENDATION
Recommended for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents, no existing cloud account was named, and you did not ask for local processing.
Model API
STRONG ALTERNATIVEA model vendor’s API behind an application you build and own
- ASSESSMENT
You write and host the application — the interface, the retrieval layer, the database, the access control, the audit log — and call somebody else’s endpoint for the model itself. Two kinds of endpoint sit in this class: a closed model from the vendor that made it (OpenAI, Anthropic, Google Gemini, xAI, DeepSeek, Moonshot, Mistral, Cohere), and an open-weight model served by a managed inference provider (Together, Fireworks, Groq and others).
- ASSESSMENT
Those two are not interchangeable. A closed model can only be obtained from its vendor or from a cloud that licenses it, so the model and the supplier are one decision. An open-weight model can be moved: the same weights run on a managed endpoint today and on your own GPU later, which makes the provider a swappable component rather than a dependency — and makes the licence, not the contract, the document that governs what you may do with it.
- ASSESSMENT
It is the shortest path to a frontier model: no GPUs to buy, no capacity to plan, no serving stack to patch, and you can change model with a configuration line. What it costs instead is a per-token bill that scales with use and a dependency on one supplier’s availability, pricing and deprecation schedule.
- ASSESSMENT
What the supplier sees is the whole prompt: the user's question, the system instructions, and every passage your retrieval layer attached to it — which is usually the most sensitive part, because retrieval is what puts internal documents into the request. For a brief that involves confidential documents, that is the attribute to check first. What stays yours is everything else: the application, the retrieval index, the identity system, the logs, and the record of who asked what.
- ASSESSMENT
Nothing about a supplier's handling of your data is assumed here. Before real content goes near an endpoint, verify against that supplier's own documents: the data processing agreement, and that it covers the API rather than only the consumer product; whether zero-data-retention or an equivalent no-logging mode is available on your account, and on which endpoints; the default retention period for prompts and outputs, and what triggers human review; the region the request is served from, and whether that is a commitment or a routing preference; the current subprocessor list and how you are notified when it changes; the supported-countries page, which decides whether you may use the service at all.
- RECOMMENDATION
Take this route when the workflow is yours but the model is not the differentiator, and your team can build and run an application. Your stated technical capability is "unknown", which is the attribute this option most depends on. Where the same model is available inside your own cloud account, compare it against private cloud before committing — the application is identical and only the tenancy of the model changes.
- RECOMMENDATION
A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents, no existing cloud account was named, and you did not ask for local processing.
Self-hosted
STRONG ALTERNATIVEOpen-weight models on infrastructure you operate
- ASSESSMENT
Documents, queries and embeddings stay on machines you own, using an open-weight model whose licence you review. For a brief that involves confidential documents, that removes a model-API vendor from the data path rather than governing that transfer by contract.
- ASSESSMENT
It costs you the operational work instead: a GPU server, Docker, Linux, backups and a patching routine. Your stated technical capability is "unknown", which is the attribute this option most depends on.
- ASSESSMENT
No processor agreement, subprocessor list or cross-border transfer assessment is needed for the model itself, because no third party processes the content.
- RECOMMENDATION
Recommended where local processing is preferred (you did not say so) and the content is sensitive (confidential documents).
- RECOMMENDATION
A strong alternative for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents, no existing cloud account was named, and you did not ask for local processing.
Enterprise SaaS
CONSIDER IFFinished closed-source cloud product with enterprise controls
- ASSESSMENT
This is a complete vendor application, not a model API: examples include an enterprise assistant, coding copilot or document product with the workflow, interface, connectors and administration already built. It can use closed-source cloud models while requiring no model hosting or application engineering from your team.
- RECOMMENDATION
Choose it when the product already performs the actual workflow and its controls meet your requirements. Do not choose it only because its underlying model is strong: a finished SaaS product is less flexible than building against a managed API when your process, integrations or review steps are organisation-specific.
- ASSESSMENT
Vendor commitments are treated as unverified until we have fetched the page that makes them. Until then this option carries questions to ask, not assurances: a signed data processing agreement covering the data you will actually put in; a documented data residency commitment naming the region, in the contract rather than a blog post; a written no-training commitment for your content, including uploads and connected sources; stated retention periods and a deletion path you can exercise; an administrative audit log you can export, and SSO with group-based access control.
- RECOMMENDATION
No jurisdiction was named, so this is the check rather than the conclusion: compare the vendor's stated processing locations and subprocessor list against the cross-border transfer rules wherever you operate before uploading anything.
- RECOMMENDATION
Worth considering for this brief: one tenancy in a region you name is the smallest boundary that still gives you a frontier model, and opening an account is less work than building a server room, given you did not say who would run this, the brief involves confidential documents, no existing cloud account was named, and you did not ask for local processing.
03Deployment stacks
- Self-hostedLocal LLM on a workstation (LM Studio / Ollama)LM Studio or Ollama on an Apple Silicon machine (unified memory holds large models) or an NVIDIA workstation (a 96 GB card serves them faster), running an open-weight model sized to the hardware, exposed as a local server when other tools need it. Single-machine: the strongest privacy story and the weakest governance story.
- Self-hostedLocal LLM inference server (Ollama / vLLM)vLLM for throughput or Ollama for simplicity, one GPU, and LiteLLM in front as the gateway that issues per-team keys and records spend. The endpoint other recipes point at.
- Self-hostedPrivate ChatGPT on your own serverOllama serving an open-weight model on one GPU, Open WebUI in front of it for accounts, chats and admin controls, both in Docker on a single machine. Deliberately the smallest thing that works: no vector database, no connectors, no cluster.
04Tools by hosting option
Self-hosted15
- HybridAnythingLLMDesktop and server application that turns a document set into a chat workspace, with per-workspace embeddings, multiple model back ends and a built-in vector store.
- HybridContinueOpen-source IDE extension for VS Code and JetBrains that connects completion and chat to any model back end, including a local server, under a checked-in configuration file.
- HybridJanOpen-source desktop assistant that runs open-weight models locally and can also call remote endpoints. The open alternative to LM Studio for a single-machine deployment.
- PlatformLiteLLMGateway that presents one OpenAI-compatible API in front of many providers and local servers, with per-team keys, budgets, rate limits, fallbacks and request logging.
- Libraryllama.cppC++ inference engine for quantised models on CPU, Apple Silicon and GPUs, with a bundled HTTP server. The engine underneath many desktop runtimes and the GGUF quantisation format.
- Model serverLMDeployServing toolkit from the InternLM team with its own inference engine and quantisation tooling, and strong coverage of Chinese open-weight model families.
- HybridLM StudioDesktop application for downloading and running open-weight models locally, with a chat interface and a local OpenAI-compatible server. Windows, macOS and Linux.
- Model serverLocalAIDrop-in OpenAI-compatible API server that runs text, embedding, image and audio models locally across several back ends, including CPU-only deployments.
- Model serverNVIDIA NIMPrebuilt inference containers with an OpenAI-compatible API, deployable into your own cluster including air-gapped sites. Licensed through NVIDIA AI Enterprise rather than open source.
- LibraryNVIDIA TensorRT-LLMCompiles models into optimised engines for NVIDIA GPUs. The build step is the trade: peak throughput on a fixed configuration, in exchange for recompiling when it changes.
- Model serverOllamaLocal model runtime with a one-command install, a model library and an OpenAI-compatible API. The usual starting point for running open-weight models on a workstation or small server.
- Self-hostedOpen WebUISelf-hosted chat interface for local and hosted models, with user accounts, groups, document upload and built-in retrieval. Runs in Docker against Ollama, vLLM or any OpenAI-compatible endpoint.
- Model serverSGLangServing framework for large models with prefix caching and structured-output support, aimed at high-throughput deployments and multi-GPU serving.
- Self-hostedTabbySelf-hosted coding assistant with its own inference server, repository-aware context and IDE extensions. Runs entirely inside the network, including on a single GPU.
- Model servervLLMHigh-throughput GPU inference server using paged attention and continuous batching, with an OpenAI-compatible API. Built for many concurrent users rather than single-session use.
Private cloud16
- PlatformAmazon SageMaker AIAWS’s machine-learning platform. JumpStart deploys open-weight models into your own VPC, which is the route to self-managed weights without leaving the AWS account.
- HybridAnythingLLMDesktop and server application that turns a document set into a chat workspace, with per-workspace embeddings, multiple model back ends and a built-in vector store.
- PlatformBasetenDeploys open-weight and custom models as autoscaling endpoints, including into a customer’s own cloud account. Publishes a subprocessor list, which most inference providers do not.
- HybridContinueOpen-source IDE extension for VS Code and JetBrains that connects completion and chat to any model back end, including a local server, under a checked-in configuration file.
- PlatformFireworks AIHosted open-weight model endpoints with fine-tuning and a dedicated-deployment tier. Publishes a data-security page and a trust centre, which is what an enterprise review will ask for.
- PlatformHugging Face Inference EndpointsDeploys any model from the Hub onto dedicated infrastructure in a chosen cloud and region, inside a private network where required. The shortest path from a Hub model to an endpoint.
- PlatformLiteLLMGateway that presents one OpenAI-compatible API in front of many providers and local servers, with per-team keys, budgets, rate limits, fallbacks and request logging.
- Model serverLMDeployServing toolkit from the InternLM team with its own inference engine and quantisation tooling, and strong coverage of Chinese open-weight model families.
- Model serverLocalAIDrop-in OpenAI-compatible API server that runs text, embedding, image and audio models locally across several back ends, including CPU-only deployments.
- Model serverNVIDIA NIMPrebuilt inference containers with an OpenAI-compatible API, deployable into your own cluster including air-gapped sites. Licensed through NVIDIA AI Enterprise rather than open source.
- LibraryNVIDIA TensorRT-LLMCompiles models into optimised engines for NVIDIA GPUs. The build step is the trade: peak throughput on a fixed configuration, in exchange for recompiling when it changes.
- Model serverOllamaLocal model runtime with a one-command install, a model library and an OpenAI-compatible API. The usual starting point for running open-weight models on a workstation or small server.
- Self-hostedOpen WebUISelf-hosted chat interface for local and hosted models, with user accounts, groups, document upload and built-in retrieval. Runs in Docker against Ollama, vLLM or any OpenAI-compatible endpoint.
- Model serverSGLangServing framework for large models with prefix caching and structured-output support, aimed at high-throughput deployments and multi-GPU serving.
- Self-hostedTabbySelf-hosted coding assistant with its own inference server, repository-aware context and IDE extensions. Runs entirely inside the network, including on a single GPU.
- Model servervLLMHigh-throughput GPU inference server using paged attention and continuous batching, with an OpenAI-compatible API. Built for many concurrent users rather than single-session use.
Vendor cloud3
- PlatformAmazon SageMaker AIAWS’s machine-learning platform. JumpStart deploys open-weight models into your own VPC, which is the route to self-managed weights without leaving the AWS account.
- HybridContinueOpen-source IDE extension for VS Code and JetBrains that connects completion and chat to any model back end, including a local server, under a checked-in configuration file.
- PlatformLiteLLMGateway that presents one OpenAI-compatible API in front of many providers and local servers, with per-team keys, budgets, rate limits, fallbacks and request logging.
On-premise (enterprise plan)6
- Model serverNVIDIA NIMPrebuilt inference containers with an OpenAI-compatible API, deployable into your own cluster including air-gapped sites. Licensed through NVIDIA AI Enterprise rather than open source.
- LibraryNVIDIA TensorRT-LLMCompiles models into optimised engines for NVIDIA GPUs. The build step is the trade: peak throughput on a fixed configuration, in exchange for recompiling when it changes.
- Self-hostedOpen WebUISelf-hosted chat interface for local and hosted models, with user accounts, groups, document upload and built-in retrieval. Runs in Docker against Ollama, vLLM or any OpenAI-compatible endpoint.
- Model serverSGLangServing framework for large models with prefix caching and structured-output support, aimed at high-throughput deployments and multi-GPU serving.
- Self-hostedTabbySelf-hosted coding assistant with its own inference server, repository-aware context and IDE extensions. Runs entirely inside the network, including on a single GPU.
- Model servervLLMHigh-throughput GPU inference server using paged attention and continuous batching, with an OpenAI-compatible API. Built for many concurrent users rather than single-session use.
05Compliance hot spots
This use case usually raises open-source licensing, model access, security, intellectual property, confidentiality, data residency, human oversight, logging, personal data, prompt leakage, retention, transparency.
- Open-source licensing
- No published jurisdiction page names this topic yet
- Model access
- No published jurisdiction page names this topic yet
- Security
- China (mainland)BrazilIndia
- Intellectual property
- No published jurisdiction page names this topic yet
- Data residency
- United Arab Emirates
- Human oversight
- Singapore
- Logging
- European Union
- Personal data
- United Arab EmiratesJapanTaiwanIndiaSingapore
- Retention
- Hong Kong
06Example questions
Each of these opens the question box with the text already in it. The answer is researched for your organisation, not for this page.
07Related use cases
- InfrastructurePrivate LLMUsing a language model without your data leaving a boundary you control — a country, a cloud region, or your own network. The constraint is where processing happens and who can see the prompts, not which model runs.
- InfrastructurePrivate company ChatGPTA chat assistant for staff that behaves like a consumer chatbot but runs under company control: your accounts, your logging, your retention, your choice of model, and optionally your own documents attached.
- InfrastructureChoosing a modelDeciding which model to build on — a hosted family, an open-weight one, or several behind a gateway. The decision that lasts is not which model scores highest today but which contract, licence and exit path you can live with.
- InfrastructureChoosing a cloud platformDeciding which cloud hosts the AI work — usually between the hyperscaler you already run on and a regional or sovereign alternative. Identity, data residency and the models actually offered in your region decide it more often than the platform feature list does.
Improve this page
Sign in to contribute
From the field
0 deployments · 0 questions
Nobody has reported deploying this here yet, and no question has been opened against this page. Both appear once a reviewer accepts them.