可信执行推理：在 TEE 中运行私有 AI 模型

FreeGuideOnline 最新 2026-06-29

什么是可信执行推理

可信执行推理指在可信执行环境中加载并运行私有 AI 模型，确保推理过程的代码、模型权重、输入数据和输出结果对外部环境（包括操作系统、云管理员和其他租户）完全不可见。它将 AI 推理的完整性、机密性以及数据隐私保护从应用层下沉到硬件层，形成一道对抗特权软件和物理攻击的纵深防线。

在传统推理架构中，模型和数据通常以明文形式存在于内存或存储中，容易遭受以下威胁：

  • 云平台管理员或恶意内部人员窃取模型参数
  • 其他虚拟机通过侧信道或漏洞逃逸读取推理负载
  • 主机操作系统被入侵后直接转储进程内存
  • 传输和存储过程中密钥管理不当导致数据泄露

可信执行环境借助 CPU 硬件级加密和隔离能力，在内存中构建出被称为 Enclave（飞地） 的安全区域，使得即使拥有 root 权限的攻击者也无法读取解密后明文。目前主流的 TEE 实现包括 Intel SGX（已逐步转向 TDX）、AMD SEV-SNP、ARM CCA 以及新兴的 NVIDIA Confidential Computing（通过 H100 GPU 上的机密计算模式）。

可信执行推理的核心价值

防护维度 传统部署痛点 TEE 推理解决方案
模型机密性 模型权重明文落盘或存于内存，可被导出 内存加密，离开 Enclave 的数据均为密文
数据隐私 用户输入可能被记录、分析或转发 输入在 Enclave 内完成推理后立即销毁
计算完整性 推理过程可能被篡改或重放 硬件远程证明验证执行环境与代码一致性
合规性 难满足金融、医疗等领域的处理可审计性要求 可生成加密证明，证明仅使用指定模型处理数据

制定你的可信推理方案

动手搭建一套完整的 TEE 推理系统前，需要从模型格式、运行框架、远程证明和密钥管理四个层面做好设计。下面以最常见的 基于 CPU 的机密推理 为例，介绍典型的架构决策。

选择 TEE 技术与运行环境

当前最成熟的方案是依托 Intel TDX 或 AMD SEV-SNP 的机密虚拟机。与进程级飞地（如 Intel SGX）相比，机密虚拟机支持直接运行未修改的 Linux 操作系统和容器化负载，对模型依赖库的兼容性大幅提升。

推荐技术栈：

  • 机密虚拟机：Ubuntu/TD-SHIM + Kata Containers，或直接使用 Azure confidential VMs、GCP Confidential VM
  • 推理运行时：与普通虚拟机一致，可选择 ONNX Runtime、OpenVINO、TensorFlow Serving 或 PyTorch 直接运行
  • 私密通信：所有进出 Enclave 的网络流量应在 Enclave 内部完成 TLS 终止，避免外部程序截获明文

如果你需要更精细的控制，例如只保护模型推理函数而其他部分可以明文运行，可采用 库 OS 型 或 进程隔离型 TEE（如使用 Gramine 运行原生 PyTorch，或者 Occlum），但要付出的移植和调试成本会显著增加。

模型加密与安全加载

模型文件在存储和传输阶段必须始终保持加密状态，解密密钥仅在 Enclave 建立并完成远程证明后注入。一个典型的安全加载流程如下：

  1. 模型打包与加密
    使用 AES-256-GCM 对模型文件加密，生成密钥 K。

    openssl enc -aes-256-gcm -in model.bin -out model.bin.enc -kfile key.bin

  2. 密钥托管与分发
    K 被安全地存储到密钥管理服务，并配置访问策略，仅允许具备特定 Enclave 测量值（MRENCLAVE 或 MRTD）的环境获取。常用 KMS 包括 HashiCorp Vault（通过自研启动时注入）、Azure Key Vault（与机密 VM 集成）或 AWS KMS（结合 Nitro Enclaves）。

  3. Enclave 启动与证明
    机密虚拟机启动后，执行远程证明流程，获取包含固件哈希、内核测量等信息的硬件证据。该证据被发送至 KMS，KMS 验证证据签名和测量值。

  4. 安全密钥注入与磁盘卸载
    验证通过后，KMS 将 K 通过加密通道发送至 Enclave 内部。解密程序在 Enclave 内存中完成解密，模型明文仅存在于加密内存页中，绝不落盘或交换到非保护区域。

内置远程证明流程

远程证明是可信执行推理中信任建立的关键环节。它允许输入数据方（例如客户端或数据拥有者）验证推理服务确实运行在真实硬件 TEE 上，以及运行的是经过审查的代码和模型。

一个完整的证明交互包含三个角色：

  • 依赖方（Relying Party）：希望验证推理环境的一方，可以是最终用户或 API 网关
  • 证明者（Attester）：运行在 Enclave 内的代理，负责收集证据
  • 验证者（Verifier）：通常是 KMS 或自定义验证服务，负责校验证据并返回令牌

以 Intel TDX 为例，证明流程如下：

  1. Enclave 生成包含 TD 配置、固件哈希和用户指定数据的报价（Quote）
  2. 报价被发送到 Intel® Trust Authority 或自建验证层进行校验
  3. 验证通过后，颁发短生命周期的访问令牌（JWT），令牌中明确声明模型摘要和代码测量值
  4. 用户端每次请求携带该令牌，Enclave 在解密数据前校验令牌有效性

推理请求的安全处理

即使模型在 TEE 内得到保护，客户端发来的推理请求和响应也必须保持端到端机密性：

  • 客户端与 Enclave 之间必须建立 直连安全通道，排除反向代理或负载均衡器进行明文转发
  • 实现方式是让 Enclave 内部运行一个轻量 HTTPS 服务，证书私钥在 Enclave 内生成且永不外泄，公钥通过证明绑定
  • 如果担心 DoS 攻击，可在前端加一层流控网关，但该网关仅转发密文，不解密请求体
  • 请求正文和响应正文在 Enclave 边界内完成加解密，外部仅能看到密文流量和少量元数据

动手实践：基于机密虚拟机的 LLM 推理

本节将以 Azure Confidential VM + ONNX Runtime 为例，展示一个端到端的可信推理搭建步骤。你可以将同样的思路迁移到 GCP Confidential VM 或自建 AMD SEV-SNP 环境。

步骤一：创建机密虚拟机并安装依赖

在 Azure 门户选择 “Confidential VM” 系列，操作系统使用 Ubuntu 22.04 LTS（TDX 兼容版）。创建时开启 Secure Boot 和 vTPM。登录后，安装推理运行时：

sudo apt update
sudo apt install -y python3-pip curl
pip3 install onnxruntime numpy transformers

步骤二：准备并加密一个示例模型

为便于演示，我们使用 Hugging Face 上经过量化的 Whisper tiny 模型并转换为 ONNX 格式：

from transformers import AutoProcessor, AutoModelForSpeechSeq2Seq
import torch

model = AutoModelForSpeechSeq2Seq.from_pretrained("openai/whisper-tiny")
dummy_input = torch.randn(1, 80, 3000)
torch.onnx.export(model, dummy_input, "whisper_tiny.onnx", opset_version=14)

将导出的 ONNX 文件加密：

openssl rand -out model_key.bin 32
openssl enc -aes-256-gcm -in whisper_tiny.onnx -out whisper_tiny.onnx.enc -kfile model_key.bin
echo "key: $(xxd -p model_key.bin)"  # 请妥善保管此密钥，后续用于注入

加密后的文件上传至 VM，但此时我们还在普通环境中，下一步将构建 Enclave 并注入密钥。

步骤三：编写 Enclave 内推理服务

为了最大兼容性，我们直接在机密 VM 内建立一条严格的网络隔离规则，将推理服务绑定到虚拟受信网络命名空间，并确保解密和推理在已验证的受信用户态进程内完成。

简易推理服务 (tee_infer_server.py)：

import onnxruntime as ort
import numpy as np
import ssl, socket, sys, os

# 1. 解密模型：密钥需通过安全注入，这里以环境变量示意（生产环境请使用临时 memfd）
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
with open("whisper_tiny.onnx.enc", "rb") as f:
    nonce = f.read(12)
    ciphertext = f.read()
key = bytes.fromhex(os.environ["MODEL_KEY"])
model_bytes = AESGCM(key).decrypt(nonce, ciphertext, None)

# 2. 从内存加载 ONNX 模型
session = ort.InferenceSession(model_bytes)

# 3. 建立仅监听到 localhost 的 TLS 服务（证书在 Enclave 内生成）
context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain("server.crt", "server.key")
bindsocket = socket.socket()
bindsocket.bind(('127.0.0.1', 8443))
bindsocket.listen(5)

while True:
    newsocket, fromaddr = bindsocket.accept()
    connstream = context.wrap_socket(newsocket, server_side=True)
    data = connstream.recv(4096)
    # 简化的语音特征输入，实际应解析完整的请求体
    input_data = np.frombuffer(data, dtype=np.float32).reshape((1, 80, 3000))
    outputs = session.run(None, {"input": input_data})
    connstream.send(outputs[0].tobytes())
    connstream.close()

步骤四：安全注入密钥并启动服务

上面的环境变量 MODEL_KEY 绝不能明文写入任何脚本或文件中。我们利用机密 VM 的 vTPM 或直接通过元数据服务获取来自 KMS 的密钥。以 Azure 为例：

  1. 在 Azure Key Vault 中存储 model_key，并授权此机密 VM 的托管标识读取权限
  2. 在启动脚本中调用实例元数据服务获取 token，再访问 Key Vault
# 获取访问令牌
token=$(curl -H 'Metadata:true' \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net" \
  | jq -r .access_token)

# 从 Key Vault 读取密钥
model_key=$(curl -H "Authorization: Bearer $token" \
  "https://your-vault-name.vault.azure.net/secrets/model-key?api-version=7.3" \
  | jq -r .value)

# 以环境变量注入给受信进程
export MODEL_KEY="$model_key"
sudo -u trusted_user python3 tee_infer_server.py

trusted_user 是一个专用本地账户，并通过 SELinux/AppArmor 限制其能力，防止密钥被其他进程嗅探。

步骤五：客户端建立安全通道并验证 Enclave

在真实场景中，客户端在发送数据前需要先验证服务确实运行在机密 VM 上。你可以使用 Azure 提供的 AMD SEV-SNP 证明报告 或 Intel TDX 报价进行验证。

简化的验证步骤如下（客户端执行）：

import requests, hashlib

# 1. 请求服务端的证明报告
attestation_url = "http://server_ip/attestation"
report = requests.get(attestation_url).json()
# 2. 验证报告签名、测量值以及是否来自受信平台
#   （生产环境中应调用验证 SDK，如 Azure Attestation SDK）
assert report["platform"] == "sevsnp"
expected_measurement = "你的已知好态测量值"
assert report["measurement"] == expected_measurement

# 3. 验证通过后，向 Enclave 的 HTTPS 端口发送加密请求
response = requests.post("https://server_ip:8443/v1/infer",
                          data=audio_bytes,
                          cert="server_public.crt")
predictions = response.content

性能优化与可观测性

在加密内存中运行推理会带来一定性能开销。根据测试，与原生相比，机密 VM 的 CPU 吞吐下降通常在 5%–10% 之间，内存访问延迟略有增加，但批处理场景可通过增大并发度来弥补。

优化建议：

  • 使用 量化模型（INT8）降低内存占用，缩小需加密的页数量
  • 避免频繁在 Enclave 内外进行上下文切换，将整个推理逻辑封装在单一受信进程内
  • 利用多线程和异步推理并行处理请求，充分利用 vCPU
  • 将日志、监控指标脱敏后输出，或仅输出聚合后的明文指标（如吞吐量），避免泄露输入分布

可观测性约束：传统监控代理无法直接窥视 Enclave 内部状态。可以在受信代码中有意识地把非敏感的统计信息通过安全管道输出到外部收集器，但必须审查每一条输出以防止通过日志泄露隐私。

常见问题与下一步

  • Q: 是否所有 AI 模型都适合机密推理？
    A: 大部分纯 CPU 推理的模型（如 NLP 分类、语音识别、基于 Transformer 的小模型）可直接享用。需要 GPU 加速的大模型目前可以通过 NVIDIA 机密计算（H100）实现，或采用 CPU+ 机密 VM 混合方案，将敏感层放在 CPU TEE 中。
  • Q: 如何进行模型更新而不破坏已建立的信任链？
    A: 采用版本化的测量值策略，每个模型版本对应一组唯一测量值。更新模型时，授权策略允许同一模型 ID 下的新测量值，客户端验证时也会携带目标测量值白名单。
  • Q: 远程证明的时延影响用户体验怎么办？
    A: 可通过令牌缓存复用证明结果。首次请求完成完整证明后，签发短期会话令牌（如 5 分钟有效），后续推理请求仅校验令牌，将验证耗时降至亚毫秒级。

进阶学习路径：

  1. 深入研究 Intel TDX 与 AMD SEV-SNP 硬件设计，理解加密内存和完整性保护机制
  2. 掌握远程证明协议细节（如 IETF RATS 架构），自行搭建验证服务
  3. 探索联邦学习场景，利用 TEE 作为安全聚合的中心节点
  4. 阅读 NVIDIA 机密计算文档，将机密推理扩展到 GPU 加速负载

可信执行推理让“模型即服务”彻底摆脱了对平台方的无条件信任依赖，让私有 AI 真正掌握在数据所有者和模型所有者手中。