Air-Gapped LLM Deployment: What It Means and When You Need It

What is air-gapped LLM deployment? It is a language model deployment that is physically or logically isolated with no inbound or outbound network route. The model, data, and serving runtime all live inside your boundary and cannot call out to the internet.

An air-gapped deployment runs a model on infrastructure that has no route to the public internet. The model weights, the data, the serving runtime, and the monitoring all live inside your network boundary. Nothing leaves, and nothing needs to come in.

This is the strictest form of data control. It is not the same as a private cloud VPC, which is isolated from other tenants but still connected to the internet. Air-gapped means physically or logically disconnected — the model must be fully self-contained.

In practice that means every dependency is brought in deliberately. Weights are delivered as a versioned artifact you load from disk, the runtime is installed from an internal registry, and even evaluation and model upgrades happen by importing a new artifact rather than pulling from the internet. If the system cannot run with the network cable unplugged, it is not air-gapped.

Air-gapped deployment is driven by regulation, national-security requirements, and the most sensitive commercial data. The industries that most often require it:

• Defense and government — where data classification and network isolation are non-negotiable.
• Banking and insurance — where customer data and model behavior are subject to strict audit and jurisdiction rules.
• Healthcare — where patient data carries legal obligations that a hosted API cannot satisfy.
• Manufacturing and energy — where operational data and control systems must stay off the public network.

If your compliance posture requires data to stay in a jurisdiction or on a specific network, air-gapped is the architecture that makes it possible.

The common thread is that the cost of a boundary breach exceeds the cost of self-operation. When a single prompt may contain classified, patient-level, or customer-account context that cannot leave the facility, even an encrypted API call is a policy violation. Air-gap removes the network path entirely, so the policy is enforced by architecture rather than by audit trail alone.

For those teams, the air-gap is not a preference for privacy in the abstract — it is a concrete requirement that the data plane never leaves the building. The model must therefore be capable enough to complete the task without calling a larger hosted model for help, which is why model quality under isolation matters more, not less.

Running a model with no external dependencies changes the requirements in three concrete ways:

• Self-contained weights. The model must be delivered as an artifact you can load offline — no runtime downloads, no telemetry calls, no dependency on a vendor's infrastructure.
• On-prem serving. The runtime (vLLM, MLX, or llama.cpp) must run entirely on your hardware, with your keys and your data plane.
• Offline operations. Monitoring, evaluation, and upgrades must work without a connection. Versioned releases you can bring in deliberately are essential.

Choosing an artifact that is already built for this posture saves months. For example, Tres-1 is air-gap capable and ships as a self-contained artifact you can load offline with no runtime downloads. It is designed so the serving stack, tokenizer, and weights all live inside your boundary and can be imported as a versioned release without a network call.

The same offline requirement applies to the operating model. You still need logging, latency metrics, and an eval loop — but all of it must run locally. Plan for locally computed evaluation, locally stored traces, and upgrade by importing a new versioned artifact after you have validated it. If you are scoping cost and support for that cycle, see pricing for how versioned delivery and offline support are structured.

Thinking in imports rather than connections also simplifies audit. Each model version is a discrete bundle you can checksum, stage, and promote through environments the same way you promote any other critical artifact — with approvals and reproducibility, not with a live pull during serving.

The honest trade-off is that air-gapped deployment rules out the convenience of a hosted frontier model. You cannot call a bigger model for the hard cases, and you cannot rely on the vendor to keep improving it for you. You are committing to a model that runs entirely inside your wall.

That is why the model choice matters so much. For regulated and isolated workloads, the right approach is a model that is high-capability enough to handle the task on its own, delivered as a versioned, self-contained artifact — not a raw checkpoint you have to operationalize yourself.

Isolation also changes how you think about compression. You cannot rely on a fallback API when the small model fails, so the compressed model must hold quality under the same isolation. Our REAP Apple Silicon study (2026-06-29, 96.8% at 25% compression) — REAP expert pruning on Apple Silicon — is instructive here: REAP retained 96.8% quality at 25% compression on MoE models for Apple Silicon, showing that a well-chosen pruning recipe can shrink the footprint for edge and on-device air-gap scenarios without giving up the capability you committed to keep inside the wall.

Measure isolation and capability together. An air-gapped model that is 30% smaller but drops below your accuracy bar is not cheaper — it is a failed deployment. The right metric is capability per isolated gigabyte: task success inside the boundary per unit of VRAM you provision for it.

Choose air-gapped deployment when the cost of a data or network boundary breach exceeds the cost of running your own model. For most enterprises that threshold is crossed by regulation or by the sensitivity of the data itself. If you are not sure whether you need it, you probably do not — but if your compliance team is asking, the answer is usually yes.

Use the requirements matrix in the next section to make the decision explicit. If your workload must show no inbound or outbound route, self-contained weights, and offline operations, you are in air-gap territory. If tenant isolation with internet routing satisfies your audit, a private cloud VPC may be sufficient. If data can leave the boundary under contract, a hosted API is the simplest path. Naming the requirement before choosing the architecture keeps you from over- or under-isolating.

When isolation is required, start with a model that is already packaged for it and validate on your data inside the boundary. A single offline eval on your real prompts tells you more than any external benchmark about whether the isolation trade is worth it.

This matrix isolates what changes when you move from a hosted API to a private cloud and then to a true air-gap. Use it to align engineering and compliance on the same terms before you commit to hardware or a model artifact.

The practical test is whether the system functions with external networking disabled. If monitoring, evaluation, and inference all continue with no outside route, you have met the air-gap bar. If any of them require a pull, callback, or telemetry endpoint, you are in private-cloud posture, not air-gap.

Air-gapped inference must run with networking disabled at the container boundary. The example below starts a self-contained Tres-1 artifact with the network namespace removed, mounts the model read-only from your internal store, and serves it on your data plane only:

--network none is the enforcement; --offline tells the runtime to refuse any attempt to fetch weights, tokenizer extensions, or telemetry endpoints. Upgrade is a new image and a new /models/tres-1 import — never a live pull inside the container.

How is air-gapped different from a private cloud VPC?

A private cloud VPC isolates your workload from other tenants but remains connected to the internet. You can pull images, call external APIs, and reach vendor endpoints over the network — traffic is gated, but the route exists. An air-gapped deployment has no inbound or outbound route at all. The model, runtime, data, and evaluation all live inside your network boundary and cannot call out. The matrix above makes the split explicit: VPC gives you tenancy isolation with internet routing; air-gap gives you physical or logical disconnection. If your requirement says no data or weight fetch may traverse the public network even in principle, you need the latter.

How is air-gapped different from on-prem?

On-prem means the model runs on infrastructure you own — your servers, your network, your keys. Air-gapped is the strictest form of on-prem: on-prem with the network cable conceptually unplugged. All on-prem deployments give you control of the data plane; only air-gapped deployments guarantee that the data plane has no route out. In practice that adds three constraints beyond standard on-prem: weights must be self-contained offline artifacts, the serving runtime must have no external dependencies, and every operational task — logging, metrics, evaluation, and upgrades — must work without a connection. If you can satisfy your requirements with on-prem that still pulls a container image over the internet, you do not need air-gap; if not, you do.

Which industries need air-gapped LLMs?

Defense and government lead the list, where classification and network isolation are non-negotiable, but the same requirement appears in banking and insurance where customer data and model behavior are under audit, in healthcare where patient data carries legal obligations that a hosted API cannot meet, and in manufacturing and energy where operational data and control systems must stay off the public network. The pattern is not the sector but the data: when a prompt, document, or trace cannot leave a jurisdiction or a facility under any contract, the only architecture that satisfies the policy by construction is one with no network path out.