Apple reveals new AI architecture built around Google Gemini models - infra 架构解读

作者：dodo

原文：https://www.macrumors.com/2026/06/08/apple-reveals-new-ai-architecture/ 补充来源：https://www.macrumors.com/2026/06/09/apples-new-ai-contains-no-gemini/ 发布时间：2026-06-08 解读视角：大模型基础建设架构设计 沉淀时间：2026-06-09 标签：#Apple #AFM #Private-Cloud-Compute #知识蒸馏 #系统编排 #机密计算 #多模型路由

一句话核心

Apple 在 WWDC 2026 披露了第三代 Apple Foundation Models（AFM）的完整架构：以 System Orchestrator 为核心枢纽、五模型分层部署（端侧两档 + 云侧三档）、通过知识蒸馏借用 Gemini 能力却不运行 Gemini 代码，并将私有云延伸至 Nvidia GPU on Google Cloud 并以「模糊机密计算」保障隐私——这是目前消费级 AI 系统中最完整的"隐私原生多模型混合推理"工程样板。

文章背景与问题域

背景

WWDC 2026 发布会前后，苹果高层（Craig Federighi、Amar Subramanya、Mike Rockwell、Sebastien Marineau-Mes）举行了专场技术媒体解读会，首次系统性披露 AFM 第三代家族的架构细节，并澄清了外界对"Apple 直接集成 Gemini"的误解。

问题域

苹果面临多重约束交织的工程难题：

能力 vs. 隐私的根本矛盾：State-of-the-art 大模型（如 Gemini Pro）运行在第三方云上，苹果无法接受用户数据出境到不受控环境。
端侧资源受限 vs. 功能丰富性：iPhone/Mac 芯片性能持续提升，但仍无法运行数百亿参数的模型；需在端侧和云侧合理分工。
研发成本 vs. 竞争追赶：从零训练 frontier 模型代价极高，苹果需要找到借力第三方能力的合规通道。
第三方云依赖 vs. 可验证隐私承诺：扩展到 Google Cloud 上的 Nvidia GPU 后，如何向用户和监管机构证明数据未被访问？

核心架构 / 方案解析

五模型分层部署

端侧（Apple Silicon 本地）
├── AFM Core          — 新一代稠密架构，主力端侧模型
└── AFM Core Advanced — 稀疏架构，原生多模态，支持语音生成/高精度语音识别/视觉理解
                        （无需云请求）

云侧（Private Cloud Compute）
├── AFM Cloud         — 延迟优化，承接需要云算力的 PCC 请求
├── AFM Cloud Image   — 专用图像生成与编辑（含空间重构帧）
└── AFM Cloud Pro     — Agentic 工具调用 + 复杂推理，能力对标 Gemini frontier
                        （运行于扩展的 Nvidia GPU on Google Cloud）

AFM Core 到 AFM Cloud Pro 形成从轻量到旗舰的完整梯队，覆盖延迟敏感到计算密集的全谱请求。

System Orchestrator：隐私架构的核心枢纽

Federighi 明确将 System Orchestrator 定义为"隐私架构的关键"——它并不只是一个路由层，而是承担了以下职责：

用户请求
    │
    ▼
System Orchestrator
    ├── 上下文感知模块
    │     ├── App Toolbox（应用内动作目录）
    │     ├── Spotlight Semantic Index（个人内容向量索引）
    │     └── 屏幕实时上下文（on-screen context）
    │
    ├── 路由决策
    │     ├── 请求复杂度评估
    │     ├── 所需个人上下文量级评估
    │     └── → 选择 端侧模型 / PCC 云模型 / AFM Cloud Pro
    │
    └── 知识检索
          └── World Knowledge Service（Apple 自建，非 Google Search）

Orchestrator 能够依据"当前活跃 App + 用户任务"调整响应策略，实现所谓"真正的系统级智能"。

知识蒸馏：借力 Gemini 而不运行 Gemini

这是整个架构中最具工程巧思的部分：

AFM Core / Core Advanced / Cloud / Cloud Image 四个模型均使用「Gemini frontier 模型输出」作为蒸馏来源进行训练后精炼（refinement）。
运行时：没有任何 Gemini 代码、没有 Gemini 权重、没有 Google 推理基础设施。
Gemini 仅扮演"教师模型"角色，贡献的是训练信号而非运行时依赖。

第三方云扩展与机密计算

AFM Cloud Pro 的运行环境打破了苹果以往"自营服务器"的边界：

硬件：Nvidia 最新 GPU（具体型号未披露）
托管方：Google Cloud
隐私保障技术：Nvidia「Ambiguous Confidential Compute」（模糊机密计算）——GPU 被配置为无法读取 Apple 服务器内容
可验证性：Apple 声称第三方研究人员可随时独立验证，用户数据从不被存储或访问

关键工程决策与权衡

决策点	选择	放弃的方案	理由
引入 Gemini 能力	知识蒸馏（训练时）	运行时调用 Gemini API / 集成 Gemini 权重	保持运行时零第三方依赖，隐私可控；避免用户数据流出
Frontier 推理扩容	Google Cloud + Nvidia GPU + 机密计算	自建 GPU 数据中心	时间窗口和成本约束；Nvidia 最新芯片短期内无法自建
端侧旗舰模型架构	稀疏架构（AFM Core Advanced）	纯稠密架构	稀疏架构在同等参数量下可激活更少计算，适合端侧资源约束
知识基础	自建 World Knowledge Service	接入 Google Search	彻底切断对 Google 数据管道的运行时依赖，知识主权内化
隐私验证	第三方可独立审计（开放验证）	自我声明	应对监管压力和用户信任危机；与 PCC 白皮书策略一致

大模型基建视角专项解读

1. 系统架构与分层设计

AFM 采用「端云协同五模型梯队」而非单一模型，这是对「一模型通吃」思路的有意拒绝。工程上的关键洞察是：不同任务对延迟、隐私、算力的要求差异巨大，用统一模型满足全谱请求会导致严重的效率浪费或体验降级。

稀疏架构在端侧旗舰模型（AFM Core Advanced）的引入尤其值得关注——这意味着苹果在 Apple Silicon 上实现了 MoE（Mixture of Experts）或类似的条件计算，可以支撑"邀请语气生成、富有表现力的语音、本地图像理解"而无需联网，这在以往是不可想象的端侧能力边界。

2. 上下文与状态管理

System Orchestrator 整合了三类异构上下文信号：

持久化个人语义索引（Spotlight Semantic Index）：用户历史文件、邮件、消息的本地向量化，是 RAG 的端侧实现
实时屏幕上下文：无需用户描述当前场景，模型可直接感知
App Toolbox：结构化工具调用目录，支持应用内动作

三者共同构成了一个"零输入上下文补全"的隐私感知 RAG 系统。与业界通行做法（显式检索 + 外部知识库）不同，苹果将向量索引和工具目录全部保留在设备本地，Orchestrator 在路由时同步完成上下文注入。

3. 安全与权限隔离

苹果的隐私架构分为三个层次：

端侧零出境：AFM Core / Core Advanced 的推理在设备内完成，个人数据从不离开设备
PCC 内的加密隔离：云端推理在 Private Cloud Compute 节点执行，苹果员工无法访问请求内容
第三方云的机密计算扩展：AFM Cloud Pro 运行在 Google Cloud Nvidia GPU 上，通过「Ambiguous Confidential Compute」使 GPU 配置为无法读取宿主服务器内容

第三层是技术突破——将「可验证隐私」的概念延伸至非自有硬件上，依赖硬件级机密计算而非软件承诺。

4. 可扩展性设计

AFM Cloud Pro 的出现表明苹果已设计了一个"弹性云端旗舰层"：当任务复杂度超出 PCC 能力上限时，请求可无缝路由到 Google Cloud 的 Nvidia GPU 节点。这个设计天然支持横向扩展——Nvidia GPU 资源池可按需增加，而不需要改变端侧或 PCC 的任何逻辑。

整体上，五模型梯队为苹果保留了独立升级任一层次的灵活性：未来可以换掉某一档模型而不影响其他层。

5. 评测与可观测性

苹果声称 AFM Cloud Pro 质量"类似 Gemini frontier models"。这一表述值得细究：这是对齐了哪个 benchmark？是 MMLU、GPQA 还是内部基准？苹果没有公布详细评测数据，这在工程上是一个需要持续追踪的缺口——没有公开 benchmark 的"类似 frontier"声明缺乏可重复验证性。

工程模式提炼

模式名	文章中的实现	大模型基建启示
蒸馏解耦模式	用 Gemini frontier 输出作为训练信号精炼 AFM，运行时零 Gemini 依赖	能力引入与运行时依赖可以解耦：用 teacher 模型蒸馏获得能力，保留 student 模型独立运行；适合有合规/隐私约束的企业 AI 场景
多档梯队路由模式	五档模型（端侧2+云侧3）+ System Orchestrator 按复杂度动态路由	构建 AI 系统时，按请求复杂度和隐私敏感度划分模型档次，用统一 Orchestrator 路由，避免单一大模型承载全谱请求
本地 RAG + 工具目录模式	Spotlight Semantic Index（本地向量库）+ App Toolbox + 屏幕上下文统一注入 Orchestrator	个人 AI 助手的上下文管理应优先考虑本地向量化存储，避免个人数据上传外部向量数据库；工具目录本地化是隐私保护的关键
硬件级机密计算扩展模式	Apple PCC 逻辑扩展到 Nvidia GPU on Google Cloud，用 Ambiguous Confidential Compute 提供硬件级隔离	当计算需扩展至第三方云时，应首选硬件级机密计算（如 Intel TDX、AMD SEV、Nvidia CC）而非依赖软件承诺；这是"可验证隐私"的工程基础
世界知识内化模式	自建 World Knowledge Service，完全替代 Google Search 作为知识基础	依赖外部搜索引擎作为 AI 系统知识基础会造成数据主权风险；有条件的团队应考虑自建知识检索层，至少为关键查询建立内部 fallback
稀疏架构端侧旗舰模式	AFM Core Advanced 采用稀疏架构支撑端侧多模态，避免稠密大模型的全参数激活开销	端侧旗舰模型应优先考虑稀疏架构（MoE 或条件计算），在参数总量受限时最大化特定任务的激活能力，而非压缩稠密模型
开放可审计隐私模式	声明第三方研究人员可随时独立验证 PCC 及扩展 GPU 节点的隐私保障	隐私声明从"自我背书"升级为"第三方可验证"是建立用户信任的关键工程选择；对应实现包括：代码开源、硬件认证公告、独立安全审计

反常识点梳理

反常识点	常规认知	文章实际做法	背后原因
与 Google 深度合作却不运行 Google 代码	与 Google 合作 = 集成 Gemini API 或权重	仅在训练阶段用 Gemini 输出做蒸馏，运行时零 Gemini 代码	隐私约束要求运行时依赖可控；蒸馏恰好是在训练时转移能力的合规通道
隐私保护反而需要扩展到第三方云	保护隐私 = 不出自营机房	AFM Cloud Pro 运行在 Google Cloud Nvidia GPU 上	旗舰能力所需算力超出现有自营设施；机密计算技术使"第三方硬件上的可信执行"成为可能
Orchestrator 是"隐私"组件而非仅是"路由"组件	Orchestrator = 请求分发器	Orchestrator 是"隐私架构的关键"，负责上下文注入 + 路由决策 + 隐私边界管理	路由决定了数据去哪个执行环境，错误路由会导致原本应本地处理的数据出境

延伸思考

知识蒸馏的法律边界在哪里？ 苹果以"蒸馏输出"而非"使用模型权重"的方式引入 Gemini 能力，从工程上巧妙绕开了"集成第三方 AI"的合规争议。但若 Gemini 输出本身受到版权或使用条款保护，蒸馏产物的知识产权归属仍是模糊地带。这个模式一旦大规模推广，将触发 AI 训练数据来源的新一轮法律博弈。
Ambiguous Confidential Compute 能成为云 AI 的标准隐私基础设施吗？ 苹果是首个将机密计算扩展到第三方 GPU 云并公开承诺可验证的主流厂商。若 Nvidia CC + 主流云厂商的组合被证明足够可靠，这可能成为"隐私原生 AI 云"的标准范式，对 Azure Confidential Computing、AWS Nitro Enclaves 等既有方案形成压力，也为国内企业 AI 的合规部署提供参考路径。
五模型梯队的 Orchestrator 如何实现"无感路由"的低延迟？ 用户感知的响应速度取决于 Orchestrator 的决策延迟。若决策逻辑过重（需要运行 Semantic Index 检索），反而会拖累简单请求的首 token 时间。苹果如何在"上下文丰富度"和"路由决策延迟"之间取得平衡，是值得追踪的后续工程细节——目前公开信息中尚无数据披露。