Private Cloud Compute 上的 Foundation Models

端侧 Foundation Model 迎来了一个兄弟。iOS 27 为该框架带来了一个运行在 Private Cloud Compute 上的服务器规模模型，拥有 32K 的上下文窗口和推理能力，而您只需改动一行代码就能用上它¹。同样的 LanguageModelSession，同样的 Generable，同样的 Tool 协议⁴。更大的变化藏在底层：Apple 通过一套公开协议向几乎所有 LLM 开放了这个框架，于是端侧模型、云端模型、您随应用一同发布的本地模型、来自 Hugging Face 的开源模型，以及即将到来的 Claude 和 Gemini，都响应同一套 Swift API²。您不再针对某个模型编程，而是针对一个可以随意替换的插槽编程。

本文是构建在框架参考之上的云端与提供方层。如果您还没有接触过 LanguageModelSession、Tool 协议或引导式生成，请先阅读 Foundation Models 框架详解和 iOS 27 工具调用一文，再回到这里。

TL;DR

• Private Cloud Compute 为 Foundation Models 框架引入了一个更大的服务器模型，从端侧模型切换过来只需改动一行。它提供 32K 的上下文窗口（端侧为 4K），支持三个级别的推理，并可在 iOS、macOS、visionOS 和 watchOS 上运行¹²。
• 其隐私姿态与系统模型一致：Apple 在设计 PCC 时确保用户数据从不被存储，仅用于当次请求，并经研究人员独立验证；开发者无需 API 密钥、无需账户配置，也没有令牌成本¹。
• 每位用户都有一个按其 iCloud 账户计算的每日请求上限，可通过 iCloud+ 升级。在 UI 中处理这一上限时，应检查模型的配额状态，并展示一个持久、可操作的控件，而非弹窗。请在开发者网站申请使用权限；面向下载量低于 200 万的应用开放¹。
• 新的 LanguageModel 协议让每个模型都成为可插拔项：系统模型、PCC、用于在 ANE 上运行本地模型的 Core AI、面向 Hugging Face 社区的 MLX，以及即将到来的 Anthropic 与 Google 的提供方包²。
• DynamicProfile 让单个会话可以在对话进行中于这些模型之间切换，于是头脑风暴这一轮可以用高温度的 PCC，而审阅这一轮可以降到端侧模型以节省服务器调用³。

更大的模型，同样的三行代码

去年的卖点是：向端侧模型发起提示只需三行代码——创建会话、调用 respond、读取答案¹。今年这一卖点延伸到了云端。无论您与哪个模型对话，框架都提供统一的 Swift API，因此从端侧的系统模型切换到 PCC 模型，改变的只有您所构造的模型，其余一概不动¹。通过 Generable 实现的结构化输出与工具调用，在两者之间表现完全一致¹。

Louis 在 session 319 中表示：向端侧模型发起提示只需三行代码，而切换到 PCC 服务器模型只是一行改动，换来的是一个上下文更大、具备推理能力的大得多的模型。

用框架自己的术语来说，这次替换的形态如下：

import FoundationModels

// On-device: the System model.
let onDevice = LanguageModelSession(model: SystemLanguageModel.default)

// Cloud: swap the model. Same session API, same prompts, same tools.
let cloud = LanguageModelSession(model: PrivateCloudComputeLanguageModel.default)

let summary = try await cloud.respond(to: "Summarize this 30-page contract.")

这些符号名直接来自会话本身：Apple 将云端模型暴露为 PrivateCloudComputeLanguageModel，会话则通过 SystemLanguageModel 和 PrivateCloudComputeLanguageModel 上的 contextSize 属性读取并展示上下文大小¹。由于云端模型遵循其他所有模型都遵循的同一个 LanguageModel 协议，您代码的其余部分察觉不到任何差异²。

有一条约束从端侧模型沿袭而来，值得严格检查：PCC 仅在支持 Apple Intelligence 的设备上运行。请检查可用性 API，并处理 Apple Intelligence 不可用的情况——就像您已经为端侧模型所做的那样¹。

PCC 能带来什么，又有什么代价

PCC 是 Apple 对端侧模型无法触及的那些用例给出的答案：需要对大量用户输入进行推理的助手，或会触发大量带有大体量输出的工具调用的功能¹。这笔取舍是实打实的，而非凭感觉的，会话以正面对比的方式将其摆了出来。

其中两行承载了大部分决策。从 4K 到 32K 的跃升，正是让”对一份带图片的长文档进行总结”这类功能在云端模型上可行、而在端侧模型上捉襟见肘的关键¹。推理是另一点：普通响应读取提示后直接生成，而推理响应会在作答之前，于转录的一个独立片段中生成额外文本¹。三个级别据此调整思考预算的大小。light 收集少量额外上下文，moderate 推理更深，deep 则可能产出比答案本身还长的推理片段¹。您在会话上调用 respond 时设定这一级别¹。

推理并非免费。推理片段是模型生成的文本，因此会消耗令牌，并计入 32K 的上下文预算¹。会话对此所要求的纪律毫不含糊：在端侧与 PCC 之间做选择、挑选推理级别时，要依据数据而非感觉¹。Apple 正是为此在 Xcode 中推出了一套全新的 Evaluations 框架，因为端侧模型在许多任务上的表现会超出您的预期，而唯一确知的方法就是去测量¹。

隐私姿态才是重头戏

一个处理用户私密输入的服务器模型，通常正是隐私叙事崩塌之处。PCC 的构建方式让它不至如此。Apple 在设计 Private Cloud Compute 时以端到端隐私为念，确保用户数据从不被存储、仅用于当次请求，且这一设计已经研究人员独立验证¹。PCC 早已为 Apple Intelligence 自身的复杂任务提供支撑；如今框架向您的应用开放了同一套基础设施¹。

开发者真正能感受到的是其在运行层面的影响。PCC 与 iCloud 一同集成在操作系统中，因此无需接入任何身份验证、无需轮换 API 密钥，也无需要求用户做账户配置¹。用户只需一台支持 Apple Intelligence 的设备，仅此而已。作为开发者，您没有任何令牌成本；每位用户都有每日上限，用户可通过 iCloud+ 提高它¹。该模型面向下载量低于 200 万的应用开放，您可在开发者网站申请¹。

Session 319 谈到隐私保证：无需账户配置、无需身份验证、无需 API 密钥，开发者也没有令牌成本，每位用户的请求都计入其 iCloud 账户。

更新，2026 年 6 月 8 日：PCC 走出 Apple silicon

就在 WWDC 开幕的同一周，Apple 发布了一篇安全博文，改变了 PCC 的运行位置。PCC 现在扩展到搭载 NVIDIA GPU 的 Google Cloud，用于承载新的 Apple Intelligence 工作负载，”首次将我们业界领先的 PCC 隐私承诺延伸至第三方数据中心”⁵。您所面向的框架没有改变，改变的是它底层的基础设施。

Apple 保持契约一字不差。五项核心要求原封不动：”无状态计算、可强制执行的保证、无特权运行时访问、不可定向，以及可验证的透明度”⁵。改变的是实现方式，Apple 将其命名为”采用 NVIDIA GPU 的 NVIDIA Confidential Computing、采用 TDX 的 Intel CPU，以及 Google 的 Titan 芯片”⁵。Apple 在两个方面将这一基础加固到超出标准机密计算部署的水平，开发者应当留意。其一，Apple 维护着”一份可加密验证、仅可追加的账本，记录属于 PCC 集群的所有 Google Cloud 硬件”；其二，对于可能外泄用户数据的组件，”软件证明根植于来自独立厂商的至少两个相互独立的信任根”⁵。

对隐私姿态而言最关键的一句话关乎控制权。Apple 声明：”Apple 对 PCC 软件保有完全控制权；Apple 设备只会信任经 Apple 加密批准的 PCC 软件”⁵。面向研究人员的验证机制同样得以沿袭：Apple 表示将公开所有二进制文件供公众检查，并通过 Apple Security Bounty 计划提供以研究模式访问实时 PCC 节点的途径⁵。该推进是分阶段的，”在整个夏季预览期内逐步达成完整的一整套保护措施”，因此您面向 PCC 发布的功能，在预览期间继承的是一套不断变化的保证，而非最终形态⁵。

对本文中的代码而言，要点在于：上述隐私主张对 PCC 模型同样成立，无论它是从 Apple silicon 还是从 Google Cloud 作答，因为 Apple 保持着同样的五项要求和同样的设备侧信任门槛。PCC 也是 Apple 在第三方模型无法跟进之处给出的第一方答案，这与同一周里 Apple 对提示注入给出的第一方答案相呼应。

实验室札记：PCC 的保证止步于框架边界

WWDC 实验室直言不讳的一点，值得紧挨着上述扩展拿出来说，因为它划出了营销话术没有划出的那条线。PCC 的各项保证——无状态计算、不可定向和临时存储——并不延伸到您通过框架的语言模型协议接入的第三方模型，例如 Gemini 或 Claude。当您的会话路由到某个提供方包而非系统模型或 PCC 模型时，阅读该提供方的条款、披露由此产生的数据流向（包括在 App Store 的隐私”营养标签”中）就由开发者负责⁶。该协议为您提供了跨模型统一的一套 Swift API，却没有为您提供跨模型统一的一套隐私姿态。那份披露工作落在您身上，而非 Apple 身上。

在不破坏 UI 的前提下处理每日上限

每日上限是云端模型唯一会侵扰用户体验的地方，而会话对如何处理它态度鲜明。请求计入用户的 iCloud 账户，超出上限的请求会抛出一个错误¹。在 UI 中直接把这个原始错误抛给用户是错误的做法，因为该错误无法操作¹。

正确的做法是检查模型上的配额状态，并渲染您自己的控件。会话会检查模型 quotaUsage 上的 isLimitReached，并在超出上限时展示一个按钮，让用户管理或升级其上限¹。其呈现方式由两条规则约束。其一，不要使用弹窗，因为上限状态应当持久存在而非被一关了之；应改为更新您 UI 的状态，例如禁用请求按钮，并在其下方显示一个带升级操作的不显眼标签¹。其二，也要检测临近上限的情形：模型暴露了一个 belowLimit 状态，让您可以提醒已接近上限的用户，由其自行决定哪些请求值得花费¹。

// Sketch following the session's pattern.
let quota = PrivateCloudComputeLanguageModel.default.quotaUsage
if quota.isLimitReached {
    // Persistent label + upgrade button. No alert.
    showUpgradeAffordance()
} else if quota.belowLimit {
    // Optional: warn the user they are nearing the daily limit.
    showNearingLimitNotice()
}

Xcode 帮助您在不消耗真实配额的情况下构建这一切。在 scheme 的 Debug Options 中，”Simulate Apple Foundation Models Availability”设置提供了”Quota Usage Limit Reached”和”Nearing Usage Limit”两项，于是您可以在模拟器中演练这两种 UI 状态¹。

自带 LLM：提供方协议

iOS 27 中更深层的变化在于，Foundation Models 不再是一个单模型框架。Apple 重建了端侧系统模型，又新增了三个第一方选项，随后向其他所有人敞开了大门。PCC 带来了具备推理能力和 32K 上下文的服务器模型。Core AI 在 Apple Neural Engine 上高效运行本地模型。MLX 则通过模型 ID 解锁了 Hugging Face 上 MLX 社区的数千个模型²。而由于这一切都建立在一套全新的公开协议之上，前沿模型提供方可以发布自己的 Swift 包；Apple 点名 Anthropic 和 Google，称它们将通过同一框架把 Claude 和 Gemini 带给 Swift 开发者²。

Christopher Webb 在 session 339 中表示：在系统模型之外，框架新增了 PCC、Core AI 和 MLX，而一套公开协议让 Anthropic、Google 这样的提供方可以用各自的 Swift 包来扩展它。

该协议有两个部分，而这一拆分正是整个设计的精髓。LanguageModel 向框架描述模型：它声明各项能力，并交回一份配置。LanguageModelExecutor 才是实际干活的地方，它有一个接收该配置的初始化器、一个用于在首次请求前加载权重或建立连接的 prewarm，以及一个将生成内容流式回传给会话的 respond²。配置是两者之间的纽带，也是查找键。每个会话持有一个执行器存储；当某个模型产出存储未曾见过的配置时，框架会构建一个执行器并缓存起来，而会话将配置描述为 Hashable，于是带有相同配置的第二个模型会解析到同一个执行器²。正是这种缓存，让一个有状态的集成能够跨多次调用持有 KV 缓存或持久连接，而非重复劳作²。

对模型提供方而言，执行器的职责就是翻译。框架交给它一份转录——一个由带类型的条目组成的序列——执行器则把这些条目映射到自己推理引擎所使用的各种角色上²。Apple 定义了六种条目类型：instructions、prompts、tool calls、tool outputs、responses 和 reasoning²。一个只有 system、user 和 assistant 角色的模型，会把 tool calls 和 reasoning 映射到 assistant；而一个拥有专门 tool 角色的模型则会路由到那里²。每个请求还在两个属性包中携带开发者的意图：ContextOptions 负责进入提示的内容，例如推理级别或响应模式（schema）；GenerationOptions 负责解码循环，例如采样、温度和长度²。在输出方向上，执行器在一个通道上流式发送事件，先以一条元数据更新（模型与请求 ID）和一条用量更新（提示令牌计数）打头，再发送文本增量，从而让开发者无需等到整个流结束就能得知一次请求的成本²。

即便应用开发者从不编写提供方，错误处理这件事对他们也很重要。Foundation Models 提供了 LanguageModelError，覆盖每个模型都会遇到的情况：上下文窗口溢出、速率限制、拒答等等²。提供方在合适时应抛出其中之一，因为任何框架用户都已经知道如何捕获它，而把自定义错误类型留给只有其自身服务才会产生的失败，例如订阅层级或账户状态²。提供方还可以通过自定义响应元数据（每秒令牌数、首字延迟）以及把协议扩展到音频或视频等新模态的自定义片段类型来形成差异化，这一切都流经同一个会话²。云端提供方会收到一条尖锐的凭证提醒：不要把 API 密钥当作纯字符串接收；应提供一个令牌提供器或登录流程，将令牌持久化到 Keychain 中，并通过 App Attest 配合设备证明²。

智能体层面的意涵：在一个会话内路由模型

当您不再以”每个应用一个模型”来思考，转而以”每个任务一个模型”来思考时，提供方协议和 PCC 的价值便兑现了。这正是 DynamicProfile 所赋能的。它让单个 LanguageModelSession 在对话进行中切换模型，为眼前的任务选择最佳配置³。

Erik 和 Oliver 在 session 242 中演示：一款手工艺应用声明了多个充当智能体的 profile——在高温度的 PCC 上头脑风暴、以深度推理做规划、在端侧模型上审阅以节省服务器调用。

会话给出的示例是一款分三个阶段的手工艺应用。头脑风暴需要广博的知识和创造力，因此其 profile 使用 PrivateCloudComputeLanguageModel 并将温度设为 1³。规划需要深度，因此它仍留在 PCC，并将 reasoningLevel 设为 deep³。审阅则是用户工作过程中的日常指导，因此降到 SystemLanguageModel，以省去不必要的服务器调用，这同时也把用户的每日 PCC 配额留给真正需要它的工作³。DynamicProfile 的主体会在每次提示时重新求值，于是随着应用切换模式，会话也切换人格：换帽子，或者换智能体³。

在上下文大小各异的模型之间路由，会强加一种纯端侧框架从未要求过的纪律。从 PCC 的 32K 移到端侧的 4K，可能需要裁剪条目以适配，而会话还点出了一个隐私用途：在转向隐私性更弱的模型时，从既有条目中编辑掉私密信息³。框架的 historyTransform 会在提示前施加一次本地的、非破坏性的变换，于是您可以为某个模型做裁剪，同时不丢失下一轮可能用得上的上下文³。变更是有代价的：向转录追加内容会保留 KV 缓存并使首字延迟最小化，而改写历史（移除条目、更换工具、更新指令）通常会令缓存失效并增加延迟³。去年会话 API 是仅可追加的，以保证那项优化；今年 Apple 拆掉了辅助轮，而要弄清一个模型的缓存行为，唯一的方法就是用 Xcode 中的 Foundation Models Instrument 去测量³。

决策：端侧、PCC，还是您自己的提供方

这三个选项不是一道阶梯。每一个都对应着一种不同形态的问题。

先伸手去拿端侧系统模型。 它免费、可离线工作、没有请求上限，而 iOS 27 的重建让它在遵循指令方面更出色，还新增了图像输入²。它 4K 的上下文才是真正的天花板¹。在假定自己需要更多之前先做评估，因为会话提醒您：它的表现之好会让您惊讶¹。

当任务超出端侧模型的能力且数据敏感时，伸手去拿 Private Cloud Compute。 需要 32K 窗口的长文档、多步推理，或带有大体量输出的大量工具调用¹。PCC 是唯一一个保有 Apple 隐私姿态的云端选项——无密钥、无账户、无令牌成本，代价是一个需要您据以设计的按用户每日上限¹。当您本来打算自建一个服务器模型、却又对隐私审查心生畏惧时，选它。

当您需要一个平台未提供的特定模型时，伸手去拿您自己的提供方。 Core AI 用于您打包并在 ANE 上运行的本地模型，MLX 用于通过 ID 引入的开源模型，或者用一个提供方包（Claude、Gemini）来引入一个前沿模型²。您要承担凭证处理、证明和隐私披露，作为交换，您得到的是一个具名模型，它藏在您应用早已使用的同一个 LanguageModelSession 之后²。会话明确指出，端侧模型和云端模型有着截然不同的隐私特性，而用户理应知道是哪一个在作答²。

当各阶段诉求不同时，在一个会话里把它们混用。 这正是 DynamicProfile 的用武之地：用 PCC 应对繁重的创意或推理回合，用端侧模型应对日常回合，每个 profile 各自携带其模型、温度和推理级别³。

FAQ

我如何从端侧模型切换到 Private Cloud Compute？

改变您传给 LanguageModelSession 的模型。框架在各模型之间提供统一的 Swift API，因此从端侧的系统模型移到 PrivateCloudComputeLanguageModel 是一行改动，您的提示、Generable 输出和工具照常工作¹。PCC 仅在支持 Apple Intelligence 的设备上运行，因此请保留您的可用性检查¹。

Private Cloud Compute 和端侧模型一样私密吗？

Apple 设计 PCC 时确保用户数据从不被存储、仅用于当次请求，且该设计已经研究人员独立验证¹。它与 iCloud 一同集成在操作系统中，因此没有 API 密钥、没有账户配置、也没有需要您管理的身份验证¹。在离线运行和无限请求上，端侧仍然胜出；在上下文大小和推理上，PCC 胜出¹。

PCC 成本如何，每日上限是多少？

作为开发者，您没有任何令牌成本¹。每位用户都有一个按其 iCloud 账户计算的每日请求上限，用户可通过 iCloud+ 升级以获得更高的上限¹。在 UI 中处理这一上限时，请检查模型的配额状态（isLimitReached、belowLimit），并展示一个持久、可操作的升级控件，而非弹窗¹。该模型面向下载量低于 200 万的应用开放，您可在开发者网站申请¹。

“自带 LLM 提供方”究竟意味着什么？

Apple 新增了一套公开的 LanguageModel 协议，于是任何模型都能接入 Foundation Models 框架，并通过与 Apple 自家模型相同的 API 被调用²。在系统模型和 PCC 之外，框架还新增了用于在 ANE 上运行本地模型的 Core AI，以及面向 Hugging Face 社区模型的 MLX，而 Apple 点名 Anthropic 和 Google，称它们将为 Claude 和 Gemini 发布 Swift 包²。提供方需实现 LanguageModel，外加一个 LanguageModelExecutor，由后者把框架的转录翻译成自己的格式，并将生成内容流式回传²。

一个会话能用多个模型吗？

可以。DynamicProfile 让单个 LanguageModelSession 在对话进行中切换模型，为每个任务选择最佳配置³。一个 profile 携带其自身的模型、指令、温度和推理级别，而 profile 主体会在每次提示时重新求值，于是一个会话可以在同一段对话中先用 PCC 头脑风暴、再用端侧模型审阅³。这样做时，请留意各模型之间的上下文大小差距，以及改写历史所带来的 KV 缓存代价³。

完整的 Apple Ecosystem 系列：Foundation Models 框架详解；iOS 27 工具调用控制；智能体式工作流之辨；以及端侧 LLM。中枢页面是 Apple Ecosystem 系列。如需更宏观的”iOS 搭配 AI 智能体”背景，请参阅 iOS 智能体开发指南。