BLOG

Air-gapped LLM training: what it
actually requires.

"Private cloud" shows up as a checkbox feature on nearly every AI infrastructure vendor's site. It usually means a dedicated account inside a public cloud provider, not an environment with no external network path at all. Air-gapped is a much narrower, stricter claim, and confusing the two tends to matter most exactly when it's too late to do anything about it.

What "private cloud" usually means

In practice, a vendor's private cloud deployment is a VPC or dedicated tenancy inside AWS, GCP, or Azure. Your workloads are isolated from other customers at the account level, but the environment still depends on the provider's control plane, still receives telemetry and update traffic over the internet, and still runs on infrastructure the vendor, and by extension the cloud provider, can reach. That's a real and useful isolation boundary. It just isn't the same thing as no external network path.

Private cloud versus a real air gap Top: your workloads connect over a dashed line to a vendor's cloud account, which itself has an external dependency reaching out to the internet. Bottom: your workloads sit behind a sealed boundary with no network path in or out, with a padlock marking the boundary and no line crossing it. PRIVATE CLOUD (TYPICAL) YOUR WORKLOADS VENDOR'S CLOUD ACCOUNT EXTERNAL DEPENDENCIES AIR-GAPPED YOUR WORKLOADS OFFLINE MEDIA TRANSFER (ONE-WAY) NO NETWORK PATH IN OR OUT
A private cloud VPC still has a way out. A real air gap doesn't, by design, not by configuration.

What air-gapped actually requires

Air-gapped means exactly what it says: no network path in or out, verified rather than assumed. That's a much higher bar than picking a deployment region, and it touches every layer of the stack. Three requirements come up in nearly every real air-gapped environment.

NO NETWORK EGRESS

Not "restricted." None. No license check-ins, no telemetry, no runtime call home for updates or model downloads, verified at the network layer, not taken on trust.

LOCAL ARTIFACT MIRROR

Model weights, container images, and package registries have to be mirrored inside the boundary ahead of time. There's no pulling anything on demand.

OFFLINE IDENTITY & UPDATES

Auth, secrets, and patching all need a self-contained path. A tool that assumes a hosted identity provider or update server won't run here unmodified.

None of these three can be retrofitted quietly. A tool built assuming it can call home has to be re-architected, not just reconfigured, to run without one.

Getting artifacts in without a network path

Model weights, container images, and OS patches still have to reach the environment somehow. The answer isn't a hole in the boundary, it's a one-way, verified transfer process: artifacts get vetted in a connected staging area, then moved across the boundary through a controlled one-way transfer, physical media or a verified one-way gateway depending on the environment's accreditation requirements, never pulled in response to a request from inside, and never sent back out.

One-way artifact transfer into an air-gapped environment A connected staging area holding model weights, container images, and OS updates flows through a verify and transfer step into the air-gapped environment. A dashed line marked with an X shows there is no path back out. STAGING (CONNECTED) MODEL WEIGHTS CONTAINER IMAGES OS / PACKAGE UPDATES VERIFY + TRANSFER (ONE-WAY) AIR-GAPPED ENVIRONMENT NO PATH BACK OUT
Artifacts move in through a verified one-way transfer. Nothing moves back out, ever.

This is why Lupine, P95, and NinetyFive are built to run fully air-gapped, not just inside a private VPC: no license check-ins, no required telemetry, no assumption that the box can reach the internet to fetch anything at runtime. If your infrastructure actually needs to run without a network path, private cloud was never going to be enough on its own.

Numerata runs inside your own environment: private cloud, on-prem, or fully air-gapped.  ·  Back to blog