Apple 把 Private Cloud Compute 扩到 Google Cloud：机密 AI 基础设施开始跨云

预计阅读时间：8 分钟

Apple 首次选择在自有数据中心之外运行 Private Cloud Compute，而这次合作方是 Google Cloud。这个变化值得关注，不是因为“又多了一个云供应商”，而是因为它把 Apple 对隐私计算的要求带到了第三方云环境：NVIDIA Blackwell GPU、Intel TDX、Google Titan 芯片、独立的 append-only 硬件账本，以及双供应商 attestation root，都进入了同一个信任链条。

这不是普通的 GPU 扩容

Private Cloud Compute 的核心问题不是“有没有算力”，而是“用户请求进入云端之后，谁能证明这台机器、这段代码、这条供应链没有被替换”。

这次 Apple 使用 Google Cloud，摘要里点出的硬件组合很关键：

NVIDIA Blackwell GPU：承载 AI 推理或相关加速负载。
Intel TDX：提供 CPU 侧的可信执行环境能力，用来隔离虚拟机级别的运行时。
Google Titan 芯片：Google 自家的硬件信任根，用于平台身份与启动链路验证。

这说明 Apple 并不是简单租用一批 GPU 实例，而是在第三方云上继续要求可验证的硬件身份、启动状态和隔离边界。对做 AI 后端的团队来说，这个方向很清楚：未来“高性能推理”会越来越多地和“可验证执行环境”绑在一起交付。

Append-only 硬件账本意味着什么

摘要提到 Apple 维护一个独立的 append-only hardware ledger。append-only 的意思是账本只能追加记录，不能静默改写历史。它的工程价值在于：

每台可用硬件都需要被登记。
后续审计可以检查硬件记录是否被插入、删除或篡改。
客户端或验证服务可以拒绝不在账本中的机器。

这类设计不只是合规话术。它改变了信任模型：云厂商提供硬件和运行环境，但硬件是否被 Apple 的隐私计算系统接受，需要通过独立账本和证明链路判断。

双供应商 attestation root：把信任拆开

另一个重要细节是 dual-vendor attestation roots。可以理解为，证明链条不能只依赖单一厂商的根证书或根信任。Apple 和 Google Cloud 的组合里，硬件平台、云环境、PCC 运行要求分别来自不同控制面。

这样做的好处是降低单点信任风险：如果某一方的证明链条无法满足策略，系统可以拒绝承载敏感请求。代价也很直接：验证逻辑更复杂，证书轮换、根信任管理、审计记录都必须工程化处理。

摘要也明确说 AWS 和 Azure 不在这次合作中。也就是说，这不是一个通用多云发布，而是 Apple 针对 Google Cloud 做的一次特定扩展。

可以这样实践：给机密 AI 节点加一个准入检查

下面是一个可复制运行的最小示例，用来模拟“硬件账本 + 双 attestation root + 节点准入”的思路。它不是 Apple 或 Google Cloud 的真实接口，只是把摘要中的架构思想变成团队可以改造的 CI/CD 或 admission gate 原型。

运行前只需要本机有 bash 和 jq。如果没有 jq，可先安装：macOS 用 brew install jq，Debian/Ubuntu 用 sudo apt-get install jq。

cat > ledger.json <<'JSON'
{
  "allowed_hardware": [
    {
      "hardware_id": "pcc-gcp-node-001",
      "gpu": "NVIDIA Blackwell",
      "tee": "Intel TDX",
      "platform_root": "Google Titan",
      "status": "active"
    }
  ],
  "trusted_roots": {
    "apple": "apple-pcc-root-v1",
    "google": "google-titan-root-v1"
  }
}
JSON

cat > attestation.json <<'JSON'
{
  "hardware_id": "pcc-gcp-node-001",
  "measurements": {
    "gpu": "NVIDIA Blackwell",
    "tee": "Intel TDX",
    "platform_root": "Google Titan"
  },
  "roots": {
    "apple": "apple-pcc-root-v1",
    "google": "google-titan-root-v1"
  }
}
JSON

hardware_id=$(jq -r '.hardware_id' attestation.json)
ledger_match=$(jq --arg id "$hardware_id" '
  .allowed_hardware[]
  | select(.hardware_id == $id and .status == "active")
' ledger.json)

apple_root_ok=$(jq -r '.trusted_roots.apple' ledger.json)$(jq -r '.roots.apple' attestation.json)
google_root_ok=$(jq -r '.trusted_roots.google' ledger.json)$(jq -r '.roots.google' attestation.json)

if [ -z "$ledger_match" ]; then
  echo "DENY: hardware is not in the append-only ledger"
  exit 1
fi

if [ "$(jq -r '.trusted_roots.apple' ledger.json)" != "$(jq -r '.roots.apple' attestation.json)" ]; then
  echo "DENY: Apple attestation root mismatch"
  exit 1
fi

if [ "$(jq -r '.trusted_roots.google' ledger.json)" != "$(jq -r '.roots.google' attestation.json)" ]; then
  echo "DENY: Google attestation root mismatch"
  exit 1
fi

echo "ALLOW: node passed ledger and dual-root attestation checks"

你可以把这个模式改造成 Kubernetes admission webhook、CI 发布门禁，或模型推理服务启动前的自检。真实生产环境还需要验证签名、证书链、测量值、时间戳、撤销列表和日志完整性，不能只比较 JSON 字段。

采用建议：别只盯 GPU 型号

这次合作给工程团队的启发是：AI 基础设施采购和架构评审不能只看 GPU 性能、区域覆盖和价格。处理敏感数据时，还要把这些问题写进验收清单：

运行节点是否有可验证的硬件身份？
TEE attestation 是否能接入现有发布流程？
硬件清单是否 append-only，并且可审计？
是否依赖单一厂商信任根？
证明失败时，请求是降级、排队，还是直接拒绝？

Apple 把 PCC 扩到 Google Cloud，不代表所有工作负载都应该马上跨云。它更像一个信号：当 AI 推理进入隐私敏感场景，云基础设施必须同时交付算力、隔离和可验证性。缺少其中任何一项，系统都不该被称为真正的机密 AI 平台。