Apple 官方文档列出的上下文容量是：设备端 SystemLanguageModel 为 4K tokens，Private Cloud Compute 为 32K tokens；这说明云端模型能处理更长上下文，但不能据此推断它适合所有请求。Apple 的 PCC 接入文档也明确指出，PCC 需要网络连接，而设备端模型可在无网时工作。
本周建议动作：先把产品需求按离线能力、数据敏感度和自定义程度分流；需要 Apple 云端能力时评估 Private Cloud Compute，需要自选模型或服务端工具时再评估符合协议的提供方。不要因为调用接口统一，就假定数据处理、可用性和输出质量也相同；上线前应分别验证真实请求与失败回退。
谁该看这篇：正在为 iOS App 加入文本生成或智能功能的独立开发者，可据此确定先验证本地模型还是云端方案。
负责隐私说明与数据处理的人，可用本文盘点输入数据和服务端责任。
维护构建发布环境的小团队，可据此规划 Xcode、macOS 和项目验收要求。
最后更新于 2026 年 10 月 25 日，核对自 Apple Foundation Models 文档、WWDC26 框架资料与 Xcode 系统要求。
Foundation Models framework 模型选择：先按产品边界分流
Foundation Models framework 是应用访问模型的接口层，不是一个会让所有模型呈现相同行为的单一模型。Apple 官方文档将设备端模型和 Private Cloud Compute 列为 Apple 提供的能力；WWDC26 资料则介绍了通过 LanguageModel 协议接入自选模型的方式。模型实现不同，联网依赖、数据去向、模型可用性和输出特征也会不同。Foundation Models 官方文档
| 路径 | 适合优先评估的需求 | 决策前必须确认 |
|---|---|---|
设备端 SystemLanguageModel |
无网也要工作，且任务可在设备端模型能力范围内完成 | 用户设备、地区及系统是否支持；模型是否已就绪；实际输出是否满足产品质量要求 |
PrivateCloudComputeLanguageModel |
需要 Apple 提供的云端模型能力，且接受网络依赖 | PCC 的系统与资格要求、可用状态及每日使用限额；无网或服务失败时的界面与替代路径 |
| 自选模型提供方 | 需要指定模型、额外定制能力或提供方侧工具 | 输入数据送往哪里、认证与密钥如何管理、费用和限流规则、服务错误如何处理 |
| 应用自己的服务端 | 需要自行编排模型、工具、业务权限或数据处理流程 | 应用服务端与模型服务端的责任边界、日志留存、密钥保护及持续运维成本 |
可执行的初步判断：离线是硬性要求，先验证设备端；希望调用 Apple 的服务器模型能力，验证 PCC；必须指定模型或执行自有服务端工具，再评估自选提供方或应用服务端。若一个功能同时有轻量、可离线的请求和复杂请求，可以把两种路径作为候选，但必须在应用逻辑中明确路由与回退条件，不能把统一调用形式当成自动切换保证。
隐私边界取决于请求实际经过哪里
设备端处理与云端处理不是同一种数据路径。对设备端模型，应确认功能在目标设备上可用，并明确哪些内容只在本机处理；对 PCC，Apple 的安全说明描述了请求处理与隐私保护设计。这些说明只适用于 PCC，不应扩写成所有云模型都遵循相同处理规则。Apple 的 Private Cloud Compute 安全说明
接入自选提供方时，开发团队仍须逐项阅读该提供方正式的隐私说明、数据保留规则和服务条款，确认提示词、用户输入、工具结果及故障日志分别会送到哪里。若 App 先把请求发往自己的服务端，再由服务端调用模型，用户数据可能经过两层服务：应用团队要分别处理自己的日志与存储责任，以及模型提供方的处理责任。不能只因为模型封装在 Foundation Models framework 的调用流程里，就省略这些披露。
密钥也属于架构边界。WWDC26 的提供方接入资料专门讲到服务器模型认证；面向生产环境时，应避免把长期有效的服务端密钥直接放进 App 包。若请求必须经过自有后端，后端就需要承担认证、权限校验、密钥轮换和异常请求处理，而不是把这些工作交给框架自动完成。WWDC26 自选 LLM 提供方接入说明
联网依赖决定弱网和无网时的用户体验
设备端模型可在没有网络连接时工作，但它仍可能因设备资格、Apple Intelligence 设置或模型尚未就绪而不可用。Apple 的 SystemLanguageModel 文档提供了可用状态检查；开发者应根据实际状态隐藏入口、提示用户或采用产品定义的备用功能，而不是仅凭系统版本推断模型已可调用。SystemLanguageModel 状态说明
PCC 是服务器模型，需要网络连接。Apple 文档建议在网络不可用导致请求失败时，考虑改用设备端模型；这是应用需要实现和验证的回退，而不是网络层会替应用自动完成的保证。还要让用户知道请求正在连接、已取消、遇到错误，还是切换到了不同能力的模型。
若使用第三方模型，在线服务的状态、限流和收费方式取决于具体提供方。Apple 的 WWDC26 说明指出，使用第三方模型时通常会按 token 计费；上线前应从该提供方的正式文档核实当前价格、配额和失败响应，再在自己的服务端预算和界面逻辑中落实，不能把 PCC 的使用规则套用到第三方服务。WWDC26 Foundation Models 框架更新
iOS App 应该选本地模型还是云端模型？
可用这组条件先缩小范围：
- 如果断网时核心功能仍必须完成，优先测试设备端模型，并准备模型不可用时的非生成式替代体验。
- 如果请求需要更长上下文或复杂推理，可评估 PCC；先验证地区、设备、系统、资格与网络条件。
- 如果产品必须指定模型、调用自有工具或深度控制服务端行为，评估自选提供方，并把认证、费用、数据处理和运维纳入决策。
- 如果输入包含敏感内容，先确定哪些字段必须保留在设备端；无法明确请求会经过哪些服务时，不应先以“隐私友好”作为产品承诺。
自选模型接入时，控制权与维护责任会一起增加
Foundation Models framework 能否接入自选大模型，取决于提供方是否按官方协议实现模型能力。Apple 的 WWDC26 资料介绍了 LanguageModel 与 LanguageModelExecutor 等协议角色，以及模型包、认证、会话状态和自定义输入输出的处理方式；这意味着它不是仅在配置中填入一个模型名称，开发团队还需要核验提供方包的目标平台、能力声明和实际行为。
统一接口可以减少上层业务代码对具体模型的直接耦合，但不会自动统一下列差异：模型可接受的输入、工具调用方式、认证与配额、流式响应行为、服务错误、费用以及内容边界。越需要控制模型选择和服务端工具，越要预留提供方升级、认证故障排查和兼容性验证的维护时间。若产品需求只涉及简单的文本整理，而系统模型已能满足要求，自定义接入可能换来不必要的服务端负担。
发布验收要覆盖输出质量、故障和数据说明
调用成功只说明请求得到响应，不代表功能符合产品要求。模型输出质量、内容安全、延迟和服务错误应分别验收；结果也只能代表实际测试过的系统版本、模型实现、提示词和项目场景。Apple 的 Foundation Models 更新资料提醒开发者，系统模型变化后应重新测试提示词与应用行为，因此升级系统或模型实现时不能只依赖旧版本的验收记录。Foundation Models 更新说明
在提交版本之前，逐项完成这份可勾选清单：
- [ ] 画出数据流：标明用户输入、上下文、工具结果和诊断日志分别经过设备、PCC、应用服务端或第三方服务的哪些环节。
- [ ] 核对可用性：在目标设备与系统环境中检查模型状态，分别覆盖模型未就绪、设备不符合条件和服务不可用的界面。
- [ ] 验证弱网与无网：模拟请求中断、超时和用户取消，确认重试不会重复执行有副作用的操作，也不会悄悄丢失用户输入。
- [ ] 比较真实输出：准备代表性输入，检查格式正确性、事实错误、拒答或安全边界；分别记录不同模型路径的结果，而不是只记录接口是否成功。
- [ ] 核实服务端约定：对自选模型确认认证、密钥存放、数据保留、限流和计费说明；不要把 Apple 对 PCC 的承诺转述为第三方保证。
- [ ] 复核发布工具链：在当前 macOS 与 Xcode 组合下完成项目构建、测试与归档，并查对 Apple 的 Xcode 系统要求表；具体支持关系以该表和项目实际目标平台为准。
- [ ] 留存验收范围：记录测试使用的系统版本、模型实现、提示词和失败回退结果；环境变化后重新验证，不把一次测试外推到所有用户。
Foundation Models framework 的本地调用、PCC 与自选提供方最终都要落到真实项目的构建和发布验证；远程环境是否适合，仍应按团队的工具链、交互方式和项目要求判断。团队如果还在评估远程开发环境，可先查看 NodeMini 的远程 Mac 环境介绍，核对它是否适合项目的构建与测试流程。
自购 Mac 适合需要长期稳定使用、需要本地物理接口或希望一次投入后持续控制硬件的团队；远程 Mac 则要考虑网络质量、远程桌面交互和租期成本，不能替代所有本地工作。如果只是临时集成、测试或需要独立构建环境，可以通过 NodeMini 的远程 Mac 算力方案说明核对环境是否符合项目要求；无需长期占用构建机时，租用可能比专门购置一台 Mac 更灵活。