ORTEX
Engineering insights

Technical blueprint

Step-by-Step Architecture for Deploying Private LLMs on Air-Gapped Clusters

A practical blueprint for moving from model selection to an auditable, disconnected inference platform.

12 min read

01 / Field note

Start with the boundary, not the model

An air-gapped LLM project is an infrastructure and governance project before it is a model-selection exercise. The first decision is what may cross the boundary: model artifacts, container images, telemetry, evaluation data, support bundles, and administrator access each need an explicit policy. A useful architecture document names the disconnected zone, the staging zone, the people who can move artifacts between them, and the evidence required before promotion.

This framing prevents a common failure mode: choosing a model that performs well in a benchmark and discovering later that its runtime, tokenizer, monitoring stack, or license cannot be operated inside the approved environment. Treat the boundary as a product requirement. Every later layer should make the boundary easier to verify.

02 / Field note

1. Build a controlled artifact pipeline

The connected staging environment is responsible for collecting approved base images, model weights, tokenizers, CUDA dependencies, Python wheels, Helm charts, and security metadata. Pin versions and record checksums. Generate a software bill of materials for container images, scan them, and place the approved bundle in an immutable registry or transfer medium.

Inside the disconnected network, promotion should be a deliberate import operation. The receiving process verifies signatures and checksums before an artifact becomes available to workloads. Do not allow production nodes to reach public package registries as a convenience. That shortcut undermines the very boundary the platform exists to protect.

03 / Field note

2. Provision the GPU substrate

Size the cluster around the workload shape: concurrent users, context length, output tokens, batchability, and latency objectives. A small model with long context can create a different memory profile from a larger model with short requests. Measure GPU memory, interconnect bandwidth, CPU preprocessing, storage throughput, and network paths together.

Use dedicated nodes with a known driver and runtime matrix. Kubernetes can provide scheduling and service discovery, while a simpler system may be preferable for a single stable inference pool. Whichever platform you choose, expose health checks for GPU memory, model load state, queue depth, and token throughput. Operators should know whether an apparent AI failure is a model issue or a saturated node.

04 / Field note

3. Separate the gateway from inference

Clients should not call the model server directly. Place an internal policy gateway in front of it to authenticate the caller, apply quotas, validate request shape, redact prohibited fields, select a model, and attach a trace identifier. The gateway is also the right place to present a stable API while models and serving runtimes change underneath.

The inference tier should be intentionally boring: pinned model artifacts, a small number of well-understood endpoints, and predictable resource limits. Keep orchestration, retrieval, tools, and business actions outside the model server. That separation lets you upgrade a serving runtime without rewriting every consuming application.

05 / Field note

4. Add retrieval and tools as governed layers

Private models become useful when they can work with enterprise context. Retrieval should therefore be its own service with explicit connectors, indexing policy, access checks, and citations. The model receives a bounded context assembled by the retrieval layer; it should not be given unrestricted database credentials or arbitrary network access.

Tool calls need the same discipline. Define each action with a typed input, an authorization requirement, an idempotency strategy, and an audit event. For high-impact operations, require a human approval step. A private deployment protects data residency, but it does not automatically make autonomous actions safe.

06 / Field note

5. Make evaluation and observability possible offline

An air-gapped platform still needs feedback. Keep a versioned evaluation set inside the environment, with representative prompts, expected properties, access-control cases, and adversarial examples. Track retrieval hit rate, citation correctness, refusal behavior, latency percentiles, token throughput, and operator feedback.

Logs should be useful without becoming a second data leak. Classify prompts and outputs, apply retention rules, and separate operational metadata from sensitive content where possible. Dashboards can report queue depth, errors, and performance without exposing the underlying conversation. When detailed traces are required, access them through the same role and audit controls as the application itself.

07 / Field note

Promotion is a recurring operating process

Model deployment is not complete when the first endpoint answers a prompt. Define how a new model, adapter, runtime, or security patch moves from evaluation to production, how the previous version is retained for rollback, and who signs off on the change. Run the process often enough that it is familiar before an urgent security update arrives.

The resulting platform is more than an on-premise chatbot. It is a private AI control plane: a verified artifact supply chain, dedicated compute, policy enforcement, governed retrieval, observable inference, and a repeatable path for change. That is the architecture required when sovereignty and reliability matter as much as capability.

Continue the architecture conversation

Turn the blueprint into a system your team can own.

Talk with VORTEX about the constraints, interfaces, and operating model behind your next technical initiative.

Schedule a technical consultation

This article links directly to the corresponding commercial solution for implementation planning.