Private and custom LLMs: a deployment playbook

Executive summary

More enterprises want language models they control. The reasons vary: data residency rules, sensitive intellectual property, regulated workloads, predictable cost at high volume, low latency, or the need to keep a model version stable for audit. Private and custom models address these needs, but they also shift responsibility onto you. You become accountable for the data, the model, the serving infrastructure and the results.

This playbook describes how to deploy private and custom LLMs well. It covers seven stages:

1. Define the workload and the decision.
2. Choose the deployment environment.
3. Prepare the data.
4. Select and adapt the model.
5. Evaluate against ground truth.
6. Serve, secure and scale.
7. Govern and operate over time.

The guidance is drawn from common industry practice and our own delivery experience. It is technology-neutral, and it applies whether the model runs in your public cloud tenancy, a virtual private cloud, a private data center or a sovereign, air-gapped environment.

Terms used in this paper

• Private model: a model that runs entirely within infrastructure you control, so prompts, outputs and logs do not leave your environment.
• Custom model: a model adapted to your domain or tasks, usually by fine-tuning an open-weight base model on your own data.
• Open-weight model: a model whose trained weights are published and can be run on your infrastructure, under the terms of its license.
• Retrieval-augmented generation (RAG): supplying relevant documents to the model at request time, so it answers from your current information rather than only from what it learned in training.

A model can be private without being custom, and many effective deployments are exactly that: a well-chosen open-weight model, self-hosted, with retrieval over your data.

Stage 1: define the workload and the decision

Deployments go best when they start with a narrow, written workload definition. It should answer:

• What task the model performs, for whom, and what it produces.
• What good output looks like, with real examples checked by domain experts.
• What the model must never do, such as reveal certain data, make certain commitments or act without approval.
• Expected volume, peak load and latency targets.
• Data classification for inputs, outputs and logs.
• The business outcome the workload should change, and how that will be measured.

With this in hand, run a baseline. Test the strongest model you are permitted to use, with careful prompting and retrieval, on a representative evaluation set. The baseline tells you how far a general model gets on its own, and gives every later decision a reference point.

Then make the decision explicit: is a private model required by policy, justified by cost or latency, or needed to close a quality gap the baseline revealed? Write down the reason. It will be asked for later.

Stage 2: choose the deployment environment

Private models can run in several environments. Each has trade-offs.

• Public cloud tenancy or VPC. Fast to provision, elastic GPU capacity, mature managed services. Suitable for most workloads where data can reside in a chosen cloud region under your control.
• Private data center. Full physical control and potentially lower cost at sustained high utilization. Requires procurement lead time, power and cooling capacity, and operations skill.
• Sovereign or air-gapped environment. Required for some government, defense and critical infrastructure workloads. Adds controls for moving models, updates and data across the boundary, and limits access to external services.
• Edge. Small models deployed close to where data is created, for latency, bandwidth or connectivity reasons.

Hybrid patterns are common: training in a cloud environment with elastic capacity, then serving on premises; or serving sensitive workloads privately while routing low-risk tasks to external APIs under policy.

Decide early, because the environment shapes model size, serving software, security controls and cost.

Stage 3: prepare the data

Data preparation is usually the largest part of the effort and the largest source of risk.

Collect

Identify the sources that represent the task: past documents, tickets, transcripts, reports or code, with expert-verified outputs where possible. Confirm that you have the right to use each source for this purpose, including any contractual, privacy or consent limits.

Clean and protect

• Remove duplicates, broken records and examples that do not reflect current policy or practice.
• Scan for secrets, credentials and personal information. Remove or mask what the model does not need.
• Check for imbalance: a dataset dominated by one product line, region or document type will produce a model that is weaker on the rest.

Label and review

For fine-tuning, each example needs an input and a correct output. Domain experts should write or review these. A smaller set of high-quality examples usually beats a large set of noisy ones.

Record lineage

Version every dataset and record its sources, transformations and approvals. You will need this to reproduce a model, investigate a problem, answer an audit request or remove data later.

Prepare retrieval content separately

Retrieval corpora need their own care: chunking that preserves meaning, metadata for filtering, access control that matches source permissions, and a process for updating and retiring content.

Stage 4: select and adapt the model

Selecting a base model

Consider:

• License terms for commercial use, modification and distribution.
• Size relative to your hardware, latency and cost targets. Smaller models adapted to a narrow task often match larger general models on that task.
• Language and domain coverage for your content.
• Context length relative to the documents and conversations you need to handle.
• Provenance: a reputable source, published hashes, and a format that does not execute code on load.

Shortlist a few candidates and run them against your baseline evaluation set before committing.

Choosing the lightest adaptation that works

Work up this ladder, stopping as soon as the quality bar is met:

1. Prompting and retrieval on a private base model.
2. Parameter-efficient fine-tuning, such as low-rank adapters, which trains a small number of additional parameters and is far cheaper than full fine-tuning.
3. Full fine-tuning, when adapters are not enough and you have sufficient data and compute.
4. Preference tuning, to align outputs with expert judgments about which responses are better.
5. Distillation, where a larger model generates training examples for a smaller one, subject to the license terms of the larger model.

Fine-tuning is most effective for teaching format, style, terminology and task behavior. For facts that change, retrieval remains the better tool.

Stage 5: evaluate against ground truth

Evaluation decides whether a model is fit to deploy, and whether each later change keeps it fit.

• Task quality. Use verifiers that check outputs against known answers wherever possible: correct fields extracted, correct classification, valid structured output, citations that point to real supporting passages.
• Expert review. For outputs that cannot be checked by a program, have domain experts grade a sample. If you use a model as a judge, calibrate it against these grades.
• Safety and security. Test resistance to prompt injection, attempts to extract training data or system prompts, and requests outside the permitted scope.
• Regression. Confirm the custom model has not lost general abilities it needs, such as following instructions or refusing unsafe requests.
• Fairness. Where outputs affect people, check for differences in quality across relevant groups.
• Performance and cost. Measure latency, throughput and cost per completed task under realistic load.

Compare every candidate against the baseline from Stage 1. A custom model earns its place only if it beats the baseline on the dimensions that matter to the workload.

Stage 6: serve, secure and scale

Serving

• Choose inference software that supports your model architecture, batching strategy and hardware.
• Consider quantization to reduce memory and cost, and verify its effect on quality with your evaluation suite.
• Size capacity for peak load with headroom, and use autoscaling where the environment supports it.
• Cache repeated work, such as embeddings, retrieval results and common prompts.

Security

• Pull models only from an internal registry, with hash and signature verification.
• Isolate model servers on the network, run them with least privilege, and patch the serving stack like any other software.
• Authenticate every request, and apply rate limits and quotas per application.
• Apply input trust boundaries and output validation in the application layer.
• Log requests and responses according to your data classification and retention rules.

Integration

Expose the model behind a stable internal interface, so applications do not depend on a specific model version. A routing layer can direct requests to different models based on data classification, task type, cost and quality targets.

Stage 7: govern and operate

A private model is a product with a lifecycle.

• Ownership. Name an accountable owner for the model and each workload that depends on it.
• Documentation. Maintain a model record covering purpose, base model, training data, evaluation results, known limits and approved uses.
• Change control. Treat changes to weights, prompts, retrieval content and serving configuration as releases, gated by the evaluation suite.
• Monitoring. Track quality, safety, latency, cost and usage in production. Sample outputs for review on a schedule.
• Feedback. Capture corrections from the people who use the outputs, and route confirmed failures into the evaluation set.
• Retraining. Plan for periodic updates as data, policy and available base models change.
• Retirement. Define how a model will be replaced or withdrawn, and how dependent workloads will move.

Map these practices to your existing governance. The NIST AI Risk Management Framework offers a useful structure, and regulated industries will have additional expectations, such as model risk management guidance in financial services.

Common failure modes

• No baseline. Without one, no one can show the custom model is better.
• Training on unreviewed data. Errors and outdated practices in the data become errors in the model.
• Fine-tuning for facts. Facts change; models trained on them go stale quickly.
• Evaluation by demonstration. A handful of good examples hides systematic failures.
• Underfunded operations. Models that no one maintains drift away from the business they serve.
• Unclear ownership. When something goes wrong, no one is sure who decides.

A readiness checklist

1. A written workload definition with examples and a measured baseline.
2. A documented reason for a private or custom model.
3. A chosen environment with capacity, security and operations plans.
4. Datasets with confirmed rights, cleaning, expert review and lineage.
5. A base model with acceptable license and verified provenance.
6. An evaluation suite covering quality, safety, regression and cost.
7. Serving infrastructure with registry pulls, isolation and monitoring.
8. A named owner, change process and retraining plan.

How TuQuant can help

TuQuant builds and deploys custom, private and sovereign language models for enterprises, in your cloud, VPC, data center or air-gapped environment. We work across every stage of this playbook, from workload definition and data preparation through evaluation design, serving and governance, and we transfer the capability to your teams as we go.

Our products apply the same approach: TuQuant Prizm helps you see what AI infrastructure costs per outcome, and our domain products are designed to run in the environment your policies require. Learn more about our sovereign and on-premises AI services, or contact us to discuss a specific workload.

This paper is general guidance and does not constitute legal, licensing or regulatory advice. Review model licenses and data rights with your own counsel.