机密推理是否等于给磁盘和 HTTPS 加密？

不是。磁盘加密保护静态数据，TLS 保护传输中的数据；机密推理关注数据正在 CPU 和 GPU 中处理时的隔离，并使用远程证明确认运行环境满足策略后再释放解密密钥。

只验证 GPU 证明就能确认整套 LLM 服务可信吗？

不能。GPU 证明主要描述 GPU 硬件、固件和安全模式，还应组合 CPU TEE、虚拟机或容器镜像度量、启动参数和应用版本，形成端到端证明策略。

机密计算会不会完全消除 Prompt 泄露风险？

不会。它缩小基础设施层的信任边界，但无法替代身份鉴权、最小权限、日志脱敏、输出控制、应用代码审计和密钥生命周期管理。

证明服务不可用时能否继续提供推理？

取决于风险等级。高敏感业务通常只允许在现有短期租约未过期时继续服务，并禁止新实例获取密钥；租约过期后应停止接收新请求。直接绕过证明属于 Fail Open，不适合作为默认降级策略。

LLM 机密推理生产实战：用 GPU 远程证明、按证明放行密钥与证据链保护敏感数据

为什么普通加密仍留下”使用中数据”空档

企业部署 LLM 时，通常已经启用对象存储加密、磁盘加密和 TLS。它们分别保护静态数据与传输中的数据，但推理服务真正执行时，模型权重、Prompt、系统提示词、工具凭证和 KV Cache 等中间状态仍要进入 CPU 或 GPU 可计算的内存空间——这些正是”使用中数据”（data in use）。

如果威胁模型包含云平台管理员、宿主机 Root、被攻陷的 Hypervisor、恶意运维组件或错误配置的调试工具，仅依赖存储和网络加密并不能回答一个关键问题：谁能在推理运行期间读取明文？

机密推理的目标不是让系统”绝对安全”，而是把信任边界从整台宿主机和云平台缩小到经过度量的可信执行环境（TEE），并让密钥系统只向通过证明的工作负载释放解密能力。

核心原理：证明通过之前，模型和 Prompt 都不应变成明文

机密推理的工程核心只有一句话：在硬件证明通过之前，模型权重、Prompt 和中间态都不应以明文形式存在于可被宿主机访问的内存中。

可信执行环境覆盖 CPU、GPU 与数据通路

生产级 LLM 推理不能只看 GPU。完整路径通常包括：

CPU 侧的机密虚拟机或可信执行环境，例如 Intel TDX 或 AMD SEV-SNP；
支持 Confidential Computing 模式的 GPU；
CPU 与 GPU 之间受保护的数据通路；
经过度量的 Guest OS、驱动、容器镜像和推理服务；
独立的证明验证器（Attestation Verifier）与密钥管理系统（KMS）。

这里最容易被忽略的是：GPU 证明并不天然等于应用证明。它可以证明 GPU 身份、固件和安全状态，但不能单独证明当前运行的是哪一个推理镜像、哪一版启动参数或哪一套业务代码。因此，生产方案应使用组合证明，将 CPU TEE、GPU、安全模式和工作负载制品绑定在同一策略中。

远程证明必须具备新鲜度

远程证明不是启动日志，也不是一张永久有效的”安全证书”。验证器至少要检查：

证据签名链是否合法；
硬件、VBIOS、固件、驱动和安全模式是否在允许清单中；
证据中的度量值是否匹配批准的运行环境；
是否绑定本次挑战的随机数 nonce，防止重放旧证明；
证明生成时间是否在允许窗口内；
调试模式、降级模式或异常状态是否被明确拒绝。

NVIDIA 的证明体系包含远程证明、参考完整性清单（RIM）和证书状态相关服务。工程上不应只验证”签名正确”，还要把证明中的 claims 转换为可审计的策略判定。

按证明释放密钥，而不是启动后直接挂载密钥

最关键的工程边界是：证明系统负责判断，密钥系统负责执行拒绝。

模型权重和敏感配置应以数据密钥（DEK）加密保存。推理实例启动后先生成证明，只有验证器判定通过，KMS 或 Key Broker 才返回被当前 TEE 会话公钥封装的密钥材料。宿主机、网关和普通 Sidecar 即使截获响应，也不应获得可直接使用的明文密钥。

AWS Nitro Enclaves 的文档给出了同类模式：外部 KMS 可以根据证明文档中的度量值决定是否允许特定密码学操作。GPU 机密推理可以采用相同原则，但需要进一步组合 CPU 与 GPU 证明。

一条可落地的启动状态机

建议把机密推理 Worker 的启动过程拆成明确状态，而不是在启动脚本中零散执行命令：

PROVISIONED → PLATFORM_ATTESTING → WORKLOAD_ATTESTING → POLICY_VERIFIED
→ KEY_RELEASED → MODEL_DECRYPTING → READY

任何一步失败都进入 QUARANTINED，不得进入服务发现和负载均衡池。特别要避免”证明服务暂时不可用，因此先启动模型”的 Fail Open 设计。

下面是一个简化的控制逻辑，表达的是架构原则而非特定厂商 SDK：

async def bootstrap_worker() -> None:
    nonce = verifier.issue_nonce()
    platform_evidence = collect_cpu_and_gpu_evidence(nonce=nonce)
    workload_evidence = collect_workload_measurement(
        image_digest=read_running_image_digest(),
        config_digest=hash_runtime_config(),
        nonce=nonce,
    )
    verdict = await verifier.verify(
        platform=platform_evidence,
        workload=workload_evidence,
    )
    if not verdict.allowed:
        quarantine_worker(reason=verdict.reason)
        raise RuntimeError("attestation policy denied")

    wrapped_key = await key_broker.release(
        policy_token=verdict.short_lived_token,
        recipient_public_key=tee_session_public_key(),
    )
    model_key = unwrap_inside_trusted_boundary(wrapped_key)
    load_encrypted_model(key=model_key)
    zeroize(model_key)
    register_worker_as_ready()

证明策略要版本化，而不是写死在代码里

证明策略应当像模型发布配置一样进入版本管理、审批和回滚流程。可以维护一份供应商无关的策略模型，再由适配层转换成 NRAS、KMS 或 Key Broker 的具体条件：

policyVersion: 3
workload:
  imageDigest: "sha256:approved-image-digest"
  configDigest: "sha256:approved-config-digest"
platform:
  cpuTee:
    allowed: ["intel-tdx", "amd-sev-snp"]
  gpu:
    confidentialModeRequired: true
    allowedArchitectures: ["hopper", "blackwell"]
    compatibilityProfile: "secure-ai-matrix-2026-07"
attestation:
  requireNonce: true
  maxEvidenceAgeSeconds: 300
  denyDebugMode: true
keyRelease:
  keyAlias: "llm-production/model-dek"
  leaseSeconds: 900
  renewalRequiresFreshEvidence: true

生产中不建议只允许某个宽泛的驱动主版本。硬件、VBIOS、固件、CUDA 和驱动存在组合兼容关系，应该把经过测试的组合固化成 compatibility profile，并为升级建立灰度验证。

密钥生命周期：短租约、可撤销、可轮换

按证明释放密钥并不意味着可以发放长期密钥。更稳妥的设计包括：

模型数据密钥只在可信边界内解封；
使用短期租约（lease）或短期会话令牌；
续租时重新验证新鲜证明；
Worker 被摘流、重启、证明状态变化或进入维护模式时立即停止续租；
密钥轮换时允许新旧密文在短窗口并存，但不得把旧密钥永久留在节点；
对解封失败、证明过期和策略不匹配分别记录原因码。

密钥服务必须成为最终控制点。即使编排系统误把未证明的实例加入集群，没有密钥也无法加载模型或解密敏感请求。

请求链路：不要在可信边界外提前解密

一种常见错误是：网关先解密 Prompt，再把明文发给机密推理 Worker。这样虽然 GPU 端受保护，但网关仍成为高价值明文集中点。

更严格的链路可以采用以下方式：

客户端或受控入口获取已证明实例的临时公钥；
Prompt 使用会话密钥加密；
会话密钥只封装给通过证明的可信工作负载；
Worker 在可信边界内解密并执行推理；
响应在离开可信边界前重新加密；
网关只处理密文路由、限流和计费元数据。

是否需要做到端到端密文取决于威胁模型。若网关本身属于可信边界，可以适当简化；但设计文档必须明确哪些组件能够看到明文，不能用”全链路加密”代替清晰的数据流说明。

证据链与可观测性

机密模式通常会限制部分传统调试和性能分析能力。NVIDIA Secure AI Operations Guide 明确列出若干功能支持边界，并提示某些开发工具在 CC 模式下受到限制。因此，上线前要重新设计可观测性，而不是直接复制普通 GPU 集群的方案。

建议记录以下非敏感证据字段：

类别	字段示例
策略	attestation policy version
平台	CPU TEE 类型和验证结果、GPU 设备身份摘要、固件与安全模式判定
工作负载	workload image/config digest
判定	verifier verdict、reason code 和证据时间
密钥	key lease ID、发放时间、续租次数和吊销原因
性能	Worker 从启动到 Ready 各阶段耗时
对比	机密模式与普通模式的 TTFT、TPOT、吞吐和失败率

⚠️ 不要把完整证明、密钥响应、Prompt 或模型路径直接写入通用日志。证明文档也可能包含可用于基础设施识别的字段，应按安全日志处理。

性能与兼容边界必须单独压测

机密计算不是一个无成本开关。部分 CUDA 特性、调试工具、GPUDirect RDMA、MPS 或 MIG 可能在特定 Secure AI 模式中不受支持，且支持能力与 GPU 架构、CPU TEE、驱动、固件和运行模式高度相关。

因此至少需要建立两组基线：

基线类型	关键指标
安全基线	证明成功率、密钥释放延迟、证据续期、吊销生效时间
性能基线	模型加载时间、TTFT、TPOT、吞吐、CPU 使用率、Host–Device 传输和多 GPU 通信

不要把普通模式的容量数据直接用于机密模式。尤其是多 GPU、RDMA 和复杂拓扑场景，必须以官方兼容矩阵和本地实测为准。

适用场景

机密推理更适合以下工作负载：

金融、医疗、保险等需要处理受监管数据的推理；
企业源代码、合同、研发资料等高价值 Prompt；
第三方云上运行但不希望基础设施运营方读取的模型权重；
多方数据协作，需要证明数据只交给批准工作负载的场景；
私有模型授权，希望把模型解密能力绑定到指定硬件和软件状态的场景。

对于公开模型、公开数据、低敏感度批处理，机密计算带来的部署复杂度和性能成本可能不划算。应先由数据分类和威胁模型决定，而不是把所有推理统一迁移到 CC 模式。

常见误区

误区一：启用 Confidential Mode 就完成了安全建设

机密计算只解决特定基础设施威胁，仍需要鉴权、租户隔离、最小权限、应用漏洞治理、内容安全和日志脱敏。

误区二：证明通过一次，实例可以永久可信

固件、驱动、运行状态和工作负载都可能变化。长时间运行的 Worker 应采用短期证明租约或周期性重新证明，并在证据失效时停止接收新请求。

误区三：验证签名就足够

签名只说明证据来自某个可信签发链。策略还要检查版本、度量、模式、时间、新鲜 nonce 和吊销状态。

误区四：密钥可以由启动脚本保存在环境变量里

环境变量、挂载文件和普通 Secret Sidecar 往往扩大明文暴露面。关键模型密钥应在证明通过后释放，并只在可信边界内解封和短暂使用。

误区五：普通 GPU 优化可原样迁移

机密模式下部分 CUDA、P2P、调试与共享能力可能不同。每一项性能优化都要重新验证功能、错误行为和降级路径。