用同一套 Swift API 呼叫任何 LLM
這支 43 秒短片濃縮 WWDC26 Foundation Models 的一個大方向：Apple 想讓 app 用同一個模型抽象層，切換 on-device、Private Cloud Compute、Core AI、MLX、第三方與開源模型。
Foundation Models 的重點不只是多一個模型入口，而是把「模型選擇」從 app 業務邏輯裡抽離成共同協定：只要模型符合 LanguageModel protocol，就能放進同一個 session 工作流。
短片背後其實是三層架構變化
模型被收斂成共同介面
官方完整 session 說明每個 model 都遵守 LanguageModel protocol；app 端不再為每個 provider 重寫一套呼叫邏輯。
同一段 app code 可切不同執行位置
小模型可留在裝置上，雲端能力可走 Private Cloud Compute，既有自有模型也能透過 Core AI 或其他 provider package 接進來。
第三方與開源模型變成 Swift package 問題
模型供應商可建立自己的 Language Model package；Apple 也提到 Anthropic 與 Google 將提供 Claude、Gemini 相關整合。
使用者體驗由模型能力組合決定
開發者可以先用低摩擦模型驗證功能，再依隱私、成本、延遲、上下文長度與品質需求替換模型。
導入時先回答這四個問題
這個功能能不能完全 on-device？
若資料敏感、互動短、品質需求可控，先用 System Language Model 或自有 Core AI 模型；這能降低隱私與網路依賴。
何時需要 frontier model？
複雜推理、長上下文、跨資料整合或更高品質輸出，才考慮 Private Cloud Compute、第三方 provider 或開源大型模型。
模型替換是否會改變產品承諾？
同一 API 不代表同一品質。要測 prompt adherence、structured output、tool calling、latency、錯誤型態與 fallback 訊息。
provider package 要如何治理？
如果團隊允許第三方或開源模型，版本、授權、資料處理、成本上限與 incident fallback 都要進 release checklist。
它解決的開發者問題
AI app 最難維護的地方，常不是呼叫某個模型一次，而是每次更換模型時都要重寫初始化、session、輸入輸出、streaming、tool use、錯誤處理與測試。Foundation Models framework 在 WWDC26 的方向，是把模型變成可替換的能力來源。
這支短片只有 43 秒，沒有完整章節。頁面整理採用 YouTube 描述、Apple 官方完整 session「Bring an LLM provider to the Foundation Models framework」與「Platforms State of the Union」補足脈絡。
實務啟發
如果你的 app 正在規劃 AI 功能，不要一開始就把特定 provider 寫死在 feature code 裡。先把「模型選擇」包在一層 app 自己可控的 policy：隱私敏感走 on-device；高品質輸出走 PCC 或第三方；離線模式提供 degraded experience；每個路徑都用 Evaluations 驗證。
同一套 Swift API 的價值，在於讓產品可以逐步調整模型策略，而不是每次 provider、價格或系統能力變動就大改 app 架構。
風險與遷移注意事項
API 抽象會降低接入成本，但不會自動消除模型差異。不同模型對 schema、工具、中文、長上下文與安全拒答的行為都可能不同。導入時要建立 evaluation set，測同一 prompt 在不同 runtime / provider 下的品質與延遲。
若採用第三方 provider package，也要確認資料是否離開裝置、是否進入供應商服務、使用者是否需要明確同意，以及 fallback 時 UI 是否能清楚說明能力降級。
來源
YouTube：Use any LLM through one Swift API。官方完整脈絡：Bring an LLM provider to the Foundation Models framework、Platforms State of the Union、What’s new in the Foundation Models framework。
- 01Foundation Models 正把不同模型來源包成共同 Swift API，而不是只推單一模型。
- 02架構上要把模型選擇做成 policy，依隱私、成本、延遲與品質切換。
- 03真正的導入風險在 evaluation、fallback、provider governance 與使用者資料邊界。