HyperGPU：赋能通用 GPU 设备，构筑大模型隐私计算算力底座

摘要：导读欢迎蚂蚁集团徐基明博士带来分享。今天的题目是关于机密计算的基础设施技术架构，特别是机密计算赋能大模型 GPU 算力的场景。主要内容包括相关的性能数据以及应用场景介绍。本次分享题目为 HyperGPU 机密计算释放通用 GPU 算力构筑大模型密态算力底座。

导读欢迎蚂蚁集团徐基明博士带来分享。今天的题目是关于机密计算的基础设施技术架构，特别是机密计算赋能大模型 GPU 算力的场景。主要内容包括相关的性能数据以及应用场景介绍。本次分享题目为 HyperGPU 机密计算释放通用 GPU 算力构筑大模型密态算力底座。

主要介绍：

1. 背景介绍

2. HyperGPU 设计

3. HyperGPU 性能

4. 展望与总结

分享嘉宾｜徐基明博士蚂蚁密算科技技术专家

编辑整理｜曹加印

内容校对｜郭慧敏

出品社区｜DataFun

背景介绍

首先和大家介绍一下机密计算的背景。

1. 数据要素流通的业务背景

为了让数据产生更大的价值，有很多工作和场景需求，包括政策上的引导现实问题：数据在实际使用中存在很多数据孤岛以及相关的隐私安全、数据安全问题存在很多典型的攻击案例，包括隐私数据泄露、灰产库等问题蚂蚁和其他友商在这方面做了很多工作，通过不同技术（联邦学习、MPC、TEE 等）为数据流通提供保护机密计算呼之欲出

2. 机密计算呼之欲出

TEE(Trusted Execution Environment)可实现数据"可用而不可见"：

（1）数据加密（密不透风）

REE 中的复杂软件被排除在外，代码量小，漏洞更少在软硬件的加持下，REE 无法读写 TEE 应用的敏感数据TEE 硬件通常对内存进行加密，抵御硬件攻击无损：通过联邦学习分散建模的效果和把数据合在一起建模的效果对比，几乎是无损的。

（2）可验证（清者自清）

TEE 硬件可作为信任根，提供远程证明能力

（3）性能好（行云流水）

TEE 内部的计算都是以明文的方式进行，性能接近数据未保护的场景

3. 大模型场景中 TEE 的作用

大模型推理场景中的参与方在大模型推理场景中，主要有三个参与方：

大模型开发商需要使用收集的语料库数据训练自己的大模型;云服务管理商开发商将大模型寄卖到云服务平台上对外提供服务 ,大模型数据传到云服务器，拉起镜像对外提供推理服务;终端用户接入大模型推理服务 API 接口使用服务,发送 prompt，获得返回数据。

各方数据隐私诉求

模型提供商的诉求保护训练用的语料库（可能包含用户数据、业务数据）。

保护大模型权重文件（知识产权）

终端用户的诉求保护上传的 prompt（可能包含病历数据、财务数据等隐私信息）, 不希望云服务商利用提交的 prompt 训练自己的模型。

管理员可能的攻击可能攻击模型提供商和终端用户的数据,可能在程序中植入后门窃取隐私数据。

GPU 支持的必要性

大模型场景不可能纯 CPU 运行，需要拓展 GPU 支持，在 TEE 中需要支持 GPU 算力，数据流程需要在 TEE 中加密处理，防止管理员植入后门窃取数据。

现状分析

英伟达 H 系列高算力卡基本处于禁售状态，是商业上的制约。

CPU TEE 的信任根问题 使用境外厂商的 CPU 时，必须信任这些厂商提供的可信执行环境;在当前国际环境下，这种信任链存在供应链风险。

国内方案的局限性 不同方案在生态兼容性和落地成本上存在制约。

设备更新成本问题 为了支持 TEE 应用，是否需要更换所有存量设备？数据中心需要投入大量建设成本，完全更换支持 GPU TEE 的设备不太现实。如何让现有存量 GPU 设备在 TEE 技术背景下使用起来是一个关键问题。

HyperGPU 设计

1. 设计目标

通用性：不依赖于较新的硬件特性，让众多 GPU 设备都具备 TEE 能力易用性：不依赖于用户态的修改，只对系统层的软件进行改动，用户零感知普惠性：以较低的成本，将普通算力升级成密态算力可解耦：不与任何的 GPU 厂商绑定，支持通用的平台；信任根可解耦

2. HyperGPU 设计

基于虚拟化的纯软件实现 TEE 架构;在虚拟化 L0 层实现，将 host OS 降级到 L1 层;隐私抽象支持 Enclave 和 CVM 以及基于 CVM 拓展的 GPU TEE 能力; 隐私虚拟机跑在 L2 层，L0 层控制 L2 层数据进出访问，实现隔离效果;L0 层实现对硬件层的加密访问管控。

信任根解耦连通 TPM（蚂蚁自研可信根芯片，兼容国产 TPM 芯片），可信根支持通过政府权威认证,通过虚拟化硬件抽象支持更通用的硬件设备,支持英特尔、AMD 主流平台及海光、兆芯等国产 CPU

3. 安全设计

隔离性设计

抵御高特权级软件攻击系统管理员在 L1 层发起攻击会被 L0 层拦截；恶意 CVM 尝试访问合法 CVM 数据会在认证阶段被拦截数据面隔离恶意 CVM 尝试访问可信硬件部分会被L0层隔离管控；无权限访问核心设备

不考虑的攻击场景（也可抵御）

硬件攻击（如冷启动攻击）可通过内存加密防御；即使比特被攻击者读出，读出的是加密密文链路攻击（如探针攻击）通过端到端加密防御；总线链路上使用探针探出的仍是密文侧信道攻击TEE场景中较难防护，敏感密码操作可通过算法变换、掩码等提升保护能力DoS 攻击

GPU TEE 扩展

GPU 设备与 CPU 通过 PCIE 总线标准连接,内存访问特征和设备权限管控有相似性,CPU TEE 的隔离架构设计可拓展到 GPU。

防范的攻击场景

恶意管理员插拔设备、更换设备加探针、篡改设备配置尝试读写可信 GPU 上的数据内存在总线上传输指令时篡改指令执行恶意 CVM 部署恶意指令恶意设备PCIE 总线上专门用于攻击的显卡篡改过的 FPGA 卡伪装成显卡通过 DMA 访问其他 CVM 上的合法设备内存专门用于窃听的卡直接 dump 数据

隔离性实现

控制面隔离通过页表与 PortIO 管控方式;对 PIO、MMIO、GPU 地址空间进行控制隔离;基于 HyperEnclave，REE 中的恶意进程访问需经过 L0 层。数据面隔离管理设备列表及 DMA 访问;通过 IOMMU 方式管理;控制哪个 CVM 可以直通到 GPU 卡;其他 REE 在 HyperEnclave 管控权限时被拦截。

密码学实现设备可信认证

通用 GPU 设备的挑战通用 GPU 设备不包含任何密码学功能；没有硬件可信根，无法使用基于硬件可信根的设备认证和密钥协商；需要验证设备是否为合法的卡，而非被篡改的卡

攻击场景分类

PCIE 总线攻击（白盒攻击）管理员可能篡改设备、篡改总线、加探针；可能窃听总线上传输的大模型底层运算数据；设计对标 STDM 和 TDS 设备安全标准协议GPU 内部攻击（灰盒攻击）攻击者难以直接窃听显存上的明文数据；可能通过侧信道泄露或 CPU 后门访问数据；攻击成本较高，难以精确到每一个比特

设备认证设计

设备指纹机制根据合法设备运行时产生的物理特性设计可信根，先部署特定显卡型号对应的设备指纹库，在可信环境中部署可信数据库，通过远程认证验证环境未被篡改，实际认证时 CVM 从指纹库请求对应型号指纹，指纹验证逻辑加入密码学扰动和随机抽取，提高安全性，GPU 根据挑战数据和指纹计算响应，加密后返回 CVM 验证，验证后确认设备指纹特征是否匹配预期型号

密钥协商与总线加密

密钥协商确认设备指纹合法后，基于指纹派生用于协商的私钥；基于私钥进行密钥协商协议，形成双方共享的会话密钥；实现总线加密协议设计