从 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：gitlab.com/qemu-projec…
- commit 2：gitlab.com/qemu-projec…
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 创新提供坚实、高效且安全的算力底座。
