← 文章 / AI技术
NVIDIA 开发者博客 2小时前 · 2026-09-23 02:05:06 · 3 阅读

借助 NVIDIA Confidential Computing 实现高性能私有化生产级 AI 推理

随着大语言模型(LLM)推理在个人、企业和受监管场景中越来越多地处理敏感信息和专有模型上下文,数据必须在可信环境中处理。NVIDIA Confidential Computing(CC,机密计算)提供了一条安全运行这类工作负载的路径,通过内存加密的机密虚拟机(CVM)、机密 GPU 和加密的 NVIDIA NVLink 实现,从而让生产级 AI 推理可以运行在可信硬件上。 NVIDIA TensorRT LLM 等推理框架通过框架级优化与 NVIDIA 加速计算相结合,提供了顶尖的 AI 推理性能。但当这些框架运行在启用 CC 的环境中时,安全执行会改变内存传输、时序、调度和多 GPU 通信背后的假设。如果运行时不做适配,就会引入性能开销。因此,要维持高性能,推理框架和机密计算环境必须协同优化。 针对正在 NVIDIA Blackwell GPU 上评估机密推理的 AI 平台工程师,本文将探讨 TensorRT LLM 等 AI 推理框架为适应安全执行所做的 CC 感知优化,在保障安全的同时尽量保持推理性能,并介绍一种受控的测量方法,供团队量化 CC 对自身工作负载带来的开销。

选择能暴露 CC 开销的工作负载

工作负载的特性决定了 CC 开销的可见程度。高请求量可以通过让停顿与其他工作重叠来摊薄固定的加密成本,使直接影响更难观察到。 要暴露这些影响,应选择输入上下文长、输出生成时间长且并发度低的工作负载。长上下文会给 prefill 阶段的数据传输带来压力,长输出生成会放大 decode 阶段每 token 的微小 CC 开销,而低并发则限制了对并发请求间隐藏这些成本的机会。 NVIDIA 性能工程团队在本次评估的工作负载中正是采用了这些特性。
参数 配置
模型nvidia/DeepSeek-R1-0528-NVFP4
推理框架TensorRT LLM,PyTorch 后端
I/O 序列长度32K 输入/1K 输出
并发请求数1, 2, 4, 8, 16
并行策略TP=8, EP=1, PP=1
KV cacheFP8
表 1. 用于 CC 开启与 CC 关闭对比的工作负载配置

通过受控的 CC 开启与 CC 关闭对比测量 CC 开销

为隔离 CC 对性能的影响,在两种条件下运行相同的工作负载:关闭机密计算(CC off)和开启机密计算(CC on)。在此过程中保持模型、硬件、框架版本、序列长度、并行策略和并发数不变,使 CC 状态成为唯一变化的变量。

在每个并发级别下:

  • 输出吞吐量保留率:100 × (CC on 输出 tokens/s ÷ CC off 输出 tokens/s)
  • 每输出 Token 延迟开销(TPOT): 100 × (CC on TPOT ÷ CC off TPOT − 1)

性能团队可以利用这些测量数据,量化在启用 CC 后,针对目标工作负载能保留多少 CC-off 基准性能。NVIDIA 性能工程团队使用表 2 中总结的硬件和软件配置,应用了此对比方法。

组件版本 / 详情
硬件1 台 NVIDIA DGX B200 系统(8 块 NVIDIA B200 GPU)
平台Intel TDX
主机 OSUbuntu 25.10
主机内核6.17.0-20-generic
客户机 OSUbuntu 24.04.4 LTS
客户机内核6.8.0-124-generic
客户机 vCPU256
客户机 NUMA2 个节点
NVIDIA 驱动595.71.05
配置项版本/规格
VBIOSFW 1.4.x [97.10.64.00.0C]
GPU 功耗限制1,000 W
CUDA13.2
TensorRT LLMnvcr.io/nvidia/tensorrt-llm/release:1.3.0rc22
NCCLv2.30
OpenSSL3.6.0
编排管理Docker Container + NVIDIA Container Toolkit
表 2. CC 开启与 CC 关闭测试所采用的软硬件配置

性能结果

如图 1 和图 2 所示,在并发数 1–16 的范围内,开启 CC 时的输出 token 吞吐量保持率为 CC 关闭时的 96.1%–98.2%,平均 TPOT 仅比基准线高出 1.2%–4.3%。

水平成对条形图,对比并发数为 1、2、4、8 和 16 时 CC 关闭与 CC 开启的输出 token 吞吐量。CC 关闭状态以深灰色表示并归一化为 100%,CC 开启状态以绿色表示,分别保持 98.2%、98.0%、96.1%、96.8% 和 96.8%。
图 1. 并发数 1–16 下 CC 开启时的输出 token 吞吐量相对 CC 关闭基准线的占比。CC 开启状态保持率为基准吞吐量的 96.1%–98.2%
水平成对条形图,对比并发数为 1、2、4、8 和 16 时 CC 关闭与 CC 开启的平均 TPOT。CC 关闭状态以深灰色表示并归一化为 100%。CC 开启状态以 NVIDIA 绿色表示,分别为 101.2%、103.2%、104.3%、103.5% 和 103.1%。测得的 CC 开启 TPOT 数值为 3.225、4.571、6.658、10.759 和 18.039 毫秒。数值越低表示延迟越优。
图 2. 并发数 1–16 下 CC 开启时的平均 TPOT 相对 CC 关闭基准线的占比。CC 开启带来的 TPOT 开销为 1.2%–4.3%(TPOT 越低越优)

识别与降低 CC 开销

NVIDIA Blackwell 机密计算架构引入了由硬件强制的安全通道,用于保护使用中的数据和负载。想深入了解该架构,请参阅Hardware-Rooted AI Security That Won't Slow You Down

对 TensorRT LLM 用户和框架开发者来说,下文将说明这些安全通道如何改变运行时的常见假设,以及 TensorRT LLM 如何适配以降低由此带来的性能开销。

适配主机到设备的数据传输

在 B200 CC 模式下,主机到设备的传输需要经过软件加密的中转缓冲区(bounce buffer),因为 GPU 无法直接访问受保护的 CVM 内存。这改变了推理框架原本预期的行为:锁页内存不再具备以往的异步传输优势,部分拷贝操作还可能阻塞调用线程。

  • 主机到设备的缓解措施:TensorRT LLM 采用感知 CC 的内存选择策略,在受影响的路径上使用可分页内存,而不是无条件使用锁页内存。
  • 设备到主机的缓解措施:TensorRT LLM 将重复的 token 和采样数据回读移到异步工作线程中,避免受保护的拷贝操作在解码期间阻塞主调度器。详情请参阅 TensorRT LLM PR #11573

稳定 kernel 自动调优的计时

kernel 自动调优器通常使用 CUDA event 来比较候选策略。但在测试的 CC 配置中,CUDA event 时间戳产生的计时信号不稳定,可能导致调优器选中更慢的策略。

  • 缓解措施:TensorRT LLM 在 CC 模式下改用 GPU 的 %globaltimer 进行策略计时,在非 CC 模式下仍保留 CUDA event。详情请参阅 TensorRT LLM PR #11657

选择感知 CC 的多 GPU 通信

B200 CC 配置不支持 NVLS(NVLink SHARP)多播。没有 NVLS,NCCL_SYMMETRIC 无法提供预期的多播优势,但在使用非多播集合通信路径之前,仍可能产生内存注册和跨 rank 同步开销。

  • 缓解措施:针对 CC 的框架应检测 NVLS 的可用性,并根据给定的消息大小、拓扑结构和负载特性,选择能最小化延迟的通信算法。

快速上手 NVIDIA 机密计算

NVIDIA 机密计算将硬件强制保护扩展到机密虚拟机、NVIDIA Blackwell GPU 和加密的 NVLink,在数据处理过程中保护专有模型、企业上下文和敏感提示。

机密计算并不会消除性能优化的需求——反而让框架层面的感知变得更加重要。借助 TensorRT LLM 针对 CC 的适配(包括安全数据移动、自动调优和多 GPU 通信),在八块 NVIDIA B200 GPU 上,机密 DeepSeek-R1 推理在关闭 CC 的情况下仍保留了 96% 以上的输出 token 吞吐量,同时每 token 延迟开销控制在 5% 以内。

当机构将私有推理推向生产环境时,应把安全配置和推理优化视为同一个部署问题。启用机密计算,验证环境,并使用计划服务的实际负载对开启和关闭 CC 进行基准测试。对于推动私有推理落地的 AI 平台工程师和 TensorRT LLM 用户,安全配置和推理优化应被视为一项全栈工程努力。

要开始规划您的机密推理部署,请参考 NVIDIA Trusted Computing 文档,并了解最新的 TensorRT LLM 特性和发布说明。关注 NVIDIA 机密计算新闻 以获取最新动态。

致谢

谨此感谢 Dan Hansen、Sheel Pethe、Samuel Mendoza-Jonas、Moein Ghaniyoun、Vidhya Krishnan、Avinash Ahuja、Laikh Tewari、Laura Martinez 和 Matheen Raza 在工程贡献、技术指导、分析以及本文的细致审阅方面所付出的努力。

原始来源: NVIDIA 开发者博客

评论 (0)