Enabling Private High-Performance Production AI Inference with NVIDIA Confidential Computing

As large language model (LLM) inference increasingly processes sensitive information and proprietary model context across personal, enterprise, and regulated settings, data must be processed inside a trusted environment. NVIDIA Confidential Computing (CC) provides a pathway for running these workloads securely using memory-encrypted confidential virtual machines (CVMs), confidential GPUs, and encrypted NVIDIA NVLink. This enables running production AI inference on trusted hardware.

Inference frameworks such as NVIDIA TensorRT LLM deliver best-in-class AI inference by combining framework-level optimizations with NVIDIA accelerated computing. However, when these frameworks run in a CC-enabled environment, secure execution changes assumptions behind memory movement, timing, scheduling, and multi-GPU communication. These changes introduce performance overhead if the runtime does not adapt. Maintaining high performance therefore requires the inference framework and the confidential computing environment to be optimized together.

For AI platform engineers evaluating confidential inference on NVIDIA Blackwell GPUs, this post examines the CC-aware adaptations that AI inference frameworks like TensorRT LLM use to account for secure execution while helping preserve inference performance. It presents a controlled methodology that teams can apply to quantify CC overhead on their own workloads. 

Selecting a workload to expose CC overhead

Workload characteristics determine how visible CC overhead can be. High request volume can amortize fixed encryption costs by overlapping stalls with other work, making the direct effects harder to observe.

To expose these effects, select a workload with a long input context, extended output generation, and low concurrency. Long context stresses data movement during prefill, extended generation amplifies small per-token CC overhead during decode, and low concurrency limits the opportunity to hide those costs across concurrent requests. 

The NVIDIA performance engineering team used these characteristics for the workload evaluated here.

Parameter	Configuration
Model	nvidia/DeepSeek-R1-0528-NVFP4
Inference framework	TensorRT LLM, PyTorch backend
I/O sequence length	32K input/1K output
Concurrent requests	1, 2, 4, 8, and 16
Parallelism	TP=8, EP=1, PP=1
KV cache	FP8

Measuring CC overhead with a controlled CC-on and CC-off comparison

To isolate the performance impact of CC, run the same workload under two conditions: confidential compute disabled (CC off) and confidential compute enabled (CC on) holding the model, hardware, framework version, sequence lengths, parallelism, and concurrency constant so that CC state is the only changing variable.

At each concurrency level:

• Output throughput retained: 100 x (CC on output tokens/s ÷ CC off output tokens/s)
• Latency overhead Time Per Output Token (TPOT): 100 x (CC on TPOT ÷ CC off TPOT − 1)

Performance teams can use these measurements to quantify how much of the CC-off baseline is retained when CC is enabled for the target workload. The NVIDIA performance engineering team applied this comparison using the hardware and software configuration summarized in Table 2.

Component	Version / Detail
Hardware	1 NVIDIA DGX B200 system ( 8 NVIDIA B200 GPUs)
Platform	Intel TDX
Host OS	Ubuntu 25.10
Host kernel	6.17.0-20-generic
Guest OS	Ubuntu 24.04.4 LTS
Guest kernel	6.8.0-124-generic
Guest vCPUs	256
Guest NUMA	2 nodes
NVIDIA driver	595.71.05
VBIOS	FW 1.4.x [97.10.64.00.0C]
GPU power limit	1,000 W
CUDA	13.2
TensorRT LLM	nvcr.io/nvidia/tensorrt-llm/release:1.3.0rc22
NCCL	v2.30
OpenSSL	3.6.0
Orchestration	Docker Container + NVIDIA Container Toolkit

Performance results

As shown in Figures 1 and 2, across concurrency 1–16, CC on retained 96.1– 98.2% of CC off output-token throughput, while mean TPOT remained within 1.2% to 4.3% of the baseline.

Identifying and reducing CC overhead

The NVIDIA Blackwell confidential computing architecture introduces hardware-enforced security paths for protecting data and workloads in use. For a detailed overview of the architecture, see Hardware-Rooted AI Security That Won’t Slow You Down.

For TensorRT LLM users and framework developers, the following details show how these secure paths change common runtime assumptions and how TensorRT LLM adapts to reduce the resulting performance overhead.

Adapting host-to-device data movement

In the B200 CC, host-to-device transfers pass through a software encrypted bounce buffer because the GPU cannot directly access protected CVM memory. This changes the behavior expected by inference frameworks: pinned memory no longer provides its usual asynchronous-transfer advantage, and some copies can block the calling thread.

• Host-to-device mitigation: TensorRT LLM uses CC-aware memory selection, choosing pageable memory for affected paths instead of unconditionally using pinned memory.
• Device-to-host mitigation: TensorRT LLM moves repeated token and sampling-data readback to an asynchronous worker, preventing protected copies from blocking the main scheduler during decode. For details, see TensorRT LLM PR #11573.

Stabilizing kernel autotuner timing

The kernel autotuner normally uses CUDA events to compare candidate tactics. In the tested CC configuration, CUDA-event timestamps produced an unstable timing signal, which could cause the autotuner to select a slower tactic.

• Mitigation: TensorRT LLM uses the GPU %globaltimer for tactic measurements under CC while retaining CUDA events outside CC. For details, see TensorRT LLM PR #11657.

Choosing CC-aware multi-GPU communication

NVLS (NVLink SHARP) multicast is not available in B200 CC configurations. Without NVLS, NCCL_SYMMETRIC cannot provide its intended multicast benefit but may still incur memory registration and cross-rank synchronization costs before using a non-multicast collective path.

• Mitigation: Frameworks targeting CC should detect NVLS availability and choose communication algorithms that minimize latency for the given message size, topology, and workload characteristics.

Get started with NVIDIA Confidential Computing

NVIDIA Confidential Computing extends hardware-enforced protection across confidential VMs, NVIDIA Blackwell GPUs, and encrypted NVLink, protecting proprietary models, enterprise context, and sensitive prompts while they are processed.

Confidential computing does not remove the need for performance engineering—it makes framework awareness even more important. With TensorRT LLM CC-aware adaptations to secure data movement, autotuning, and multi-GPU communication in place, confidential DeepSeek-R1 inference retained more than 96% of CC-off output-token throughput while keeping per-token latency overhead below 5% on eight NVIDIA B200 GPUs.

As organizations move private inference into production, security configuration and inference optimization should be approached as a single deployment problem. Enable confidential computing, attest the environment, and benchmark CC-on and CC-off using the exact workload you intend to serve. For AI platform engineers and TensorRT LLM users moving private inference into production, security configuration and inference optimization should be treated as a full-stack engineering effort.

To start planning your confidential inference deployment, use the NVIDIA Trusted Computing documentation and explore the latest TensorRT LLM features and release notes. To stay up to date with the latest developments, follow NVIDIA Confidential Compute news.

Acknowledgments

I would like to thank Dan Hansen, Sheel Pethe, Samuel Mendoza-Jonas, Moein Ghaniyoun, Vidhya Krishnan, Avinash Ahuja, Laikh Tewari, Laura Martinez, and Matheen Raza for their engineering contributions, technical guidance, analysis, and thoughtful review throughout this work.