Model weights representing six months of training on proprietary data sit unencrypted on an NVMe drive. A decommissioned server reaches a recycler without proper disk wiping. Your intellectual property walks out the door on a 2 TB drive. Encryption at rest prevents this scenario entirely — even if physical security fails, the data is unreadable without the key. For dedicated GPU servers hosting AI workloads, encryption at rest protects model weights, training datasets, inference logs, and cached outputs.
What Needs Encryption
AI infrastructure contains several categories of sensitive data, each requiring encryption:
| Data Type | Sensitivity | Encryption Priority |
|---|---|---|
| Model weights | IP — training investment | High |
| Fine-tuning datasets | May contain PII, proprietary data | High |
| Inference logs | Input prompts may contain customer data | High |
| KV cache on disk | Contains intermediate inference state | Medium |
| Configuration files | API keys, connection strings | High |
| Swap/pagefile | May contain leaked inference data | High — or disable entirely |
Full-disk encryption covers all categories simultaneously. On private GPU servers, you control the encryption from provisioning through decommissioning.
LUKS Full-Disk Encryption
Linux Unified Key Setup (LUKS) is the standard for full-disk encryption on Linux GPU servers. LUKS2 with AES-256-XTS provides strong encryption with hardware acceleration on modern CPUs. The setup encrypts the entire root partition and data partitions, requiring a passphrase or key file at boot.
For remote GPU servers, the challenge is unlocking the disk at boot without physical console access. Solutions include Dropbear SSH in initramfs (SSH into the boot environment to enter the passphrase), Tang/Clevis for network-bound disk encryption (automatic unlock when on the correct network), and TPM-bound keys (unlock tied to the specific hardware configuration). Network-bound encryption with Tang is the recommended approach for dedicated servers — the disk unlocks automatically when connected to your secure network, but is unreadable if the drive is removed.
Performance Impact on AI Workloads
The concern with encryption at rest is I/O overhead. For AI workloads, the impact varies by operation:
| Operation | I/O Pattern | Encryption Overhead |
|---|---|---|
| Model loading | Sequential read, large files | 3-8% slower (AES-NI accelerated) |
| Inference (model in VRAM) | No disk I/O | Zero — model is in GPU memory |
| Log writing | Sequential append, small writes | 1-3% slower |
| KV cache swap to disk | Random read/write | 5-12% slower |
| Dataset loading for fine-tuning | Sequential read, large files | 3-8% slower |
The critical insight: once a model is loaded into GPU VRAM via vLLM, encryption at rest has zero impact on inference performance. The overhead only applies during model loading at startup. A model that takes 45 seconds to load unencrypted takes approximately 48 seconds encrypted. This is negligible for production deployments where models are loaded once and serve thousands of requests.
Key Management
Encryption is only as strong as key management. Never store encryption keys on the same server as the encrypted data. Use a dedicated key management system — HashiCorp Vault, a hardware security module (HSM), or at minimum a separate secured server. Implement key rotation annually at minimum, with the ability to re-encrypt data under new keys without downtime.
For GPU servers, maintain a documented key hierarchy: a master key (stored in HSM or Vault), per-server data encryption keys (wrapped by the master key), and per-application keys for fine-grained access control. Escrow master key recovery material in a physical safe with dual-control access.
Model-Specific Encryption
Beyond full-disk encryption, consider encrypting model weights at the application layer. This protects against scenarios where an attacker gains shell access but not disk encryption keys. Use GPG or age to encrypt model weight files, decrypt into a tmpfs (RAM disk) at deployment time, and serve the model from RAM — the decrypted weights never touch persistent storage.
This approach is particularly valuable for proprietary fine-tuned models. Open-source base models are publicly available, but your fine-tuned weights represent proprietary investment. Encrypt the LoRA adapters or merged weights separately from the base model. See infrastructure guides for deployment automation.
Compliance Evidence
Document your encryption implementation for auditors. Record the encryption algorithm and key length (AES-256-XTS), key management procedures, key rotation schedule and evidence, disk decommissioning procedures, and test results demonstrating encrypted disks are unreadable without keys. This documentation satisfies GDPR Article 32 requirements for appropriate security measures, PCI DSS encryption requirements, and ISO 27001 Annex A.8.24. Production use cases across regulated sectors rely on this encryption foundation.
Encrypted GPU Infrastructure
Dedicated GPU servers with full-disk encryption, key management support, and zero-overhead inference performance. UK data centres.
Browse GPU Servers
