跳转至

从 CPU 到 GPU 全链路可信，百度智能云新一代 AI 机密计算实例的探索与落地

Ch01.848 从 CPU 到 GPU 全链路可信，百度智能云新一代 AI 机密计算实例的探索与落地

📊 Level ⭐⭐⭐ | 31.7KB | entities/从-cpu-到-gpu-全链路可信百度智能云新一代-ai-机密计算实例的探索与落地.md

从 Cpu 到 Gpu 全链路可信百度智能云新一代 Ai 机密计算实例的探索与落地

。 点击蓝字，关注我们 ** 从 CPU 到多 GPU，从单点到全链路：百度智能云第 7 代 AI 机密虚拟机正式落地， 让「数据可用不可见」真正成为云上高敏感业务的基础设施。 **

  • 全链路机密计算： CPU TDX + GPU CC + PPCIe 加密链路；
  • 多 GPU 弹性扩展：支持 NVLink / NVSwitch 高速互联；
  • 全资源售卖： DPU 卸载 I/O ， CPU 资源完全交付；
  • 可信验证： TDX + GPU CC 双重远程认证；
  • 开箱即用：预置 环境 + 最新 LTS 驱动 + CUDA。

1. AI ** 机密计算：让上云不再为安全焦虑 ** 企业上云的核心矛盾，正在从 资源获取 转向 信任建立 。当计算与数据迁移至云端，传统基于边界防护的安全模型不再适用，取而代之的是对 数据在使用中是否仍然可控 的根本追问。 在这一背景下，机密计算（ Confidential Computing ）通过在硬件层构建可信执行环境（ TEE ），将 安全边界 从系统外围收敛至计算本身，成为云基础设施演进的关键方向。 英特尔 ® 至强 ® 处理器内置的 TDX （ Trust Domain Extensions ）技术 在云环境中构建了硬件级可信执行环境（ TEE ），通过「可信域」（ Trust Domain ， TD ）实现虚拟机级隔离，配合内存加密（ 英特尔 ® 多密钥全内存加密，英特尔 ® MK-TME ）与远程证明，真正让数据在使用状态下也处于严密保护之中。 百度智能云基于英特尔 ® 至强 ® 处理器内置的 TDX 机密计算能力， 结合远程证明技术，设计并实现了新一代 AI 机密虚拟化架构，让用户可验证、可信任。 更重要的是，在百度智能云第 7 代 AI 机密虚拟机中，这份信任不再局限于 CPU。通过引入 NVIDIA BlueField 的 vDPA（虚拟化数据路径加速）技术，并结合支持机密计算的 GPU 协同，实现 CPU 与 GPU 之间数据传输链路的全程加密保护，实现端到端数据保护，为云上 GPU 业务提供更高等级的数据保护与更强有力的隔离边界。 ** 2. ** ** 第 7 代 AI 机密虚拟机：从单点到全栈的跨越 ** ** 2.1. ** ** 第 6 代的局限：算力与资源的两难 ** 在基于第 6 代虚拟机构建的机密虚拟机方案中，仅支持单块 GPU ，主要适用于 7B / 13B 等小规模大模型的推理场景，难以满足更高算力任务的需求。 同时 ，由于未使用 DPU 进行 I/O 卸载 ，网络与存储 I/O 需要占用服务器侧的 CPU 核心，导致计算与内存资源无法全量交付，影响了客户使用体验。 ** 2.2. ** ** 第 7 代的突破：算力与弹性兼得 ** 如今，基于第 7 代虚拟机 —— 搭载新款英特尔 ® 至强 ® 处理器及 BlueField DPU —— 百度智能云打造了新一代 AI 机密虚拟机，从两个维度实现了全面突破。 在算力层面，引入了 NVIDIA 提出的 Protect PCIe 加密模式，支持将多块 GPU 直通到同一虚拟机，并能通过 NVLink 或 NVSwitch 构建高速互联集群，显著拓展了机密计算在更大规模、更高性能场景下的应用边界。在资源弹性层面，通过将网络和存储 I/O 全面卸载至 DPU，实现了计算与内存资源的完整交付，为客户提供了更优的资源利用与性能体验。 百度智能云推出的第 7 代 AI 机密虚拟机， 面向高端计算与 AI 训练场景的旗舰机型。它集极致算力、超大显存、高速存储与网络于一身，专为大规模、高敏感度的计算任务而生，在释放强大 AI 算力的同时，让数据与应用始终处于可信的保护之中。 第 7 代 AI 机密虚拟机关键能力如下：

  • 全链路机密计算： CPU TDX + GPU CC + PPCIe 加密链路；
  • 多 GPU 弹性扩展：支持 NVLink / NVSwitch 高速互联；
  • 全资源售卖： DPU 卸载 I/O ， CPU 资源完全交付；
  • 可信验证： TDX + GPU CC 双重远程认证；
  • 开箱即用：预置 环境 + 最新 LTS 驱动 + CUDA。

** 3. ** ** 从硬件到链路：构建全栈可信 **

** 3.1. DPU vDPA ** ** ：高性能与弹性调度如何兼得？ **

在基于 DPU 实现「全资源售卖」虚拟机的过程中，我们面临一个关键问题：如何在虚拟机中获得媲美物理设备的性能，同时又不牺牲弹性调度的能力？ ** 3.1.1. ** ** 两种路径的权衡 ** 围绕这一问题，业界通常有两种实现路径：基于 VFIO 的传统直通方案，以及基于 vDPA 的半虚拟化加速方案。 VFIO 方案强调极致性能。它通过将物理设备直通到虚拟机中，使虚拟机几乎以裸金属方式访问硬件，从而获得接近物理机的 I/O 性能，这也是高性能计算场景中的常见选择。 但这种「直接访问」也带来了明显限制：虚拟机与底层硬件形成强绑定，无法进行热迁移。一旦宿主机需要维护或发生故障，业务只能中断，难以实现云环境所需的弹性调度与高可用能力。 因此，我们需要在两者之间取得平衡：既要接近物理机的性能，又要具备热迁移能力。 ** 3.1.2. vDPA ** ** 的答案： 数据路径硬件卸载、控制路径软件管理 ** 基于这一目标，第 7 代虚拟机选择采用 vDPA 方案。 这个问题的本质是：如何既不打破虚拟化的灵活性，又能把性能关键路径交给硬件来做？ vDPA 的答案很直接—— ** 数据路径硬件卸载，控制路径软件管理 ** 。通过将数据转发下沉到智能网卡硬件加速，同时将设备管理与调度保留在虚拟化系统中，vDPA 在性能与弹性之间实现了有效解耦。 ** 3.1.3. ** ** 实现细节： VFE 与智能网卡的协同 ** 在具体实现上， BlueField DPU 通过 vhost-vDPA 与 VFE （ Virtio Full Emulation ）模块（用于在用户态模拟 virtio 设备语义），将底层硬件能力封装为标准的 virtio 接口提供给虚拟机使用。一方面， VFE 通过 vhost-user 与 QEMU 通信；另一方面，通过 VFIO 机制管理设备资源，并结合 vDPA 实现数据路径加速，从而在虚拟机与硬件之间建立起一层解耦结构。 这种解耦设计不仅使数据路径能够充分利用硬件加速，保障高性能，同时也让设备逻辑与迁移状态管理得以独立演进，降低了系统复杂度与运维成本，使整体架构在性能、弹性与可维护性之间实现了更优平衡。 此外，BlueField DPU 的 vDPA 还支持 page-per-vq 与 host-notifier 特性，可将 virtio notify region 直接透传给虚拟机，避免频繁的 VM exit，显著提升 I/O 密集型场景的性能。这一能力为后续支持多 GPU 高吞吐训练任务奠定了网络基础，但也带来了与 TDX、GPU 共存的新挑战。 ** 3.2. ** ** I/O ** ** 可信链路：如何打破私有与共享的矛盾？ ** ** 3.2.1. ** ** 核心矛盾：私有与共享 ** 在 AI 机密虚拟机中，一个绕不开的问题是：机密计算强调「私有」，而 vDPA 高性能 I/O 依赖「共享」，两者看似天然矛盾。 在 TDX 体系下，内存并非物理划分为两块，而是在地址级别被标记为不同属性：一类为仅供虚拟机内部访问的私有内存，另一类为用于与外部设备交互的共享内存。这种机制保证了安全性，但也带来了新的挑战：一旦内存属性标记不正确， 会触发 TDX 的访问校验异常（如 #VE ），导致设备无法正常工作 。 ** 3.2.2. ** ** 误标记的代价： notify region 为何失效 ** 以 vDPA 场景为例，其高性能能力依赖共享内存来完成数据交互。但在默认实现中，部分关键内存区域（如 notify region ）并没有在启动阶段被正确标记为「共享」。 结果是，当虚拟机启动、固件初始化设备时，这些内存会被当作「私有」处理，从而触发安全校验失败，导致设备无法正常工作，甚至影响虚拟机启动。 这类问题的本质，并不在于设备本身，而在于机密计算的安全边界没有正确延伸到 I/O 路径上。 在 TEE-IO 技术出现之前，传统 I/O 设备模型无法感知或适配机密计算环境，因而不具备与 TEE 虚拟机直接协同的能力。在这一阶段，系统必须在机密计算的内存隔离模型与 I/O 虚拟化依赖的共享内存机制之间进行权衡与适配。 随着 I/O 设备侧对机密计算支持能力的持续演进，支持 TEE-IO 的设备模型逐步出现，使 I/O 设备能够与处理器侧机密虚拟机建立安全直通路径，如英特尔的 TDX Connect 技术。 ** 3.2.3. ** ** 固件优化：让共享内存回归共享 ** 针对这一点，百度智能云对 TDVF 固件进行了针对性优化：在系统启动阶段，提前识别并标记设备相关内存区域，确保其具备正确的共享属性。同时，在共享与私有内存之间建立受控的数据处理机制，在保证安全的前提下，实现高效的数据流转。 通过这一系列优化，机密计算环境下的 I/O 通路得以打通 —— 既保证了数据始终处于可控保护之下，又不牺牲高性能 I/O 所需的效率。 ** 3.3. ** ** 多卡 GPU ：如何拓展 AI 算力的可信边界？ ** ** 3.3.1. ** ** 从「用得好」到「用得安全」 ** 在传统 GPU 虚拟化场景中，关注重点通常是资源切分与调度效率，即如何更高效地使用 GPU 算力资源。然而，在机密计算场景下，问题的重点发生了变化：不仅要「用得好」，更要「用得安全」。 虽然 CPU 侧已经通过 TDX 构建了可信执行环境，但在实际 AI 计算过程中，数据并不会停留在 CPU 内部，而是需要频繁在 CPU 与 GPU 之间，以及 GPU 与 GPU 之间进行传输与处理。 ** 3.3.2. ** ** 明文链路的隐患 ** 这意味着，尽管 CPU 侧已经建立了可信执行环境，但一旦数据在传输过程中脱离该边界（例如以明文形式经过 PCIe 总线），原有的安全假设即被打破，形成所谓的「边界泄露」（ boundary leakage ）。 因此，机密计算的有效性，不取决于单一组件的安全能力，而取决于 ** 整个数据路径是否始终处于受控边界之内 ** 。 ** 3.3.3. Protected PCIe ** ** ：为 GPU 通信打造加密隧道 ** 基于这一判断，百度智能云在第 7 代机型中引入 NVIDIA Protected PCIe （ PPCIe ）模式，在 CPU 信任域与 GPU 之间建立基于硬件的链路级加密保护机制，使数据在传输过程中始终处于硬件级加密保护之下。 通过这一方式，系统不仅保障了 GPU 侧的数据处理安全，也封堵了 PCIe 总线层面的潜在窃听风险，从而将机密计算能力从「单点保护」扩展为「全链路保护」。 ** 3.3.4. ** ** 地址空间的冲突：多 GPU 带来的新挑战 ** 在引入多 GPU 以提升算力规模的过程中，系统的 PCI 地址空间分配机制也随之发生变化。 每块高性能 GPU 都需要预留一块较大的地址窗口（即 BAR 空间），用于 CPU 与 GPU 之间的通信。以某款 GPU 为例，单卡预留的 BAR 地址空间就高达 64 GB 。由于低地址空间（通常只有 2-3 GB 可用）无法容纳如此大的连续地址窗口，系统固件会将这类大 BAR 分配到 4 GB 以上的高地址区域。 这带来一个连锁反应：当多块 GPU 共存时，大量高地址空间被 GPU 的 BAR 占据。系统固件在为其他 PCI 设备（如 vDPA 设备的 notify region ）分配资源时，也可能将其分配到 4 GB 以上，以满足地址连续性和对齐要求。 这一变化带来了一个关键影响：传统启动固件（如 SeaBIOS ）运行在 32 位模式下，默认无法直接访问 4 GB 以上的 MMIO 地址。当 notify region 位于 4 GB 以上时，固件必须通过 PCI 配置访问机制（如 CF8/CFC 端口）间接访问，这会触发 VM exit ，使执行流程从虚拟机切换到宿主机侧的 QEMU 进行处理，从而改变了原有的访问路径。 在 page-per-vq 优化模式下， VFE 并未对这一新的访问路径进行完整模拟，导致后端设备无法正确接收到来自虚拟机的通知信号，最终造成设备初始化流程中断，虚拟机启动失败。 ** 3.3.5. ** ** 突破兼容性瓶颈：从问题定位到社区贡献 ** 针对这一问题，百度智能云对内存子区域的查找与处理逻辑进行了优化，使系统能够在复杂地址空间布局下，准确定位对应的 MemoryRegion ，并由其内置的 handler 正确处理访问请求，从而恢复 notify 机制的正常工作。 通过这一优化，系统成功解决了多 GPU 与 vDPA 设备在高地址空间场景下的兼容性问题，保障了虚拟机的正常启动与运行。目前，该修复已提交至 QEMU 社区 （ commit 1 ， commit 2 ） ，为更广泛的虚拟化生态贡献了来自百度智能云的工程实践。

  • commit 1： https://gitlab.com/qemu-project/qemu/-/commit/ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a
  • commit 2： https://gitlab.com/qemu-project/qemu/-/commit/55fa4be6f76a3e1b1caa33a8f0ab4dc217d32e49 ** 4. ** ** 第 7 代 AI 机密虚拟机核心性能评估 ** 安全不意味着牺牲性能，这是第 7 代 AI 机密虚拟机时始终坚持的设计原则。 ** 4.1. ** ** 内存性能：几乎无感 ** 开启 TDX 后，内存带宽与延迟几乎与普通虚拟机持平 —— 全链路测试中细微的波动完全在预期可控范围内。高带宽敏感型业务，不需要为安全买单。 ** 4.2. I/O ** ** 性能：稳定可靠 ** Virtio 磁盘与网卡在引入 TDX 后在绝大多数场景下，性能损失可以忽略不计。整体表现与常规 KVM 机型基本持平。存储与网络敏感的生产场景，同样可以放心部署。 ** 4.3. GPU ** ** 性能：算力无损，带宽因卡而异 ** 以 GEMM 为代表的典型计算任务，在机密环境下的性能达成率高达 99% ，核心算力几乎没有损耗。不过主机到设备（ H2D ）与设备到主机（ D2H ）的数据传输带宽，会因不同 GPU 型号而存在差异。用户可以根据业务对 I/O 带宽的敏感程度，选择最适合的那一款，在安全隔离与传输效率之间找到最佳平衡。 总而言之，从内存到 I/O 再到 GPU 核心计算，安全增强带来的性能开销微乎其微。高敏感、高算力的业务，完全可以放心跑在第七代 AI 机密虚拟机上。 ** 5. ** ** 在约束中构建可信 AI 算力 ** AI 机密虚拟机的演进，本质上是对「可信边界」在复杂计算体系中的一次重构。从 CPU 到 GPU ，从内存语义到 I/O 路径，每一次工程决策，都是在安全约束与性能诉求之间寻找新的平衡点。 百度智能云所构建的，并不仅是一种产品形态，而是一种在 AI 计算时代下， ** 重新定义数据使用方式的基础设施范式 ** 。 第 7 代 AI 机密虚拟机，已在百度智能云正式落地，并面向高敏感数据处理与大模型训练场景开放使用。未来，百度智能云将继续推动机密计算与 AI 算力的深度融合，借助英特尔 ® 至强 ® 6推出的 TDX Connect 技术，让「数据可用不可见」真正成为云上高敏感业务的基础设施，为客户的 AI 创新提供坚实、高效且安全的算力底座。

深度分析

全链路可信的技术架构逻辑

百度智能云第 7 代 AI 机密虚拟机的核心创新在于将机密计算从 CPU 单点扩展到 GPU 全链路。 三层可信架构：

  • CPU 层：Intel TDX 构建硬件级 TEE，通过 Trust Domain（TD）实现虚拟机级隔离，配合 MK-TME 内存加密
  • I/O 层：BlueField DPU vDPA 实现数据路径硬件卸载，同时通过 TDVF 固件优化解决私有/共享内存属性标记问题
  • GPU 层：NVIDIA Protected PCIe（PPCIe）模式建立 CPU 信任域与 GPU 之间的链路级加密

vDPA 方案的技术选型洞察

百度智能云选择 vDPA 而非 VFIO 直通，本质上是在性能与弹性之间取得的平衡。 VFIO 方案虽然能提供接近物理机的 I/O 性能，但与底层硬件强绑定，无法实现热迁移。这对于需要弹性扩缩容的云环境来说是致命缺陷。 vDPA 的核心设计思想是数据路径硬件卸载、控制路径软件管理——既保留了虚拟化的灵活性，又通过硬件加速保证了高性能。这一设计原则在云厂商的存储/网络虚拟化方案中具有普适参考价值。

内存属性标记：机密计算与 Virtio 的兼容性挑战

TDX 体系下，内存按地址属性分为私有内存和共享内存。Virtio 高性能 I/O 依赖共享内存机制，但默认实现中 notify region 并未被正确标记为共享，导致 #VE（Virtualization Exception）异常。 这揭示了机密计算与现有虚拟化生态兼容性的核心矛盾：传统 I/O 设备模型无法感知 TEE 的内存隔离语义，需要固件层主动适配。 百度的解决方案是对 TDVF 固件进行针对性优化，在启动阶段提前识别并标记设备相关内存区域。这种「固件层修复」的思路对于其他希望落地机密计算的云厂商具有借鉴意义。

多 GPU 与 vDPA 的地址空间冲突

多 GPU 场景下，64GB BAR 空间导致地址分配到 4GB 以上，引发 32 位 SeaBIOS 无法直接访问 MMIO 的兼容性问题。 百度对 QEMU 社区的贡献（ffa8a3e3b2e6ff017113b98d500d6a9e05b1560a、55fa4be6f76a3e1b1caa33a8f0ab4dc217d32e49）解决了这一问题的根本原因：对 MemoryRegion 查找和处理逻辑进行优化，使其能正确处理高地址空间的访问请求。 这个案例体现了云厂商在推动开源生态适配机密计算过程中的独特角色——既能发现上游未覆盖的边缘场景，又有动力贡献修复。

性能维度评估

从测试数据看，机密计算的安全增强代价极低：

  • 内存性能：几乎无感
  • I/O 性能：可忽略不计
  • GPU 计算：GEMM 达成率 99% H2D/D2H 带宽因卡而异的特性，说明不同 GPU 型号对 PPCIe 的支持程度不同，用户需根据业务 I/O 模式选型。

实践启示

对云厂商的启示

  1. 机密计算的全链路化是必然趋势：仅保护 CPU 侧是不够的，数据在 CPU-GPU、GPU-GPU 传输过程中的边界泄露同样需要封堵。PPCIe 模式的引入标志着机密计算从「单点 TEE」走向「全链路 TEE」。
  2. vDPA 是云环境机密计算 I/O 的优选方案：兼顾性能与弹性热迁移能力，但需要解决与 TDX 内存模型的兼容性问题。百度 TDVF 固件优化的实践可为参考。
  3. 上游开源生态的深度参与至关重要：百度对 QEMU 社区的贡献案例表明，机密计算的落地不是闭门造车，而是需要主动向上游反馈边缘场景的修复。

对企业用户的启示

  1. 高敏感 AI 负载上云的时机已成熟：第 7 代机密虚拟机在实现全链路可信的同时，保持了 99% 的 GPU 计算效率。安全与性能的矛盾已基本解决。
  2. 多 GPU 训练场景已支持：从第 6 代仅支持单卡扩展到第 7 代支持 NVLink/NVSwitch 高速互联，大规模大模型训练不再受限于机密计算。
  3. 选型时需关注 GPU 型号的 PPCIe 支持程度：H2D/D2H 带宽差异意味着对数据传输带宽敏感的业务需要更仔细的选型评估。

对技术选型的启示

  1. DPU I/O 卸载是实现「全资源售卖」的关键：第 7 代通过 BlueField DPU 卸载网络和存储 I/O，实现了 CPU 资源的完整交付，这是提升客户体验的重要细节。
  2. 开源与闭源的平衡：QEMU 社区贡献表明，在虚拟化基础设施层，开源共建是推动技术生态覆盖边缘场景的最有效途径。

关联阅读

相关实体

→ 原文存档