Google Cloud于2026年10月21日将Confidential G4（基于NVIDIA RTX PRO 6000 Blackwell GPU）推向正式可用，旨在通过机密计算保护模型权重、提示词与生成结果等“运行中数据”。正式可用覆盖36个可用区，但部署仍受机型、区域、配额与GKE支持限制，性能开销因场景而异，且应用层安全责任仍需由用户承担。
Google Cloud于2026年10月21日宣布，采用NVIDIA RTX PRO 6000 Blackwell Server Edition GPU的Confidential G4正式可用。这项服务将机密计算能力引入G4实例，面向模型推理和AI智能体运行时处理的敏感信息，包括模型权重、用户提示词和生成结果。
根据Google Cloud的正式公告，Confidential G4覆盖36个可用区，可通过Compute Engine虚拟机和Google Kubernetes Engine（GKE）节点使用。但正式可用并不意味着所有G4配置、所有GKE模式都获得相同支持；机型、区域、配额与调度方式仍决定具体部署能否落地。
这次发布的核心，是把隐私保护进一步延伸到GPU实际处理数据的阶段。它并不等于AI应用已经获得完整的安全保证，也不意味着所有相关服务同时进入正式可用。
为什么加密存储和网络还不够
企业部署AI时，敏感数据不仅存在于数据库和网络连接中，也会进入正在执行计算的内存。模型需要读取提示词、加载权重并生成输出，仅保护磁盘上的数据和传输连接，不能完整覆盖这个处理过程。
机密计算试图解决的正是“运行中数据”的保护问题。Google称，Confidential G4结合不可导出的硬件密钥、远程证明和透明内存加密，在硬件强制执行的隔离环境中处理数据与模型参数，降低宿主机管理员、虚拟机管理程序及云服务提供方访问这些内容的风险。
其中，远程证明的作用不只是确认“加密已经开启”，而是让数据持有方在释放敏感信息之前，验证执行环境是否符合预先设定的要求。安全判断因此从对运营方的承诺，部分转向可核验的环境证据。
Google在2026年6月23日的预览公告中解释，G4方案使用第五代AMD EPYC Turin CPU及AMD SEV，并结合NVIDIA GPU的机密计算能力，保护处理中的数据以及CPU与GPU之间传输的数据。此次10月发布的变化，是Confidential G4从预览走向正式可用，而不是首次提出这一架构。
对于需要处理内部工作讨论、客户信息或专有模型的企业，这种机制提供了一条在公共云中缩小数据暴露面的路径。不过，保护效果仍取决于实际配置、证明策略和应用如何使用数据，不能仅凭实例名称推断整个业务链路都已受到保护。
性能代价有多大：两组数字不能混用
加密与隔离会不会明显拖慢推理，是这类服务能否进入日常生产环境的关键问题。
Google在公告中披露，其测试使用g4-standard-48机型，对比Confidential G4和普通G4实例，在Llama 3、Llama 3.3、ResNet-50和SDXL等模型上的推理吞吐量。公司称，按每秒生成的词元数或图像数衡量，吞吐量下降低于3.5%。
这是一项供应商披露的测试结果，而不是独立评测。Google也注明，结果受具体测试条件和配置影响，不同系统设置、硬件选择及软件环境下，实际表现可能不同。因此，不能将“低于3.5%”解释成所有模型、所有推理框架和所有负载都适用的固定开销。
同一公告还引用客户Vertebrae的测试：该公司称，在相同软件和自身工作负载下，使用Confidential G4后，端到端延迟增加5.2%。
两组数字描述的是不同指标。吞吐量反映单位时间内能够处理多少任务，端到端延迟则反映一次请求从开始到完成需要多久。它们不能合并成一个统一的“性能损失”，更不能据此推断加密对所有交互式应用都几乎没有影响。
对企业而言，这些结果支持的是一个有条件的判断：在已披露的工作负载中，机密计算的性能代价可能处于可接受范围。是否适合具体业务，仍需要结合实际模型、并发请求和响应时间要求进行验证。
覆盖36个可用区，不等于部署没有门槛
正式公告强调了全球覆盖范围，但Confidential VM支持配置文档给出了更具体的边界：G4的受支持配置列为g4-standard-48，CPU平台为AMD EPYC Turin，机密计算技术为AMD SEV与NVIDIA Confidential Computing，且不支持实时迁移。
文档还指出，现有普通虚拟机不能直接转换成Confidential VM，需要创建新的实例；NVIDIA机密计算虚拟机也不支持用于多节点工作负载的集群创建。对于依赖既有虚拟机原地升级、实时迁移或多节点扩展的团队，这些限制会影响迁移与可用性设计。
GKE入口同样需要逐项核对。GKE的机密GPU节点文档注明，Autopilot模式目前仅支持搭载NVIDIA H100 80GB GPU的机密节点。因此，不能把“Confidential G4支持GKE节点”进一步写成“G4已在所有GKE运行模式中开放”。
该文档还按配置方法规定了GKE版本、GPU配额、驱动安装和资源供应方式，并明确不支持GPU时间共享或多实例GPU等共享功能。这意味着，企业在评估安全收益的同时，也需要重新检查资源利用率、调度策略和运维方式，而不是仅在现有部署中打开一个开关。
Google表示，模型可使用标准Ubuntu镜像、NVIDIA驱动和CUDA-X库运行，无须修改应用代码。但“无须重构应用”与“无须调整基础设施”并不是同一回事。
Confidential Space的后续支持仍要与本次GA区分
公告同时提到，用于安全多方数据共享的Confidential Space支持将在未来数周进入正式可用。这是后续时间安排，不是10月21日已经完成的里程碑。
按照Confidential Space官方概述，其设计目标是让不同数据持有方将敏感资源交给共同认可的工作负载处理，同时限制环境运营方访问处理中的数据。它结合容器化工作负载、加固操作系统、机密虚拟机及证明服务，让资源只向获得授权的工作负载释放。
这种模式适合解释多方合作的信任问题：参与方不仅要知道数据交给了谁，还需要知道哪些代码能够使用它。相比之下，本次已经正式可用的Confidential G4，首先提供的是GPU计算环境层面的保护基础。两者相关，但不能把后续支持计划当成本次已经交付的全部能力。
硬件隔离之后，应用安全责任仍然存在
Confidential G4所回答的问题，是如何减少计算过程中敏感数据被执行环境之外的主体读取的风险。它并不直接判断智能体是否获得了过大的业务权限，也不会自动保证一次工具调用或生成结果符合企业政策。
这一区别对AI智能体尤其重要：一个经过证明、受到隔离的运行环境，仍可能执行应用本身允许的错误操作。因此，身份权限、工具授权、数据出口控制以及必要的人工审批，仍需要在应用层设计。
此次正式可用的意义，在于企业部署GPU推理时，多了一种将执行环境纳入隐私保护与验证范围的选择。其价值不应被简化为“开启加密即可安全运行AI”：真正需要评估的，是硬件隔离能覆盖哪些威胁、部署限制会改变哪些架构，以及在自身负载下，性能代价是否值得承担。