在 Private Cloud Compute 上執行的 Foundation Models

裝置端的 Foundation Model 多了一個兄弟。iOS 27 為框架帶來一個在 Private Cloud Compute 上執行的伺服器規模模型，具備 32K 的上下文視窗與推理能力，而您只要改一行程式碼就能用上它¹。同樣的 LanguageModelSession、同樣的 Generable、同樣的 Tool 協定⁴。更大的一步藏在底層：Apple 透過一套公開協定，將框架開放給幾乎任何 LLM，於是裝置端模型、雲端模型、您自己隨 app 一起發布的本地模型、來自 Hugging Face 的開源模型，以及即將登場的 Claude 與 Gemini，全都回應同一套 Swift API²。您不再針對某個模型寫程式，而是針對一個可以替換的插槽寫程式。

本文是建立在框架參考之上的雲端與供應商層。如果您還沒接觸過 LanguageModelSession、Tool 協定或引導式生成，請先閱讀 Foundation Models 框架解說與 iOS 27 工具呼叫一文，再回到這裡。

重點摘要

• Private Cloud Compute 為 Foundation Models 框架帶來一個更大的伺服器模型，只要從裝置端模型改一行程式碼即可切換。相較裝置端的 4K，它提供 32K 的上下文視窗，支援三種層級的推理，並可在 iOS、macOS、visionOS 與 watchOS 上執行¹²。
• 隱私態勢與系統模型一致：Apple 設計 PCC 時就確保使用者資料絕不儲存、且僅用於該次請求，並經研究人員獨立驗證；對開發者而言沒有 API 金鑰、無需設定帳號、也沒有 token 費用¹。
• 每位使用者都有每日請求上限，計入其 iCloud 帳號，並可透過 iCloud+ 提升。請在 UI 中查詢模型的配額狀態來處理上限，並顯示一個持續存在、可操作的控制項，而非用警示視窗。請至開發者網站申請存取權；適用於下載量低於 200 萬的 app¹。
• 全新的 LanguageModel 協定讓每個模型都能即插即用：System、PCC、在 ANE 上執行本地模型的 Core AI、為 Hugging Face 社群提供的 MLX，以及即將到來、來自 Anthropic 與 Google 的供應商套件²。
• DynamicProfile 讓單一工作階段在對話進行中於這些模型之間切換，因此腦力激盪的回合可以用高 temperature 的 PCC，而審閱的回合則可降至裝置端模型以節省伺服器呼叫³。

更大的模型，同樣的三行程式碼

去年的賣點是：對裝置端模型下提示只要三行程式碼——建立工作階段、呼叫 respond、讀取答案¹。今年這個賣點延伸到了雲端。無論您與哪個模型對話，框架都提供一套統一的 Swift API，因此從裝置端的 System 模型切換到 PCC 模型，只會改變您建構的模型，其餘一概不變¹。透過 Generable 的結構化輸出與工具呼叫，在兩者上的行為完全相同¹。

Louis 在議程 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 時設定該層級¹。

推理並非免費。推理區段是模型生成的文字，因此會消耗 token，並計入 32K 的上下文預算¹。工作階段對此所要求的紀律毫不含糊：在裝置端與 PCC 之間抉擇、以及挑選推理層級，都要依據資料而非感覺¹。Apple 為此在 Xcode 中推出了全新的 Evaluations 框架，正是因為裝置端模型在許多任務上的表現比您預期的更好，而唯一能確認的方法就是實測¹。

隱私態勢才是頭條

一個處理使用者私密輸入的伺服器模型，通常正是隱私故事崩解之處。PCC 的打造方式讓它不致如此。Apple 在設計 Private Cloud Compute 時就把端對端隱私放在心上，確保使用者資料絕不儲存、且僅用於該次請求，研究人員也已獨立驗證了這項設計¹。PCC 早已為 Apple Intelligence 自身的複雜任務提供動力；框架將同一套基礎設施開放給您的 app¹。

操作面的後果才是開發者真正感受到的部分。PCC 與 iCloud 一同整合進作業系統，因此沒有驗證要接、沒有 API 金鑰要輪替、也不必要求使用者設定帳號¹。使用者只需要一台支援 Apple Intelligence 的裝置，別無其他。對身為開發者的您而言沒有 token 費用；每位使用者都有每日上限，使用者可透過 iCloud+ 提高¹。此模型適用於下載量低於 200 萬的 app，您可至開發者網站申請¹。

議程 319 談隱私保證：無需設定帳號、無驗證、無 API 金鑰，對開發者也沒有 token 費用，且每位使用者的請求都計入其 iCloud 帳號。

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

就在 WWDC 揭幕的同一週，Apple 發表了一篇安全性文章，改變了 PCC 的執行地點。PCC 現在延伸至 Google Cloud 上的 NVIDIA GPU，以承載新的 Apple Intelligence 工作負載，「首次將我們業界領先的 PCC 隱私承諾擴及第三方資料中心」⁵。您所對應的框架不變，底下的基礎設施則改變了。

Apple 讓這份契約維持一致。五項核心要求一字不改地保留：「無狀態運算、可強制執行的保證、無特權執行階段存取、不可鎖定性，以及可驗證的透明度」⁵。改變的是實作，Apple 將其命名為「搭配 NVIDIA GPU 的 NVIDIA Confidential Computing、採用 TDX 的 Intel CPU，以及 Google 的 Titan 晶片」⁵。Apple 以兩種開發者應留意的方式，將這個基礎強化到超越標準的機密運算部署。它維護「一份可加密驗證、僅可附加的帳本，記錄屬於 PCC 機群的所有 Google Cloud 硬體」，而對於可能外洩使用者資料的元件,「軟體證明扎根於至少來自獨立供應商的兩個分開的信任根」⁵。

對隱私態勢而言最關鍵的一句話與控制權有關。Apple 表示「Apple 對 PCC 軟體保有完整控制權；Apple 裝置只會信任經 Apple 加密核准的 PCC 軟體」⁵。對研究人員的驗證機制也一併延續：Apple 表示將公布所有二進位檔供公眾檢視，並透過 Apple Security Bounty Program 提供以研究模式存取線上 PCC 節點的權限⁵。推出採分階段進行,「在整個夏季預覽期間逐步邁向完整的保護組合」，因此您針對 PCC 發布的功能，在預覽期間所繼承的是一組不斷變動的保證，而非最終版本⁵。

對本文程式碼的啟示是：上述隱私主張對 PCC 模型成立，無論它是從 Apple silicon 還是從 Google Cloud 作答，因為 Apple 維持同樣的五項要求與同樣的裝置端信任閘門。在第三方模型無法跟進之處，PCC 也是 Apple 的第一方答案，這與同一週 Apple 對提示注入的第一方答案相互呼應。

實驗室筆記：PCC 的保證止於框架邊界

WWDC 實驗室直言不諱的一點值得緊接著那項擴張一併提出，因為它畫出了行銷不會畫的那條界線。PCC 的保證——無狀態運算、不可鎖定性與暫時性儲存——並不延伸到您透過框架語言模型協定接入的第三方模型，例如 Gemini 或 Claude。當您的工作階段路由到某個供應商套件，而非 System 或 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 重新打造了裝置端的 System 模型，又新增三個第一方選項，接著為其他所有人敞開大門。PCC 帶來具備推理與 32K 上下文的伺服器模型。Core AI 在 Apple Neural Engine 上高效執行本地模型。MLX 則透過 model ID 解鎖了 Hugging Face 上 MLX 社群的數千個模型²。而由於這一切都建立在一套全新的公開協定之上，前沿供應商可以推出自己的 Swift 套件；Apple 點名 Anthropic 與 Google，透過同一套框架將 Claude 與 Gemini 帶給 Swift 開發者²。

Christopher Webb 在議程 339 中表示：除了系統模型之外，框架還新增了 PCC、Core AI 與 MLX，而一套公開協定讓 Anthropic 與 Google 這類供應商能用自己的 Swift 套件加以擴充。

這套協定有兩個部分，而這個切分正是整個設計的精髓。LanguageModel 向框架描述模型：它宣告能力並交回一份組態。LanguageModelExecutor 才是工作所在之處，它有一個接收該組態的初始化器、一個用於在首次請求前載入權重或開啟連線的 prewarm，以及一個將生成串流回工作階段的 respond²。組態是兩者之間的連結，也是查找鍵。每個工作階段都持有一個 executor 儲存區；當某個模型產生了儲存區未曾見過的組態時，框架便建立一個 executor 並加以快取，而工作階段將該組態描述為 Hashable，因此具有相同組態的第二個模型會解析到同一個 executor²。正是這種快取，讓有狀態的整合能跨呼叫保留一份 KV 快取或一個持續連線，而不必重做工作²。

對模型供應商而言，executor 的職責是轉譯。框架交給它一份記錄稿——一段帶有型別的項目序列——而 executor 把這些項目對應到自家推理引擎所說的任何角色上²。Apple 定義了六種項目型別：instructions、prompts、tool calls、tool outputs、responses 與 reasoning²。一個只有 system、user 與 assistant 角色的模型，會把 tool calls 與 reasoning 對應到 assistant；一個有專屬 tool 角色的模型則改路由到那裡²。每個請求還用兩個屬性袋承載開發者的意圖：ContextOptions 負責進入提示的內容，例如推理層級或回應結構描述；GenerationOptions 負責解碼器迴圈，例如取樣、temperature 與長度²。在輸出端，executor 在一條通道上串流事件，先送出中繼資料更新（模型與請求 ID）與用量更新（提示的 token 數），再送出文字增量，讓開發者無需等待整段串流就能得知一個請求的成本²。

即使 app 開發者永遠不會撰寫供應商,錯誤處理的故事對他們仍然重要。Foundation Models 提供 LanguageModelError，涵蓋每個模型都會遇到的情況：上下文視窗溢位、速率限制、拒絕回應等等²。供應商在情況吻合時應擲出其中一種，因為任何框架使用者都已懂得如何捕捉它，而把自訂錯誤型別保留給只有自家服務才會產生的失敗，例如訂閱層級或帳號狀態²。供應商也有空間透過自訂回應中繼資料（每秒 token 數、首個 token 時間）以及將協定擴充至音訊或視訊等新模態的自訂區段型別來做出區隔，這一切全都流經同一個工作階段²。雲端供應商則收到一則明確的憑證提醒：不要把 API 金鑰當成純字串接收；請提供一個 token 供應器或登入流程，將 token 保存在 Keychain 中，並搭配透過 App Attest 進行的裝置證明²。

代理式意涵：在單一工作階段內路由模型

當您不再以「每個 app 一個模型」的方式思考，而開始以「每個任務一個模型」的方式思考時，供應商協定與 PCC 才會展現價值。這正是 DynamicProfile 所實現的。它讓單一 LanguageModelSession 在對話進行中切換模型，為眼前的任務挑選最佳組態³。

Erik 與 Oliver 在議程 242 中示範：一個手作 app 宣告多個如同代理般運作的 profile——以高 temperature 在 PCC 上腦力激盪、以深度推理進行規劃、並在裝置端模型上進行審閱以節省伺服器呼叫。

工作階段的範例是一個分三階段的手作 app。腦力激盪需要廣博的知識與創意，因此它的 profile 使用 PrivateCloudComputeLanguageModel，並將 temperature 設為 1³。規劃需要深度，因此它停留在 PCC，並將 reasoningLevel 設為 deep³。審閱是使用者作業過程中的例行指引，因此它降至 SystemLanguageModel 以省去不必要的伺服器呼叫，這同時也把使用者的每日 PCC 配額留給真正需要的工作³。DynamicProfile 的主體會在每次提示時重新評估，因此隨著 app 切換模式，工作階段也跟著切換角色：換帽子，或者說換代理³。

在上下文大小不同的模型之間路由，迫使您採取一種純裝置端框架從不曾要求的紀律。從 PCC 的 32K 移到裝置端的 4K，可能需要裁減項目以符合容量，而工作階段也點出一項隱私用途：在移至隱私性較低的模型時，從既有項目中遮蔽私密資訊³。框架的 historyTransform 會在提示前套用一個本地、非破壞性的轉換，因此您可以為某個模型裁減內容，又不致失去下一回合可能需要的脈絡³。變動是有代價的：附加到記錄稿可保留 KV 快取並將首個 token 時間降到最低，而改寫歷史（移除項目、更換工具、更新指示）通常會使快取失效並增加延遲³。去年工作階段 API 為了保證那項最佳化而只能附加；今年 Apple 把輔助輪拆了，而得知某個模型快取行為的唯一方法，就是用 Xcode 中的 Foundation Models Instrument 實測³。

抉擇：裝置端、PCC，還是您自己的供應商

這三個選項並非一道階梯。每一個都適合不同形貌的問題。

先伸手拿裝置端的 System 模型。 它免費、可離線運作、沒有請求上限，而 iOS 27 的重建讓它更擅長遵循指示，並新增了圖片輸入²。它 4K 的上下文才是真正的天花板¹。在假設您需要更多之前先評估，因為工作階段已警告您會對它的表現之佳感到驚訝¹。

當任務超出裝置端模型、且資料敏感時，伸手拿 Private Cloud Compute。 需要 32K 視窗的長文件、多步推理，或會帶來龐大輸出的大量工具呼叫¹。PCC 是唯一一個維持 Apple 隱私態勢的雲端選項——無金鑰、無帳號、無 token 費用，代價是一個您要圍繞著設計的每位使用者每日上限¹。當您原本得自行架設伺服器模型、又對隱私審查心生畏懼時，就選它。

當您需要平台不提供的特定模型時，伸手拿您自己的供應商。 用 Core AI 來執行您自行打包並在 ANE 上跑的本地模型、用 MLX 以 ID 取得開源模型，或用供應商套件（Claude、Gemini）取得前沿模型²。您要扛起憑證處理、證明與隱私揭露，換來的是一個藏在您 app 早已熟悉的同一個 LanguageModelSession 之後的具名模型²。工作階段明白指出，裝置端與雲端模型的隱私特性截然不同，而使用者理應知道是哪一個在作答²。

當各階段有別時，在單一工作階段內混用它們。 這就是 DynamicProfile 的情境：以 PCC 應付吃重的創意或推理回合、以裝置端模型應付例行回合，每個 profile 各自帶著自己的模型、temperature 與推理層級³。

常見問答

我要如何從裝置端模型切換到 Private Cloud Compute？

更改您傳給 LanguageModelSession 的模型。框架跨模型提供一套統一的 Swift API，因此從裝置端的 System 模型移到 PrivateCloudComputeLanguageModel 只是一行程式碼的改動，而您的提示、Generable 輸出與工具運作方式都相同¹。PCC 只能在支援 Apple Intelligence 的裝置上執行，所以請保留您的可用性檢查¹。

Private Cloud Compute 和裝置端模型一樣私密嗎？

Apple 設計 PCC 時就確保使用者資料絕不儲存、且僅用於該次請求，這項設計也已由研究人員獨立驗證¹。它與 iCloud 一同整合進作業系統，因此沒有 API 金鑰、無需設定帳號、也沒有驗證要您管理¹。在離線運作與無限請求上，裝置端仍勝出；在上下文大小與推理上，則是 PCC 勝出¹。

PCC 的費用是多少，每日上限又是多少？

對身為開發者的您而言沒有 token 費用¹。每位使用者都有計入其 iCloud 帳號的每日請求上限，使用者可透過 iCloud+ 升級以取得更高上限¹。請在 UI 中查詢模型的配額狀態（isLimitReached、belowLimit）並顯示一個持續存在、可操作的升級控制項，而非用警示視窗來處理上限¹。此模型適用於下載量低於 200 萬的 app，您可至開發者網站申請¹。

「自帶 LLM 供應商」實際上是什麼意思？

Apple 新增了一套公開的 LanguageModel 協定，因此任何模型都能接入 Foundation Models 框架，並透過與 Apple 自家模型相同的 API 被呼叫²。除了 System 模型與 PCC 之外，框架還新增了在 ANE 上執行本地模型的 Core AI，以及用於 Hugging Face 社群模型的 MLX，而 Apple 也點名 Anthropic 與 Google 將推出 Claude 與 Gemini 的 Swift 套件²。供應商需實作 LanguageModel，外加一個將框架的記錄稿轉譯成自家格式、並把生成串流回來的 LanguageModelExecutor²。

一個工作階段可以使用一個以上的模型嗎？

可以。DynamicProfile 讓單一 LanguageModelSession 在對話進行中切換模型，為每個任務選擇最佳組態³。一個 profile 帶著自己的模型、指示、temperature 與推理層級，而 profile 主體會在每次提示時重新評估，因此一個工作階段可以在同一段對話中於 PCC 上腦力激盪、並在裝置端模型上審閱³。這麼做時，請留意模型之間的上下文大小落差，以及改寫歷史所帶來的 KV 快取成本³。

完整的 Apple Ecosystem 系列：Foundation Models 框架解說；iOS 27 工具呼叫控制；代理式工作流程的區別；以及裝置端 LLM。系列中樞是 Apple Ecosystem 系列。若想了解更廣泛的 iOS 與 AI 代理脈絡，請參閱 iOS 代理開發指南。