NVIDIA Developer ★ 89 5 min

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

Agentic AI / Generative AIData Center / CloudTrustworthy AI / CybersecurityAI InferenceConfidential ComputeTrustworthy AI

🔗 https://developer.nvidia.com/blog/enabling-private-high-performance-production-ai-inference-with-nvidia-confidential-computing/

📌 NVIDIA機密運算上線,AI推理效能只掉不到5%

TL;DR:CC-aware最佳化讓TensorRT LLM在機密運算開啟下仍保留96%以上的輸出吞吐量。

當LLM推理開始處理病歷、合約、企業機密prompt時,「資料在記憶體裡是明文」本身就是風險。但機密運算過去給人的印象是「安全但慢」,這次NVIDIA用實測資料回應了這個疑慮。

🤔 機密運算為什麼會拖慢推理

NVIDIA Confidential Computing(CC)透過記憶體加密的confidential virtual machines(CVM)、confidential GPU 與加密的NVLink,讓LLM推理全程在受信任環境中執行,藉此保護專有模型與敏感prompt在「使用中」的安全。但CC啟用後,會改變推理框架原本對記憶體搬移、時間量測、排程與多GPU通訊的假設,如果推理框架沒有針對這些變化調整,就會產生額外效能負擔。

NVIDIA以TensorRT LLM為例,說明推理框架該如何跟CC環境「一起最佳化」,才能在啟用安全防護的同時盡量維持效能。

🧩 三個關鍵調整點

NVIDIA的效能工程團隊分析出CC啟用後,TensorRT LLM需要因應的三個主要瓶頸:

  • Host-to-device資料搬移:在B200 CC架構下,host到device的傳輸必須經過軟體加密的bounce buffer,因為GPU無法直接存取受保護的CVM記憶體。這讓pinned memory失去原本非同步傳輸的優勢,部分複製甚至會阻塞呼叫執行緒。TensorRT LLM因此改用CC-aware的記憶體選擇策略,在受影響路徑改用pageable memory,並把重複的token與取樣資料回讀搬到非同步worker執行,避免decode階段被受保護複製卡住主排程器。
  • Kernel autotuner計時失準:autotuner原本用CUDA events比較候選執行策略的效能,但在CC環境下CUDA-event時間戳會出現不穩定訊號,可能導致autotuner選到較慢的策略。TensorRT LLM因此在CC環境下改用GPU的%globaltimer量測,非CC環境仍維持CUDA events。
  • 多GPU通訊選擇:B200 CC組態不支援NVLS(NVLink SHARP)multicast,若框架仍預設走NCCL_SYMMETRIC,反而會白白付出記憶體註冊與跨rank同步成本卻拿不到multicast的好處。因應之道是偵測NVLS可用性,依訊息大小、拓撲與工作負載特性選擇合適的通訊演算法。

📊 測試方法與數據:CC on/off對照

為了讓CC造成的效能差異可被觀察到,NVIDIA刻意挑選長輸入、長輸出、低併發的工作負載,這類負載讓prefill階段的資料搬移、decode階段的per-token負擔更明顯,且併發不足以互相掩蓋延遲。

測試以nvidia/DeepSeek-R1-0528-NVFP4搭配TensorRT LLM(PyTorch backend)進行,輸入/輸出序列長度為32K/1K,併發數涵蓋1、2、4、8、16,並行策略為TP=8、EP=1、PP=1,KV cache採FP8。硬體為8張NVIDIA B200 GPU的DGX B200系統,Host端為Intel TDX、Ubuntu 25.10;Guest端為Ubuntu 24.04.4 LTS,配置256個vCPU。

在維持模型、硬體、框架版本、序列長度、並行度與併發數完全一致的前提下,僅切換CC on/off做對照,衡量兩項指標:輸出吞吐量保留率(CC on輸出tokens/s ÷ CC off輸出tokens/s)與Time Per Output Token(TPOT)延遲負擔。

結果顯示,在併發1到16的區間,CC on保留了CC off基準96.1%到98.2%的輸出token吞吐量,平均TPOT延遲負擔則落在1.2%到4.3%之間。

💡 安全與效能不是二選一,而是要一起設計

這份實測的意義在於,機密運算並沒有消除效能工程的必要性,反而讓「框架是否感知CC環境」變得更重要。若TensorRT LLM沒有做上述三項調整,直接把CC當成透明的底層開關,實際負擔恐怕會更明顯。

🎯 實務啟示

對正在評估機密推理的AI平臺工程師來說,這篇文章給出一套可複製的方法論:挑選長context、低併發的工作負載來放大CC效應,固定其餘變數只切換CC on/off,量測吞吐量保留率與TPOT延遲負擔。啟用CC前,務必用自己實際要serve的workload做一次CC-on/off的基準測試,而不是假設安全與效能必然互斥。

🔗 來源

#NVIDIA #ConfidentialComputing #TensorRTLLM #LLMInference #Blackwell #AIInfrastructure #DataPrivacy #GPU #MLOps #DeepSeekR1

原始資料 NVIDIA Developer · 收集於 2026-09-22
來源原標題
Enabling Private High-Performance Production AI Inference with NVIDIA Confidential Computing
作者
Tanya Lenz
原始標籤
Agentic AI / Generative AI · Data Center / Cloud · Trustworthy AI / Cybersecurity · AI Inference · Confidential Compute · Trustworthy AI
原始連結
https://developer.nvidia.com/blog/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 Table 1. Workload configuration for the CC on and CC off comparison 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 Table 2. Hardware and software configuration used for both CC-on and CC-off runs 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. Figure 1. CC on output-token throughput relative to the CC off baseline at concurrency 1–16. CC on retained 96.1% to 98.2% of baseline throughput Figure 2. Mean TPOT with CC enabled relative to the CC off baseline at concurrency 1–16. CC on introduced 1.2% to 4.3% TPOT overhead (lower TPOT is better) 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 .

由 claude-code/sonnet 自動生成