Confidential Computing for GPU Workloads: AMD SEV-SNP vs Intel TDX

GPU-accelerated processing of sensitive data - patient health records for medical imaging models, financial transaction histories for fraud detection, proprietary training datasets - now faces regulatory and competitive pressure to protect data in use, not just at rest and in transit. The HIPAA Security Rule's 2025 guidance explicitly calls out memory-level isolation for workloads processing ePHI on shared infrastructure. GDPR Article 28's data processor requirements are increasingly interpreted to require memory encryption for cloud GPU deployments. Confidential computing addresses this gap by encrypting data while it is being processed in GPU memory, preventing access by the host operating system, hypervisor, or co-tenants.

AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) and Intel TDX (Trusted Domain Extensions) are the two dominant CPU-side confidential computing technologies. Both create hardware-enforced encrypted memory regions where even the hypervisor cannot inspect guest data. For GPU workloads, these technologies encrypt the PCIe memory transaction path between the CPU and GPU, ensuring that model weights, inference inputs, and training data remain encrypted while traversing the interconnect and while resident in GPU HBM. The GPU itself - H100, H200, B200, or AMD MI3xx series - does not need native confidential computing support because the encryption boundary is at the CPU memory controller.

The market context in mid-2026: AMD's 4th Gen EPYC (Genoa) and Intel's 5th Gen Xeon (Emerald Rapids) both support their respective TEE technologies. Azure, GCP, and AWS all offer confidential GPU VM SKUs. ClusterBid's marketplace aggregates inventory across data centers that support both SEV-SNP and TDX, though availability varies. The premium for confidential compute-enabled H100 nodes typically runs 15-25% above non-confidential on-demand pricing due to the hardware requirements (certified CPUs, measured boot infrastructure, attestation services).

SEV-SNP extends AMD's earlier SEV and SEV-ES technologies with secure nested paging, which prevents the hypervisor from manipulating the guest's page tables and launching page-table-based attacks. For GPU acceleration, the critical path is the PCIe DMA transaction: when the H100 GPU issues a DMA read from host memory for training data or model weights, the SEV-SNP encrypted region is decrypted by the CPU memory controller before being transmitted over PCIe to the GPU. The GPU receives plaintext data. When the GPU writes results back, the data is encrypted on the PCIe return path. The encryption is transparent to the GPU driver and the CUDA runtime.

Attestation for SEV-SNP uses AMD's Secure Processor (a dedicated ARM Cortex-A5 embedded in the EPYC SoC). The guest VM requests an attestation report from the Secure Processor, which includes: the measurement (hash) of the guest's initial memory state, the TCB version of the platform firmware, and a signature chain rooted in AMD's hardware key. This report is presented to a remote attestation service (typically a Key Management Service or the workload operator's own verifier). Once verified, the attestation service issues an encryption key for the GPU-encrypted data channel.

The key practical limitation of SEV-SNP for GPU workloads: the encrypted region size. SEV-SNP supports encrypted VMs with up to 1TB of encrypted memory per socket on 4th Gen EPYC. For GPU workloads that use CPU-side pinned memory buffers for GPU DMA transfers (typically 10-20GB for large-scale training), this is sufficient. However, for workloads that attempt to encrypt the full GPU memory (80GB H100 -> 192GB B200) via the PCIe BAR mapping, performance degrades because BAR-mapped GPU memory encryption incurs significant latency overhead. Best practice: encrypt only the CPU-side data buffers, not the GPU's BAR space.

Intel TDX creates Trusted Domains (TDs) that are hardware-isolated virtual machines with full memory encryption using Intel Total Memory Encryption - Multi-Key (TME-MK). Each TD gets its own encryption key, managed by the TDX module running in SEAM (Secure Arbitration Mode). The key difference from SEV-SNP: TDX encrypts all memory accesses from the TD, including DMA transactions to devices like GPUs. When an H100 GPU performs a DMA read from TD memory, the data is automatically decrypted by the memory controller before reaching the PCIe bus - same end result as SEV-SNP, but achieved through TDX's comprehensive memory encryption rather than SEV's page-table-based encryption.

TDX attestation uses Intel's SGX-like EPID (Enhanced Privacy ID) or DCAP (Data Center Attestation Primitives). The TD Quote Provider in the platform software collects measurements from the TDX module: the TD's initial memory contents, the TDX module version, and the platform TCB. The quote is signed by Intel's Provisioning Certification Key (PCK) unique to the platform. Remote attestation services verify the quote against Intel's PCK certificate chain and check the platform's revocation status. The workflow is more mature than SEV-SNP's attestation pipeline, with signed Intel SGX DCAP libraries available for Go, Rust, and Python.

Intel TDX's advantage for GPU workloads is its simpler memory model: because TDX encrypts all TD memory uniformly, there is no need to carefully delineate encrypted and unencrypted regions. The tradeoff: TDX imposes a 3-8% memory access latency overhead on all TD memory operations compared to non-TDX execution, even for memory regions that do not contain sensitive data. SEV-SNP can selectively encrypt only specific guest memory pages, reducing the overhead for non-sensitive GPU buffers to effectively zero. For workloads where only the training data is sensitive (while model weights and intermediate activations are not), SEV-SNP's selective encryption is more efficient.

CPU-side attestation (verifying the host VM is running in a TEE) is only half the story. For GPU workloads processing sensitive data, the attestation must also verify that the GPU is the intended device, that its firmware has not been tampered with, and that the data path between CPU and GPU is secure. This is the GPU attestation flow, and it is less mature than CPU attestation across both platforms.

NVIDIA's confidential computing framework for Hopper and Blackwell GPUs introduces GPU-attested TLS: the GPU driver provides a certificate chain rooted in the GPU's fused fuses (hardware identity burned during manufacturing). The GPU can prove to the VM that it is a genuine NVIDIA H100/B200 GPU running signed firmware. This attestation happens during GPU initialization: the VM requests an attestation token from the GPU via the CUDA driver's nvmlDeviceGetConfidentialComputeToken API, includes it in the VM's remote attestation report, and the remote verifier confirms that the GPU is trusted before releasing data encryption keys.

The practical integration flow involves four steps. Step one: the VM boots within SEV-SNP or TDX, performs CPU attestation, and establishes a secure channel to the remote key server. Step two: the VM initializes the GPU, collects the GPU attestation token, and sends it to the key server as part of the attestation evidence bundle. Step three: the key server verifies the GPU token against NVIDIA's OCSP responder (checking firmware revocation status), verifies the CPU attestation against AMD's/Intel's key infrastructure, and derives a data encryption key that it sends back through the secure channel. Step four: the VM uses this key to decrypt the model weights and training data before passing them to the GPU. The entire flow adds 2-5 seconds to GPU initialization time but runs once per VM boot, not per inference request.

The performance cost of confidential computing for GPU workloads depends heavily on the proportion of CPU-GPU data transfer versus GPU-internal compute. For inference workloads where a single prompt generates hundreds of output tokens with minimal input-output data transfer, the overhead is negligible - below 1% in both SEV-SNP and TDX configurations tested on ClusterBid H100 nodes. The model weights are loaded once at startup through the encrypted path, and subsequent inference runs entirely on GPU-resident data.

For training workloads, the overhead varies by the training data pipeline architecture. Training pipelines that preprocess data on the CPU and transfer preprocessed batches to the GPU incur encryption/decryption overhead on each batch. In our benchmarks on an 8x H100 SXM5 running Llama 3.1 8B fine-tuning with local dataset I/O, SEV-SNP added 3.2% to total training time and TDX added 5.8%. The difference reflects TDX's uniform encryption overhead versus SEV-SNP's selective page encryption. Training pipelines using GPU-centric data loading (NVIDIA DALI with direct GPU I/O) saw lower overhead: 1.5% for SEV-SNP and 3.1% for TDX, because data bypasses CPU memory entirely for most of the pipeline.

The overhead that surprises most teams: GPU attestation initialization time. The first GPU initialization in a confidential VM can take 30-60 seconds versus 5-10 seconds in a non-confidential VM, because the GPU must generate its attestation token and the driver must verify the GPU firmware signature chain. This is a cold-start cost only, amortized over hours-long training runs or continuous inference deployments. For serverless GPU workloads with sub-minute cold starts, the attestation overhead can meaningfully impact startup responsiveness. Pre-warming GPU attestation tokens via a token cache service is the recommended mitigation.

HIPAA's 2026 enforcement guidance explicitly addresses GPU shared tenancy. The key requirement: ePHI processed on GPU hardware shared with other tenants must use hardware-enforced memory isolation with attested firmware state. SEV-SNP and TDX both satisfy this requirement when configured with GPU attestation. Without confidential computing, a GPU-resident data breach via row hammer or CUDA memory introspection is a theoretical but increasingly litigated risk. Three of the major neocloud GPU providers now include confidential computing as a checkbox in their BAA templates.

GDPR Article 28 requires that data processors implement 'appropriate technical and organizational measures' to protect personal data. While GDPR does not explicitly mandate memory encryption, the 2025 EDPB guidelines on AI training data mention GPU memory isolation as a best practice for processing personal data on shared infrastructure. The practical interpretation: if you are processing EU personal data on shared GPUs, confidential computing significantly de-risks your data protection impact assessment (DPIA). Without it, your DPIA must explain why standard memory isolation is adequate despite the documented risks of GPU memory scraping attacks demonstrated in academic research since 2024.

The regulated industry segments that most benefit from GPU confidential computing: healthcare AI (medical imaging, genomic analysis, clinical NLP), fintech (fraud detection models trained on transaction histories), legal tech (document analysis with attorney-client privilege), and defense/govtech (classified analysis on unclassified infrastructure). The premium for confidential compute H100 nodes on ClusterBid's marketplace varies by data center but typically ranges from $1.35-$1.50/hr per H100 SXM5 versus $1.15/hr standard on-demand - a $0.20-0.35/hr premium that is easily justified by the regulatory compliance and customer trust benefits.

Choose AMD SEV-SNP when your GPU workload uses AMD Instinct MI300/MI350 accelerators, when you need selective memory encryption to minimize overhead for non-sensitive GPU buffers, or when you are already running on AMD EPYC-based infrastructure and want to avoid the platform migration cost. SEV-SNP's selective encryption is particularly valuable for fine-tuning workloads where the training data is sensitive but the foundational model weights are public - encrypting only the training data pipeline buffers reduces overhead to near zero.

Choose Intel TDX when your workload requires Intel SGX compatibility (if you have existing SGX-based attestation infrastructure), when you prefer the simpler uniform memory model over selective page management, or when your GPU deployment uses NVIDIA H100/B200 exclusively (TDX's broader industry ecosystem and more mature attestation tooling integrate more smoothly with NVIDIA's confidential GPU attestation API). TDX's slightly higher memory overhead is offset by simpler operational management - no need to identify which memory pages need encryption and tune the SEV-SNP policy accordingly.

The pragmatic choice for most teams running both CPU and GPU confidential workloads: align with the CPU platform your preferred data center provider offers, since the confidential computing premium is driven more by CPU platform support than by GPU compatibility. ClusterBid's marketplace shows roughly 60% of confidential compute GPU inventory on Intel TDX platforms and 40% on AMD SEV-SNP, with the gap narrowing as AMD's Instinct GPUs gain adoption. Neither technology is a wrong choice - both provide hardware-guaranteed memory isolation that is vastly superior to the pure software isolation that shared GPU deployments have relied on historically. The important thing is to deploy one of them before your next regulatory audit.